FAST and wind loads on tower

Dear all,
as the subject suggests I would know if FAST take into account the action of the wind on tower either in platform load calculation and in local tower sensors calculation.

thanks in advance
ste

Dear Stefano,

The short answer is “not yet.”

The current version of FAST–or more correctly, AeroDyn–does not calculate any loads on the tower. This is one of the most requested enhancements because the wind load on the tower is an important load in extreme wind conditions. We are busy working on the AeroDyn overhaul. The new interface that we are developing between FAST and AeroDyn will permit sharing of the proper data for tower aerodynamics (e.g., tower positions and velocities). Once this new interface is complete (which should be soon), adding tower aerodynamics is one of first new features we plan on adding.

Until then, FAST has a “hook” for user-defined tower loading. You can add your own tower aerodynamics calculations here if you can’t wait for the new versions.

Best regards,

Hi Jason,
thanks for the quick reply. I will wait for the next release of the software. Do you guys have any timeline for that release?

Btw, I’ve seen from the output data contained in a CertTest folder that exists a newer version of FAST something like 6.10 (not sure but certainly greater than 6.01) and newer AeroDyn.
Is there a public repository for such alpha/beta FAST/AeroDyn code like for MCrunch?

Thanks again.

cheers
ste

Hi Sefano,

The AeroDyn overhaul is progressing in two paths: (1) developing a clear and streamlined interface between AeroDyn and the various structural-dynamic codes and (2) making the internals of AeroDyn much more modular such that new aerodynamic theories (like tower aerodynamics loading) can be added in the future. We are on track to release the interface from path (1) in late March 2010. Along with the improved interface in this upcoming release, we plan to include (a) an improved tower influence model (with upwind interference), (b) the ability to read in additional wind file formats, (c) improved error handling, and (d) IVF compatibility. We are calling this version AeroDyn v13, but it does not contain the tower aerodynamics loading. The modularization of AeroDyn with improved functionality (including tower aerodynamics loading) from path (2) will come later, but likely not until 2011.

There are alpha versions of FAST newer than v6.01. These alpha version are not typically (1) thoroughly tested and (2) documented with updates to the User’s Guide. This, of course, makes them much hard to “support,” so we do not make these alpha versions publically available. We make them available to those who know about them, reqeust them, and would like to use/test the new features.

Best regards,

Hi Jason

Back in March 2010 you thought that you might have a version of FAST that took account of wind loading on the tower by 2011. I’ve had a rummage thruogh the manuals and I can’t find anything. Also I can’t find any tower diameter - height profile in the input files which I think would be needed for these calculations.

Are you able to give a fresh update on the status of this work?

Thanks

Alec

Dear Alec,

We are still making progress on the overhaul, but the progress is slower than we had originally hoped. Regarding my earlier post, the interface from path (1) was completed with the release of AeroDyn v13.00.00a-bjj. This version of AeroDyn includes the updated tower-influence (“tower dam”) model, but not direct wind loading on the tower. See the following post for more information: http://forums.nrel.gov/t/normal-aerodynamic-forces-on-the-tower/379/1. We are still working on path (2) and will include direct wind loading on the tower in that version.

Best regards,

I have updated FAST with a modified version of UserTwrLds. Thanks for setting this subroutine out so clearly. There wasn’t much left for me to do actually. I am now trying to work out how to output the external wind loads from FAST so that we can use them in an external program (SACS). This posting is about distinguishing between aero and hydro loads on the respective parts of the structure.

I need to be sure that the wind loads are only calculated for locations on the tower above the water line. The FAST manual clearly shows two heights (Figure 20):-

  1. TwrDraft for the vertical distance between the lower limit of the flexible part of the tower and the water level and
  2. TowerHt for the vertical distance between the water level and the yaw bearing

Please can you confirm that (a) these are both used in the code, (b) my understanding (above) is correct and that (c) the water level is fixed by the relative values of these two parameters before the simulation is run?

There’s a DO loop in RtHS, which calculates external loads for each node (see below).

DO J = 1,TwrNodes

ENDDO ! J - Tower nodes / elements

TwrLoading is called twice in this loop. Once to compute the external forces, TwrFt (but only if CompAero) and once to compute the added mass matrix, TwrAM. The stated purpose of UserTwrLd is for computing additional external loads on the platform, so I would expect that this loop includes tower elements below the water surface.

If I am right and the loop above only runs between the water level and the yaw bearing, please can you tell me which loop deals with hydrodynamic loads on sub-structure?

Kind Regards,

Mark

additional discussion on tower wind loading is in the following thread:-
http://forums.nrel.gov/t/normal-aerodynamic-forces-on-the-tower/379/1

It looks as though my understanding may have been wrong and the number of tower nodes (TwrNodes) is used to divide up the whole structure from the bottom of the flexible part of the pile to the yaw bearing. The excerpt below is from RtHS and calculates the height at which wave kinematics should be calculated and external loads applied to the sub-structure.

NWaveKin0 = TwrNodes
DO J = 1,NWaveKin0 ! Loop through the tower nodes / elements
WaveKinzi0(J) = TwrRBHt + HNodes(J) - TwrDraft
ENDDO ! J - Tower nodes / elements

I think I have answered my own question (see previous posting). Jason recently sent me the expression for the height of the tower element mid-point.

TwrRBHt + ( J – ½ ) • [ ( TowerHt + TwrDraft – TwrRBHt ) / TwrNodes ])

This also suggests that the total sub-structure length (height) is divided up into TwrNodes elements. I ought to test whether the current node is submerged or in the wind.

(height < TwrRBHt) ------------ therefore rigid (base section)
(height < TwrDraft .AND. height > TwrRBHt) ------------ therefore submerged
(height > TwrDraft .AND. height < TwrDraft + TowerHt) ------------ therefore in the wind

Only in the latter situation should aerodynamic drag forces be calculated and applied to the element.

Kind Regards,

Mark

Dear Mark,

Your understanding of TwrDraft and TowerHt is correct.

When the user-defined tower loading option is enabled, FAST will call routine UserTwrLd separately for each tower node for each structural time step, but it is not called twice within the DO J = 1,TwrNodes… loop. (Actually to be exact, because FAST employs a predictor-correct time-integration scheme, FAST solves the equations of motion twice per time step – once for the predictor and once for the corrector – and so, FAST will call UserTwrLd twice per node per time step, but this is not within the DO J = 1,TwrNodes… loop.) Whenever UserTwrLd is called, the values of the external force per unit length, TwrFt, and added mass matrix per unit length, TwrAM, must both be calculated and returned for that node. UserTwrLd is called for all tower analysis nodes–both those below and above the water, so, UserTwrLd can be used both for external aerodynamic and hydrodynamic loads.

The equation you give for the tower analysis nodes elevations is correct, but that equation gives the tower elevations relative to the tower base (that is, at a distance of TwrDraft below the mean sea level (MSL)) and assumes that the tower is not deflecting and that the platform is not displacing. The actual position of the tower analysis nodes relative to the inertia frame origin at MSL is input to UserTwrLd routine (that is, X). If you want to know if a given analysis node is above the MSL at the current time, you should check “IF ( X(3) >= 0.0 )”.

I hope that helps.

Best regards,

Thanks a lot, Jason.

What I would like is to enable the user to set a switch controling whether or not to write out all the external wind loads on the tower (not just at the gauge locations). The reasons for this are (1) QA of new code (2) to have a complete set of external loads to be able to apply the identical actions to a model of the structure in SACS (time-domain dynamic simulation). The neatest thing I think would be to use the existing subroutines and the AllOuts array to write to the single FAST output file every time step. However, the size of AllOuts is controlled at compile-time by a parameter and therefore may not be altered based on the user-selected number of tower nodes TwrNodes. What would be possible though is to allocate enough elements to OutData at run-time and to insert the array (external wind loads) each time step into OutData using a DO loop to transfer all the elements of FTAero into OutData. The key lists of parameters, ValidParamAry, ParamIndxAry and ParamUnitsAry may still be used, but the index for FTAero would point to a dummy location in AllOuts, which was not used to store the data. The alternatives would be either to output up to 9 locations per time step, controled by the user-defined gauge locations or not to output FTAero at all via AllOuts or OutData. In the latter case, a completely separate output file would need to be opened for writing each time step and data merged after the simulation.

Kind Regards,

Mark

I have just successfully compiled a version of FAST with tower wind loads (aerodynamic drag forces). The following might be useful to others working on FAST and AeroDyn developments. I am sorry if this is already stated somewhere else, I am relatively new to FAST (July 2012). Also, please correct me if I have misunderstood something (this was the result of a bit of trial-and-error).

The SUBROUTINEs and FUNCTIONs in the various FORTRAN files associated with AeroDyn are all contained within MODULEs (MODULE AeroSubs and MODULE AeroDyn). The consequence of this is that it is necessary to include a USE statement at the beginning of any SUBROUTINE or FUNCTION which needs to call one of these SUBROUTINEs or FUNCTIONs (example below). Conversely, the SUBROUTINES in the various FORTRAN files associated with FAST are all at the “top level” (I don’t know the technical term for this) and so do not need an explicit USE statement but may simply be called from any other SUBROUTINE or FUNCTION in a file associated with the FAST project.

USE AeroDyn, ONLY: AD_GetConstant
USE AeroSubs, ONLY: GetTwrSectProp

I want to call the FUNCTIONs AD_GetConstant and GetTwrSectProp in my routine so that I can calculate the air density and find out local values of the tower radius and drag coefficient. These functions are in the following files AeroDyn.f90 and AeroSubs.f90

Hi, Mark.

I’m don’t think this is exactly correct (or maybe I misunderstood what you are saying):

If a SUBROUTINE or FUNCTION is defined in MODULE “A”, that SUBROUTINE/FUNCTION can access anything else also defined in MODULE “A”. If there is a USE statement at the top of MODULE “A” (say, USE MODULE B), then everything in MODULE A can also access anything in MODULE B (assuming there is no PRIVATE statement defined → PUBLIC is the default attribute). If there is no “USE MODULE B” statement, then the subroutines/fuctions contained in MODULE A cannot access anything MODULE B.

Modules that do not contain a PRIVATE statement do, however, also pass the USE association of modules they use. For example, if MODULE “C” contains a statement “USE MODULE D”, anything that uses module “C” also gets access to everything in module “D” (without explictly saying “USE MODULE D”).

I hope that makes sense. :slight_smile: Basically, if something is contained in a different module, you will need a USE statement to have access to it, but the USE statement may be inherited from another MODULE.

Dear Bonnie,

This functionality sounds very useful and I had not gleaned this from my experiments. I think the compiler should issue a warning if you have a USE statement, referring to a module which has already been linked to elsewhere in the module.

I have just added in new output for the external forces on the tower due to aerodynamic drag. I have added a switch called TWFtAero at the end of the list of user-selected outputs in the primary FAST intput file (called “OutList”). If this is present, then the two horizontal components of FtAero will be written to the output file.

In the process of including this option for additional output, I discovered an issue with setting the size of the list of user-selected outputs. The primary input file must first be read before the number of user-selected outputs is known by FAST. Then the list variable (OutList) can be dimensioned. Then OutList can be populated. For this reason, I have created a DO loop just to check and count the user-selected outputs. I have then closed and reopened the primary input file, set the size of the OutList array (ALLOCATE), skipped to the list of user-selected outputs (OutList) and the re-read the list.

  • I cannot understand how this was done previously in FAST.
  • If OutList is not dimensioned, I get the error “access violation” if I try to write any character string to a location in OutList.
  • It also seems like good programming practice to declare the dimensions of an array explicitly before using it.

Kind Regards,

Mark

Please can you tell me how the aerodynamic drag coefficient is calculated by FAST from the table, defining the relationship between Reynolds number and drag coefficient? I changed the input file so that, instead of a single value, a table of five values is used in the input file. I was expecting FAST to interpolate between values, but instead, the values were mostly given as NaN (not a number). What am I doing wrong? Many thanks.

Below I have reproduced three versions of the tower input file.

PREVIOUSLY:-

NREL 5.0 MW offshore baseline aerodynamic tower CD input properties.
Used with AeroDyn 13.00.00 hidden tower influence feature.
12 NTwrHt - Number of tower input height stations listed (-)
1 NTwrRe - Number of tower Re values (-)
1 NTwrCD - Number of tower CD columns (-)
0.0 Tower_Wake_Constant - Tower wake constant (-) {0.0: full potential flow, 0.1: Bak model}
---------------------- DISTRIBUTED TOWER PROPERTIES ----------------------------
TwrHtFr TwrWid NTwrCDCol
0.00000 6.000 1


---------------------- Re v CD PROPERTIES --------------------------------------
TwrRe TwrCD1 TwrCD2 TwrCD2 …
1.0 0.0

MY CHANGES:-

NREL 5.0 MW offshore baseline aerodynamic tower CD input properties.
Used with AeroDyn 13.00.00 hidden tower influence feature.
12 NTwrHt - Number of tower input height stations listed (-)
5 NTwrRe - Number of tower Re values (-)
5 NTwrCD - Number of tower CD columns (-)
0.0 Tower_Wake_Constant - Tower wake constant (-) {0.0: full potential flow, 0.1: Bak model}
---------------------- DISTRIBUTED TOWER PROPERTIES ----------------------------
TwrHtFr TwrWid NTwrCDCol
0.00000 6.000 1


---------------------- Re v CD PROPERTIES --------------------------------------
TwrRe TwrCD1 TwrCD2 TwrCD2 …
1.0 1.0
1.1 1.1
1.2 1.2
1.3 1.3
1.4 1.4

I ALSO TRIED THE FOLLOWING:-

NREL 5.0 MW offshore baseline aerodynamic tower CD input properties.
Used with AeroDyn 13.00.00 hidden tower influence feature.
12 NTwrHt - Number of tower input height stations listed (-)
2 NTwrRe - Number of tower Re values (-)
2 NTwrCD - Number of tower CD columns (-)
0.0 Tower_Wake_Constant - Tower wake constant (-) {0.0: full potential flow, 0.1: Bak model}
---------------------- DISTRIBUTED TOWER PROPERTIES ----------------------------
TwrHtFr TwrWid NTwrCDCol
0.00000 6.000 1


---------------------- Re v CD PROPERTIES --------------------------------------
TwrRe TwrCD1 TwrCD2 TwrCD2 …
1.0 1.0 2.0

Mark,

I’m behind on answering your questions here, but hopefully this still helps:

Currently, the OutList array is dimensioned to the size of the MaxOutPts parameter at compile time:

CHARACTER(10) :: OutList (MaxOutPts) ! List of output parameters.
MaxOutPts is the number of output parameters available (986 in my version), and that number is set using the Matlab-generated code. FAST reads the OutList values specified in the input file and populates the OutList array, producing an error if it reads more than MaxOutPts values. It also keeps count of how many outputs were specified, using the variable NumOuts. (There is a routine in NWTC Subroutine Library v1.05.00 called [b]ReadOutputList/b, which isolates the code where the input-file values are parsed and placed into an array.) By setting a maximum number of allowable outputs at compile time, we do not have to read the input file twice.

The first NumOut values of OutList are transferred to the OutParam array (which is dimensioned to 0:NumOuts using an ALLOCATABLE statement in the code, after OutList is read).

It is very important to declare dimensions of an array in Fortran before using it (and the compiler can help detect it). Did you remove the line where OutList is dimensioned? Is there a problem with how your one output name (TWFtAero) is actually creating multiple output channels? Do you have more than 986 outputs?

I can’t help with the aerodynamics, but I can tell you the “Re v CD Properties” section looks for NTwrCD+1 columns for each NTwrRe rows. So, if you have specified NTwrRe = 5 and NTwrCD = 5, you should have 5 rows and 6 columns in that section.

It may be helpful to turn on the “Echo” feature in the primary FAST input file to help you see what values are being read and used with this feature.

I would like to check my modified version of FAST, in which wind loads on the tower are calculated and added to the FTAero array.

I would like to use the NREL 5MW turbine on a fixed-bottom monopile. Thanks, Jason for pointing me to the archive of input files for this model.

Please forgive me asking a few basic questions to make sure I am defining the tower and sub-structure geometry correctly.

  1. the mode shapes ought to have been calculated for a structure of total length (height) TowerHt+TwrDraft
  2. these two parameters are specified in the two input files for tower data (TowerHt) and platform data (TwrDraft)
  3. the wind loads ought to be applied to the tower between mean sea level and MSL+TowerHt (the yaw bearing height)
  4. between the mudline and the mean sea level (a total vertical distance of TwrDraft), only hydrodynamic loads ought to be applied
  5. the total length (height) of the structure is divided into (TwrNodes-1) elements of equal length
  6. external loads are applied half-way along the length of each element
  7. if I want to output loads between the mudline and mean sea level, I would specify a node number between 1 and TwrDraft/(TwrDraft+TowerHt)×TwrNodes
  8. if I want to output loads between the mean sea level and the yaw bearing, I would specify a node number between TwrDraft/(TwrDraft+TowerHt)×TwrNodes and TwrNodes

If you can confirm my 8 assumptions above, I would be very grateful.

Kind Regards,

Mark

Dear Mark,

The answer to all of your questions is “yes,” except for question 5. For question 5, the total flexible length of the tower is divided into TwrNodes elements of equal length (not TwrNodes - 1).

Best regards,