Wave visualization as a post-processing function

[jtgrasb]

I created a function in the response class which creates a visualization of the waves and body reactions and saves it as either a video file or gif. I've attached examples below of the RM3 with regular waves and the OSWEC with irregular, directional waves.

The function can be run by adding "output.plotWaves(simu.dt,1,simu.g,[-100 100 -100 100 -40 15],body,waves,1);" to the userDefinedFunctions.

[akeeste]

See inline comments for suggested changes. I think this works well but there are a few changes that can make it more robust and easier to read. Also, I would consider including a colored plane for the seafloor and force the axes to have the same aspect ratio (see daspect([]) or axis equal commands). If not, then the device can appear stretched depending on the domain size input

[jtgrasb]

@akeeste Thanks for the suggestions! I made the requested changes and I think it is a lot simpler and easier to read now. One small issue I ran into is that because I used simu.domainSize/2 for the axes, the seafloor is not on the figure for the RM3 because it's at -200 m. Should I just make the axes go to the full simu.domainSize?

[akeeste]

@jtgrasb For the lower z-axis limit, you could instead use -waves.waterDepth. This is the parameter that currently determines the depth shown in the Mechanics Explorer.

The upper z-axis limit doesn't need to be very high. A couple thoughts:

• Easy solution - choose something relatively arbitrary (15m? 20m?) and let users optionally input the z-limits to overwrite the default value.
• Alternative - use the maximum z position of the bodies and calculate the highest point that any mesh reaches. The maximum z-axis could then be that point + ~5m.

It might be worthwhile letting users override the default limits regardless of method chosen.

[jtgrasb]

@akeeste I like the idea of having options instead of needing to specify some of the inputs. I made the default z maximum 10 and allow the user to input the axis limits, timesPerFrame, and saveSetting as optional inputs.

[akeeste]

@jtgrasb Great work! I made a few more minor changes:

• use options.axisLimits for X,Y grids
• allow different simu.dtOut and simu.dt
• Change default z axis maximum to -999. By default this is overwritten with the maxHeight of the body if the user does not input another option
• move time annotation to the 2nd title line so that it cannot lie on top of the title box (this happened to me depending on the figure size upon opening)

I wasn't sure if you will have time to review before your semester starts so I went ahead and committed directly to your branch. Let me know if you disagree with anything

Adam

[akeeste]

@kmruehl @jtgrasb My only other concern is that this function will not work with the variable step solver. However this relates to a larger problem of how we use simu.maxIt to calculate the waves.waveAmpTime before the simulation, instead of using the actual simulation sample time or the output sample time. I am okay merging this PR in and addressing the variable step solver problems later on when I solve issue #656

[kmruehl]

@akeeste I like the idea of having options instead of needing to specify some of the inputs. I made the default z maximum 10 and allow the user to input the axis limits, timesPerFrame, and saveSetting as optional inputs.

@jtgrasb another option would be to make it a multiplier of waves.H, so it could be 4*waves.H by default (or similar).

[kmruehl]

@kmruehl @jtgrasb My only other concern is that this function will not work with the variable step solver. However this relates to a larger problem of how we use simu.maxIt to calculate the waves.waveAmpTime before the simulation, instead of using the actual simulation sample time or the output sample time. I am okay merging this PR in and addressing the variable step solver problems later on when I solve issue #656

@akeeste that sounds good to me. I think we should go ahead and merge it and then open an issue or project card related to the variable time-step issue with this feature.

[kmruehl]

@jtgrasb and @akeeste I made some minor revisions in this PR, feel free to merge or resolve them elsewhere: jtgrasb#1

• added output.plotWaves to examples, we could comment this but provide it as an example
• resolved issues with examples files to use the wecSimInputFile instead of custom parameters

To Do

• add documentation

[kmruehl]

Please add documentation!

[akeeste]

Please add documentation!

@kmruehl Where are you thinking to add this? I don't see anything in the documentation about plotForces() or plotReponse() outside of the autogenerated API. Maybe we should start an advanced features section on the response class?

[kmruehl]

@akeeste I think that's a good suggestion. The only reason we don't have docs for functions it because they were merged prior to our enforcement of the docs requirement. So if you'd like to add docs for them too... :)

[kmruehl]

This looks good, I'll add a the lines to the examples, and we should be good to go.