Pointbreak

[sanguinariojoe]

As promised, here you have the utilities to do lines breaking!

It is just the scaffolding (+ an API entry). All the stuff about configurations, triggers and so on is not implemented. Thus it is not fully fixing #378, but some work has to be done yet

[sanguinariojoe]

Hint: Check the new test

[sanguinariojoe]

Apparently the test fails on MacOs... Checking...

[sanguinariojoe]

Everything is alright now. But I am finding some uninitialized values that might require a deeper analysis

[sanguinariojoe]

Well, it is more elusive than I thought. Tomorrow I am finding and fixing it

[sanguinariojoe]

@RyanDavies19 , no more errors! Please take a look, and if it suffices just merge and feel free to implement MoorDynF alike line breaking

[RyanDavies19]

Hi @sanguinariojoe,

I haven't forgotten about this! Hoping to be able to look later this week/weekend. Thanks for putting it together.

[RyanDavies19]

Thanks for adding it to the API, thats a great addition. Reading through the code, it seems like the remaining tasks would be:

1. IO through the MD input file still needs to be added in a way that matches OpenFAST
2. Accommodations for when lines are attached directly to rods (I don't recall if rod end nodes are in the point list or not)

Does that sound right?

Also a side note: I noticed in the animation you gave a point goes flying off w/ no lines. Is that intentional or does that show the point type changing from coupled/fixed to free? Based on the code I don't see where that would be happening but thought it would be good to double check.

[sanguinariojoe]

I don't recall if rod end nodes are in the point list or not

Nope, they are not. Another MoorDyn::BreakLine(moordyn::Rod* rod, moordyn::Line* line) function is required.

Also, the C API entry shall be renamed to MoorDyn_BreakLineAtPoint() and another function MoorDyn_BreakLineAtRod() shall be created. Alternatively, we can create sort of an alias for generic entities, something like MoorDynInstance, as an alias of void*. But that would be way less explicit, letting the user to accidentally do strange things.

Also a side note: I noticed in the animation you gave a point goes flying off w/ no lines. Is that intentional or does that show the point type changing from coupled/fixed to free? Based on the code I don't see where that would be happening but thought it would be good to double check.

As you can see here:

https://github.com/core-marine-dev/MoorDyn/blob/pointbreak/source/MoorDyn2.cpp#L809

The original point is kept, while the line is detached from it. That is indeed convenient in the case of coupled points (otherwise the user shall check and modify the number of DOFs he passes through MoorDyn_Step()). It would be risky for free points, but I actually do not see any border case on which a line can break and left a free point unconnected from all other entities. Maybe a big hanging weight?

Should we look for and remove standalone free points at the end of the function?

[RyanDavies19]

@sanguinariojoe,

I like the idea of two functions, one for rod detachments and one for point detachments. I also think we leave the possibility of free points with no lines, better to not unnecessarily constrain what can be simulated imo.

My question was about this point moving away from the fairlead location (red arrow in screenshot below). It seems like the type is being set to free somehow, though I don't see where in the code that could happen.

[sanguinariojoe]

Nope, that one is the original coupled point

…

On Mon, 11 May 2026, 17:25 Ryan Davies, ***@***.***> wrote: *RyanDavies19* left a comment (FloatingArrayDesign/MoorDyn#379) <#379 (comment)> @sanguinariojoe <https://github.com/sanguinariojoe>, I like the idea of two functions, one for rod detachments and one for point detachments. I also think we leave the possibility of free points with no lines, better to not unnecessarily constrain what can be simulated imo. My question was about this point moving away from the fairlead location (red arrow in screenshot below). It seems like the type is being set to free somehow, though I don't see where in the code that could happen. Screenshot.2026-05-11.at.8.14.07.AM.png (view on web) <https://github.com/user-attachments/assets/5811d8b3-a850-4f08-aad0-4482666d2d08> — Reply to this email directly, view it on GitHub <#379 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKCSGSTXETQQ4JGFCDT42HWGHAVCNFSM6AAAAACX3IG5TGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMRSGA3DEOJRGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sanguinariojoe]

I mean, it is never set to free. It is still moving after the line break because I am imposing a constant motion on x direction for the 3 coupled points On Mon, 11 May 2026, 17:46 pepe cullera, ***@***.***> wrote:

…

Nope, that one is the original coupled point On Mon, 11 May 2026, 17:25 Ryan Davies, ***@***.***> wrote: > *RyanDavies19* left a comment (FloatingArrayDesign/MoorDyn#379) > <#379 (comment)> > > @sanguinariojoe <https://github.com/sanguinariojoe>, > > I like the idea of two functions, one for rod detachments and one for > point detachments. I also think we leave the possibility of free points > with no lines, better to not unnecessarily constrain what can be simulated > imo. > > My question was about this point moving away from the fairlead location > (red arrow in screenshot below). It seems like the type is being set to > free somehow, though I don't see where in the code that could happen. > Screenshot.2026-05-11.at.8.14.07.AM.png (view on web) > <https://github.com/user-attachments/assets/5811d8b3-a850-4f08-aad0-4482666d2d08> > > — > Reply to this email directly, view it on GitHub > <#379 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAMXKKCSGSTXETQQ4JGFCDT42HWGHAVCNFSM6AAAAACX3IG5TGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMRSGA3DEOJRGY> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you were mentioned.Message ID: > ***@***.***> >