Tendon failure in FAST modeling

I think if you remove the key word “ABSTRACT” from the specification of the three interface statements in OrcaFlexInterface.f90 (reported on lines 114, 127, and 145, the first 3 errors in your attachment), that will solve your issue.

This was fixed in OpenFAST a while ago. Older Fortran compilers allowed this syntax (with the ABSTRACT key word), though it is technically not correct.

Dear Bonnie,

Thanks for the input. Based on the suggestion, I have removed the word ABSTRACT from line 106. The errors changed into somewhat different this time. Any guidance would be helpful.
P.S. Facing an http error to attach text document.

“Severity Code Description Project File Line Suppression State
Error fatal error LNK1169: one or more multiply defined symbols found …..\bin\FAST_dev_Debug_Win32.exe
Error error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj) mkl_core.lib(dlarfgn.obj)”

Thanks and regards
Abhinay Goga

The linking error you show is typically caused by a mismatch between libraries used to link the final executable. I don’t recall the details of FAST8 builds, but make sure you are using consistent libraries and compile settings in all the files and projects. The first place I would check is under “properties”, “Configuration properties->Fortran->Libraries->Runtime library”. Those settings should be the same for all projects. Another thing to check is that the settings under “Configuration properties->Fortran->Floating point” are the same in all projects in the solution.

With one version of the compiler, I recall the OrcaFlex interface files couldn’t be optimized, so that might be causing trouble, too. (right-click on the OrcaFlexInterface.F90 file, select “properties” and then set “Configuration Properties->Fortran->Optimization->Optimization” to “Disable (/Od)”). Though, in debug mode it’s probably already turned off optimizations.

Dear Bonnie and Matt,

Thanks for guidance. With configuring the properties to release,the recompilation is successful.
The Fairlead tension for line 1 after 50 sec reaches zero, yet there are are no significant rise in the loads for remaining lines. And in the mooring file, I have designed 9 lines (with 2 connections for each). Anchor 7 tension for line 1 is not resulted as zero. Could you please make a comment about this behavior?

Thanks and regards
Abhinay Goga

Dear Abhinay,

I’m glad that you’ve now successfully compiled your updated source code.

I’m not sure what type of floater this is (a semisubmersible?), and perhaps Matt can comment further, but assuming the mooring lines are centenaries, I would imagine the mean tensions in the remaining lines after the loss of line 1 would go down because the tension from line 1 is no longer pulling on them. I would suggest that you start by running simple tests (e.g. no wind and still water) to ensure that platform response is what you expect after the line loss.

Best regards,

Dear Jason and Matt,

Thanks. The floater is OlavOlsen Semi-submersible star floater. My aim is to validate fiber ropes instead of conventional catenary chains. My connections of lines look like the following:

“Line LineType UnstrLen NumSegs NodeAnch NodeFair Flags/Outputs
(-) (-) (m) (-) (-) (-) (-)
1 chain 60 6 4 1 -
2 chain 60 6 5 2 -
3 chain 60 6 6 3 -
4 fiber 80 8 7 4 “ptsd”
5 fiber 80 8 8 5 “ptsd”
6 fiber 80 8 9 6 “ptsd”
7 chain 60 6 10 7 -
8 chain 60 6 11 8 -
9 chain 60 6 12 9 -”

Based on your suggestion, I ran complete static situation without any initial offsets. The performance of the floater seems reasonable with increase in surge and heave. However, the anchor tensions seems not in order. Can anyone please clarify, why there is such behavior on anchors?

Thanks and regards
Abhinay Goga


Dear Abnhinay,

The results you’re seeing are as I’d expect. My understanding was you were only concerned with simulating the results of a line failure on the floater itself. You’ll see the code I helped you with simply zeroes the forces of the failed line on the platform; it does not do anything to physically free the line from the floater. So the line still acts attached to the platform and has the corresponding tensions. Only the floater does not feel the line anymore.

Hopefully this approach meets your needs. If you actually wanted to model the effect of the simulated failure within the mooring system as well, it would be considerably more complicated. You would need to add additional states to the system for the freed line end, which would convert from “vessel” to “connect” type. These capabilities will be developed eventually, but they aren’t quick to do.

Best,
Matt

Dear Matt,

Understood that the source code you helped with creates a Pseudo event of transient line loss. Thanks for all the guidance and support. For my thesis, the implemented model is suffice. Looking forward to future improvements on the glue codes.

Kind regards
Abhinay Goga

Dear all,
I am trying to implement a condition where the mooring line is experiencing a vertical force of zero temporarily and then gets back to normal after some time. Seeing the above posts I tried to change the source code of MAP.f90 to achieve my purpose. The modified code is attached below. The code is compiling fine and I run Matlab simulation using the obtained DLL. I can see a transient motion in the platform surge displacement. But, when I tried to see the output time series of global Z fairlead force [N] GZ_FORCE, and expected to have a zero value during the time I set the vertical force to zero , I cannot see that. Am I doing anything wrong and If not how can I see the effect in the line force parameters?

Modifications made to MAP_CalcOutput function:

REAL(DbKi), PARAMETER :: t_fault_start = 400.0
REAL(DbKi), PARAMETER :: t_fault_end = 420.0
IF (ALLOCATED(y%WriteOutput) .AND. ASSOCIATED(y%WrtOutput)) y%WriteOutput = REAL(y%WrtOutput, ReKi)

! Apply transient fault
IF (time >= t_fault_start .AND. time <= t_fault_end) THEN
DO i = 1, y%ptFairleadLoad%NNodes
! Example: Drop forces to 20% of normal values
y%ptFairleadLoad%Force(1, i) = -y%FX(i)
y%ptFairleadLoad%Force(2, i) = -y%FY(i)
y%ptFairleadLoad%Force(3, i) = 0

END DO
ELSE
! Copy the MAP C output types to the native Fortran mesh output types
DO i = 1, y%ptFairleadLoad%NNodes
y%ptFairleadLoad%Force(1, i) = -y%FX(i)
y%ptFairleadLoad%Force(2, i) = -y%FY(i)
y%ptFairleadLoad%Force(3, i) = -y%FZ(i)
END DO
END IF

Thanks in Advance

Dear @Nitin.Sivakumar,

SUBROUTINE map.f90/MAP_CalcOutput() returns two sets of outputs from MAP++ to OpenFAST: (1) the forces at each fairlead in the mesh output that gets applied to the structural mesh in ElastoDyn or SubDyn and (2) the write outputs written to the output file. It looks like you are changing (1), but not (2), so, you’ll see the effect you want (eliminating the vertical reaction force from the lines) in terms of the dynamic response of the floater, but you will not see the effect in terms of the MAP++ outputs written to the file.

Best regards,

Dear jason sir,
How to the write outputs written to the output file.
Thanks and regards

Dear @Nitin.Sivakumar,

The outputs written to the output file of MAP++ are stored in the y%WriteOutput() array. Changing this array may be a bit more involved in MAP++ than it is in other OpenFAST modules because in MAP++, the core calculations take place in the C++ source code and the Fortran source code is simply a wrapper that converts the data to Fortran for use in OpenFAST.

FYI: Not sure which version of OpenFAST you are currently using, but the modeling of line failure is now built-in functionality within the MoorDyn module of OpenFAST.

Best regards,

The Map++ is given as the default mooring line code in the TLP turbine primary file which Iam using. I found Map++ quite simple than MoorDyn as I am implementing a reduced platform condition. Is it straightforward to change the mooring line code to MoorDyn for the TLP? And also can I see the mooring line failure setup in the MoorDyn manual online?

Dear @Nitin.Sivakumar,

If you are using the OpenFAST model of the NREL 5-MW baseline wind turbine atop the MIT/NREL TLP, a MoorDyn input file is already available in the r-test (along with the MAP++ input file).

The line failure feature in MoorDyn is documented here: Input Files — MoorDyn 2.3.1 documentation.

Best regards,

Dear Jason sir,
I tried using MoorDyn input file instead of Map++ input file for the 5 MW turbine atop the MIT/TLP .For the original cofiguration of water depth of 200 m, the simulation worked with MoorDyn file without problem. But since I was using the reduced water depth for the turbine (100m) , while setting parameters of depth and UnstrLen same as the map++ file , the simulation is giving an error as follows.
"Fairlead forces: NaN, NaN, NaN
Fairlead tension: NaN
Fairlead forces: NaN, NaN, NaN
MoorDyn initialization completed.

OpenFAST completed.

Error using PI_NonlinFloat_prial3FFtrialSmPICode_modd22 (line 345)
Error reported by S-function ‘FAST_SFunc’ in ‘PI_NonlinFloat_prial3FFtrialSmPI1/Subsystem/FAST Nonlinear Wind Turbine/S-Function’:
FAST_InitializeAll:ED_Init:ED_ReadInput:ReadBladeInputs:ReadBladeFile:The ElastoDyn Blade file,
D:\ONGOING_WORKS\labworks\r-test-main_feb25\r-test-main\glue-codes\openfast\5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti../5MW_Baseline/NRELOffshrBsline5MW_Blade.dat,
DISTRIBUTED BLADE PROPERTIES table contains the PitchAxis column. This column is unused and will be removed in future releases
FAST_InitializeAll:SeaSt_Init:SeaStateInput_ProcessInitData:WvHiCOff adjusted to 12.566 rad/s, based on WaveDT.
SeaSt_Init:Waves_Init:VariousWaves_Init:CalculateWaveDirection:CalculateWaveNDir:Changed WaveNDir from 13 to 15 so that an equal number of frequencies are
assigned to each direction.
FAST_InitializeAll: NaN state detected. "

I am attaching my Map++ and MoorDyn file portions below.
Map++
“---------------------- LINE DICTIONARY ---------------------------------------
LineType Diam MassDenInAir EA CB CIntDamp Ca Cdn Cdt
(-) (m) (kg/m) (N) (-) (Pa-s) (-) (-) (-)
Material 0.127 116.027 1.5E9 1.0 0 0 0 0
---------------------- NODE PROPERTIES ---------------------------------------
Node Type X Y Z M B FX FY FZ
(-) (-) (m) (m) (m) (kg) (mˆ3) (N) (N) (N)
1 fix 27 0 depth 0 0 # # #
2 Vessel 27 0 -47.89 0 0 # # #
---------------------- LINE PROPERTIES ---------------------------------------
Line LineType UnstrLen NodeAnch NodeFair Flags
(-) (-) (m) (-) (-) (-)
1 Material 52.1159 1 2 GZ_FORCE
---------------------- SOLVER OPTIONS-----------------------------------------
Option
(-)
repeat 270 180 90 0 270 180 90”

MoorDyn file
"
--------------------- MoorDyn Input File ------------------------------------
Mooring system for MIT/NREL TLP
FALSE Echo - echo the input file data (flag)
----------------------- LINE TYPES ------------------------------------------
Name Diam MassDen EA BA/-zeta EI Cd Ca CdAx CaAx
(-) (m) (kg/m) (N) (N-s/-) (-) (-) (-) (-) (-)
main 0.127 116.027 1.5E9 6e6 0.0 1.6 1.0 0.1 0.0
---------------------- POINTS --------------------------------
ID Attachment X Y Z M V CdA CA
(-) (-) (m) (m) (m) (kg) (m^3) (m^2) (-)
1 fixed 27.0 0.0 -100.0 0 0 0 0
2 fixed 0.0 27.0 -100.0 0 0 0 0
3 fixed -27.0 0.0 -100.0 0 0 0 0
4 fixed 0.0 -27.0 -100.0 0 0 0 0
5 fixed 27.0 0.0 -100.0 0 0 0 0
6 fixed 0.0 27.0 -100.0 0 0 0 0
7 fixed -27.0 0.0 -100.0 0 0 0 0
8 fixed 0.0 -27.0 -100.0 0 0 0 0
9 vessel 27.0 0.0 -47.89 0 0 0 0
10 vessel 0.0 27.0 -47.89 0 0 0 0
11 vessel -27.0 0.0 -47.89 0 0 0 0
12 vessel 0.0 -27.0 -47.89 0 0 0 0
13 vessel 27.0 0.0 -47.89 0 0 0 0
14 vessel 0.0 27.0 -47.89 0 0 0 0
15 vessel -27.0 0.0 -47.89 0 0 0 0
16 vessel 0.0 -27.0 -47.89 0 0 0 0
---------------------- LINES --------------------------------------
ID LineType AttachA AttachB UnstrLen NumSegs Outputs
(-) (-) (-) (-) (m) (-) (-)
1 main 1 9 52.1159 10 -
2 main 2 10 52.1159 10 -
3 main 3 11 52.1159 10 -
4 main 4 12 52.1159 10 -
5 main 5 13 52.1159 10 -
6 main 6 14 52.1159 10 -
7 main 7 15 52.1159 10 -
8 main 8 16 52.1159 10 -
---------------------- SOLVER OPTIONS ---------------------------------------
0.001 dtM - time step to use in mooring integration (s)
3.0e4 kbot - bottom stiffness (Pa/m)
3.0e4 cbot - bottom damping (Pa-s/m)
2.0 dtIC - time interval for analyzing convergence during IC gen (s)
60.0 TmaxIC - max time for ic gen (s)
4.0 CdScaleIC - factor by which to scale drag coefficients during dynamic relaxation (-)
0.01 threshIC - threshold for IC convergence (-)
"
The depth in the Map++ file corresponds to the value I initialised in primary file as 100m. Why is there such an error when I used same parameters? How can I configure the MoorDyn file to perform similarly to Map++ file?
Thanks in Advance
Best Regards

Hi @Nitin.Sivakumar,

Your system is numerically unstable. Typically the way to resolve this is to decrease your time-step size (dtM), reduce CdScaleIC (if there are Nans during dynamic relaxation), and adjust the number of segments in your lines. I ran your case after changing to 0.0001 dtM and 1.0 CdScaleIC in the options list and saw no errors. Please let me know if that doesn’t work for you.

Side note: I noted you have duplicate points (two points at the same location). You can reduce the number of points you have if you are not explicitly looking for the forces on them, as points can have any number of lines attached to them. Functionally there should be no difference with or without the duplicates.

Thanks @Ryan.Davies ,
The simulation is working fine with the changes you suggested. However, I am not clear about your point about reducing the number of points. I understand that points at the same location correspond to another line from the same point. So if I remove the point I will have to remove the corresponding line also. Is my understanding correct?
Another question I have is regarding the line failure implementation available in MoorDyn .With the line failure added to the MoorDyn, I can implement a line failure after a time or at the reach of a specified line tension. But What if I want to implement a temporary line disconnection and then reverse the condition after a time interval like I had implemented in Map++ after modifying the source code as given below? Is that possible with the line failure functionality available in MooDyn?

Modifications made to MAP_CalcOutput function:

REAL(DbKi), PARAMETER :: t_fault_start = 400.0
REAL(DbKi), PARAMETER :: t_fault_end = 420.0
IF (ALLOCATED(y%WriteOutput) .AND. ASSOCIATED(y%WrtOutput)) y%WriteOutput = REAL(y%WrtOutput, ReKi)

! Apply transient fault
IF (time >= t_fault_start .AND. time <= t_fault_end) THEN
DO i = 1, y%ptFairleadLoad%NNodes
! Example: Drop forces to 20% of normal values
y%ptFairleadLoad%Force(1, i) = -y%FX(i)
y%ptFairleadLoad%Force(2, i) = -y%FY(i)
y%ptFairleadLoad%Force(3, i) = 0

END DO
ELSE
! Copy the MAP C output types to the native Fortran mesh output types
DO i = 1, y%ptFairleadLoad%NNodes
y%ptFairleadLoad%Force(1, i) = -y%FX(i)
y%ptFairleadLoad%Force(2, i) = -y%FY(i)
y%ptFairleadLoad%Force(3, i) = -y%FZ(i)
END DO
END IF

Thanks in advance
Best Regards

Hi @Nitin.Sivakumar, to your first question about the points. The following snippet of an input file should be equivalent to what you have shared above. There is no limit on the number of lines attached to a point.

---------------------- POINTS --------------------------------
ID Attachment X Y Z M V CdA CA
(-) (-) (m) (m) (m) (kg) (m^3) (m^2) (-)
1 fixed 27.0 0.0 -100.0 0 0 0 0
2 fixed 0.0 27.0 -100.0 0 0 0 0
3 fixed -27.0 0.0 -100.0 0 0 0 0
4 fixed 0.0 -27.0 -100.0 0 0 0 0
5 vessel 27.0 0.0 -47.89 0 0 0 0
6 vessel 0.0 27.0 -47.89 0 0 0 0
7 vessel -27.0 0.0 -47.89 0 0 0 0
8 vessel 0.0 -27.0 -47.89 0 0 0 0
---------------------- LINES --------------------------------------
ID LineType AttachA AttachB UnstrLen NumSegs Outputs
(-) (-) (-) (-) (m) (-) (-)
1 main 1 5 52.1159 10 -
2 main 2 6 52.1159 10 -
3 main 3 7 52.1159 10 -
4 main 4 8 52.1159 10 -
5 main 1 5 52.1159 10 -
6 main 2 6 52.1159 10 -
7 main 3 7 52.1159 10 -
8 main 4 8 52.1159 10 -

Secondly, if you wanted a temporary failure / disconnect in MoorDyn you would need to adjust the source code. This could be tricky, because if you disconnect the line and the body moves before you re-attach it you will get transients from the sudden spike in tension that could result in the simulation becoming unstable. The way the failure simulation capability works in MoorDyn is it adds a free point at the position of line failure, causing the end of the line to move freely. There is not a way to “undo” this during a simulation with the current code.

Dear @Ryan.Davies ,
I tried to implement the temporary disconnect in MoorDyn by changing the source code, similar to the code I had implemented for MAP++ as I gave in my previous post. I found in the subroutine Line_GetStateDeriv of source code that the way in which @Abhinay.Goga implemented the failure is now to be done in Point_DoRHS . So I changed the source code with my limited coding knowledge. the modification is given below.

  IF ((Point%time >= 400.0_DbKi) .AND. (Point%time < 410.0_DbKi)) THEN

DO J = 1,2
Point%Fnet(J) = Point%Fnet(J) - 0.5 * p%rhoW * Point%rd(J) * ABS(Point%rd(J)) * Point%pointCdA ! add drag forces
Point%M (J,J) = Point%M (J,J) + Point%pointV * p%rhoW * Point%pointCa ! add added mass
END DO
DO J = 3,3
Point%Fnet(J) = 0.0_DbKi
Point%M (J,J) = 0.0_DbKi
END DO
ELSE
DO J = 1,3
Point%Fnet(J) = Point%Fnet(J) - 0.5 * p%rhoW * Point%rd(J) * ABS(Point%rd(J)) * Point%pointCdA ! add drag forces
Point%M (J,J) = Point%M (J,J) + Point%pointV * p%rhoW * Point%pointCa ! add added mass
END DO

The source code is building okay.
Can you confirm that it is correct and will do the function of making vertical force to zero for interval 400-410 s?
The next question I have is how to reflect these changes to the simulation output in Fairlead tension. Will I need to make additional code modification?
Thanks in advance.
Best Regards

Hi @Nitin.Sivakumar,

Your solution seems like it will zero out any forces and mass contributions on the z axis. This won’t affect the tensions however, because this is done at the point level. This picture from the documentation might help:

You have effectively zeroed the vertical forces being passed upwards from the point to external objects. However the line itself calculates forces (and fairlead tensions) below the level of the point. So while anything coupling to MoorDyn via that point will not feel a vertical force, the fairlead tensions output by MoorDyn will be unchanged. If you wanted to get the net force from the point on external bodies (equal the fairlead tension in a simple system like the one you shared above), you can combine the x y and z forces from the point by post processing the outputs for channels Point#FX Point#FY Point#FZ.