Based on @dav-og suggestion, consider including passive yaw as use case and deprecating the current passive yaw implementation

One follow-up on passive yaw-- A feature that passive yaw has that is not currently planned here is interpolation between data points. Passive yaw (I believe) will interpolate between directions if past the threshold. We were not planning that here since right now the user-defined switching parameter is not a dimension of each hydroForce array. That may be possible, but the implementation will definitely be more complicated. We were planning to force the user to include as much state discretization as is required ahead of time.

Thats correct, passive yaw interpolates hydrodynamic coefficients between headings - for a user-defined threshold. The results can change a lot depending on this threshold - but if you set it very low then the computation time explodes. User has to evaluate this speed-accuracy trade off.

For passive yaw, the hydrostatic stiffness matrix is rotated with the body in WEC-Sim

FYI I've been reading briefly on methods to accomplish this hydrodynamics variation. This post and this older post both describe pathways and limitations of how we can implement this feature with minimal changes.

The possible methods seems to be the following. Based on my initial research, I suggest the following order of preference based on what I've read:

• Load the entire list of structures contained in body.hydroForce into the simulation. Then we may be able to treat it as a bus signal, then index and pull out the relevant signal based on the user defined hydroForceIndex
• Use parameter writer to change the value of the constant blocks loading
• Make the force coefficients a signal instead of a constant. This seems overkill and complicated since we only want to select the index of the hydroForce struct, not control the data within each hydroForce struct during simulation

I made some nice progress on this PR lately by turning the body.hydroForce structure into a bus signal. All data nested within body.hydroForce can be loaded once as a constant in the simulation. The data to use at a given time can be indexed using a signal defined by the user. Some progress left to go, but this is a big step in moving this PR forward.

test_v2.zip

Going the library I noticed that regular wave excitation (both with and without passive yaw ) does not handle directional spreading and probably should. It only takes the first directional component of the excitation force.

Excitingly, I got this feature working for a basic case now! I temporarily edited the RM3 example model and input files to run when importing the a set of 3 h5files into the same body. There a few more complex cases to test/implement next which I added to the TODO list above.

Comment from @MShabara - we may want to reference the buffered fourier spectral method to address unstable switching in this feature

Recording a few recent updates:

Right now the implementation mostly works but has a couple odd edge cases that should work but don't. I'm working through fixes for these edge cases.

Working scenarios:

• all bodies use variable hydro (``body.variableHydro.option=1) and each has multiple h5Files.
• no bodies use variable hydro

Breaking scenarios:

• some but not all bodies use variable hydro
• a body with variable hydro has only one h5 file

Summarizing a discussion that @salhus and I had on this feature:

An important but currently missing aspect of this PR is how to treat the CG, mass, and inertia if a body state changes. E.g if a device is flooded, its cg, mass, and inertia all change. Simscape may allow a time-varying inertia tensor through the general variable mass block

@akeeste the merge conflicts are resolved, but do you know why the tests are failing?

@akeeste the merge conflicts are resolved, but do you know why the tests are failing?

@akeeste the tests are throwing a warning when the Simulink files are copied, and the MATLAB version doesn't match. This happens in C:\Users\kmruehl\Documents\GitHub\WEC-Sim\WEC-Sim\tests\runFromSimTest.m lines 34-37

            copyfile(fullfile(testCase.wsDir,'/examples/RM3FromSimulink/RM3FromSimulink.slx'),...
                fullfile(testCase.runFromSimDir,'fromSimInput.slx'));
            copyfile(fullfile(testCase.wsDir,'/examples/RM3FromSimulink/RM3FromSimulink.slx'),...
                fullfile(testCase.runFromSimDir,'fromSimCustom.slx'));   

However, the error is due the following:

    ---------
    Error ID:
    ---------
    'MATLAB:num2str:nonNumericInput'
    --------------
    Error Details:
    --------------
    Error using num2str (line 24)
    Input to num2str must be numeric.
    
    Error in writeBlocksFromInput (line 160)
            values{i,1} = num2str(maskVars.(names{i,1}));
    
    Error in loadInputFileCallback (line 40)
                writeBlocksFromInput(blockHandle,type,inputFilePath);
    
    Error in runFromSimTest/setupInputFiles (line 81)
                        loadInputFileCallback(grfBlockHandle);

maskVars.(names{i,1}) is not numeric

@kmruehl I saw these tests failures yesterday. In short, no I don't yet know why. I did not touch any WEC-Sim GUI or Run From Simulink functionality. I'm guessing there was a problem coming from library changes in main that were pulled into dev, and then into my branch

@kmruehl The WEC-Sim GUI issue should be resolved pending the test completion. I thought the bug was coming from a library merge that I messed up because a non-variable hydro case was failing. But the issue was on my development efforts--related to body.h5File becoming a cell which is not allowed in a mask

@akeeste thanks for the update, looks like all tests are passing now. Thanks!