I am trying to reproduce the platform RAOs calculated by Denis Matha in “Model Development and Loads Analyis of an Offshore Wind Turbine on a Tension Leg Platform, with a Comparison to other Floating Concepts” (Figure 26) by using the available input files in “NRELOffshrBsline5MW_TLP”. For some reason the magnitude of the RAOs get bigger, and I am suspecting that it might have something to do with the definitions in HydroDyn.
The way I do it is setting CompAero to False in the FAST input file and WaveMod to 1 in the HydroDyn input file. I also set WaveHs to 2, but other than that everything is the same as originally. I first suspected that WaveHs is the same as the amplitude when choosing WaveMod as 1, but this did not solve the problem either. Is there something I am forgetting or doing wrong? The aim is to verify that I am using FAST correctly.
It would be great if someone could help me out on this.
I don’t see anything in your post that indicates a problem. When WaveMod = 1, WaveHs should be specified as the wave height (twice the wave amplitude). So WaveHs = 2 is correct for unit amplitude.
Did you ensure that the response fully converged on a solution periodic with the wave frequency before recording the ampitude of the reponse for your RAO calculation?
Thank you for your fast reply. The platform periodic response has the same period as the excited wave, except for heave mode which for some reason has approximately half the period. I don’t reallly know why this is occuring.
I noticed that TwrDraft in the HydroDyn input file is set to 0. Shouldn’t this parameter be a negative number, since from what I understand by the drawings of the MIT/NREL TLP the platform/tower connection is above the MSL. I can’t find information anywhere about the exact position of this coupling. But I am thinking that maybe this is causing the different results I am getting. For instance, at omega equals 1.4 rad/s the pitch RAO becomes approximately 1, which is 18 times larger than the result Matha got.
I also have a question regarding the spokes of the platform. Are the mass of these included in FAST?
Due to the tendon arrangement, when the MIT/NREL TLP surges downwind it heaves downward and when it surges upwind it heaves downward. So, the heave mode appears to have half the period as surge.
We’ve set TwrDraft to 0.0 for the MIT/NREL TLP even thought the actual connection between the tower base and platform is above the MSL. This was so that we could easily compare the tower-base loads between the TLP and land-based wind systems. We’ve felt that this was a reasonable approximation.
Have you properly normalized the RAOs for roll, pitch, and yaw? An RAO is dimensionless and the rotational displacements output by FAST are in degrees. Thus, you must convert the output of FAST to radians and multiply by a length scale to properly normalize the RAOs. I believe we used the platform radius (9 m) as the length scale. Thus, the output of FAST must be scaled by a factor ( 9 m )*( Pi rad )/( 180 deg ).
Thank you for your help. The pitch RAO seems to be more correct now. However, I am still getting some deviations from the previous calculated RAOs, and I think maybe it has something to do with the PcMode and VSContrl options in the FAST input file. I would think these didn’t matter for the computations when CompAero is False, but the RAOs change when I change these parameters. What should these be set to in order to achieve correct RAOs? I am using FASTbladed.exe and RotSpeed is set to 12.1 rpm. I run the simulations for 1200 s, and record RAOs after 1000 s to make sure the solutions have converged.
I believe the RAOs reported by Denis Matha were computed with CompAero = True at steady uniform 11 m/s wind, with torque and pitch control enabled.
thank you for clearing that up. I was a bit confused on whether Matha had included the steady wind in his computations in FAST.
I have another question it would be great if you could answer. When running FAST with another TLP with draft of 44 m I am getting the error: “Unstretched mooring line length too large. Routine Catenary() cannot solve quasi-static mooring line solution.” I tried decreasing the parameter LUnstrLen, which is 156 m in the platform input file, but this did not solve the problem. Do you have any ideas of what might be causing the problem?
Thank you for your help.
The error you are reporting is generated when the mooring line is so slack that there is no unique solution of the quasi-static catenary equations.
Was this error generated during a time-domain or linearization analysis?
In a TLP time-domain analysis, you should see the anchor tension dropping to (near) zero just before error is generated. Obviously, it is not desirable for the lines to go slack in a TLP; the TLP and/or mooring system should be redesigned in this case.
In a TLP linearization analysis, the slack lines may be generated from too large of a platform perturbation. (FAST uses a central-difference perturbation method to calculate the linearized matrices.) In this case, it is necessary to reduce the size of the platform perturbations in the linearization process (this will require a recompile of FAST).
In all cases, changing the value of LSeabedCD to be negative would eliminate this error. (Setting LSeabedCD to a negative number eliminates the seabed model and allows the line to pass below the seabed.) This may be useful if you wish to run time-domain simulations to see how often the TLP lines go slack.
I hope that helps.
I was doing a time-domain analysis, and by changing the design a bit such that the average line tension increased the problem was solved. Thank you so much for helping me.
Dear Jonkman ,
I want to know where we can find that normalized factor ? is it a input ? or is it some where in FAST files.
Actually WAMIT output are normalized by its unit length (ULEN) which we will decide. then how can FAST know about this means what is the normalized factor ?
For me the error: “Unstretched mooring line length too large. Routine Catenary() cannot solve quasi-static mooring line solution.” sometimes comes , sometimes didn’t come and i am using the same configuration for all the cases. Why this is happening may be some other parameter will also affect this.?
WAMIT nondimensionalizes its output based on the WAMIT length-scale input parameter, ULEN (and other values). When the WAMIT data is read in by FAST’s HydroDyn module, HydroDyn will redimensionalize the data; in this process, HydroDyn assumes that ULEN is unity (1). We have added ULEN as an input parameter for our next release of HydroDyn. Until then, if you have run WAMIT without ULEN = 1 and you wish to use this data within HydroDyn, you can recompile FAST with the parameter PtfmULEN from SUBROUTINE InitFltngPtfmLd of HydroCalc.f90 set to the desired value.
As I stated above, if you received an error about “unstretched mooring line length too large”, the mooring line is so slack that there is no unique solution of the quasi-static catenary equations, so, FAST cannot solve them. This could be because the mooring system is not designed properly or there is some other problem with your model. Your question is too general for me to give a specific solution.
I am a newbie in hydrodynamics. I am learning FAST by redoing the RAO calculation of NREL 5MW TLP as Matha in his thesis. I compared my results with the data in Figure 26 of Matha’s thesis. I have read all the above disscussion in this thread.
I only changed WaveHs=2, WaveTp as the income wave period, Tmax=1230, and the response is from output of “PtfmSurge, PtfmSway , PtfmHeave PtfmRoll , PtfmPitch, PtfmYaw”.
The wind data is listed below.
! Wind file for Trivial turbine.
! Time Wind Wind Vert. Horiz. Vert. LinV Gust
! Speed Dir Speed Shear Shear Shear Speed
0.0 11.0 0.0 0.0 0.0 0.0 0.0 0.0
0.1 11.0 0.0 0.0 0.0 0.0 0.0 0.0
9999.9 11.0 0.0 0.0 0.0 0.0 0.0 0.0
The RAO is calculated by the 0.5*(max-min) response of last period.
For RAO of heave, I found my results is one tenth of Matha’s, but for RAO of yaw, my results is tenth bigger than Matha’s.
This problem has confused me for several days. Thanks for your help.
I have found the error in my program.