TowerHt would be B? (B is 107m)
TowerBsHt would be (C=9m)+18m= 27m?
If so, should I provide the tower distributed properties from 0 to 107m? Or only for the 80m (107-27) of ‘real’ tower?
If I give values only for the 80m tower, I will violate the inequality TipRad<TowerHt+Twr2Shft+(OverHang*sin(ShftTilt). My blades are extraordinarily large and flexible.
If I give values for the 107m tower (let’s imagine I can figure out how), is there any problem later in SubDyn when I give the full description of the substructure?
My turbine is a kind of nearshore or quasi-offshore configuration (see the photography). It has water (0.5m or so, and there are include into the 18m in the drawing) only during the high tide. In this case, and having in account that the wave loads are going to be small, would be better to model it as an onshore turbine?
If so, how that will affect the previous questions?
Based on your drawing, TowerHt in ElastoDyn should be 107 m, TowerBsHt in ElastoDyn should be 27 m, the distributed tower properties should be specified along 80 m (that is the tower base is at 27 m above mean sea level (MSL), and the tower top is 107 m above MSL), and the SubDyn model should extend up to 27 m above MSL. HydroDyn can be enabled/disabled independent from SubDyn, so, you can choose to enable HydroDyn for only cases where hydrodynamic loads are important.
Thank you very much for your prompt and useful answer.
Giving distributed values for the 80m, and setting up TowerHt=107m gives me the next error message:[code]FAST_InitializeAll:InitModuleMappings:ED_L_2_AD_L_T:MeshMapCreate:CreateMotionMap_L2_to_L2:CreateMapping_ProjectToLine2:Node 1 does not project onto any line2 element.
FAST encountered an error during module initialization.
Simulation error level: FATAL ERROR
Aborting FAST.[/code]
Could be because I didn’t set up SubDyn yet?
In AeroDyn15, I have provided distributed tower properties from 0 to 80m. Is it correct?
That mesh-mapping error has been discussed in the following forum topic: Meshing error? - #2 by Jason.Jonkman. Basically, AeroDyn can only provide aerodynamic loads on the tower; it cannot map aerodynamic loads below the tower or onto a substructure modeled in SubDyn.
in case I would like to model a land-based full lattice tower and based on Jordi’s drawing in the beginning of this topic, TowerHt should be equal to TowerBsHt, shouldn’t it?
If so, I get the following error:
FAST_InitializeAll:ED_Init:ED_ValidateInput:ValidatePrimaryData:TowerBsHt must be less than TowerHt.
Furthermore I tried to overcome this by setting TowerHt to a slightly greater value, such as TowerHt = TowerHt +0.001, but then the next error arose:
CalcOutputs_And_SolveForInputs:SolveOption1:FullOpt1_InputOutputSolve:LAPACK_SGETRF: U(7, 7)=0. Facut U is exactly singular.
As prescribed in the SubDyn Manual on pages 29-30, all 6 platform DOF’s have been enabled and all tower bending DOF’s have been disabled. Here I show you the relevant part in my ElastoDyn file, where the full lattice tower should have the same hight as the reference 5MW NREL tower:
87.601 TowerHt - Height of tower above ground level [onshore] or MSL [offshore] (meters)
87.6 TowerBsHt - Height of tower base above ground level [onshore] or MSL [offshore] (meters)
0 PtfmCMxt - Downwind distance from the ground level [onshore] or MSL [offshore] to the platform CM (meters)
0 PtfmCMyt - Lateral distance from the ground level [onshore] or MSL [offshore] to the platform CM (meters)
87.6 PtfmCMzt - Vertical distance from the ground level [onshore] or MSL [offshore] to the platform CM (meters)
87.6 PtfmRefzt - Vertical distance from the ground level [onshore] or MSL [offshore] to the platform reference point (meters)
Probably I misunderstood or forgot something. Can you help me, please?
I’m not sure, but it sounds like the Jacobian relating the loads and accelerations between SubDyn, ElastoDyn (and perhaps HydroDyn if you have that enabled) calculated within FAST is singular for some reason e.g. because a mass or inertia is specified as zero. You can look at the Jacobian directly by recompiling FAST with compiler directive OUTPUT_JACOBIAN defined and then rerunning the simulation. I suggest starting there to debug.
thank you so much for your helpful reply. I did what you said and found out that the Jacobian has been singular, first. Therefore I introduced artificial inertias to the platform:
2.60789E+05 PtfmRIner - Platform inertia for roll tilt rotation about the platform CM (kg m^2)
2.60789E+05 PtfmPIner - Platform inertia for pitch tilt rotation about the platform CM (kg m^2)
2.60789E+05 PtfmYIner - Platform inertia for yaw rotation about the platform CM (kg m^2)
This solved the problem and the Jacobian is not singular anymore. Furthermore the loads seem to be consistent in terms of this full lattice configuration. What I mean by “consistent” is that the Yaw loads ≈ Tower Base Loads ≈ SD Interface Loads. In this case I arbitrary chose the artificial platform inertias to be 10% of the nacelle yaw inertia and I am wondering, if these inertias would have a significant influence to the simulation results. This questions comes up especially because I run into a “small angle violation error due to a large platform displacement” for smaller artificial platform inertia values. Maybe there is another way, do you have an idea?
My understanding is that you’ve placed the “platform” at the tower-top. So, effectively, the platform is now coincident with the nacelle.
Must you apply the same inertia in all directions (roll, pitch, yaw)? In yaw, I would guess that you’d only to specify a nonzero platform inertia if you’ve also enabled the nacelle-yaw DOF; otherwise, I would think the nacelle-yaw inertia that you’ve specified would suffice. In roll and pitch, neither of these inertias are specified for the nacelle (and they are assumed to be zero within ElastoDyn); perhaps this is why you need nonzero values for those.
Yes, if I disable the yaw-DOF, only roll, and pitch platform inertias are required. Enabling the nacelle-yaw DOF requires additional artificial platform inertia around the yaw axis.
Okay, but for me, artificial platform inertias of >10e4 kg m² seem to have no negliable influence to the whole system. I assume that they would reduce the global bending and torsional natural frequencies of the system integrated tower, which would be an assumption on the safe side in terms of following a stiff-stiff tower design philosophy, wouldn’t it?
Did you mean to say that the artificial platform inertia has negligible influence on the whole system?
Yes, reducing the natural frequency of a stiff-stiff tower would be conservative.
Regardless, I was implying that you don’t specify an “artificial” inertia, but instead apply the “real” inertia of the nacelle about the roll and pitch axes that are currently neglected by ElastoDyn.
I am not sure - that was my question. Furthermore I assumed that artificial platform inertias would decrease the bending and torsional natural frequencies. Therefore it would be conservative to introduce those artificial platfrom inertias for a stiff-stiff tower.
No, the roll and pitch inertias of the nacelle where never specified for the NREL 5-MW turbine. Using artificial values as you propose is probably best.
Hi Jason,
I came across some problem relating to hub height. I have noticed that my simulation is aborted when hub-height is around 80s.
I have reduced the grid-height in TurbSim to a small value(=2) which took a good amount of time to terminate TurbSim input file. But when I run the FAST input file, I get the following error. I know such kind of error has already been addressed in another forum, but I couldn’t resolve this issue by any means.
Do you think taking such a small hub height causes such kind of error?
I have attached error I am receiving when hub height is 85m and rotor diameter is 137m.
The grid height in TurbSim should be set larger than the rotor diameter (in your case larger than 137 m); I’m not sure why you have set it too a small value.
Thank you so much. The model is working fine when GridHeight is increased to 140 and NumGrid_Z reduced to 10.
I might have misinterpreted to what has been discussed.
I have a FAST7 model of an onshore turbine where TowerDraft has a value unequal to zero. Now I want to set up a FAST8 model representing the FAST7 model. But when I set the TwrBsHt to a negative value FAST aborts with the error:
“FAST_Solution0:CalcOutputs_And_SolveForInputs:SolveOption2:InflowWind_CalcOutput:CalcOutput:IfW_UniformWind_CalcOutput:GetWindSpeed:Height must not be negative. IfW_UniformWind_CalcOutput: Error calculating the wind speed at position (x, y, z) in the wind-file coordinates”
with z<0
If I don’t respect that part of the tower under the ground level, my tower is to short and light weight.
Is there a way to include the part of the tower under the ground level for an onshore wind turbine?
You should be able to set TowerBsHt to less than zero in FAST v8, as long as you are not modeling a floating offshore wind turbine, which FAST assumes has a rigid platform. The locations of the nodes where wind is calculated in the InflowWind module are not dictated by TowerBsHt, but by the locations of the aerodynamic nodes in AeroDyn. Have you tried to define analysis nodes in AeroDyn to be below the ground?
I defined my tower for AeroDyn between 0 and 1 but with your comment I guess that if I set TwrBsHt to a negative value the tower length he uses as reference is the total length (TowerHt +TwrBsHt) so then the TwrHtFr=0 would be under the ground and I would need to start with a value higher than 0.
Ah;I thought that you were using AeroDyn v15, but you are actually using AeroDyn v14.
In AeroDyn v14, the tower discretization in ElastoDyn is used by AeroDyn, so, you cannot extend the tower in ElastoDyn below the ground if you’ve enabled tower aerodynamics. However, in AeroDyn v15 the aerodynamic nodes are independent from those in ElastoDyn, allowing you to extend the tower in ElastoDyn below the ground. So, you can either upgrade from AeroDyn v14 to AeroDyn v15, disable tower aerodynamics in AeroDyn v14, or don’t set TowerBsHt in ElastoDyn negative.
