Bug report - MAP++ Problems with horizontal lines

[RBergua]

Bug description Some wave tank testing campaigns use horizontal mooring lines instead of catenary lines (see for example Section 2.4 from https://www.mdpi.com/2075-1702/11/9/865). In this case, the lines can be considered massless (monofilament fishing lines attached to a spring) and no hydrodynamic loading is considered (Cd = 0, Ca = 0, Cm = 0). This massless nature (i.e., no inertial loading in the lines) and lack of hydrodynamic forces would make the system a perfect candidate to be analyzed with MAP++ (quasi-static approach). Unfortunately, when running the system with MAP++, the system response is not the expected one. For example, when running a roll free decay, the outputs from MAP++ and MoorDyn v2 are clearly different. See the below plot for reference:

As it can be observed, the period in MAP++ is longer than in MoorDyn v2.

When looking at the fairlead tensions in the three mooring lines, the general trend is very similar. However, some differences can be observed between both solutions.

Interestingly, when looking at the 3 component forces (e.g., Fx, Fy, Fz) in the fairleads, clear differences between MAP++ and MoorDyn v2 can be observed. For the roll free day, it is expected that the vertical forces from lines 1 and 2 (located downwind) oscillate around positive and negative values. While the vertical force for line 3 (located upwind) should remain more or less constant. Somehow, when looking at the fairlead 1 vertical force, it can be observed that the loading in MoorDyn v2 oscillates to positive and negative values (as expected). However, in MAP++ the force is mirrored around 0 N. MAP++ cannot return negative forces in this vertical direction. Note that this negative component does not indicate line slack. There is still a large tension in the line (see plot above for reference). This negative Fz only indicates that the vertical component in this horizontal line becomes negative.

This impacts the system dynamics as shown in the first screenshot.

To Reproduce The input file used for MAP++ is attached below for reference: ---------------------- LINE DICTIONARY --------------------------------------- LineType Diam MassDenInAir EA CB CIntDamp Ca Cdn Cdt (-) (m) (kg/m) (N) (-) (Pa-s) (-) (-) (-) A 0.001 1 33862500 0 0 0 0 0 B 0.001 1 33816290 0 0 0 0 0 C 0.001 1 12285240 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 fixed 179.55 -305.69 -13.44 0 0 # # # 2 fixed 175.91 303.66 -13.58 0 0 # # # 3 fixed -186.97 2.94 -14.98 0 0 # # # 4 vessel 29.8 -51.5 -14.36 0 0 # # # 5 vessel 29.1 51.5 -14.36 0 0 # # # 6 vessel -59.4 0 -14.36 0 0 # # # ---------------------- LINE PROPERTIES --------------------------------------- Line LineType UnstrLen NodeAnch NodeFair Flags (-) (-) (m) (-) (-) (-) 1 A 268.75 1 4 tension_fair GX_FORCE GY_FORCE GZ_FORCE
2 B 266.27 2 5 tension_fair GX_FORCE GY_FORCE GZ_FORCE 3 C 99.88 3 6 tension_fair GX_FORCE GY_FORCE GZ_FORCE ---------------------- SOLVER OPTIONS----------------------------------------- Option (-)

OpenFAST Version This problem has been reproduced in OpenFAST v3.5.0 and OpenFAST dev (OpenFAST v4.0.0).

[jjonkman]

@RBergua -- I'm curious if you've compared the solution returned by MAP++ to an analytical solution of the catenary equations solved by MAP++, which, for example, are described in Eq. (19) of my 2009 Wind Energy journal article: https://onlinelibrary.wiley.com/doi/10.1002/we.347.

Perhaps MAP++ is assuming that the fairlead is always located above the anchor, e.g., by taking an absolute value of z_f somewhere?

Best regards,

[luwang00]

I think this bug is only confirmed for linear springs. I do see the absolute value being used for the vertical component of the force on line 670. Not sure if we have a similar problem with catenary lines. https://github.com/OpenFAST/openfast/blob/6b8706b75698cb1c97c6a8e3e9f42538a63fa71b/modules/map/src/lineroutines.c#L620-L672

[RBergua]

@jjonkman: The analytical formulation returns different values for positive or negative values of vertical distance (z_f). But the output of MAP++ always has one sign for the vertical force (and returns the analytical solution corresponding to a positive z_f). This means that the analytical formulation could, in theory, provide the expected outputs. But I guess it has been implemented in a way that z_f is assumed to be always positive (as expected in a conventional catenary line, but not considering our condition of horizontal lines or anchoring points located above the fairlead locations).

For reference, I checked the line 1 making the platform fixed in place. For these conditions, the inputs to the analytical formulation are:

And the solutions to the analytical formulation are:

For reference, the outputs from MAP++ are:

Note also that the vertical force in MAP++ (1.164E4 N) is the reaction force. That means that in reality MAP++ applies a force over the platform that pushes the system downwards instead of upwards.

@luwang00: I ran several tests also using the linear springs assumption in MAP++. I can confirm that the results with linear springs or catenary lines are very similar. Both have the issue with this force being always positive in the Z direction (i.e., pushing downwards). The line of code that you highlight clearly shows that the absolute value for the vertical force is used. My feeling is that for catenary lines, the code assumes that the vertical distance (z_f) is always positive (only true if fairlead location is above the anchoring location). That's why MAP++ returns a vertical force that matches the analytical formulation with the positive z_f and not the negative z_f.

This would mean that MAP++ would be effectively pushing the system downwards, but never upwards.

[jjonkman]

Thanks, @RBergua, for the clarification. I agree that this sounds like a bug. I'm not sure why the the code was implemented to only accept positive values of z_f given that the theory works for both positive and negative z_f.

[RBergua]

@jjonkman In line 288 of the source code, it can be observed that the vertical distance is always computed as the absolute value. https://github.com/OpenFAST/openfast/blob/6b8706b75698cb1c97c6a8e3e9f42538a63fa71b/modules/map/src/lineroutines.c#L283-L289

Unfortunately, if the code is modified to compute positive or negative vertical distances, the catenary solver of MAP++ fails. The source code requires further modifications...

I also tried the modification proposed by @luwang00 for the linear spring approach. In this case, MAP++ runs with the modification. Below you can see the outputs for the original MAP++ and the modified MAP++ for a free-decay in roll with an initial rotation of 6 deg:

However, the problem now is that the signs are opposite than expected. For example, when rotating the platform in roll 6 deg at t = 0 s: i. Line 1 should pull upwards (negative sign in MAP++). ii. Line 2 should pull downwards (positive sign in MAP++). iii. Line 3 should pull downwards (positive sign in MAP++).

For reference, the comparison against MoorDyn v2 is shown below. As it can be observed, both MAP++ solutions don't show the expected behavior:

To account for the proper behavior, it's necessary to change the sign in line 670: *(line->V.value) = -force.z;

By performing this additional modification, we can see that now the vertical forces behave as expected:

We can also compare the forces in MoorDyn v2 vs the forces in the modified MAP++. Note that to have the applied forces over the platform, the outputs from MAP++ below have been multiplied by -1. This way MoorDyn v2 and MAP++ are comparable.

As it can be observed, the agreement between MoorDyn v2 and the modified MAP++ is very good. Only some small differences can be observed, specially in the vertical force. These differences are observed for the three lines, but for the mooring line 3 becomes more obvious due to the y-axis range. These relatively small differences are likely due to the lack of mass and buoyancy for the line in the linear spring approach.

The fairlead tensions in the three lines can also be observed below:

Finally, we can see that the agreement between MoorDyn v2 and the modified MAP++ is also excellent in the roll free-decay motion:

Summarizing: we have a modified linear spring approach in MAP++ that returns the proper fairlead forces and system motions for anchor points that are above or below the fairlead connection.

I will perform some additional verifications and if everything works as expected, I will create a Pull Request with the code modifications so people with systems that have the anchor point above the fairlead connection can simulate the system using the linear spring approach in MAP++.

[jjonkman]

Thanks for tracking this down, @RBergua. To be honest, I was not even aware MAP++ supported the linear_spring option; good to know that exists and is being fixed.

Fixing the catenary solution to support fairleads below the anchor will require further work; probably also involving updating the Jacobian used in the Newton iterations. But I'm not sure who is responsible for MAP++ updates these days.