MoorDyn DLLs crashing MATLAB on GitHub actions

[jtgrasb]

For WEC-Sim, we are using MoorDyn dynamic link libraries to call MoorDyn and return the results to the WEC-Sim simulation. The dynamic link libraries are built using cmake via GitHub actions and build with no issues. We have this running well locally, but the MoorDyn DLLs seem to cause GitHub actions to fail by crashing MATLAB. See the latest test on our dev branch of WEC-Sim Applications. If I rerun this a few times, it will pass, but it is still frustrating to have to rerun it all the time.

I think the MATLAB crash may be caused by a window that MoorDyn tries to open. In MATLAB locally, the window shows up like below, but I think it may be trying to display some sort of graphic? While running the simulation locally does not crash MATLAB, closing this window does crash MATLAB. Do you know what may be causing this window to be opened? And if so, is there a way to disable it?

--Thanks,
Jeff

[sanguinariojoe]

From what I can see here: https://github.com/WEC-Sim/MoorDyn/blob/main/MoorDyn.h You are still using the MoorDyn v1 API, which is definitely opening a CMD to left the log there: https://github.com/FloatingArrayDesign/MoorDyn/blob/master/source/MoorDyn.cpp#L88 I think MoorDyn 2 does not open such a CMD, but Ryan can probably confirm

…

On Thu, 18 Sept 2025, 00:18 jtgrasb, ***@***.***> wrote: *jtgrasb* created an issue (FloatingArrayDesign/MoorDyn#327) <#327> For WEC-Sim, we are using MoorDyn dynamic link libraries to call MoorDyn and return the results to the WEC-Sim simulation. The dynamic link libraries are built using cmake via GitHub actions <https://github.com/jtgrasb/MoorDyn/blob/main/.github/workflows/compileLibraries.yml> and build with no issues. We have this running well locally, but the MoorDyn DLLs seem to cause GitHub actions to fail by crashing MATLAB. See the latest test on our dev branch of WEC-Sim Applications <https://github.com/WEC-Sim/WEC-Sim_Applications/actions/runs/17800892973/job/50600275103>. If I rerun this a few times, it will pass, but it is still frustrating to have to rerun it all the time. I *think* the MATLAB crash may be caused by a window that MoorDyn tries to open. In MATLAB locally, the window shows up like below, but I think it may be trying to display some sort of graphic? While running the simulation locally does not crash MATLAB, closing this window does crash MATLAB. Do you know what may be causing this window to be opened? And if so, is there a way to disable it? image.png (view on web) <https://github.com/user-attachments/assets/4337745f-89cd-4c07-8c45-d1359643ff4a> --Thanks, Jeff — Reply to this email directly, view it on GitHub <#327>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKHXCORFXRVOZTDE5ZT3THM3PAVCNFSM6AAAAACGZW5MDGVHI2DSMVQWIX3LMV43ASLTON2WKOZTGQZDOOJVGUYTKNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jtgrasb]

Got it, that makes sense. Thank you! I believe we stuck with MoorDyn v1 API to avoid extra files. MoorDyn2.h calls Waves,h, Seafloor.h, etc. but we don't use these at all in WEC-Sim. While its not a big deal to add the other .h files, the only functions that we use are MoorDyn_Init, MoorDyn_Create, MoorDyn_Step, and MoorDyn_Close so it'd be nice to not include extra files unnecessarily. I edited MoorDyn2.h to remove all other functions except these 4 and it seems to work fine for our purposes. Are there any issues you see with this approach?

[RyanDavies19]

@jtgrasb, that's probably fine if you are okay with having to modify the header file every time you want to update (assuming changes were made to the API in what ever MD version was released). Otherwise we could modify the V1 MoorDyn.cpp file, for a more permanent fix that would help keep upkeep automated. As far as I know WECSim is one of the only users of that V1 API (other V1 users like Bladed actually use a copy of the older code because of licensing issues).

[jtgrasb]

@RyanDavies19 Got it, thanks! I think updating to the V2 version makes sense. Since were still using MoorDynAPI.h and the dll is being updated for every version, there shouldn't be any significant changes in the future unless those 4 function names/inputs are changed, right?

[sanguinariojoe]

If we do an API change we are also changing the version. In particular: - Added feature = minor version change - Breaking change = major version change

…

On Fri, 26 Sept 2025, 01:01 jtgrasb, ***@***.***> wrote: *jtgrasb* left a comment (FloatingArrayDesign/MoorDyn#327) <#327 (comment)> @RyanDavies19 <https://github.com/RyanDavies19> Got it, thanks! I think updating to the V2 version makes sense. Since were still using MoorDynAPI.h and the dll is being updated for every version, there shouldn't be any significant changes in the future unless those 4 function names/inputs are changed, right? — Reply to this email directly, view it on GitHub <#327 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKHC22IECBQ6DILJQAD3URX3DAVCNFSM6AAAAACGZW5MDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZWGE4DIMRVHE> . You are receiving this because you commented.Message ID: ***@***.***>

[RyanDavies19]

@sanguinariojoe good point. @jtgrasb you can have it flag and throw an error when there is a major version change (i.e. if the version number changes from 2)

[jtgrasb]

I am running into some issues with the changeover to the v2 API. In particular, (from my understanding) MoorDyn2.h uses a MoorDyn system variable that is created by MoorDyn_Create() and used by the other MoorDyn functions. When using MATLAB, this creates a libpointer variable which are cumbersome to work with, and it seems that using the libpointer causes errors when trying to run parallel computing. See details here. Unless there's a way to use the v2 API without the MoorDyn system variable, the best solution seems to be going back to the v1 API. In that case, would you all be willing to modify MoorDyn.cpp to not open the graphics window?

[sanguinariojoe]

I suppose we can create a new API entry for MoorDyn v1, so the CMD spawn can be configured beforehand. I remember like the alternative of using the Matlab wrapper was already rejected, right?

…

On Thu, 9 Oct 2025, 00:19 jtgrasb, ***@***.***> wrote: *jtgrasb* left a comment (FloatingArrayDesign/MoorDyn#327) <#327 (comment)> I am running into some issues with the changeover to the v2 API. In particular, (from my understanding) MoorDyn2.h uses a MoorDyn system variable that is created by MoorDyn_Create() and used by the other MoorDyn functions. When using MATLAB, this creates a libpointer variable which are cumbersome to work with, and it seems that using the libpointer causes errors when trying to run parallel computing. See details here <WEC-Sim/WEC-Sim#1566>. Unless there's a way to use the v2 API without the MoorDyn system variable, the best solution seems to be going back to the v1 API. In that case, would you all be willing to modify MoorDyn.cpp to not open the graphics window? — Reply to this email directly, view it on GitHub <#327 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKC4QZZSBFGXKPHWJDT3WWEWFAVCNFSM6AAAAACGZW5MDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBTGQZDINJTHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RyanDavies19]

@sanguinariojoe yes, unfortunately it won't work. The idea is that this is a distribution that users can download pre-compiled. From my understanding, the MATLAB wrapper is only compatible with the version of MATLAB that was used to compile it, and thus is not easily distributed.

@jtgrasb, if I remember correctly that libpointer variable is why we went with the V1 API in the first place.

If we do change the V1 API we will need to make sure it stays backwards compatible. I know there are tools out there like Bladed that use MoorDyn V1 (using the older code), so it would be important to keep our V1 API matching the actual V1 API so that if those codes were to upgrade to this version it would be an easy plug and play.

[sanguinariojoe]

That's why I suggest adding a new method to the v1 API. Something like MD_Disable_CMD(). The API will remain backward compatible (because no function declaration will be changed), and if the new method is not called, the library will behave exactly the same way

…

On Fri, 10 Oct 2025, 19:06 Ryan Davies, ***@***.***> wrote: *RyanDavies19* left a comment (FloatingArrayDesign/MoorDyn#327) <#327 (comment)> @sanguinariojoe <https://github.com/sanguinariojoe> yes, unfortunately it won't work. The idea is that this is a distribution that users can download pre-compiled. From my understanding, the MATLAB wrapper is only compatible with the version of MATLAB that was used to compile it, and thus is not easily distributed. @jtgrasb <https://github.com/jtgrasb>, if I remember correctly that libpointer variable is why we went with the V1 API in the first place. If we do change the V1 API we will need to make sure it stays backwards compatible. I know there are tools out there like Bladed that use MoorDyn V1 (using the older code), so it would be important to keep our V1 API matching the actual V1 API so that if those codes were to upgrade to this version it would be an easy plug and play. — Reply to this email directly, view it on GitHub <#327 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKCBO6AOHMHKYFFE4ML3W7RPVAVCNFSM6AAAAACGZW5MDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJRGI2TKOJUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[RyanDavies19]

I am not currently working on code, but next set of changes I push I up I'll include it, unless one of you two get to it first. @jtgrasb, if you're going to do it happy to have a quick call if it would be helpful.