@akeeste, how did you diagnose this? Is there any risk that you will crash MoorDyn by forcing the library to close too early? Would it maybe be better to poll in a loop, i.e.

while 1
    if ~libisloaded('Lines')
        break
    end
end

In this way you wouldn't risk stopping MoorDyn prematurely. You could put a maximum wait time on it to avoid an infinite loop.

@H0R5E I tried a similar loop to give MoorDyn time to finish writing output, but without success. I found that this is really a WEC-Sim order of operations issue, rather than a WEC-Sim/MoorDyn racing issue. No matter how much time is given, the Lines.out file is not complete until WEC-Sim calls the MoorDyn function LinesClose.

This started occurring in the last couple of releases because we moved the WEC-Sim post-processing stopWecSim to be a stop function callback of the Frames blocks. These commands to close MoorDyn are in the MoorDyn block stop function callback.

Previously our post-processing order of operations was something like:

• Run Simulink
• MoorDyn callback when Simulink stops
  • calllib('Lines','LinesClose');
• stopWecSim
  • output.loadMoorDyn()

But right now our post-processing order of operations is:

• Run Simulink
• Frames callback when Simulink stops
  • stopWecSim
    • output.loadMoorDyn()
• MoorDyn callback when Simulink stops
  • calllib('Lines','LinesClose');

So our main post-processing is running before we actually close MoorDyn, which completes the Lines.out files. I had moved stopWecSim into the wecSim script to better debug and realized that this actually prevented the issue from occurring. I updated MoorDyn callbacks to be:
if libisloaded('Lines')
calllib('Lines','LinesClose');
unloadlibrary Lines;
end

This way MoorDyn will always close properly if Simulink crashes or stop unexpectedly, but it will not try to use the DLL if stopWecSim has already been run.

Adam

OK, Adam, makes sense. I am curious as to why the order of post-processing is as it is - would it not be sensible to post-process in the last step? Also, is there any way to build a test to catch this if it happens again?

@H0R5E I agree, it would be better to run stopWecSim as our last step. We originally moved this to the Frames callback to make it easier for users to run From Simulink. However since this is a block-level callback and not a model level callback, we don't have control over when it is run. I believe the block callbacks are run in alphabetical order by block name, so the Global Reference Frame is run before MoorDyn.

@kmruehl I think this should come into our larger discussion on the utility vs maintenance of Run From Simulink

And on the test -- hopefully one of our MoorDyn application tests can catch this. I'll think on this

Is this PR ready for a merge? I think we have a similar issue going on with wecSimPCT #782

@H0R5E are there any other changes you recommend here before we merge?

No @akeeste, go ahead.

@akeeste I'm going to go ahead and merge this, but we need to put it in dev too. Can you make the same revisions on #822? Thank you!