There are some questions that are asked often, so we decided to make a list of them here. If you have a question about our software tools, please look here first or read the appropriate user's guide. If you don't find it here, please use our forum's search feature. We will add to this list in time.
Answers to Frequently Asked Questions:
Almost all of our programs require that you specify an input file for them. You cannot merely double-click on the executable to run it because they are console applications instead of GUI applications. You must open a console window (CMD for Windows) and enter the program name followed by the input file name at the command prompt to run the program. Some programs also allow command-line switches.
Please refer to the program's user guide and our short Installing NWTC CAE Tools on PCs Running Windows paper for additional information about running our programs.
Quick Tip: If you are running on Windows 7 or Windows Server 2008 or later, if you right click while holding down the Shift key on a folder name in Windows Explorer, you can choose Open command window here to open a CMD window for that folder.
The quick answer is: "Almost always."
Any program compiled as a 32-bit program will run on a 64-bit version of Microsoft Windows. The converse is not true. You can never run a 64-bit program on a 32-bit operating system.
Some of our programs have been compiled in both 32-bit and 64-bit mode. For instance, you will find Crunch_win32.exe and Crunch_win64.exe in the Crunch archive.
One possible wrinkle happens with FAST, which can optionally use the DISCON.dll discrete controller. Both the FAST executable and the DLL must be compiled the same way.
If you want to run our program on Linux or a Mac, you must compile them yourself using our source code, so there should be no compatibility issue.
Most of the NWTC CAE Tools are console applications; i.e. you run them by calling them from a command window. Marshall Buhl wrote a short paper that describes how to install and run the NWTC CAE Tools on PCs Running Windows.
Installing NWTC CAE Tools on PCs Running Windows (157 KB, 23-August-2013)
The sum of the local twist and the blade pitch is equal to the angle between the local chord and the rotor plane. You can set the twist distribution to be whatever you want as long as the pitch is adjusted accordingly. For instance, suppose a blade has 10° of linearly varying twist between the root and the tip. If you want the tip chord to be parallel to the rotor plane, you can set the pitch to zero and the twist at the tip to zero. That would mean the root twist would be 10°. Some people like to have the twist at 70% radius to be defined as zero twist. That would mean that the root would be 7° and the tip –3°. You would have to set the pitch to 3° to make the tip chord be parallel with the rotor plane (tip twist + pitch = 0°).
This is caused by inconsistent placement of the nodes. The nodes must be at the centers of contiguous, non-overlapping segments. Here's an example of a properly configured set of nodes:
In the figure above, the vertical bars (|) are the segment boundaries and the numbers are the analysis nodes. As you can see in the figure, the nodes are at the centers of the segments. Now, suppose I choose random locations for the nodes without thinking about them being at the centers of segments. Look at this blade without the segment boundaries being marked:
If I start at the first node, I know that it must be at the center of a segment. Let's draw the segment boundaries for the first node:
The same rule holds true for the second segment--its node must be at the center of a contiguous, nonoverlapping segment. We know that it starts where the first node ended and there must be an equal amount of space on either side of the node. Here's what it must look like:
As you can see, node 3 is inside of node 2's segment! Our simulators hate this sort of thing and stubbornly refuse to continue running when we present them with this sort of layout. The only way to assure yourself of a consistent node layout is to divide the blade into segments and compute the centers of the segments to use as the node locations. This is quite trivial to do in a spreadsheet.
In future releases of AeroDyn and WT_Perf, we will change the way users specify the layout of their blades by having them specify segment boundaries instead of node locations. That will eliminate this problem.
We frequently get asked questions about compiling FAST v7, so Bonnie Jonkman put together instructions for compiling it with the Intel Visual Fortran Composer for Windows. You can access the pdf here: Instructions for Compiling FAST using IVF for Windows®
Please read this document carefully before posting questions about compiling FAST.
There is additional discussion about compiling FAST in this dedicated topic: Compiling FAST
FAST uses a 4th order Adams-Bashforth-Adams-Moulton predictor-corrector fixed-step integrator. This integrator is initialized over the first few steps with a 4th order Runga-Kutta integrator. When choosing the structural time step, a good rule-of-thumb is that it (DT in the FAST input file) should be set less than or equal to one over ten times the highest full system natural frequency. In equation form, it is:DT <= 1/( 10*HighestNF ),
where HighestNF is the highest full system natural frequency in Hz.
The full system natural frequencies can be found by running a FAST linearization analysis (AnalMode = 2) about the initial conditions. See the Linearization chapter of the FAST User's Guide for more information.
It is also necessary to use an appropriate time step for aerodynamic calculations. Because of things like wind shear and tower influence, you do not want such a large aerodynamic time step (DTAero in the AeroDyn input file) that you jump right over these effects. Our rule of thumb is 200 aerodynamic time steps per rotation. You should use the maximum rotor speed to compute this value. In FAST v7, DTAero will be forced to be an integer multiple of DT.
Another way to test time steps is to start with a largish step size and run representative cases at smaller and smaller time steps until the results stop changing. However, what works for one case may not work for others. It's not practical to do this for every case you might run. If a particular case is causing trouble, try running at a smaller time step.
We are working on guidance for FAST v8.
The formulas we use to determine the cumulative size of the bigger arrays in TurbSim is:
EffSimLen = FASTsimulationTime + GridWidth/MeanWindSpeed NumTimeSteps = EffSimLen/TimeStep + 1 SpectralGridElements = (NYGrids*NZGrids)^2 SpectralMatrixElements = 3*NZgrids*NumTimeSteps ComponentElements = SpectralMatrixElements*NYGrids TotalElements = SpectralGridElements + SpectralMatrixElements + 2*(ComponentElements + NZGrids) + NYGrids BytesRequired = 4*TotalElements (if using single precision, the TurbSim default) GBytesRequired = BytesRequired/(1024)^3
If you are running a sweep of wind speeds and want to determine the worst case, the lowest wind speed you run will produce the most time steps and consume the most memory when running TurbSim. When we modify TurbSim and InflowWind (used by FAST) to cycle through 10-minute data, the wind speed won't matter as we will no longer add extra data at the beginning and end of the file to accommodate analysis nodes upwind and downwind of the tower.
The size of the turbulence array read into InflowWind is:
FFArrayElements = 3*NZGrids*NYGrids*NumTimeSteps
Bonnie Jonkman created a spreadsheet to perform these calculations. You can get it here:
TurbSim Memory Spreadsheet (12 KB, 25-July-2012)
You need to make your turbulence grids large enough to ensure that part of the turbine does not move outside the turbulence volume during FAST simulations. If your wind-field volume is not large enough, FAST will generate a message similar to: FF wind array boundaries violated. Grid too small in Y Direction
You should make the grid width and height about 10% bigger than the rotor for land-based or non-floating, sea-based turbines. That accommodates elastic behavior of the turbine and support structure.
For a floating turbine—especially one with catenary lines—you need to consider how far it will move vertically and laterally. To determine how tall the grid needs to be, run FAST with the aerodynamics disabled and throw the largest waves at it that it is likely to see. Add twice the largest heave to 1.1 times the rotor diameter to determine the height of the wind grid. To determine the maximum lateral motion, run a maximum thrust case to determine the maximum surge. The maximum thrust case can be modeled using a hub-height wind file with the wind speed near rated. Calm seas are probably OK to use. Although the surge is a downwind motion, it gives you an idea of the maximum sway the turbine will experience, which could be caused by a current that is aligned to be 90 degrees from the nominal wind direction. Add twice the maximum surge to 1.1 times the rotor diameter to determine the width of the wind grid.
Another consideration in determining the wind grid width for floating turbines is platform heel. If your platform tends to heel easily, you may want to add some extra size to the grid width and maybe even the grid height to accommodate the turbine motion. Because it takes so long to generate long, high-resolution wind files, you should generate all the FF wind files using low-resolution, 10-minute wind files and only half the usual number of seeds for each design load case (DLC). Run all the DLCs to see if the rotor ever violates the wind-field boundaries. If it does, FAST will abort and tell you that it had tried to index outside the grid. If you get FF wind array was exhausted at xxxx.xx seconds, it means the combination of surge and pitch has pushed one of the blades past the beginning or end of the wind volume. If you get FF wind array boundaries violated. Grid too small in Y Direction, it means a combination of sway and roll caused the problem. If the error is in the Z Direction, it means a combination of heave and heel (roll and/or pitch) caused the problem. Heel can cause one of the blades to get too close to the mean sea level. You are more likely to violate the grid at the bottom boundary.
Because the platform motion is likely to be largest in the lateral direction than the vertical direction, you will probably end up with a rectangular grid.
The answer depends on the nature of your analysis/study, and the available information you have about your turbine design.
LUlt is the highest load (in absolute value) that the cross section of the component in question can withstand before failure based on its ultimate strength. TypeLMF is the mean load of the cross section of the component in question. LUlt and TypeLMF are used to define the load range versus cycles to failure (S-N or Whöler) curve, which is used by the damage, lifetime, and Goodman calculations of the fatigue analysis.
Ideally, LUlt would be based on a strength (e.g., FEA) analysis of the cross section of the component in question. If this is not available—for conceptual designs for example—what we've done in the past is to see how the fatigue loads vary over a range of LUlt values. We've defined a range by taking the overall maximum value of the load in question (e.g., derived from MExtremes), and multiplying by scaling factors of 1.25, 2.5, 5, 10, and 20. The fatigue loads will asymptotically approach a fixed value for large values of LUlt.
Ideally, TypeLMF would be the mean load in question over the time period of interest (e.g., the mean over the time series or the mean over the lifetime). In MLife, you can explicitly define this mean, set TypeLMF to AM to tell MLife to compute the mean using the aggregate mean across all input files, or set TypeLMF to WM to tell MLife to compute the mean by weighting the mean on a per file basis using the specified probability distribution.
Fatigue calculations involve rainflow cycle counting where the time series are sorted into a set of cycles each with different ranges and means. In the fatigue calculation process, MCrunch and MLife can apply the Goodman correction to transform the load ranges with varying means to equivalent load ranges at a fixed-mean load.; For generalized design studies, some people choose to perform their fatigue-life analysis without applying the Goodman correction. In MLife this is possible by setting the GoodmanFlag to 0. In this case, MLife uses the load range cycles without applying a correction, and to use a fixed-mean load of zero.
Please refer to the MLife theory manual for additional information.
People often asked where they can get airfoil data. The data we have can be found here:
Prof. Michael Selig of the University of Illinois at Urbana-Champaign has also created a fine library of airfoil data:
If you know of any other good sites for airfoil data, please notify Patrick Moriarty and he will add it to this page.
We have used the freeware XFOIL program from MIT on occasion for generating lift and drag coefficients. You can read more about it here:
If your input file does not have all the needed lines, or if you have added extra lines to it, you can have problems when a program tries to process it. Most of our programs require the input data to be in a specific order. The files cannot be free format where you add just what you need. So, even if you are not using a feature does not mean you can leave out lines pertaining to it. For most of our programs, you cannot even add blank lines. You also cannot change the order of any lines. We have recently created new input-processing routines that will allow you to add comments and blank lines just about anywhere in the input files (even at the ends of data lines), but the routines are not being used in any currently released programs.
When your file is not compatible with the program, you will usually get an error saying something about the type of information it found on a line was not what was expected. For instance, say the first two lines are supposed to be numbers and the third is a true/false flag. If you delete one of the first two lines, the program will abort because it found a true or false when it was expecting a number.
For long input files like the FAST input file, it might be difficult to find where in your input file went wrong. Most of our programs have an input parameter near the beginning of the input file that is called something like Echo. When you set the flag to TRUE, the program will create an echo file with the same root name as the input file and with an extension that is probably ec, ech, or echo. The echo files contain a list of your input values and with the name of the variable we were trying to read from that line and a description of the variable. It looks very much like the input file, but it is not a copy of your input file. Because it lists our comments next to your values, you should be able to compare it to your input file and see where the lines got out of order.
You must log in to download this software.