Line Failures added to MoorDyn #2214
Conversation
|
Added updated types after #2223 bug fix allows me to build locally. Thanks @andrew-platt |
| @@ -379,14 +373,15 @@ SUBROUTINE Point_RemoveLine(Point, lineID, TopOfLine, rEnd, rdEnd) | |||
| REAL(DbKi), INTENT(INOUT) :: rdEnd(3) | |||
|
|
|||
| Integer(IntKi) :: l,m,J | |||
| Integer(IntKi) :: found = 0 | |||
There was a problem hiding this comment.
In Fortran, initializing a variable in the type declaration statement automatically gives it a "SAVE" attribute, which means it retains its value each time it is called (i.e., it's set to 0 only the first time the routine is called). Since this is called from an UpdateStates routine, I'd be surprised if this is how it was intended to be used.... and if that was the intention, it wouldn't work properly in a restart situation.
I'd recommend either
- rewriting like this:
Integer(IntKi) :: found
found = 0
or
- putting this variable in a
MiscVartype, if you do intend for it to have theSAVEattribute.
There was a problem hiding this comment.
Also, using a LOGICAL here might make it easier to read, unless you have plans for checking something other than found vs not-found .
There was a problem hiding this comment.
Thanks @bjonkman for the review. @andrew-platt if you have a PR or something merging soon can you add the found = 0 and the logical fix there? Otherwise I can open a PR. It's intent is a boolean flag that prints an error message (I probably should've made it throw a warning, because if it fails the simulation continues with the line attached)
There was a problem hiding this comment.
I'll include this into a minor PR that I'll post tomorrow.
See comments on PR OpenFAST#2214 for details
Feature or improvement description
Added line failure capabilities to MoorDyn, which can be triggered by a time or tension threshold. The corresponding docs update can be found here: FloatingArrayDesign/MoorDyn#213. This update includes error checking and has been tested for invalid input file configurations.
Heres what is in the docs: "This section (optional) describes the failure conditions of the system. Line failures can only be triggered at an existing point or rod end where a line/lines are attached. Failures can be triggered by a time or attachment tension threshold, which ever comes first. Users can specify multiple failures for a given point, but duplicate failure configurations will be ignored. If two lines attached to a point are listed to fail (failure 1 for example), then after the failure the lines will remain attached to each other by a free point. In this multi line case, if any line reaches the tension threshold then the failure will be triggered."
I've also enabled bodies and rods in fast farm, which just entailed properly reading in the input file. I also added a warning to waves in MoorDyn to check the beginning time of the wave elevation time series. I had a report of seg faults when the time series started at t != 0.
I also included a fix to the calculation of 6 DOF drag vector for Bodies, as reported in FloatingArrayDesign/MoorDyn#205
Impacted areas of the software
MoorDyn
Additional supporting information
The types file might need to be regenerated based on the registry update. I cannot get the most recent version of dev (after the unstable pointer merge) to compile locally so the types file is generated with the old method. If @andrew-platt or someone else with the most up-to-date version of dev could PR to my branch with an updated types file that would be great!
Test results, if applicable
Here are the results from the attached test case:
Example MD driver case:
fail_test.zip