@jtgrasb Thank you for making this change to the userDefinedWaveElevation function and this will resolve the calculation so as not to try and convolute with a NaN. I have no issue with the few lines of code you have changed.

However, prior to approval I can across the similar situation within the ramp function in the Wave Diffraction and Excitation Force Calculation block, where we still have the ramp function implemented during each run, see screenshots below. As you can see with a simu.rampTime=0 we are still dividing by zero so the output from the Ramp function block is still going to be NaN. I checked this by exporting to the rampFunction_out.mat and can confirm what is coming out of R is NaN. I believe there is no issue since the switch block never sends True through so a 1 is sent as the False statement.

Therefore, my comment here is more general as the current implementation does not seem to be impacted and we can merge and move forward. I am wondering if we should also try to implement another switch or if statement within Ramp function to output a different value than NaN to prevent potential future issues.

I am happy to approve and merge as you have, but this additional note may be helpful for documentation.

@nathanmtom Thanks for pointing this out -- I hadn't thought to look into how the rampTime is used in Simulink. I just looked at the implementation, and like you said, R is a vector of all NaN's. The switching statement is actually always true though (rampTime<current time), which means that R is passed through the switch, but interestingly the output is all zeros. I wasn't able to find much on why this is, but it seems that some Simulink blocks map NaN to zero for some reason. Anyway, it seems to me that the switch block fixes the issue of NaN's within Simulink.

@jtgrasb In reviewing Issue #926 I've realized that the NaN issue with simu.rampTime=0 will also influence the Morison Element calculation, see image below. If possible, can you also review all of the Morison Element functions to include the same check you implemented for the user defined waves input already made within this PR. We should try to address all other cases of the ramp time issue with a single PR.

@nathanmtom After exploring the issue further, I realized I went about the problem in the wrong way. In the waveClass where the rampFunction is calculated, it is replaced with a 1 for any time greater than the specified rampTime. By changing this to greater than or equal to, it will then replace the rampFunction with a 1 for all times when rampTime is equal to zero. I have changed this for the reg, irreg, and user wave elevation calculation. To summarize the process (when rampTime=0), the rampFunction is calculated as Nan's due to dividing by zero, but then immediately replaced by all ones.

Similarly, for the Morison Element calculation, I updated the 3 Morison functions so that the ramp and curramp variables are only calculated when Time<rampTime. Since the current time is never less than zero, this calculation never occurs and there is no issue with Nan's.

Lastly, in the Excitation Force calculation, it doesn't make sense to me to put an extra switching block. The current switching block already avoids the issue, and I feel like adding another switch adds unnecessary complication.

Let me know if you have any thoughts/concerns on this.

--Jeff

Thanks @jtgrasb I agree that your latest changes are the simplest implementation.

I am also fine with not updating the working blocks within the body block for the wave excitation force ramp implementation. We are already implementing the 'less than' logic statement which is the same as the implementation that you have used to update the .m files.

I have no other requests and barring no further comments or requests from the larger WEC-Sim team will plan to merge at the next group meeting.

Thanks @jtgrasb for your help in solving this issue. Per the discussion this morning during the development meeting I am going to go ahead and merge this PR to fix the identified bug. If you can follow-up by putting on the project board a note to investigate how the ramp function can be converted to a function rather than Simulink blocks that would be great.