search

FloatingArrayDesign / MoorDyn

a lumped-mass mooring line model intended for coupling with floating structure codes
https://moordyn.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
71 stars 40 forks source link

Pinned bodies feature #178

Closed RyanDavies19 closed 9 months ago

RyanDavies19 commented 9 months ago

This PR includes a new option for bodies, allowing them to behave as a pinned object. It contains a corresponding unit test and documentation updates. It also contains a feature update that prints time steps to the terminal while running, similar to how MDF works at runtime.

The formulation follows the pinned rods orientation closely. Inertial responses and forces have been added to the getStateDeriv and getFnet functions for both bodies and rods. The torque from translational acceleration is: *F_iner [4:6] = M.bottomLeftCorner a6[1:3]**

and the inertial response force to acceleration is given as (contains two terms to avoid counting the externally applied force): F_iner[1:3] = - M.topLeftCorner a6[1:3] - M.topRightCorner a6[3:6]

This feature has been verified in MDF using CAD software, analytical solutions, and Subdyn. For the MDC version I verified using MDF, and the two versions match very closely.

The corresponding update will be included in OpenFAST v4.

This update did require the addition of an acceleration term for each calling time step for the calculation of inertial forces. In MDF acceleration a value passed into the step function. For MDC, I did this the same way velocity is handled: constant over the coupling step. While this isn't the most accurate, it was the simplest approach and in most use cases the coupling time step will be small enough that the effect is negligible (there was never issues when comparing with MDF).

sanguinariojoe commented 9 months ago

@RyanDavies19 you must rebase this. Everything is duplicated up to this commit, while you are missing some other commits (look the commits on dev here)

You can end up messing it a bit up, so I suggest you making a backup before. Os course, let me know if you have any trouble

RyanDavies19 commented 9 months ago

The one issue I have noticed with this update is the call to getFnet in GetBodyOutput and GetRodOutput seems to have slowed things down. It's required because that is where inertial response forces are accounted for. @sanguinariojoe Do you have any ideas off the top of your head to speed that up?

RyanDavies19 commented 9 months ago

@RyanDavies19 you must rebase this. Everything is duplicated up to this commit, while you are missing some other commits (look the commits on dev here)

You can end up messing it a bit up, so I suggest you making a backup before. Os course, let me know if you have any trouble

Okay, sorry about that I thought I had everything up to date correctly. I will rebase to adjust.

sanguinariojoe commented 9 months ago

The one issue I have noticed with this update is the call to getFnet in GetBodyOutput and GetRodOutput seems to have slowed things down. It's required because that is where inertial response forces are accounted for. @sanguinariojoe Do you have any ideas off the top of your head to speed that up?

Try replacing a6(Eigen::seqN(0,3)) by a6.head<3>() and a6(Eigen::seqN(3,3)) by a6.tail<3>() (and any other similar call, e.g. https://github.com/FloatingArrayDesign/MoorDyn/pull/178/files#diff-63e251a0644047a5e237531c8a78aca4865b1000fb75f24b3cdbf833f4836cf3R522)

P.S. This can be done just for right hand sides. It is not valid for assignments