Thank you for this opportunity to share my experiences with FAST.
I am modeling a TLP which is to support an upwind turbine, using FAST. The system has multiple tendons. I am modeling the system in the power-production mode (i.e. wind speed >11.4 m/s). When I commence the FAST simulation, i get the error message (within 8 timesteps) related to the small angle violation, and then eventually, the second error stating that a fairlead has passed below the anchor (within the next 5 timesteps). An image of the errors is attached. When I check my fairlead tensions in the .out file, they are either much smaller or much larger than the desired/conceptual pre-tension for all tendons in the system. I have used the same inertia and tendon properties used in this run to successfully perform OrfaFlex+FAST simulations. At this point, i don’t know the source of the error(s), however, i suspect that it is likely related to the buoyancy and pretensions in the system.
I would appreciate any guidance you can give me on how to overcome this error/problem.
Image of error.docx (38.9 KB)
Warnings regarding a “small angle approximation violation,” warnings regarding “supersonic blades,” a simulation crash, or very large deflections that occur in the time series near the start of a simulation are good signs of a numerical instability. Without knowing more about your simulation settings, it’s hard to know that what the problem is, but my guess is reducing the time step will help. See the following FAQ for guidance on selecting a time step for FAST v7: wind.nrel.gov/designcodes/FAQ.html#FASTTimeStep.
Thanks for your response. I will send you my run settings by email - that way you might be able to identify the problem causing my errors.
I was wondering if it is possible to analyse tendon failure in TLP Wind turbine with just FAST? Or do I need to use FAST + Orcaflex?
Thank you very much.
It is not possible to model the sudden loss of a mooring line or tendon and the resulting transient response through the setting of specifications in the FAST input file(s), but it is not a difficult source-code change to model such an event.
Regarding the previous post question, would it be possible to simulate a mooring line sudden disconnection/failure by means of the MAP++ flag “damage_time”?
Based on the description it seems like it is possible to specify a disconnection of a fairlead at a specific time. Assuming this is possible how this Flag input would need to specified in the MAP module input folder? For example in MIT TLP file:
---------------------- LINE PROPERTIES ---------------------------------------
Line LineType UnstrLen NodeAnch NodeFair Flags
(-) (-) (m) (-) (-) (-)
1 Material 151.73 1 2 tension_anch tension_fair damage_time 200
---------------------- SOLVER OPTIONS-----------------------------------------
repeat 270 180 90 0 270 180 90
I’m not sure. Actually, I was unaware that a damage_time flag was included in MAP++. I now see it in the MAP++ online documentation. Obviously, I’ve not used this feature myself. Perhaps Marco Masciola will respond. Alternatively, you can review the MAP++ source code to see how the damage_time flag is used.
That feature is suspended. Originally it was planned for the lumped mass model, along with other features INTEGRATION_DT, KB_DEFAULT, CB_DEFAULT. It can work for the quasi dynamic model with single lines, but becomes messy with interconnected lines. A dynamic line model can handle this more graceful. With that said, MAP would need to be customized to get damage_time to work with the QS model. Here’s a quick thought on one way to customize it:
The damage_time flag is assigned at initialization:
bitbucket.org/mmasciola/map-plu … nit.c-2178
This makes it possible to skip the line solve sequence in the function ‘solve_line’ (part of lineroutines.c) if damage_time_flag is equal to true. Check if ‘line_iter->options.damage_time_flag==true’. If it is, and if ‘line_iter->damage_time’ is greater than ‘time’, then the line no longer needs to be solved. The last step is to set ‘line_iter->H.value’ and ‘line_iter->V.value’ to a small value. This may work on systems with single-line elements, i.e., no ‘connect’ nodes.
Thank you for your reply and guidance. I will look into the information provided and try to simulate such event using the QS model making sure no connecting nodes exist.
Regarding other matters, I am traying to obtain the angle of the mooring line either to the horizontal plane or a vertical plane directly from MAP outputs but without much success. I have simulated simple cases to obtain these values directly through the outputs and calculated by hand the corresponding angulation but results do not match. The MAP fast outputs are having a strange behaviour and even a different name shows up from writen in the input line and obtained on output file. I list them as follows:
- azimut ->shows up as “psi” and having units in “m”. Also the obtained values do not make sense
- altitude → shows up as “alpha” and having units in “m”. Also the obtained values do not make sense.
Could you provide further advice on how to obtain this angulations and what does the previous values provide?
Thanks for pointing this out. The output header units should be in radians for the line azimuth and altitude; that’s an error. I just pushed a fix for this. The azimuth angle ‘psi’ evaluates to this:
bitbucket.org/mmasciola/map-plu … ines.c-266
and the altitude angles evaluate to this (also in radians):
bitbucket.org/mmasciola/map-plu … ines.c-187
The summary file outputs written at initialization maintains angles in degrees.
Than you once again for your quick confirmation and no worries on the units issue.
I have just verified my simple correlation cases and results do agree assuming the units provided for those outputs are in radians, so all set.
When I have more time I will look into the way to implement the line failure.
I have a relatively simple question. Is there a way to obtain the mooring line tension values at each time step in the FAST simulation using MAP++? I understand that indicating the ‘GX_force’ flag in the MAP++ input file outputs the force in the MAP++ summary file, but can FAST read this value at every time step and record it in the output file? I am currently using OpenFAST v.1.0.
Thank you for your help,
Kristopher Reed, EIT
Graduate Mechanical Engineering Student
University of Maine
Yes. Simply use the tension_fair and/or tension_anch flags in the “Line Properties” section of the MAP++ input file and the time series fairlead and/or anchor tensions for that line will be written to the OpenFAST time-series output file.
I am trying to enable a mooring loss by compiling the source code of FASTv8. The input file I’m using is test 24, whose CompMooring is set to 1(MAP++). However I can’t find the proper place in the source code which can simulate the sudden loss. Could you give any advise for this situation?
If all you want to do is zero-out the tension at the fairlead at some instance in time so that it does not apply a force to the wind turbine, without actually removing the line from the MAP++ model, simply set y%ptFairleadLoad%Force(:,i) = 0 for line "i’ at the end of SUBROUTINE MAP.f90/MAP_CalcOutput().
Thank you for your helpful information. Now one mooring line out of the three is simulated to be broken, but how would I know which specific line is broken? According to the output fair lead tension, I think the cable in line with the inflow wave direction was operated. Am I right?
Correct. The lines are numbered how they are entered in the MAP++ input file. In the OC3-Hywind model, line 1 is directed from the fairlead to the anchor in the zero-degree wave-propagation direction.
Thank you for your reply. One more question is that could I simulate another line to be broken by compiling the source code?
The source-code change I described above could be applied to any of the lines (“i”) in the MAP++ input file.
I changed the coordination of the nodes in the MAP++ input file as follow (to simulate the other line to be broken):
Node Type X Y Z M B FX FY FZ
(-) (-) (m) (m) (m) (kg) (mˆ3) (N) (N) (N)
1 fix -426.935 739.47 depth 0 0 # # #
2 Vessel -2.6 4.5 -70.0 0 0 # # #
However according to the output line tension, although the number of broken line changed from line1 to line3, the actual broken line is still the one align with load direction. I guess I might modify the input file incorrectly, could you please give any advice?