Update to MoorDyn v2 #1134
Update to MoorDyn v2 #1134
Conversation
|
Corresponds with WEC-Sim Applications PR 45 and WEC-Sim/MoorDyn PR 1. |
There was a problem hiding this comment.
@jtgrasb @RyanDavies19 Thanks for your work. It's great to see updates for MoorDyn in WEC-Sim! After installing MinGW and adding WEC-Sim/MoorDyn to the source, the applications case runs to completion.
A few requested changes:
- Update responseClass.m line 347 to account for new output file naming
- I received several messages that "No moorDyn *.out file saved for Line1", etc (These should probably be warnings). However there are output files located in
CASE/Mooring/with nameslines_Line1.out, etc. It looks like the name of the MoorDyn input file is being appended to all output files. We should account for this. The case still runs when the responseClass is updated
- I received several messages that "No moorDyn *.out file saved for Line1", etc (These should probably be warnings). However there are output files located in
- Update the variable name of
moorDyn_infileto WEC-Sim's camelCase convention. I suggestmoorDynInputFile - Please briefly note here what changes were made to the Mooring library for our future reference. It appears changes are primarily in the
Properties/CallbacksofWECSim_Lib_Moorings/MoorDyn/MoorDyn/MoorDyn. Anything else of note?
A couple other non-critical comments for future work:
- Where in the MoorDyn repo do the files in
WEC-Sim/MoorDyncome from? As an alternative to copying files to WEC-Sim/MoorDyn and then to the WEC-Sim source, could users point straight to a local MoorDyn clone? - We should add that information to the developer manual
|
Thanks for the review @akeeste. I updated accordingly and plan to add more documentation on recreating library files for future moordyn updates soon. The updates to the mooring library are only in the |
|
@jtgrasb thanks for making those adjustments. @akeeste The files in WEC-Sim/MoorDyn are compiled libraries of MoorDyn, so they don't exist until a user builds them. Our thought is providing the precompiled libraries would limit confusion from the user end because they wouldn't have to fight with compilers and whatnot. What could be added to the docs is instructions and/or a link to the MoorDyn documentation that explains to users how to compile MoorDyn if they want to use an external copy (with custom edits, new version, etc.). |
| lookupTableFlag = 0; % (`integer`) Flag to indicate a mooring look-up table, 0 or 1. Default = ``0`` | ||
| lookupTableFile = ''; % (`string`) Mooring look-up table file name. Default = ``''``; | ||
| end | ||
|
|
||
| properties (SetAccess = 'private', GetAccess = 'public') %internal | ||
| libname (1,:) {mustBeText} = 'libmoordyn' % (`string`) Name of the mooring. Default = ``'NOT DEFINED'`` |
There was a problem hiding this comment.
I don't see this variable used anywhere else. Can we remove it?
I ran a simulation with this commented out and it works fine.
|
Thanks @jtgrasb @RyanDavies19 for the updates and comments. I missed one thing in my review on |
|
@akeeste you can remove that libname variable. That was left over from a different approach we were trying, I forgot to remove it. |
|
@RyanDavies19 sounds good. I'll merge this PR and fix it on dev |
This updated the coupling of WECSim and MoorDyn to MoorDyn-C v2 using the MoorDyn v1 API. Additional updates to the MoorDyn libraries and input files will be added separately.
The only new feature added is the ability to specify the path and file name of the MoorDyn input file. This will be the same path where outputs are written. The figures below show that this update performs as well as the MoorDyn v1 coupling. This update opens the door to future utilization of the MoorDyn v2 features.