search

FloatingArrayDesign / MoorDyn

a lumped-mass mooring line model intended for coupling with floating structure codes
BSD 3-Clause "New" or "Revised" License
64 stars 37 forks source link

Refresh the API #202

Closed sanguinariojoe closed 2 months ago

sanguinariojoe commented 3 months ago

Well, this was not really a exciting task, but someone should do that...

I just added a bunch of methods to the C API, set the initial state of the coupled bodies (so calling to MoorDyn_GetBodyState() before MoorDyn_Init() is giving back the correct result) and updated the wrappers.

Tomorrow I am getting a new baby, so I will be unresponsive for a while. @RyanDavies19 feel free to merge/change whatever you need

sanguinariojoe commented 3 months ago

P.S. This should fix #193

RyanDavies19 commented 2 months ago

@sanguinariojoe Congratulations on the new baby! I will review these and merge

sanguinariojoe commented 2 months ago

OK, I am merging this and let see if on the next release someone complains about something

RyanDavies19 commented 2 months ago

@sanguinariojoe I'm not entirely sure where things changed here but the fairlead output channel values are now different. See the attached input file as an example, and the image comparing outputs to MDF. I suspect it has to do with changing the getNodeTen function. I looked around a bit and changing the fairlead output written (at line 539 in Line.cpp) to Fnet[N].norm() still causes a difference, which seems like then the value of Fnet at the fairlead node has changed. I don't have time at the moment to find a fix for this, but it will need to be fixed at some point because the difference is not negligible. In the future it might be nice to have some regression tests set up to avoid this, or a github action that tests against MDF (which has regression tests).

Commit 08ed0e089cb0ddea9cc904c01db6ecd1738e8ab3 and earlier does not have this problem, MDC and MDF agreed exactly on values. Something in the changes in this PR broke the fairlead output values.

ten_diff

case1.txt

sanguinariojoe commented 2 months ago

Yeah, the former MoorDyn_GetLineNodeTen() and moordyn::Line::getNodeTen() have been renamed as MoorDyn_GetLineNodeForce() and moordyn::Line::getNodeForce().

Now MoorDyn_GetLineNodeTen() and moordyn::Line::getNodeTen() are giving the so called wall tension (axial stiffness plus axial damping).

That is consistent with some other instances, as well as some other codes in the wild.

The problem is that I have not updated the output channels.