Floater behaviour deviation openfast3.5 and openfast v4.02

[mebrahiimi]

Dear all,
I am simulating IEA15MW with a designed floater, when I changed the files from V3.5 to V4. I faced some problem.
The mooringlines consists of three section, so we have 12 points in the mooring line input file, and 9 lines, one line type is defined with a strain-tension table in the EA (out of two).
with V4 I can see repetitive warning:
Warning: extreme pitch moment from body-attached Point 2
Warning: extreme pitch moment from body-attached Point 3
Warning: extreme pitch moment from body-attached Point 1
Warning: extreme pitch moment from body-attached Point 2
Warning: extreme pitch moment from body-attached Point 3
Warning: extreme pitch moment from body-attached Point 1
Warning: extreme pitch moment from body-attached Point 2
Warning: extreme pitch moment from body-attached Point 3
Warning: extreme pitch moment from body-attached Point 1
Warning: extreme pitch moment from body-attached Point 2
Warning: extreme pitch moment from body-attached Point 3
...
I saw another discussion in the forum about this warning, I tried to reduce dtM until one hundred times but it didn't solve the warning problem.
In the platform motion, a strange motion of heave, surge, and sway can be seen, as follows

I can see a very big FAIRTEN1 in case of V4.02, which is wrong, the value is very huge. (Fairten1 is attached to the seabed, FAIRTEN3,6,9 are attached to the floater, and 2 is the middle line)

Also you can see this problem doesn't affect the power

so, my question are

1. what makes a mooring line doesn't work properly in V4, so the tensions are noise or too much in value? how does a mooring line configuration is stable in one version and considered as unstable in another one?
2. Why the behavior of the motions are different from V3.5 to the V4.
3. By considering the difference in the heave average of platform, the generated powers should be different, but they are not.

Thank you,
BR,
Majid

[RyanDavies19]

Hi @majidpoli,

Are you able to share your input files (MoorDyn and the Strain-Tension lookup)? I would suspect that implementation might be the issue.

[mebrahiimi]

@RyanDavies19

Here are the files.

BR,

[RyanDavies19]

Hi @majidpoli,

A few notes for things you should try. First, you cannot have automatic damping calculations when you give a custom stiffness look-up table (i.e. your BA/-zeta value being -0.8 for your Poly line type). Because the damping calculation relies on the axial stiffness, it cannot be completed for a nonlinear stiffness curve. I will add a warning to the next MoorDyn update that addresses this. This is the likely source of your noise in those outputs.

I would also suggest double checking that the locations of the points attached to your platform are correct, those initial transients seem like there is a discrepancy there. When I run your MoorDyn input file with the driver (i.e. platform position fixed, no wind), fairlead tensions are on the order of 0.5 MN. When you ran this with V3.5, what was FAIRTEN1?

A couple other things to note: your input file states that Water Kinematics are not supported in MoorDyn. They can be if you provide a file path for that option, with the format as described here: https://moordyn.readthedocs.io/en/latest/inputs.html#water-kinematics-file-moordyn-f

Also, the value FrictionCoefficient has been dropped in favor of an axial and transverse friction coefficient, given by MU_KA and MU_KT respectively.

[mebrahiimi]

Dear @RyanDavies19
I put a positive value of 0.8 for damping, and it solved the warning of the V4.
For your question about FAIRTEN1 in V3.5, (I haven't paid attention to it), it's a fix value of 1.5 MN.
By changing damping coefficient and replacing the friction coefficient, still starng behaviour of platform can be seen, also the noises still remain.

BR,

[RyanDavies19]

Hi @majidpoli,

With a damping coefficient of 0.8, you will effectively have an undamped system, so the noises make sense. Normally the damping coefficient is on the order of 10^5, but is dependent on the specific properties of your mooring line. A fixed value of 1.5 MN in the v3.5 simulations makes me suspect that there was something wrong with how that simulation was ran. A constant value would only occur if the line ends were fixed in place and not moving.

[mebrahiimi]

Dear @majidpoli

I tried higher value of damping coefficient like 1e6, and the abrupt changes of the tensions signal in V35 disappeared (second figure, 4th and 5th plot- blue lines).
Also I fixed the problem of the heave deviation, now for both cases are around zero.
Still I have strange behavior in surge-sway motion and in the tensions in V4.
one question: what do you think of this error, are they some problem with the mooring config, which are not consistent just with the V4, or maybe there is bug in V4,

Thank you for your time,
BR,

[RyanDavies19]

Hi @majidpoli,

I would guess that the custom stress-strain curve is making the mooring system quite compliant. It seems that as the turbine thrust ramps, the surge increases. Have you double checked that is correct? The tension values should be in N.

For troubleshooting, I would try choosing a constant axial stiffness value, on the order of 1e8 N or so. If you still see strange behavior with that then it would be worth double checking your mooring design.

[mebrahiimi]

Dear @RyanDavies19

I replaced the table of strain-tension with the value of 1e08.
What we can see still FAIRTEN1 is too high for V4.
but the high frequency behavior of FAIRTEN6, 9 vanished.
In thrust, I can't see strange behaviour.

What do you think, I'm like 95% sure that there's something wrong in the moorings defined points, and in V35, the tool doesn't care, but in V4 it makes the simulation some sort of unstable. OR in V4, the system is not fully constrained

BR,
Majid

[RyanDavies19]

Hi @majidpoli,

Because FAIRTEN1 is constant in time in both v3 and v4, that means that the fairlead (end B of the line) is not moving. Have you double checked that Line 1 is attached to a point that can move? This is most likely an issue with your input file formats rather than a bug in the code. I'm happy to look at your OpenFAST input files that produced the plots about if you provide them.