OpenFAST Documentation¶
 Version
v3.2.0
 Date
Jul 29, 2022
OpenFAST is a multiphysics, multifidelity tool for simulating the coupled dynamic response of wind turbines. Practically speaking, OpenFAST is the framework (or “glue code”) that couples computational modules for aerodynamics, hydrodynamics for offshore structures, control and electrical system (servo) dynamics, and structural dynamics to enable coupled nonlinear aerohydroservoelastic simulation in the time domain. OpenFAST enables the analysis of a range of wind turbine configurations, including two or threeblade horizontalaxis rotor, pitch or stall regulation, rigid or teetering hub, upwind or downwind rotor, and lattice or tubular tower. The wind turbine can be modeled on land or offshore on fixedbottom or floating substructures.
Established in 2017, OpenFAST is an opensource software package that builds on FAST v8 (see FAST v8 and the transition to OpenFAST). The glue code and underlying modules are mostly written in Fortran (adhering to the 2003 standard), and modules can also be written in C or C++. It was created with the goal of being a community model developed and used by research laboratories, academia, and industry. It is managed by a dedicated team at the National Renewable Energy Lab. Our objective is to ensure that OpenFAST is well tested, well documented, and selfsustaining software. To that end, we are continually improving the documentation and test coverage for existing code, and we expect that new capabilities will include adequate testing and documentation. If you’d like to contribute, see the Developer Documentation and any open GitHub issues with the Help Wanted tag.
The following links provide more insight into OpenFAST as a software package:
Documentation Directory
This documentation¶
OpenFAST documentation is hosted on readthedocs, and is automatically generated from both the main and dev branches whenever new commits are added. Clicking on the bar on the lower left corner of the page reveals a panel (see image below) containing options to select the branch of the repository, download the documentation other formats (PDF, HTML, EPub), and link to other relevant websites.
While OpenFAST developer documentation is being enhanced here, developers are encouraged to consult the legacy FAST v8 Programmer’s Handbook. Instructions on obtaining and installing OpenFAST are available in Installing OpenFAST, and documentation for verifying an installation with the automated tests is at Testing OpenFAST.
The majority of this documentation is divided into two parts:
Directed towards endusers, this part provides detailed documentation regarding usage of the OpenFAST and its underlying modules, as well as theory and verification documentation.
The developer guide is targeted towards users wishing to extend the functionality provided within OpenFAST. Here you will find details regarding the code structure, API supported by various classes, and links to source code documentation extracted using Doxygen.
Installing OpenFAST¶
Guidelines and procedures for obtaining precompiled binaries or compiling OpenFAST from source code are described here. While there are multiple ways to achieve the same outcome, the OpenFAST team has developed a comprehensive and wellthought out system for installation, so the methods described here are the only officially supported and maintained paths for obtaining an OpenFAST executable.
Most users of OpenFAST will not require modifying or compiling the source code. For the simplest installation of OpenFAST without changing the source code, refer to the table in the Download binaries section and read the corresponding documentation for specific instructions. For instructions on compiling, see Compile from source.
Download binaries¶
For users who intend to run OpenFAST simulations without changing the
source code, installation with precompiled binaries is recommended.
The installation procedures are specific for each supported operating
system, and the table below maps operating systems to the method for
obtaining binaries. “Release” versions are well tested and stable versions
of OpenFAST. A new release corresponds to a merge from the dev
branch of the repository to the main
branch along with a version tag.
“Prerelease” versions contain the latest commits to the dev
branch
and may contain unstable code but will always have the latest features.
Operating System 
Method 
OpenFAST Version 
Docs Section 

Linux 
Conda 
Release, Prerelease 

macOS 
Conda 
Release, Prerelease 

macOS 
Homebrew 
Release 

Windows 
GitHub Releases 
Release 
Conda Installation¶
OpenFAST releases are distributed through the Anaconda package manager via the OpenFAST Conda Forge channel for macOS and Linux. The installation includes
OpenFAST gluecode executable
Available module drivers
C++ header files
The following commands describe how to create a new environment, install OpenFAST, and test the installation.
# Create a new conda environment
conda create n openfast_env
# Install OpenFAST through the Conda Forge channel
conda install c condaforge openfast
# Test OpenFAST
which openfast
openfast v
# Test the HydroDyn driver
which hydrodyn_driver
hydrodyn_driver v
Prereleases can be installed via conda by specifying the dev
label,
as shown below.
conda install c condaforge/label/dev openfast
These are always the latest commits to the dev
branch
of the repository and contain the latest changes to OpenFAST, but these
builds are not as well tested as the full release versions.
Homebrew Installation¶
For macOS systems, OpenFAST releases are distributed through the Homebrew package manager. The installation includes only the OpenFAST gluecode executable.
To install with Homebrew and test the installation, use the following commands.
# Update Homebrew
brew update
# Install OpenFAST
brew search openfast
brew install openfast
# Test OpenFAST
which openfast
openfast v
GitHub Releases¶
For Windows systems only, precompiled binaries are made available for each release on the OpenFAST GitHub Releases page. The binaries are compiled with the Intel Fortran compiler version 2020.
Important
The precompiled binaries require either the Intel Fortran compiler or the Intel MKL redistributable libraries, which are not by default included with the binaries. To configure the libraries, download the installers from the bottom of this page. If you have a Command Prompt open, you will need to close it after installing the libraries in order for the changes to take effect. Admin privileges are required to install the Intel libraries.
The OpenFAST executables can be downloaded from the “Assets” dropdown in each Release. The two assets named “Source code” are not needed.
The zipped file contains the following items:
File Name 
Description 

openfast_Win32.exe 
32bit single precision 
openfast_x64.exe 
64bit single precision 
openfast_x64_double.exe 
64bit double precision 
Map_Win32.dll 
32bit MAP++ library 
Map_x64.dll 
64bit MAP++ library 
DISCON_DLLS/<64bit or Win32>/DISCON.dll 
Controller library for NREL 5MW 
DISCON_DLLS/<64bit or Win32>/DISCON_ITIBarge.dll 
Controller library for NREL 5MW  ITI Barge 
DISCON_DLLS/<64bit or Win32>/DISCON_OC3Hywind.dll 
Controller library for NREL 5MW  OC3 Hywind 
After extracting the contents, the OpenFAST executables can be tested by opening a command prompt, moving into the directory containing the executables, and running a simple test command:
cd C:\your\path\Desktop\openfast_binaries\
openfast_x64.exe /h
Compile from source¶
To compile from source code, the NREL OpenFAST team has developed an approach that uses CMake to generate build files for all platforms. Currently, CMake support for Visual Studio while doing active development is not well supported, so OpenFAST maintains a Visual Studio Solution giving Windows developers another option for writing code, compiling and debugging in a streamlined manner. See Visual Studio Solution for Windows for more information. If Visual Studio is not a requirement in Windows development, CMake is adequate. Background on CMake is given in Understanding CMake, and procedures for configuring and compiling are given in CMake with Make for Linux/macOS and CMake with Visual Studio for Windows.
Generally, the steps required to compile are:
Install Dependencies (Section Section 2.2.1)
Configure the build system (Visual Studio: Section 2.2.3, CMake: Section 2.2.4)
Compile and test binaries (Visual Studio: Section 2.2.3, CMake: Section 2.2.5 and Section 2.2.6 )
Dependencies¶
Compiling OpenFAST from source requires additional libraries and tools that are not distributed with the OpenFAST repository. Each of the following components are required for the minimum OpenFAST compilation.
C++, C, and Fortran compiler
BLAS and LAPACK math library
Build system
In many cases, these tools can be installed with a system’s package
manager (e.g. homebrew
for macOS, yum
for CentOS/Red Hat, or
apt
for Debianbased systems like Ubuntu). For Ubuntu and macOS,
the following commands install all required dependencies.
System 
Dependency Installation Command 

Ubuntu 20.04 

macOS 10.15 

If dependencies are downloaded from vendors directly, they must be installed in a standard location for your system so that the OpenFAST build systems can find them.
Compilers¶
Compiling OpenFAST requires a C, C++, and Fortran compiler. Though many options exist, the most common and best supported compilers are listed below.
Vendor / Compiler 
Applicable systems 
Minimum version 
Link 

GNU Compiler Collection (gfortran, gcc, g++) 
macOS, Linux 
4.6.0 

Intel Compilers (ifort, icc) 
All 
2013 
https://software.intel.com/content/www/us/en/develop/tools/oneapi/hpctoolkit.html 
Other compiler packages may work and can be well suited to a particular hardware, but their mileage may vary with OpenFAST. For instance, MinGW, CygWin, and LLVM are options for obtaining compilers on various systems. It is highly recommended to use the latest version of one of the above.
Math libraries¶
Math libraries with the BLAS and LAPACK interfaces are also required. All major options can be obtained as free downloads. The most common options are listed in the table below.
Library 
Distributor 
Open Source? 
Link 

BLAS/LAPACK 
NetLib 
Yes 

BLAS/LAPACK 
OpenBLAS 
Yes 

MKL 
Intel 
No 
https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/onemkl.html 
Build tools¶
An environmentspecific build system is required and may consist of a combination of the packages listed in the table below.
Package 
Applicable systems 
Minimum version 
Link 

CMake 
All 
3.0 

GNU Make 
macOS, Linux 
1.8 

Visual Studio 
Windows 
2015 
For Windows, CMake may be used to generate a Visual Studio Solution that can then be used to compile OpenFAST. OpenFAST also contains a standalone Visual Studio project, see Visual Studio Solution for Windows.
For macOS and Linux, the recommended tools are CMake and GNU Make. CMake is used to generate Makefiles that are inputs to the GNU Make program. Other build tools exist for both Linux and macOS (Xcode, Ninja), but these are not well supported by the OpenFAST system.
Get the code¶
OpenFAST can be cloned (i.e., downloaded) from its Github repository via the command line:
git clone https://github.com/OpenFAST/OpenFAST.git
An archive of the source code can also be downloaded directly from these links:
“main” branch  Stable release
“dev” branch  Latest updates
Visual Studio Solution for Windows¶
A complete Visual Studio solution is maintained for working with the OpenFAST on Windows systems. The procedure for configuring the system and proceeding with the build process are documented in the following section:
Building OpenFAST on Windows with Visual Studio¶
These instructions are specifically for the standalone Visual Studio project at openfast/vsbuild. Separate CMake documentation is provided for Windows users at Section 2.2.6.
Prerequisites¶
A version of Visual Studio (VS).
Currently VS 2013 Professional and VS 2015 Community Edition have been tested with OpenFAST.
A list of Intel Fortran compatible VS versions and specific installation notes are found here.
The included C/C++ project files for MAP++ and the Registry are compatible with VS 2013, but will upgrade seemlessly to a newer version of VS.
If you download and install Visual Studio 2015 Community Edition, you will need to be sure and select the
C/C++ component
using theCustomize
option.
Intel Fortran Compiler
Currently only version 2017.1 has been tested with OpenFAST, but any newer version should be compatible.
You can download an Intel Fortran compiler here.
Only install Intel Fortran after you have completed your Visual Studio installation.
Git for Windows
Download and install git for Windows.
Python 3.x for Windows (for regression/unit testing)
Compiling OpenFAST¶
Open
A command prompt
, orgit bash
shell from theStart
menuCreate a directory where you will clone OpenFAST repository (change
code
to your preferred name)mkdir code cd code
Clone the OpenFAST repository
git clone https://github.com/openfast/openfast.git
This will create a directory called openfast
within the code
directory.
Using Windows Explorer, navigate to the directory
openfast\vsbuild\FAST
and doubleclick on theFAST.sln
Visual Studio solution file. This will open Visual Studio with the FAST solution and its associated projects.
NOTE: If you are using Visual Studio 2015 or newer, you will be asked to upgrade
both the Fast_Registry.vcxproj
and the MAP_dll.vcxproj
files to a newer
format. Go ahead and accept the upgrade on those files.
Select the desired Solution Configuration, such as
Release
, and the desired Solution Platform, such asx64
by using the drop down boxes located below the menubar.Build the solution using the
Build>Build Solution
menu option.If the solution built without errors, the executable will be located under the
openfast\build\bin
folder.
Understanding CMake¶
To more fully understand CMake and its methodology, visit this guide on running CMake.
CMake is a build configuration system that creates files as input to a build
tool like GNU Make, Visual Studio, or Ninja. CMake does not compile code
or run compilers directly, but
rather creates the environment needed for another tool to run compilers and
create binaries. A CMake project is described by a series of files called
CMakeLists.txt
located in directories throughout the project. The main
CMake file for OpenFAST is located at openfast/CMakeLists.txt
and each
module and gluecode has its own CMakeLists.txt
; for example, AeroDyn
and BeamDyn have one at openfast/modules/aerodyn/CMakeLists.txt
and
openfast/modules/beamdyn/CMakeLists.txt
, respectively.
Running CMake¶
Running CMake and a build tool will create many files (text files and binaries)
used in the various stages of the build. For this reason, a build
folder
should be created to contain all of the generated files associated with the
build process. Here, an important file called CMakeCache.txt
contains the
userdefined settings for the CMake configuration. This file functions like
memory storage for the build. It is initially created the first time the CMake
command is run and populated with the initial settings. Then, any subsequent
changes to the settings will be updated and stored there.
CMake can be executed in a few ways:
Command line interface:
cmake
Command line curses interface:
ccmake
Official CMake GUI
The CMake GUI is only distributed for Windows, but it can be built from source for other platforms. OpenFAST’s build process focuses on the command line execution of CMake for both the Linux/macOS and Windows terminals. The command line syntax to run CMake for OpenFAST is generally:
cmake <pathtoprimaryCMakeLists.txt> [options]
Options
D <var>[:<type>]=<value> = Create or update a cmake cache entry.
For example, a common CMake command issued from the openfast/build
directory is:
# cmake <pathtoprimaryCMakeLists.txt> [options]
# where
# <pathtoprimaryCMakeLists.txt> is ".."
# [options] can be
# DBUILD_SHARED_LIBS:BOOL=ON or
# DBUILD_SHARED_LIBS=ON
cmake .. DBUILD_SHARED_LIBS=ON
The command line curses interface can be invoked similarly:
ccmake ..
The interface will be rendered in the terminal window and all navigation happens through keyboard inputs.
OpenFAST CMake options¶
CMake has a large number of general configuration variables available. A good resource for useful CMake variables is at this link: GitLab CMake variables. The CMake API documentation is also helpful for searching through variables and determining the resulting action. Note that the CMake process should be well understood before customizing the general options.
The CMake options specific to OpenFAST and their default settings are:
BUILD_DOCUMENTATION  Build documentation (Default: OFF)
BUILD_FASTFARM  Enable FAST.Farm capabilities (Default: OFF)
BUILD_OPENFAST_CPP_API  Enable building OpenFAST  C++ API (Default: OFF)
BUILD_OPENFAST_SIMULINK_API  Enable building OpenFAST for use with Simulink (Default: OFF)
BUILD_SHARED_LIBS  Enable building shared libraries (Default: OFF)
BUILD_TESTING  Build the testing tree (Default: OFF)
CMAKE_BUILD_TYPE  Choose the build type: Debug Release (Default: Release)
CMAKE_Fortran_MODULE_DIRECTORY  Set the Fortran Modules directory
CMAKE_INSTALL_PREFIX  Install path prefix, prepended onto install directories.
CODECOV  Enable infrastructure for measuring code coverage (Default: OFF)
DOUBLE_PRECISION  Treat REAL as double precision (Default: ON)
FPE_TRAP_ENABLED  Enable Floating Point Exception (FPE) trap in compiler options (Default: OFF)
GENERATE_TYPES  Use the openfastregistry to autogenerate types modules (Default: OFF)
OPENMP  Enable OpenMP support (Default: OFF)
ORCA_DLL_LOAD  Enable OrcaFlex library load (Default: OFF)
USE_DLL_INTERFACE  Enable runtime loading of dynamic libraries (Default: ON)
Additional systemspecific options may exist for a given system, but those should not impact the OpenFAST configuration. As mentioned above, the configuration variables are set initially but can be changed at any time. For example, the defaults may be accepted to initially configure the project, but then the settings may be configured individually:
# Initial configuration with the default settings
cmake ..
# Change the build to Debug mode rather than Release
cmake .. DCMAKE_BUILD_TYPE=Debug
# Use dynamic linking rather than static linking
cmake .. DBUILD_SHARED_LIBS=ON
The commands above are equivalent to having run this command the first time:
# Initial configuration in Debug mode with dynamic linking
cmake .. DCMAKE_BUILD_TYPE=Debug DBUILD_SHARED_LIBS=ON
CMAKE_BUILD_TYPE¶
This option allows to set the compiler optimization level and debug information. The value and its effect are listed in the table below.
CMAKE_BUILD_TYPE 
Effect 

Release 

RelWithDebInfo 

MinSizeRel 

Debug 
No optimization and g flag for debug info; additional debugging flags: 
Use Debug
during active development to add debug symbols for use with a
debugger. This build type also adds flags for generating runtime checks that
would otherwise result in undefined behavior. MinSizeRel
adds basic
optimizations and targets a minimal size for the generated executable. The next
level, RelWithDebInfo
, enables vectorization and other more aggressive
optimizations. It also adds debugging symbols and results in a larger
executable size. Finally, use Release
for best performance at the cost
of increased compile time.
This flag can be set with the following command:
cmake .. DCMAKE_BUILD_TYPE=RelWithDebInfo
CMAKE_INSTALL_PREFIX¶
This flag sets the location of the compiled binaries when the build
tool runs the install
command. It should be a full path in a carefully
chosen location. The binaries will be copied into include
, lib
,
and bin
subfolders under the value of this flag. The default is to
install binaries within the repository in a folder called install
.
This flag can be set with the following command:
cmake .. DCMAKE_INSTALL_PREFIX="/usr/local/"
Setting the build tool¶
CMake can target a variety of build tools or generators. To obtain a list of available generators on the current system, run with the empty generator flag, select the target from the list, and rerun with the generator flag populated:
# Run with the empty G flag to get a list of available generators
cmake .. G
# CMake Error: No generator specified for G
#
# Generators
# * Unix Makefiles = Generates standard UNIX makefiles.
# Ninja = Generates build.ninja files.
# Xcode = Generate Xcode project files.
# CodeBlocks  Ninja = Generates CodeBlocks project files.
# CodeBlocks  Unix Makefiles = Generates CodeBlocks project files.
# CodeLite  Ninja = Generates CodeLite project files.
# CodeLite  Unix Makefiles = Generates CodeLite project files.
# Sublime Text 2  Ninja = Generates Sublime Text 2 project files.
# Sublime Text 2  Unix Makefiles
# = Generates Sublime Text 2 project files.
# Kate  Ninja = Generates Kate project files.
# Kate  Unix Makefiles = Generates Kate project files.
# Eclipse CDT4  Ninja = Generates Eclipse CDT 4.0 project files.
# Eclipse CDT4  Unix Makefiles= Generates Eclipse CDT 4.0 project files.
# Choose one from the list above and pass it as an argument after G
# NOTE: wrap this is in quotes!
cmake .. G"Sublime Text 2  Ninja"
Note
If the chosen generator name contains spaces, be sure to wrap it in quotes.
Math libraries¶
The CMake project is configured to search for the required math libraries
in default locations. However, if math libraries are not found, they can
be specified directly to CMake. The two required libraries are BLAS
and LAPACK
, and their location can be passed to CMake with this command
syntax:
cmake .. DBLAS_LIBRARIES="/path/to/blas" DLAPACK_LIBRARIES="/path/to/lapack"
The paths given should be to the directory which contains the libraries, not to the libraries themselves.
CMake with Make for Linux/macOS¶
After installing all dependencies and reading Understanding CMake, proceed with configuring OpenFAST. The CMake project is well developed for Linux and macOS systems, so the default settings should work as given. These settings should only be changed when a custom build is required.
The full procedure for installing dependencies, configuring CMake and compiling with GNU Make on Linux and macOS systems is given below.
# For Ubuntu Linux, this installs all dependencies
apt install git cmake libblasdev liblapackdev gfortran10 g++
# For macOS using Homebrew, this installs all dependencies
brew install git cmake make openblas gcc
# Clone the repository from GitHub using git
git clone https://github.com/OpenFAST/OpenFAST.git
# Move into the OpenFAST directory
cd OpenFAST
# Create the build directory and move into it
mkdir build
cd build
# Execute CMake with the default options;
# this step creates the Makefiles
cmake ..
# Execute the Makehelp command to list all available targets
make help
# Choose a particular target or give no target to compile everything
make hydrodyn_driver
# or
make openfast
# or
make
# Test the compiled binary, for example
./gluecodes/openfast/openfast v
./modules/hydrodyn/hydrodyn_driver v
# Move the binaries and other runtime files to the install location
# The default is `openfast/install`
make install
Tip
Compile in parallel by adding “jN” to the make
command where N is
the number of parallel processes to use; i.e. make j4 openfast
.
This will build the OpenFAST project in the build
directory. Binaries are
located in openfast/build/gluecodes/
and openfast/build/modules/
. Since
all buildrelated files are located in the build
directory, a new fresh build
process can be accomplished by simply deleting the build directory and starting
again.
CMake with Visual Studio for Windows¶
After installing all dependencies and reading Understanding CMake, proceed with configuring OpenFAST. The result of this configuration process will be a Visual Studio solution which will be fully functional for compiling any of the targets within OpenFAST. However, this method lacks support for continued active development. Specifically, any settings that are configured in the Visual Studio solution directly will be lost any time CMake is executed. Therefore, this method should only be used to compile binaries, and the procure described in Visual Studio Solution for Windows should be used for active OpenFAST development on Windows.
The procedure for configuring CMake and compiling with Visual Studio on Windows systems is given below.
# Clone the repository from GitHub using git
git clone https://github.com/OpenFAST/OpenFAST.git
# Move into the OpenFAST directory
cd OpenFAST
# Create the build directory and move into it
mkdir build
cd build
# Execute CMake with the default options and a specific Visual Studio version
# and build architecture. For a list of available CMake generators, run
# ``cmake .. G``.
# This step creates the Visual Studio solution.
cmake .. G "Visual Studio 14 2015 Win64"
# Open the generated Visual Studio solution
start OpenFAST.sln
Visual Studio will open a solution containing all of the OpenFAST projects,
and any module library, module driver, or gluecode can be compiled from there.
The compiled binaries are located within a directory determined by the Visual
Studio build type (Release, Debug, or RelWithDebInfo) in
openfast/build/gluecodes/
and openfast/build/modules/
. For example, the
OpenFAST executable will be located at openfast/build/gluecodes/Release/openfast.exe
when compiling in Release mode.
The CMakegenerated Visual Studio build is not currently fully functional. Any configurations made to the Solution in the Visual Studio UI will be lost when CMake is executed, and this can happen whenever a change is made to the structure of the file system or if the CMake configuration is changed. It is recommended that this method not be used for debugging or active development on Windows. Instead, see Visual Studio Solution for Windows.
C++ API¶
When compiling the C++ API, the following additional dependencies are required:
The C++ API is compiled only with CMake and it is possible to hint to CMake where to find some dependencies. The following commands configure CMake and compile the C++ interface.
# Enable compiling the C++ API
cmake .. DBUILD_OPENFAST_CPP_API:BOOL=ON DBUILD_SHARED_LIBS:BOOL=ON
# If CMake doesn't find HDF5, provide a hint
cmake .. DHDF5_ROOT:STRING=/usr/lib/
# Compile the C++ API
make openfastcpplib
FAST.Farm¶
The FAST.Farm gluecode is included in the CMake project similar to the OpenFAST gluecode. See Compile from source for a full description on installing dependencies, configuring the project, and compiling. FAST.Farm is enabled in the CMake project with an additional flag:
# Enable compiling FAST.Farm
cmake .. DBUILD_FASTFARM:BOOL=ON
# Compile FAST.Farm
make FAST.Farm
OpenMPFortran is an additional dependency for FAST.Farm. These libraries can be installed with any package manager for macOS and Linux or through the Intel oneAPI distributions.
Appendix¶
The following are additional methods for installation which may not be fully test or may be deprecated in the future.
Building OpenFAST with Spack¶
The process to build and install OpenFAST with Spack on Linux or macOS is described here.
Dependencies¶
OpenFAST has the following dependencies:
LAPACK libraries. Users should set
BLAS_LIBRARIES
andLAPACK_LIBRARIES
appropriately for CMake if the library isn’t found in standard paths. Use BLASLIB as an example when using Intel MKL.For the optional C++ API, HDF5 (provided by
HDF5_ROOT
) and yamlcpp (provided byYAML_ROOT
)For the optional testing framework, Python 3+ and Numpy
Building OpenFAST SemiAutomatically Using Spack on macOS or Linux¶
The following describes how to build OpenFAST and its dependencies mostly automatically on macOS using Spack. This can also be used as a template to build OpenFAST on any Linux system with Spack.
These instructions were developed on macOS 10.11 with the following tools installed via Homebrew:
GCC 6.3.0
CMake 3.6.1
pkgconfig 0.29.2
Step 1¶
Checkout the official Spack repo from github (we will checkout into
${HOME}
):
cd ${HOME} && git clone https://github.com/LLNL/spack.git
Step 2¶
Add Spack shell support to your .profile
by adding the lines:
export SPACK_ROOT=${HOME}/spack
. $SPACK_ROOT/share/spack/setupenv.sh
Step 3¶
Copy the https://raw.githubusercontent.com/OpenFAST/openfast/dev/share/spack/package.py file to your installation of Spack:
mkdir ${SPACK_ROOT}/var/spack/repos/builtin/packages/openfast
cd ${SPACK_ROOT}/var/spack/repos/builtin/packages/openfast
wget nocheckcertificate https://raw.githubusercontent.com/OpenFAST/openfast/dev/share/spack/package.py
Step 4¶
Try spack info openfast
to see if Spack works. If it does, check the
compilers you have available by:
machine:~ user$ spack compilers
==> Available compilers
 gcc 
gcc@6.3.0 gcc@4.2.1
 clang 
clang@8.0.0apple clang@7.3.0apple
Step 5¶
Install OpenFAST with your chosen version of GCC:
spack install openfast %gcc@6.3.0
To install OpenFAST with the C++ API, do:
spack install openfast+cxx %gcc@6.3.0
That should be it! Spack will automatically use the most uptodate dependencies unless otherwise specified. For example to constrain OpenFAST to use some specific versions of dependencies you could issue the Spack install command:
spack install openfast %gcc@6.3.0 ^hdf5@1.8.16
The executables and libraries will be located at
spack location i openfast
Add the appropriate paths to your PATH
and LD_LIBRARY_PATH
to run
OpenFAST.
Building OpenFAST on Windows with CMake and Cygwin 64bit¶
WARNING: This build process takes a significantly long amount of time. If GNU tools are not required, it is recommended that Windows users see one of the following sections:
Installing prerequisites¶
Download and install Cygwin 64bit. You will need to
Run as Administrator
to complete the installation process.Choose
Install from internet
Choose the default install location
Choose the default package download location
Choose
Direct connection
Choose a download site
See next step for
select packages
. Alternately, you can skip this step and runsetupx86_64.exe
anytime later to select and install required software.
Select packages necessary for compiling
OpenFAST
. Choosebinary
packages and not the source option.Choose
Category
view, we will be installing packages fromDevel
andMath
From
Devel
mark the following packages for installationcmake
cmakedoc
cmakegui
cygwindevel
gcccore
gccfortran
gccg++
git
make
makedepend
From
Math
mark the following packages for installationliblapackdevel
libopenblas
To run the test suite, install these optional packages from
Python
:python3
Python3numpy
Click
Next
and accept all additional packages that the setup process requests to install to satisfy dependencies
It is recommended that you reboot the machine after installing
Cygwin
and all the necessary packages.
Compiling OpenFAST¶
From here, pick up from the Linux with CMake instructions at CMake with Make for Linux/macOS.
Other tips¶
If you would like to run
openfast.exe
from thecmd
terminal, then you must add theC:\cygwin64\lib\lapack
andC:\cygwin64\home\<USERNAME>\software\bin
to your%PATH%
variable in environment setting. Replace<USERNAME>
with your account name on Windows system.It is suggested to compile with optimization level 2 for Cygwin. Do this by changing the build mode in the cmake command
cmake .. DCMAKE_BUILD_TYPE=RelWithDebInfo
Testing OpenFAST¶
OpenFAST is a complex software with many moving parts. In order to maintain stability in new and existing code, a test suite is included directly in the source code. Two primary levels of tests exist: regression tests at the highest level and unit tests at the lowest level. The regression tests compare locally generated results with stored “baseline” results. These tests give an indication of whether the fullsystem or subsystem response has changed. The unit tests focus on a single subroutine or code block. These tests need not be physically realistic and focus on the mathematics and exersizing of an algorithm. The objective of the included tests is to quickly catch bugs or unexpected changes in results. Additionally, the tests can help programmers design their module and subroutine interfaces in a sustainable and maintainable manner.
All of the necessary files corresponding to the regression tests are contained
in the reg_tests
directory. The unit test framework is housed in
unit_tests
while the actual tests are contained in the directory
corresponding to the tested module.
The OpenFAST GitHub repository uses GitHub Actions to automatically execute the test suite for new commits and pull requests. This cloud computing resource is available to all GitHub users and is highly recommended as part of the development workflow. After enabling GitHub Actions in an OpenFAST repository, simply pushing new commits will trigger the tests.
Test specific documentation¶
Unit test¶
In a software package as dynamic and collaborative as OpenFAST, confidence in multiple layers of code is best accomplished with a strong system of unit tests. Through robust testing practices, the entire OpenFAST community can understand the intention behind code blocks and debug or expand functionality quicker and with more confidence and stability.
Unit testing in OpenFAST modules is accomplished through pFUnit.
This framework provides a Fortran abstraction to the popular
xUnit structure. pFUnit is compiled
along with OpenFAST through CMake when the CMake variable BUILD_TESTING
is
turned on.
The BeamDyn and NWTC Library modules contain some sample unit tests and should serve as a reference for future development and testing.
Dependencies¶
The following packages are required for unit testing:
Python 3.7+
CMake
pFUnit  Included in OpenFAST repo through a gitsubmodule
Compiling¶
Compiling the unit tests is handled with CMake similar to compiling OpenFAST
in general. After configuring CMake with BUILD_TESTING
turned on, new
build targets are created for each module included in the unit test
framework named [module]_utest
. Then, make
the target to test:
cmake .. DBUILD_TESTING=ON
make beamdyn_utest
This creates a unit test executable at
openfast/build/unit_tests/beamdyn/beamdyn_utest
.
Executing¶
To execute a module’s unit test, simply run the unit test binary. For example:
>>>$ ./openfast/build/unit_tests/beamdyn/beamdyn_utest
.............
Time: 0.018 seconds
OK
(14 tests)
pFUnit will display a .
for each unit test successfully completed
and a F
for each failing test. If any tests do fail, the failure
criteria will be displayed listing which particular value caused
the failure. Failure cases display the following output:
>>>$ ./unit_tests/beamdyn/beamdyn_utest
.....F.......
Time: 0.008 seconds
Failure
in:
test_BD_CrvMatrixH_suite.test_BD_CrvMatrixH
Location:
[test_BD_CrvMatrixH.F90:48]
simple rotation with known parameters: Pi on xaxis expected +0.5000000 but found: +0.4554637; difference: +0.4453627E01 > tolerance:+0.1000000E13; first difference at element [1, 1].
FAILURES!!!
Tests run: 13, Failures: 1, Errors: 0
Note: The following floatingpoint exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO
ERROR STOP *** Encountered 1 or more failures/errors during testing. ***
Error termination. Backtrace:
#0 0x1073b958c
#1 0x1073ba295
#2 0x1073bb1b6
#3 0x106ecdd4f
#4 0x1063fabee
#5 0x10706691e
Adding unit tests¶
Unit tests should be included for each new, testable code block (subroutine or function). What is testable is the discretion of the developer, but an element of the pull request review process will be evaluating test coverage.
New unit tests can be added to a tests
directory alongside the src
directory included in each module. For example, a module directory may be
structured as
openfast/
└── modules/
└── sampledyn/
├── src/
│ ├── SampleDyn.f90
│ └── SampleDyn_Subs.f90
└── tests/
├── test_SampleDyn_Subroutine1.F90
├── test_SampleDyn_Subroutine2.F90
└── test_SampleDyn_Subroutine3.F90
Each unit test must be contained in a unique file called
test_[SUBROUTINE].F90
where [SUBROUTINE]
is the code block being
tested. The new files should contain a Fortran module which itself
contains a Fortran subroutine for each specific test case. Generally,
multiple tests will be required to fully test one subroutine.
Finally, update the CMake configuration for building a module’s unit test executable by copying an existing unit test CMake configuration into a new module directory:
cp r openfast/unit_tests/beamdyn openfast/unit_tests/[module]
Then, modify the new CMakeLists.txt
with the appropriate list of test
subroutines and module name variables.
For reference, a template unit test file is included at
openfast/unit_tests/test_SUBROUTINE.F90
. Each unit test should fully test
the target code block. If full test coverage is not easily achievable, it may
be an indication that refactoring would be beneficial.
Some useful topics to consider when developing and testing for OpenFAST are:
Regression test¶
The regression test executes a series of test cases which intend to fully describe OpenFAST and its module’s capabilities. Jump to one of the following sections for instructions on running the regression tests:
Each locally computed result is compared to a static set of baseline results. To account for system, hardware, and compiler differences, the regression test attempts to match the current machine and compiler type to the appropriate solution set from these combinations:
Operating System 
Compiler 
Hardware 

macOS 10.15 
GNU 10.2 
2020 MacbookPro 
Ubuntu 20.04 
Intel oneAPI 
Docker 
Ubuntu 20.04 
GNU 10.2 
Docker 
Windows 10 
Intel oneAPI 
Dell Precision 3530 
The compiler versions, specific math libraries, and more info on hardware used to generate the baseline solutions are documented in the rtest repository documentation. Currently, the regression test supports only double precision builds.
The regression test system can be executed with CMake (through its included test driver, CTest) or manually with a custom Python driver. Both systems provide similar functionality with respect to testing, but CTest integration provides access to multithreading, automation, and test reporting via CDash. Both modes of execution require some configuration as described in the following sections.
In both modes of execution a directory is created in the build directory
called reg_tests
where all of the input files for the test cases are copied
and all of the locally generated outputs are stored. Ultimately, both CTest and
the manual execution program call a series of Python scripts and libraries in
reg_tests
and reg_tests/lib
. One such script is lib/pass_fail.py
which reads the output files and computes a norm on each channel reported. If
the maximum norm is greater than the given tolerance, that particular test is
reported as failed. The failure criteria is outlined below.
difference = abs(testData  baselineData)
for i in nChannels:
if channelRange < 1:
norm[i] = MaxNorm( difference[:,i] )
else:
norm[i] = MaxNorm( difference[:,i] ) / channelRange
if max(norm) < tolerance:
pass = True
else:
pass = False
Dependencies¶
The following packages are required for regression testing:
Python 3.7+
Numpy
CMake and CTest (Optional)
Bokeh 1.4 (Optional)
Executing with Python driver¶
The regression test can be executed manually with the included driver at
openfast/reg_tests/manualRegressionTest.py
. This program reads a case list
file at openfast/reg_tests/rtest/gluecodes/openfast/CaseList.md
. Cases
can be removed or ignored by starting that line with a #
. The driver
program includes multiple optional flags which can be obtained by
executing with the help option:
>>>$ python manualRegressionTest.py h
usage: manualRegressionTest.py [h] [p [PlottingFlag]] [n [NoExecution]]
[v [VerboseFlag]] [case [CaseName]]
OpenFAST SystemName CompilerId TestTolerance
Executes OpenFAST and a regression test for a single test case.
positional arguments:
OpenFAST path to the OpenFAST executable
SystemName current system's name: [Darwin,Linux,Windows]
CompilerId compiler's id: [Intel,GNU]
TestTolerance tolerance defining pass or failure in the regression
test
optional arguments:
h, help show this help message and exit
p [PlottingFlag], plot [PlottingFlag]
bool to include plots in failed cases
n [NoExecution], noexec [NoExecution]
bool to prevent execution of the test cases
v [VerboseFlag], verbose [VerboseFlag]
bool to include verbose system output
case [CaseName] single case name to execute
Note
For the NREL 5MW turbine test cases, an external ServoDyn controller must be compiled and included in the appropriate directory or all NREL 5MW cases will fail without starting. More information is available in the documentation for the rtest repository, but be aware that these three DISCON controllers must exist
openfast/build/reg_tests/gluecodes/openfast/5MW_Baseline/ServoData/DISCON.dll
openfast/build/reg_tests/gluecodes/openfast/5MW_Baseline/ServoData/DISCON_ITIBarge.dll
openfast/build/reg_tests/gluecodes/openfast/5MW_Baseline/ServoData/DISCON_OC3Hywind.dll
Executing with CTest¶
CTest is included with CMake and is primarily a set of preconfigured targets
and commands. To use the CTest driver for the regression test, execute CMake as
described in Installing OpenFAST, but with this additional flag:
DBUILD_TESTING=ON
.
The regression test specific CMake variables are
BUILD_TESTING
CTEST_OPENFAST_EXECUTABLE
CTEST_[MODULE]_EXECUTABLE where [MODULE] is the module name
CTEST_PLOT_ERRORS
CTEST_REGRESSION_TOL
Some additional resources that are required for the full regression test suite
are included in the CMake project. Specifically, external ServoDyn controllers
must be compiled for a given system and placed in a particular location. Thus,
be sure to execute the build command with the install
target:
# Configure CMake with testing enabled and accept the default
# values for all other testspecific CMake variables
cmake .. DBUILD_TESTING=ON
# Build and install
make install
Note
REMINDER: For the NREL 5MW turbine test cases, an external ServoDyn controller must be compiled and included in the appropriate directory or all NREL 5MW cases will fail without starting. More information is available in the documentation for the rtest repository, but be aware that these three DISCON controllers must exist
openfast/build/reg_tests/gluecodes/openfast/5MW_Baseline/ServoData/DISCON.dll
openfast/build/reg_tests/gluecodes/openfast/5MW_Baseline/ServoData/DISCON_ITIBarge.dll
openfast/build/reg_tests/gluecodes/openfast/5MW_Baseline/ServoData/DISCON_OC3Hywind.dll
After CMake configuration and compiling, the automated regression test can be
executed by running either of the commands make test
or ctest
from the
build
directory. If the entire OpenFAST package is to be built, CMake will
configure CTest to find the new binary at
openfast/build/gluecodes/openfast/openfast
. However, if the intention is
to build only the test suite, the OpenFAST binary should be specified in the
CMake configuration under the CTEST_OPENFAST_EXECUTABLE
flag. There is
also a corresponding CTEST_[MODULE]_NAME
flag for each module included in
the regression test.
When driven by CTest, the regression test can be executed by running various
forms of the command ctest
from the build directory. The basic commands
are:
# Run the entire regression test
ctest
# Disable actual execution of tests;
# this is helpful in formulating a particular ctest command
ctest N
# Run the entire regression test with verbose output
ctest V
# Run tests by name where TestName is a regular expression (regex)
ctest R [TestName]
# Run all tests with N tests executing in parallel
ctest j [N]
Each regression test case contains a series of labels associating all of the
modules used. The labeling can be seen in the test instantiation in
reg_tests/CTestList.cmake
or with the command:
# Print all available test labels
ctest printlabels
The test cases corresponding to a particular label can be executed with this command:
# Filter the test cases corresponding to a particular label
ctest L [Label]
Flags can be compounded making useful variations such as
# Run all cases that use AeroDyn14 with verbose output
ctest V L aerodyn14
# Run all cases that use AeroDyn14 in 16 concurrent processes
ctest j 16 L aerodyn14
# Run the case with name "5MW_DLL_Potential_WTurb" with verbose output
ctest V R 5MW_DLL_Potential_WTurb
# List all tests with the "beamdyn" label
ctest N L beamdyn
# List the labels included in all tests matching the regex "bd"
ctest N R bd printlabels
The automated regression test writes new files only into the build directory.
Specifically, all locally generated solutions are located in the corresponding
gluecode or module within openfast/build/reg_tests
. The baseline solutions
contained in openfast/reg_tests/rtest
are strictly read and are not
modified by the automated process.
Regression test examples¶
The following examples illustrate methods of running the regression tests on Unixbased systems. However, similar procedures can be used on Windows with CMake and CTest. An alternate method of running the regression tests on Windows is given in Detailed example of running on Windows.
Compile OpenFAST and execute with CTest¶
The following example assumes the user is starting completely from scratch. The commands below download the source code, configure the OpenFAST project with CMake, compile all executables, and execute the full regression test suite.
# Download the source code from GitHub
# Note: The default branch is 'main'
git clone recursive https://github.com/openfast/openfast.git
cd openfast
# If necessary, switch to another target branch and update rtest
git checkout dev
git submodule update
# Create the build and install directories and move into build
mkdir build install && cd build
# Configure CMake for testing
#  BUILD_TESTING  turn ON
#  CTEST_OPENFAST_EXECUTABLE  accept the default
#  CTEST_[MODULE]_EXECUTABLE  accept the default
cmake .. DBUILD_TESTING=ON
# Compile and install
make install
# Execute the full test suite with 4 concurrent processes
ctest j4
Configure with CMake and a given executable¶
This example assumes the user has a fully functional OpenFAST executable available along with any necessary libraries, but does not have the source code repository downloaded. This might be the case when executables are distributed within an organization or downloaded from an OpenFAST Release. Here, nothing will be compiled, but the test suite will be configured with CMake for use with the CTest command.
# Download the source code from GitHub
# Note: The default branch is 'main'
git clone recursive https://github.com/openfast/openfast.git
cd openfast
# If necessary, switch to another target branch and update rtest
git checkout dev
git submodule update
# Create the build directory and move into it
mkdir build && cd build
# Configure CMake with openfast/reg_tests/CMakeLists.txt for testing
#  BUILD_TESTING  turn ON
#  CTEST_OPENFAST_EXECUTABLE  provide a path
#  CTEST_[MODULE]_EXECUTABLE  provide a path
cmake ../reg_tests \
DBUILD_TESTING=ON \
DCTEST_OPENFAST_EXECUTABLE=/home/user/Desktop/openfast_executable \
DCTEST_BEAMDYN_EXECUTABLE=/home/user/Desktop/beamdyn_driver
# Install required files
make install
# Execute the full test suite with 4 concurrent processes
ctest j4
Python driver with a given executable¶
This example assumes the user has a fully functional OpenFAST executable available along with any necessary libraries, but does not have the source code repository downloaded. This might be the case when executables are distributed within an organization or downloaded from an OpenFAST Release. Nothing will be compiled, but the test suite will be executed with the included Python driver.
# Download the source code from GitHub
# Note: The default branch is 'main'
git clone recursive https://github.com/openfast/openfast.git
cd openfast
# If necessary, switch to another target branch and update rtest
git checkout dev
git submodule update
# Execute the Python driver
cd reg_tests
python manualRegressionTest.py h
# usage: manualRegressionTest.py [h] [p [PlottingFlag]] [n [NoExecution]]
# [v [VerboseFlag]] [case [CaseName]]
# OpenFAST SystemName CompilerId TestTolerance
#
# Executes OpenFAST and a regression test for a single test case.
#
# positional arguments:
# OpenFAST path to the OpenFAST executable
# SystemName current system's name: [Darwin,Linux,Windows]
# CompilerId compiler's id: [Intel,GNU]
# TestTolerance tolerance defining pass or failure in the regression
# test
#
# optional arguments:
# h, help show this help message and exit
# p [PlottingFlag], plot [PlottingFlag]
# bool to include plots in failed cases
# n [NoExecution], noexec [NoExecution]
# bool to prevent execution of the test cases
# v [VerboseFlag], verbose [VerboseFlag]
# bool to include verbose system output
# case [CaseName] single case name to execute
python manualRegressionTest.py \
..\build\bin\openfast_x64_Double.exe \
Windows \
Intel \
1e5
Detailed example of running on Windows¶
The Python driver with a given executable example can be used for running the regression tests on a Windows computer. However, a more detailed, stepbystep description is given in Windows with Visual Studio regression test.
Clone the openfast repo and initialize the testing database
Open a git command shell window (like git bash)
Change your working directory to the location above where you want your local repo to be located (the repo will be placed into a folder called openfast at this location)
c. Type:
git clone https://github.com/openfast/openfast.git
(this creates a local version of the openfast repo on your computer). You should see something like this:Cloning into 'openfast'... remote: Counting objects: 23801, done. remote: Compressing objects: 100% (80/80), done. remote: Total 23801 (delta 73), reused 102 (delta 50), packreused 23670 Receiving objects: 100% (23801/23801), 92.10 MiB 18.99 MiB/s, done. Resolving deltas: 100% (13328/13328), done. Checking connectivity... done.
Type:
cd openfast
(change your working directory to the openfast folder)Type:
git checkout dev
(this places your local repo on the correct branch of the openfast repo)Type:
git submodule update init recursive
(this downloads the testing database to your computer) You should see something like this:
Submodule 'reg_tests/rtest' (https://github.com/openfast/rtest.git) registered for path 'reg_tests/rtest' Cloning into 'reg_tests/rtest'... remote: Counting objects: 3608, done. remote: Compressing objects: 100% (121/121), done. remote: Total 3608 (delta 22), reused 161 (delta 21), packreused 3442 Receiving objects: 100% (3608/3608), 154.52 MiB 26.29 MiB/s, done. Resolving deltas: 100% (2578/2578), done. Checking connectivity... done. Submodule path 'reg_tests/rtest': checked out 'b808f1f3c1331fe5d03c5aaa4167532c2492d378'
Build The Regression Testing DISCON DLLs
Open the Visual Studio Solution (
Discon.sln
) located inopenfast\vsbuild\Discon
folderChoose Release and x64 for the Solutions Configuration and Solutions Platform, respectively
From the menu bar select
Build>Build Solution
You should now see the files
Discon.dll
,Discon_ITIBarge.dll
, andDiscon_OC3Hywind.dll
in youropenfast\reg_tests\rtest\gluecodes\fast\5MW_Baseline\ServoData
folder.
Build OpenFAST using Visual Studio
Open the Visual Studio Solution (
FAST.sln
) located inopenfast\vsbuild\FAST
folderChoose Release_Double and x64 for the Solutions Configuration and Solutions Platform, respectively
From the menu bar select
Build>Build Solution
If this is the first time you have tried to build openfast, you will get build errors!!! [continue to steps (ii) and (iii), otherwise if FAST builds successfully, continue to step (3d) ]
 Cancel build using the menubar
Build>Cancel
[ VS is confused about the buildorder/dependency of the project files in FASTlib., but canceling and restarting VS, it somehow as enough info from the partial build to get this right, now]
 Cancel build using the menubar
Close your Visual Studio and then Repeat Steps (a) through (c)
You should now see the file
openfast_x64_Double.exe
in youropenfast\build\bin
folder.
Prepare regression tests
Create a subdirectory called
reg_tests
in youropenfast\build
folder.Copy the contents of
openfast\reg_tests\rtest
toopenfast\build\reg_tests
.
Execute the OpenFAST regression Tests
Open a command prompt which is configured for Python [ like Anaconda3 ]
Change your working directory to
openfast\reg_tests
 Type:
python manualRegressionTest.py ..\build\bin\openfast_x64_Double.exe Windows Intel 1e5
You should see this:
executing AWT_YFix_WSt
 Type:
The tests will continue to execute onebyone until you finally see something like this:
executing AWT_YFix_WSt PASS executing AWT_WSt_StartUp_HighSpShutDown PASS executing AWT_YFree_WSt PASS executing AWT_YFree_WTurb PASS executing AWT_WSt_StartUpShutDown PASS executing AOC_WSt PASS executing AOC_YFree_WTurb PASS executing AOC_YFix_WSt PASS executing UAE_Dnwind_YRamp_WSt PASS executing UAE_Upwind_Rigid_WRamp_PwrCurve PASS executing WP_VSP_WTurb_PitchFail PASS executing WP_VSP_ECD PASS executing WP_VSP_WTurb PASS executing WP_Stationary_Linear PASS executing SWRT_YFree_VS_EDG01 PASS executing SWRT_YFree_VS_EDC01 PASS executing SWRT_YFree_VS_WTurb PASS executing 5MW_Land_DLL_WTurb PASS executing 5MW_OC3Mnpl_DLL_WTurb_WavesIrr PASS executing 5MW_OC3Trpd_DLL_WSt_WavesReg PASS executing 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth PASS executing 5MW_ITIBarge_DLL_WTurb_WavesIrr PASS executing 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti PASS executing 5MW_OC3Spar_DLL_WTurb_WavesIrr PASS executing 5MW_OC4Semi_WSt_WavesWN PASS executing 5MW_Land_BD_DLL_WTurb PASS
If an individual test succeeds you will see
PASS
otherwise you will seeFAIL
after that test’s name
Adding test cases¶
In all modes of execution, the regression tests are ultimately driven by a
series of Python scripts located in the openfast/reg_tests
directory
with the naming scheme execute<Module>RegressionTest.py
.
The first step to adding a new regression test case is to verify that
a script exists for the target module. If it does not, an issue
should be opened in OpenFAST Issues
to coordinate with the NREL team on creating this script.
The next step is to add the test case in the appropriate location in
the rtest submodule. The directory structure in rtest mirrors the
directory structure in OpenFAST, so modulelevel tests should be placed
in their respective module directories and gluecode tests go in
rtest/gluecodes/openfast
. Note the naming scheme of files for
existing tests and adapt the new test case files accordingly. Specifically,
the main input file and output file names may be expected in a particular
convention by the Python scripts. Also, consider that any relative paths
within the input deck for the new test case must work within the rtest
directory structure.
Once the test directory exists, the test case must be registered with
the appropriate drivers. For OpenFAST gluecode tests, this happens both in
CMake and a standalone list of test cases. For CMake, edit the file
openfast/reg_tests/CTestList.cmake
. The additional test should be
added in the section corresponding to the module or driver at the
bottom of that file. For the Python driver, the new test case must
be added to openfast/reg_tests/rtest/gluecodes/openfast/CaseList.md
.
At this point, the registration with CTest can be verified:
# Move into the build directory
cd openfast/build
# Run CMake to take the new changes to the test list
cmake .. DBUILD_TESTING=ON # If the BUILD_TESTING flag was previously enabled, this can be left off
# List the registered tests, but don't run them
ctest N
For module regression tests, the only option for execution is with the
CMake driver, so follow the instructions above to edit CTestList.cmake
.
Finally, the new test cases in the rtest submodule must be added to the rtest repository. To do this, open a new issue in rtest Issues requesting for support from the NREL team to commit your test.
Obtaining and configuring the test suite¶
Portions of the test suite are linked to the OpenFAST repository through a git submodule. Specifically, the following two repositories are included:
Tip
Be sure to clone the repo with the recursive
flag or execute
git submodule update init recursive
after cloning.
The test suite is configured with CMake similar to the general OpenFAST build process with an additional CMake flag:
# BUILD_TESTING  Build the testing tree (Default: OFF)
cmake .. DBUILD_TESTING:BOOL=ON
Aside from this flag, the default CMake configuration is suitable for most systems. See the Understanding CMake section for more details on configuring the CMake targets. While the unit tests must be built with CMake due to its external dependencies, the regression test may be executed without CMake, as described in Executing with Python driver.
User Documentation¶
We are in the process of transitioning legacy FAST v8 documentation, which can be found at https://www.nrel.gov/wind/nwtc.html.
Note
Much of the documentation here is legacy documentation from FAST v8. While most of it is still directly applicable to OpenFAST, portions may be out of date.
General¶
FAST v8 and the transition to OpenFAST¶
This page describes the transition from FAST v8, a computeraided engineering tool for simulating the coupled dynamic response of wind turbines, to OpenFAST. OpenFAST was established by researchers at the National Renewable Energy Laboratory (NREL) in 2017, who were supported by the U.S. Department of Energy Wind Energy Technology Office (DOEWETO).
FAST v8¶
FAST v8 is a computeraided engineering tool for simulating the coupled dynamic response of wind turbines. FAST joins aerodynamics models, hydrodynamics models for offshore structures, control and electrical system (servo) dynamics models, and structural (elastic) dynamics models to enable coupled nonlinear aerohydroservoelastic simulation in the time domain. The FAST tool enables the analysis of a range of wind turbine configurations, including two or threeblade horizontalaxis rotor, pitch or stall regulation, rigid or teetering hub, upwind or downwind rotor, and lattice or tubular tower. The wind turbine can be modeled on land or offshore on fixedbottom or floating substructures. FAST is based on advanced engineering models derived from fundamental laws, but with appropriate simplifications and assumptions, and supplemented where applicable with computational solutions and test data.
The aerodynamic models use windinflow data and solve for the rotorwake effects and bladeelement aerodynamic loads, including dynamic stall. The hydrodynamics models simulate the regular or irregular incident waves and currents and solve for the hydrostatic, radiation, diffraction, and viscous loads on the offshore substructure. The control and electrical system models simulate the controller logic, sensors, and actuators of the bladepitch, generatortorque, nacelleyaw, and other control devices, as well as the generator and powerconverter components of the electrical drive. The structuraldynamics models apply the control and electrical system reactions, apply the aerodynamic and hydrodynamic loads, adds gravitational loads, and simulate the elasticity of the rotor, drivetrain, and support structure. Coupling between all models is achieved through a modular interface and coupler.
Transition to OpenFAST¶
The release of OpenFAST represents a transition to better support an opensource developer community across research laboratories, industry, and academia around FASTbased aerohydroservoelastic engineering models of windturbines and windplants. OpenFAST aims to provide a solid softwareengineering framework for FAST development including well documented source code, extensive automated regression and unit testing, and a robust multiplatform and compiler build system.
OpenFAST includes the following organizational changes relative to FAST v8.16:
A new GitHub organization has been established at https://github.com/openfast
The OpenFAST glue codes, modules, module drivers, and compiling tools are contained within a single repository: https://github.com/openfast/openfast
The FAST program has been renamed OpenFAST (starting from OpenFAST v1.0.0)
Version numbering has been updated for OpenFAST (starting from OpenFAST v1.0.0), e.g., OpenFASTv1.0.0123gabcd1234dirty, where:
v1.0.0 is the majorminorbugfix numbering system and corresponds to a tagged commit made by NREL on GitHub
123g is the number of additional commits after the most recent tag for a build [the ‘g’ is for ‘git’]
abcd1234 is the first 8 characters of the current commit hash
dirty denotes that local changes have been made but not committed
Because all modules are contained in the same repository, the version numbers of each module have been eliminated and now use the OpenFAST version number (starting from OpenFAST v1.0.0) though old documentation may still refer to old version numbers
The OpenFAST regression test baseline solutions (formerly the Certification Tests or CertTest) reside in a standalone repository: https://github.com/openfast/rtest (starting from OpenFAST v1.0.0)
Unit testing has been introduced at the subroutine level (starting with BeamDyn from OpenFAST v1.0.0).
An online documentation system has been established to replace existing documentation of FAST v8: http://openfast.readthedocs.io/; during the transition to OpenFAST, most userrelated documentation is still provided through the NWTC Information Portal, https://nwtc.nrel.gov
Cross platform compiling is accomplished with CMake on macOS, Linux, and Cygwin (Windows) systems
Visual Studio Projects (VSBuild) are provided for compiling OpenFAST on Windows (starting from OpenFAST v1.0.0), but the development team is working to automate the generation of Visual Studio build files via CMake in a future release
GitHub Issues has been made the primary platform for developers to report and track bugs, request feature enhancements, and to ask questions related to the source code, compiling, and regression/unit testing; general userrelated questions on OpenFAST theory and usage should still be handled through the forum at https://wind.nrel.gov/forum/wind
A new API has been added that provides a high level interface to run OpenFAST through a C++ driver code helping to interface OpenFAST with external programs like CFD solvers written in C++ (starting in OpenFAST v1.0.0)
Release Notes for OpenFAST¶
This section outlines significant modifications to OpenFAST made with each tagged release.
v0.1.0 (April 2017)¶
Algorithmically, OpenFAST v0.1.0 is the release most closely related to FAST v8.16.
Organizational changes:
A new GitHub organization has been established at https://github.com/openfast
The OpenFAST glue codes, modules, module drivers, and compiling tools are contained within a single repository: https://github.com/openfast/openfast
Cross platform compiling is accomplished with CMake on macOS, Linux, and Cygwin (Windows) systems
An online documentation system has been established to replace existing documentation of FAST v8: http://openfast.readthedocs.io/
GitHub Issues has been made the primary platform for developers to report and track bugs, request feature enhancements, and to ask questions related to the source code, compiling, and regression/unit testing; general userrelated questions on OpenFAST theory and usage should still be handled through the forum at https://wind.nrel.gov/forum/wind
The AeroDyn v15 aerodynamics module has been significantly updated. The bladeelement/momentum theory (BEMT) solution algorithm has been improved as follows:
BEMT now functions for the case where the undisturbed velocity along the xdirection of the local blade coordinate system (Vx) is less than zero
BEMT no longer aborts when a valid value of the inflow angle (\(\phi\)) cannot be found; in this case, the inflow angle is computed geometrically (without induction)
The inflow angle (\(\phi\)) is now initialized on the first call instead of defaulting to using \(\phi\) = 0, giving better results during simulation start up
When hub and/or tiploss are enabled (HubLoss = True and/or TipLoss = True), tangential induction (a’) is set to 0 instead of 1 at the root and/or tip, respectively (axial induction (a) is still set to 1 at the root and/or tip)
The BEMT solution has been made more efficient
In addition, several bugs in AeroDyn v15 have been fixed, including:
Fixed a bug whereby when hub and/or tiploss are enabled (HubLoss = True and/or TipLoss = True) along with the Pitt/Peters skewedwake correction (SkewMod = 2), BEMT no longer modifies the induction factors at the hub and/or tip, respectively
Fixed a bug whereby the time series was affected after the linearization analysis with AeroDyn coupled to OpenFAST when frozen wake is enabled (FrozenWake = True)
The BeamDyn finiteelement blade structuraldynamics model has undergone an extensive cleanup of the source code. A bug in an offdiagonal term in the structural dampinginduced stiffness (i.e., representing a change in the damping force with beam displacement) has been corrected.
A new module for userspecified platform loading (ExtPtfm) has been introduced. ExtPtfm allows the user to specify 6x6 added mass, damping, and stiffness matrices, as well as a 6x1 load vector to define loads to be applied to ElastoDyn’s tower base/platform, e.g., to support the modeling of substructures or foundations through a superelement representation (with superelement derived from external software). ExtPtfm also provides the user with a module to customize with more advanced platform applied loads. Module ExtPtfm can be enabled by setting CompSub to 2 in the FAST primary input file (a new option) and setting SubFile to the name of the file containing the platform matrices and load time history, but setting CompSub to 2 requires one to disable hydrodynamics (by setting CompHydro to 0). Please note that the introduction of option 2 for CompSub represents a minor input file change (the only input file change in OpenFAST v0.1.0), but the MATLAB conversion scripts have not yet been updated.
In the ServoDyn control and electricalsystem module, the units and sign of output parameter YawMom have been corrected
In the InflowWind windinflow module, the ability to use TurbSimgenerated tower wind data files in Bladedstyle format was corrected
Minor fixes were made to the error checking in ElastoDyn
v1.0.0 (September 2017)¶
Organizational changes:
The FAST program has been renamed OpenFAST
Version numbering has been updated for OpenFAST (see Section 4.3.2 for details)
The OpenFAST regression test baseline solutions (formerly the Certification Tests or CertTest) reside in a standalone repository: https://github.com/openfast/rtest
Unit testing has been introduced at the subroutine level (starting with BeamDyn)
The online documentation (http://openfast.readthedocs.io/en/latest/index.html) has been extensively updated with additions for installation, testing, user (AeroDyn BeamDyn, transition from FAST v8, release notes), and developer guides, etc
The scripts for compiling OpenFAST using CMake on macOS, Linux, and Cygwin (Windows) systems have been updated, including the ability to compile in single precision and building with Spack
Visual Studio Projects (VSBuild) are provided for compiling OpenFAST on Windows
TurbSim has been included in the OpenFAST repository
The AeroDyn aerodynamics module has been updated:
Added a cavitation check for marine hydrokinetic (MHK) turbines. This includes the additions of new input parameters CavitCheck, Patm, Pvap, and FluidDepth in the AeroDyn primary input file, the addition of the Cpmin to the airfoil data files (required when CavitCheck = True), and new output channels for the minimum pressure coefficient, critical cavitation, and local cavitation numbers at the blade nodes. Please note that this input file changes represent the only input file change in OpenFAST v1.0.0, but the MATLAB conversion scripts have not yet been updated.
Fixed a bug in the calculation of wind loads on the tower whereby the tower displacement was used in place of the tower velocity
Tower strikes detected by the models to calculate the influence of the tower on the wind local to the blade are now treated as fatal errors instead of severe errors
Fixed minor bugs in the unsteady airfoil aerodynamics model
The BeamDyn finiteelement blade structuraldynamics module has undergone additional changes:
The sourcecode has further undergone clean up, including changing the internal coordinate system to match IEC (with the local z axis along the pitch axis)
Trapezoidal points are now correctly defined by blade stations instead of key points
The tip rotation outputs were corrected as per GitHub issue #10 (https://github.com/OpenFAST/openfast/issues/10)
The BeamDyn driver has been fixed for cases involving spinning blades
BeamDyn no longer produces numerical “spikes” in single precision, so, it is no longer necessary to compile OpenFAST in double precision when using BeamDyn
The ElastoDyn structuraldynamics model was slightly updated:
The precision on some modulelevel outputs used as input to the BeamDyn module were increased from single to double to avoid numerical “spikes” when running BeamDyn in single precision
Minor fixes were made to the error checking
The ServoDyn control and electrical system module was slightly updated:
Fixed the values of the generator torque and electrical power sent from ServoDyn to Bladedstyle DLL controllers as per GitHub issue # 40 (https://github.com/OpenFAST/openfast/issues/40)
Minor fixes were made to the error checking
The OpenFAST driver/glue code has been updated:
Correction steps have been added to the OpenFAST driver during the first few time steps to address initialization problems with BeamDyn (even with NumCrctn = 0)
Fixed a bug in the Line2toPoint mapping of loads as per GitHub issue #8 (https://github.com/OpenFAST/openfast/issues/8). Previously, the augmented mesh was being formed using an incorrect projection, thus causing strange transfer of loads in certain cases. This could cause issues in the coupling between ElastoDyn and AeroDyn and/or in the coupling between HydroDyn and SubDyn
Added an otherwise undocumented feature for writing binary output without compression to support the new regression testing. The new format is available by setting OutFileFmt to 0 in the FAST primary input file.
A new API has been added that provides a high level interface to run OpenFAST through a C++ driver code. The primary purpose of the C++ API is to help interface OpenFAST to external programs like CFD solvers that are typically written in C++.
The TurbSim windinflow turbulence preprocessor was updated:
The API spectra was corrected
Several minor bugs were fixed.
OpenFAST: Looking forward¶
Our goal is to continually improve OpenFAST documentation and to increase the coverage of automated unit and regression testing. In order to increase testing coverage and to maintain robust software, we will require that
new modules be equipped by the module developer(s) with sufficient modulespecific unit and regression testing along with appropriate OpenFAST regression tests;
bug fixes include appropriate unit tests;
new features/capabilities include appropriate unit and regression tests. We are in the process of better instrumenting the BeamDyn module with extensive testing as a demonstration of requirements for new modules.
For unit testing, we will employ the pFUnit framework (https://sourceforge.net/projects/pfunit).
For the time being OpenFAST provides project and solution files to support users developing and compiling using Visual Studio. However, the team is continually working to automate the generation of Visual Studio build files via CMake in future releases.
Please contact Michael.A.Sprague@NREL.gov with questions regarding the OpenFAST development plan.
API changes between versions¶
This page lists the main changes in the OpenFAST API (input files) between different versions.
The changes are tabulated according to the module input file, line number, and flag name. The line number corresponds to the resulting line number after all changes are implemented. Thus, be sure to implement each in order so that subsequent line numbers are correct.
OpenFAST v3.2.0 to OpenFAST dev¶
None
OpenFAST v3.1.0 to OpenFAST v3.2.0¶
Added in OpenFAST v3.2.0 


Module 
Line 
Flag Name 
Example Value 
TurbSim 
13 
WrHAWCFF 
False WrHAWCFF  Output fullfield timeseries data in HAWC form? (Generates RootNameu.bin, RootNamev.bin, RootNamew.bin, RootName.hawc) 
Removed in OpenFAST v3.2.0 


Module 
Line 
Flag Name 
Example Value 
TurbSim 
14 
Clockwise 
True Clockwise  Clockwise rotation looking downwind? (used only for fullfield binary files  not necessary for AeroDyn) 
OpenFAST v3.0.0 to OpenFAST v3.1.0¶
Added in OpenFAST v3.1.0 


Module 
Line 
Flag Name 
Example Value 
ServoDyn 
60 
AeroControlSec 
——————— AERODYNAMIC FLOW CONTROL ——————————– 
ServoDyn 
61 
AfCmode 
0 AfCmode  Airfoil control mode {0: none, 1: cosine wave cycle, 4: userdefined from Simulink/Labview, 5: userdefined from Bladedstyle DLL} (switch) 
ServoDyn 
62 
AfC_Mean 
0 AfC_Mean  Mean level for cosine cycling or steady value () [used only with AfCmode==1] 
ServoDyn 
63 
AfC_Amp 
0 AfC_Amp  Amplitude for cosine cycling of flap signal () [used only with AfCmode==1] 
ServoDyn 
64 
AfC_Phase 
0 AfC_Phase  Phase relative to the blade azimuth (0 is vertical) for cosine cycling of flap signal (deg) [used only with AfCmode==1] 
ServoDyn 
74 
CablesSection 
——————— CABLE CONTROL —————————————— 
ServoDyn 
75 
CCmode 
0 CCmode  Cable control mode {0: none, 4: userdefined from Simulink/Labview, 5: userdefined from Bladedstyle DLL} (switch) 
HydroDyn driver 
6 
WtrDens 
1025 WtrDens  Water density (kg/m^3) 
HydroDyn driver 
7 
WtrDpth 
200 WtrDpth  Water depth (m) 
HydroDyn driver 
8 
MSL2SWL 
0 MSL2SWL  Offset between stillwater level and mean sea level (m) [positive upward] 
OpenFAST 
21 
MHK 
0 MHK  MHK turbine type (switch) {0=Not an MHK turbine; 1=Fixed MHK turbine; 2=Floating MHK turbine} 
OpenFAST 
22 
N/A 
——————— ENVIRONMENTAL CONDITIONS ——————————– 
OpenFAST 
23 
Gravity 
9.80665 Gravity  Gravitational acceleration (m/s^2) 
OpenFAST 
24 
AirDens 
1.225 AirDens  Air density (kg/m^3) 
OpenFAST 
25 
WtrDens 
1025 WtrDens  Water density (kg/m^3) 
OpenFAST 
26 
KinVisc 
1.464E05 KinVisc  Kinematic viscosity of working fluid (m^2/s) 
OpenFAST 
27 
SpdSound 
335 SpdSound  Speed of sound in air (m/s) 
OpenFAST 
28 
Patm 
103500 Patm  Atmospheric pressure (Pa) [used only for an MHK turbine cavitation check] 
OpenFAST 
29 
Pvap 
1700 Pvap  Vapour pressure of working fluid (Pa) [used only for an MHK turbine cavitation check] 
OpenFAST 
30 
WtrDpth 
50 WtrDpth  Water depth (m) 
OpenFAST 
31 
MSL2SWL 
0 MSL2SWL  Offset between stillwater level and mean sea level (m) [positive upward] 
AeroDyn 15 
40 
UAStartRad 
0.25 UAStartRad  Starting radius for dynamic stall (fraction of rotor radius) [used only when AFAeroMod=2; if line is missing UAStartRad=0] 
AeroDyn 15 
41 
UAEndRad 
0.95 UAEndRad  Ending radius for dynamic stall (fraction of rotor radius) [used only when AFAeroMod=2; if line is missing UAEndRad=1] 
AeroDyn driver 
34 
Twr2Shft 
3.09343 Twr2Shft  Vertical distance from the towertop to the rotor shaft (m) 
AirFoilTables 
12* 
alphaUpper 
5.0 alphaUpper ! Angle of attack at upper boundary of fullyattached region. (deg) [used only when UAMod=5] ! THIS IS AN OPTIONAL LINE; if omitted, it will be calculated from the polar data 
AirFoilTables 
13* 
alphaLower 
3.0 alphaLower ! Angle of attack at lower boundary of fullyattached region. (deg) [used only when UAMod=5] ! THIS IS AN OPTIONAL LINE; if omitted, it will be calculated from the polar data 
AirFoilTables 
42* 
UACutout_delta 
“DEFAULT” UACutout_delta ! Delta angle of attack below UACutout where unsteady aerodynamics begin to turn off (blend with steady solution) (deg) [Specifying the string “Default” sets UACutout_delta to 5 degrees] ! THIS IS AN OPTIONAL LINE; if omitted, it will be set to its default value 
*noncomment line count, excluding lines contained if NumCoords is not 0, and including all OPTIONAL lines in the UA coefficients table.
Modified in OpenFAST v3.1.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn 
16 
AirDens 
“default” AirDens  Air density (kg/m^3) 
AeroDyn 
17 
KinVisc 
“default” KinVisc  Kinematic viscosity of working fluid (m^2/s) 
AeroDyn 
18 
SpdSound 
“default” SpdSound  Speed of sound in air (m/s) 
AeroDyn 
19 
Patm 
“default” Patm  Atmospheric pressure (Pa) [used only when CavitCheck=True] 
AeroDyn 
20 
Pvap 
“default” Pvap  Vapour pressure of working fluid (Pa) [used only when CavitCheck=True] 
HydroDyn 
5 
WtrDens 
“default” WtrDens  Water density (kg/m^3) 
HydroDyn 
6 
WtrDpth 
“default” WtrDpth  Water depth (meters) 
HydroDyn 
7 
MSL2SWL 
“default” MSL2SWL  Offset between stillwater level and mean sea level (meters) [positive upward; unused when WaveMod = 6; must be zero if PotMod=1 or 2] 
Removed in OpenFAST v3.1.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn 
21 
FluidDepth 
0.5 FluidDepth  Water depth above midhub height (m) [used only when CavitCheck=True] 
ElastoDyn 
7 
N/A 
——————— ENVIRONMENTAL CONDITION ——————————— 
ElastoDyn 
8 
Gravity 
9.80665 Gravity  Gravitational acceleration (m/s^2) 
The AeroDyn driver input file was completely rewritten. You may consult the following examples for a
single rotor
andmultiple rotors
in addition to the AeroDyn driver documentation.SubDyn
SubDyn Driver, applied loads input:
Added 


Module 
Line 
Flag Name 
Example Value 
SubDyn driver 
21 
[separator line] 
——————— LOADS ——————————————————————– 
SubDyn driver 
22 
nAppliedLoads 
1 nAppliedLoads  Number of applied loads at given nodes false 
SubDyn driver 
23 
ALTableHeader 
ALJointID Fx Fy Fz Mx My Mz UnsteadyFile 
SubDyn driver 
24 
ALTableUnit 
() (N) (N) (N) (Nm) (Nm) (Nm) () 
SubDyn driver 
25 
ALTableLine1 
10 0.0 0.0 0.0 0.0 0.0 0.0 “” 
SubDyn: the lines at n+1 and n+2 below were inserted after line n.
Added 


Module 
Line 
Flag Name 
Example Value 
SubDyn 
n 
OutCOSM 
Output cosine matrices with the selected output member forces (flag) 
SubDyn 
n+1 
OutCBModes 
Output Guyan and CraigBampton modes {0: No output, 1: JSON output}, (flag) 
SubDyn 
n+2 
OutFEMModes 
Output first 30 FEM modes {0: No output, 1: JSON output} (flag) 
OpenFAST v2.6.0 to OpenFAST v3.0.0¶
ServoDyn Changes
The input file parser is updated to a keyword/value pair based input. Each entry must have a corresponding keyword with the same spelling as expected.
The TMD submodule of ServoDyn is replaced by an updated Structural Control module (StC) with updated capabilities and input file.
Removed in OpenFAST v3.0.0 


Module 
Line 
Flag Name 
Example Value 
ServoDyn 
60 
na 
——————— TUNED MASS DAMPER ————————————— 
ServoDyn 
61 
CompNTMD 
False CompNTMD  Compute nacelle tuned mass damper {true/false} (flag) 
ServoDyn 
62 
NTMDfile 
“NRELOffshrBsline5MW_ServoDyn_TMD.dat” NTMDfile  Name of the file for nacelle tuned mass damper (quoted string) [unused when CompNTMD is false] 
ServoDyn 
63 
CompTTMD 
False CompTTMD  Compute tower tuned mass damper {true/false} (flag) 
ServoDyn 
64 
TTMDfile 
“NRELOffshrBsline5MW_ServoDyn_TMD.dat” TTMDfile  Name of the file for tower tuned mass damper (quoted string) [unused when CompTTMD is false] 
Added in OpenFAST v3.0.0 


Module 
Line 
Flag Name 
Example Value 
ServoDyn 
60 
na 
——————— STRUCTURAL CONTROL ————————————– 
ServoDyn 
61 
NumBStC 
0 NumBStC  Number of blade structural controllers (integer) 
ServoDyn 
62 
BStCfiles 
“unused” BStCfiles  Name of the files for blade structural controllers (quoted strings) [unused when NumBStC==0] 
ServoDyn 
63 
NumNStC 
0 NumNStC  Number of nacelle structural controllers (integer) 
ServoDyn 
64 
NStCfiles 
“unused” NStCfiles  Name of the files for nacelle structural controllers (quoted strings) [unused when NumNStC==0] 
ServoDyn 
65 
NumTStC 
0 NumTStC  Number of tower structural controllers (integer) 
ServoDyn 
66 
TStCfiles 
“unused” TStCfiles  Name of the files for tower structural controllers (quoted strings) [unused when NumTStC==0] 
ServoDyn 
67 
NumSStC 
0 NumSStC  Number of substructure structural controllers (integer) 
ServoDyn 
68 
SStCfiles 
“unused” SStCfiles  Name of the files for substructure structural controllers (quoted strings) [unused when NumSStC==0] 
OpenFAST v2.5.0 to OpenFAST v2.6.0¶
Many changes were applied to SubDyn input file format. You may consult the following example:
(SubDyn's Input File)
:
and the online SubDyn documentation.
Added in OpenFAST v2.6.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn 15 
TwrTi 
0.0000000E+00 6.0000000E+00 1.0000000E+00 1.0000000E01 [additional column in Tower Influence and Aerodynamics table] 

SubDyn 
8 
GuyanLoadCorr. 
False GuyanLoadCorection  Include extra moment from lever arm at interface and rotate FEM for floating 
SubDyn 
15 
GuyanDampMod 
0 GuyanDampMod  Guyan damping {0=none, 1=Rayleigh Damping, 2=user specified 6x6 matrix} 
SubDyn 
16 
RayleighDamp 
0.001, 0.003 RayleighDamp  Mass and stiffness proportional damping coefficients (Rayleigh Damping) [only if GuyanDampMod=1] 
SubDyn 
17 
GuyanDampSize 
6 GuyanDampSize  Guyan damping matrix size (square, 6x6) [only if GuyanDampMod=2] 
SubDyn 
18 
GuyanDampMat 
0.0000e+00 0.0000e+00 0.0000e+00 0.0000e+00 0.0000e+00 0.0000e+00 
SubDyn 
23 
GuyanDampMat 
0.0000e+00 0.0000e+00 0.0000e+00 0.0000e+00 0.0000e+00 0.0000e+00 
SubDyn 
na 
CablesSection 
————————– CABLE PROPERTIES ———————————— 
SubDyn 
na 
CablesSection 
0 NCablePropSets  Number of cable cable properties 
SubDyn 
na 
CablesSection 
PropSetID EA MatDens T0 
SubDyn 
na 
CablesSection 
() (N) (kg/m) (N) 
SubDyn 
na 
RigidSection 
——————— RIGID LINK PROPERTIES ———————————— 
SubDyn 
na 
RigidSection 
0 NRigidPropSets  Number of rigid link properties 
SubDyn 
na 
RigidSection 
PropSetID MatDens 
SubDyn 
na 
RigidSection 
() (kg/m) 
HydroDyn 
52 
NBody 
1 NBody  Number of WAMIT bodies to be used () [>=1; only used when PotMod=1. If NBodyMod=1, the WAMIT data contains a vector of size 6*NBody x 1 and matrices of size 6*NBody x 6*NBody; if NBodyMod>1, there are NBody sets of WAMIT data each with a vector of size 6 x 1 and matrices of size 6 x 6] 
HydroDyn 
53 
NBodyMod 
1 NBodyMod  Body coupling model {1: include coupling terms between each body and NBody in HydroDyn equals NBODY in WAMIT, 2: neglect coupling terms between each body and NBODY=1 with XBODY=0 in WAMIT, 3: Neglect coupling terms between each body and NBODY=1 with XBODY=/0 in WAMIT} (switch) [only used when PotMod=1] 
ServoDyn 
61 
NumBStC 
0 NumBStC  Number of blade structural controllers (integer) 
ServoDyn 
62 
BStCfiles 
“unused” BStCfiles  Name of the files for blade structural controllers (quoted strings) [unused when NumBStC==0] 
ServoDyn 
63 
NumNStC 
0 NumNStC  Number of nacelle structural controllers (integer) 
ServoDyn 
64 
NStCfiles 
“unused” NStCfiles  Name of the files for nacelle structural controllers (quoted strings) [unused when NumNStC==0] 
ServoDyn 
65 
NumTStC 
0 NumTStC  Number of tower structural controllers (integer) 
ServoDyn 
66 
TStCfiles 
“unused” TStCfiles  Name of the files for tower structural controllers (quoted strings) [unused when NumTStC==0] 
ServoDyn 
67 
NumSStC 
0 NumSStC  Number of substructure structural controllers (integer) 
ServoDyn 
68 
SStCfiles 
“unused” SStCfiles  Name of the files for substructure structural controllers (quoted strings) [unused when NumSStC==0] 
AirFoilTables 
12* 
alphaUpper 
5.0 alphaUpper ! Angle of attack at upper boundary of fullyattached region. (deg) [used only when UAMod=5] ! THIS IS AN OPTIONAL LINE; if omitted, it will be calculated from the polar data 
AirFoilTables 
13* 
alphaLower 
3.0 alphaLower ! Angle of attack at lower boundary of fullyattached region. (deg) [used only when UAMod=5] ! THIS IS AN OPTIONAL LINE; if omitted, it will be calculated from the polar data 
AirFoilTables 
42* 
UACutout_delta 
“DEFAULT” UACutout_delta ! Delta angle of attack below UACutout where unsteady aerodynamics begin to turn off (blend with steady solution) (deg) [Specifying the string “Default” sets UACutout_delta to 5 degrees] ! THIS IS AN OPTIONAL LINE; if omitted, it will be set to its default value 
*noncomment line count, excluding lines contained if NumCoords is not 0, and including all OPTIONAL lines in the UA coefficients table.
Modified in OpenFAST v2.6.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn 15 
9 
TwrShadow 
0 TwrShadow  Calculate tower influence on wind based on downstream tower shadow (switch) {0=none, 1=Powles model, 2=Eames model} 
SubDyn 
26 
Joints 
JointID JointXss JointYss JointZss JointType JointDirX JointDirY JointDirZ JointStiff 
SubDyn 
27 
Joints 
() (m) (m) (m) () () () () (Nm/rad) 
SubDyn 
na 
Members 
MemberID MJointID1 MJointID2 MPropSetID1 MPropSetID2 MType COSMID 
SubDyn 
na 
Members 
() () () () () () () 
SubDyn 
na 
ConcentratedM 
CMJointID JMass JMXX JMYY JMZZ JMXY JMXZ JMYZ MCGX MCGY MCGZ 
SubDyn 
na 
ConcentratedM 
() (kg) (kg*m^2) (kg*m^2) (kg*m^2) (kg*m^2) (kg*m^2) (kg*m^2) (m) (m) (m) 
HydroDyn 
48 
ExtnMod 
1 ExctnMod  Waveexcitation model {0: no waveexcitation calculation, 1: DFT, 2: statespace} (switch) [only used when PotMod=1; STATESPACE REQUIRES *.ssexctn INPUT FILE] 
HydroDyn 
49 
RdtnMod 
2 RdtnMod  Radiation memoryeffect model {0: no memoryeffect calculation, 1: convolution, 2: statespace} (switch) [only used when PotMod=1; STATESPACE REQUIRES *.ss INPUT FILE] 
HydroDyn 
50 
RdtnTMax 
60 RdtnTMax  Analysis time for wave radiation kernel calculations (sec) [only used when PotMod=1 and RdtnMod>0; determines RdtnDOmega=Pi/RdtnTMax in the cosine transform; MAKE SURE THIS IS LONG ENOUGH FOR THE RADIATION IMPULSE RESPONSE FUNCTIONS TO DECAY TO NEARZERO FOR THE GIVEN PLATFORM!] 
HydroDyn 
51 
RdtnDT 
0.0125 RdtnDT  Time step for wave radiation kernel calculations (sec) [only used when PotMod=1 and ExctnMod>0 or RdtnMod>0; DT<=RdtnDT<=0.1 recommended; determines RdtnOmegaMax=Pi/RdtnDT in the cosine transform] 
HydroDyn 
54 
PotFile 
“Barge” PotFile  Root name of potentialflow model data; WAMIT output files containing the linear, nondimensionalized, hydrostatic restoring matrix (.hst), frequencydependent hydrodynamic added mass matrix and damping matrix (.1), and frequency and directiondependent wave excitation force vector per unit wave amplitude (.3) (quoted string) [1 to NBody if NBodyMod>1] [MAKE SURE THE FREQUENCIES INHERENT IN THESE WAMIT FILES SPAN THE PHYSICALLYSIGNIFICANT RANGE OF FREQUENCIES FOR THE GIVEN PLATFORM; THEY MUST CONTAIN THE ZERO AND INFINITEFREQUENCY LIMITS!] 
HydroDyn 
55 
WAMITULEN 
1 WAMITULEN  Characteristic body length scale used to redimensionalize WAMIT output (meters) [1 to NBody if NBodyMod>1] [only used when PotMod=1] 
HydroDyn 
56 
PtfmRefxt 
0.0 PtfmRefxt  The xt offset of the body reference point(s) from (0,0,0) (meters) [1 to NBody] [only used when PotMod=1] 
HydroDyn 
57 
PtfmRefyt 
0.0 PtfmRefyt  The yt offset of the body reference point(s) from (0,0,0) (meters) [1 to NBody] [only used when PotMod=1] 
HydroDyn 
58 
PtfmRefzt 
0.0 PtfmRefzt  The zt offset of the body reference point(s) from (0,0,0) (meters) [1 to NBody] [only used when PotMod=1. If NBodyMod=2,PtfmRefzt=0.0] 
HydroDyn 
59 
PtfmRefztRot 
0.0 PtfmRefztRot  The rotation about zt of the body reference frame(s) from xt/yt (degrees) [1 to NBody] [only used when PotMod=1] 
HydroDyn 
60 
PtfmVol0 
6000 PtfmVol0  Displaced volume of water when the body is in its undisplaced position (m^3) [1 to NBody] [only used when PotMod=1; USE THE SAME VALUE COMPUTED BY WAMIT AS OUTPUT IN THE .OUT FILE!] 
HydroDyn 
61 
PtfmCOBxt 
0.0 PtfmCOBxt  The xt offset of the center of buoyancy (COB) from (0,0) (meters) [1 to NBody] [only used when PotMod=1] 
HydroDyn 
62 
PtfmCOByt 
0.0 PtfmCOByt  The yt offset of the center of buoyancy (COB) from (0,0) (meters) [1 to NBody] [only used when PotMod=1] 
HydroDyn 
6974 
AddF0 
0 AddF0  Additional preload (N, Nm) [If NBodyMod=1, one size 6*NBody x 1 vector; if NBodyMod>1, NBody size 6 x 1 vectors] 
HydroDyn 
7580 
AddCLin 
0 0 0 0 0 0 AddCLin  Additional linear stiffness (N/m, N/rad, Nm/m, Nm/rad) [If NBodyMod=1, one size 6*NBody x 6*NBody matrix; if NBodyMod>1, NBody size 6 x 6 matrices] 
HydroDyn 
8186 
AddBLin 
0 0 0 0 0 0 AddBLin  Additional linear damping(N/(m/s), N/(rad/s), Nm/(m/s), Nm/(rad/s)) [If NBodyMod=1, one size 6*NBody x 6*NBody matrix; if NBodyMod>1, NBody size 6 x 6 matrices] 
HydroDyn 
8792 
AddBQuad 
0 0 0 0 0 0 AddBQuad  Additional quadratic drag(N/(m/s)^2, N/(rad/s)^2, Nm(m/s)^2, Nm/(rad/s)^2) [If NBodyMod=1, one size 6*NBody x 6*NBody matrix; if NBodyMod>1, NBody size 6 x 6 matrices] 
HydroDyn 
na 
Simple Coef Tab 
SimplCd SimplCdMG SimplCa SimplCaMG SimplCp SimplCpMG SimplAxCa SimplAxCaMG SimplAxCa SimplAxCaMG SimplAxCp SimplAxCpMG 
HydroDyn 
na 
() () () () () () () () () () () () 

HydroDyn 
na 
Depth Coef Tab 
Dpth DpthCd DpthCdMG DpthCa DpthCaMG DpthCp DpthCpMG DpthAxCa DpthAxCaMG DpthAxCa DpthAxCaMG DpthAxCp DpthAxCpMG 
HydroDyn 
na 


HydroDyn 
na 
Member Coef Tab 
MemberID MemberCd1 MemberCd2 MemberCdMG1 MemberCdMG2 MemberCa1 MemberCa2 MemberCaMG1 MemberCaMG2 MemberCp1 MemberCp2 MemberCpMG1 MemberCpMG2 MemberAxCd1 MemberAxCd2 MemberAxCdMG1 MemberAxCdMG2 MemberAxCa1 MemberAxCa2 MemberAxCaMG1 MemberAxCaMG2 MemberAxCp1 MemberAxCp2 MemberAxCpMG1 MemberAxCpMG2 
HydroDyn 
na 
() () () () () () () () () () () () () () () () () () () () () () () () () 

HydroDyn 
na 
OutList names 
see OutlistParameters.xlsx for new and revised output channel names 
Removed in OpenFAST v2.6.0 


Module 
Line 
Flag Name 
Example Value 
HydroDyn 
68 
na 
——————— FLOATING PLATFORM FORCE FLAGS ————————– [unused with WaveMod=6] 
HydroDyn 
69 
PtfmSgF 
True PtfmSgF  Platform horizontal surge translation force (flag) or DEFAULT 
HydroDyn 
70 
PtfmSwF 
True PtfmSwF  Platform horizontal sway translation force (flag) or DEFAULT 
HydroDyn 
71 
PtfmHvF 
True PtfmHvF  Platform vertical heave translation force (flag) or DEFAULT 
HydroDyn 
72 
PtfmRF 
True PtfmRF  Platform roll tilt rotation force (flag) or DEFAULT 
HydroDyn 
73 
PtfmPF 
True PtfmPF  Platform pitch tilt rotation force (flag) or DEFAULT 
HydroDyn 
74 
PtfmYF 
True PtfmYF  Platform yaw rotation force (flag) or DEFAULT 
OpenFAST v2.4.0 to OpenFAST v2.5.0¶
InflowWind
The input file parser is updated to a keyword/value pair based input. Each entry must have a corresponding keyword with the same spelling as expected. See Section 4.1.3 for an overview.
Driver code includes ability to convert between wind types
Added in OpenFAST v2.5.0 


Module 
Line 
Flag Name 
Example Value 
IfW driver 
6 
[separator line] 
===================== File Conversion Options ================================= 
IfW driver 
7 
WrHAWC 
false WrHAWC  Convert all data to HAWC2 format? (flag) 
IfW driver 
8 
WrBladed 
false WrBladed  Convert all data to Bladed format? (flag) 
IfW driver 
9 
WrVTK 
false WrVTK  Convert all data to VTK format? (flag) 
InflowWind 
7 
VFlowAng 
0 VFlowAng  Upflow angle (degrees) (not used for native Bladed format WindType=7) 
Modified in OpenFAST v2.5.0 


Module 
Line 
Flag Name / section 
Example Value 
MoorDyn 
na 
added CtrlChan column in LINE PROPERTIES table 
Line LineType UnstrLen NumSegs NodeAnch NodeFair Outputs CtrlChan
() () (m) () () () () ()
1 main 835.35 20 1 4  0

OpenFAST v2.3.0 to OpenFAST v2.4.0¶
Additional nodal output channels added for AeroDyn15, BeamDyn, and ElastoDyn.
Added in OpenFAST v2.4.0 


Module 
Line 
Flag Name 
Example Value 
HydroDyn 
53 
ExctnMod 
0 ExctnMod  Wave Excitation model {0: None, 1: DFT, 2: statespace} () 
OpenFAST 
44 
CalcSteady 
true CalcSteady  Calculate a steadystate periodic operating point before linearization? [unused if Linearize=False] (flag) 
OpenFAST 
45 
TrimCase 
3 TrimCase  Controller parameter to be trimmed {1:yaw; 2:torque; 3:pitch} [used only if CalcSteady=True] () 
OpenFAST 
46 
TrimTol 
0.0001 TrimTol  Tolerance for the rotational speed convergence [used only if CalcSteady=True] () 
OpenFAST 
47 
TrimGain 
0.001 TrimGain  Proportional gain for the rotational speed error (>0) [used only if CalcSteady=True] (rad/(rad/s) for yaw or pitch; Nm/(rad/s) for torque) 
OpenFAST 
48 
Twr_Kdmp 
0 Twr_Kdmp  Damping factor for the tower [used only if CalcSteady=True] (N/(m/s)) 
OpenFAST 
49 
Bld_Kdmp 
0 Bld_Kdmp  Damping factor for the blades [used only if CalcSteady=True] (N/(m/s)) 
InflowWind 
48 
InitPosition(x) 
0.0 InitPosition(x)  Initial offset in +x direction (shift of wind box) [Only used with WindType = 5] (m) 
AeroDyn 
13 
CompAA 
False CompAA  Flag to compute AeroAcoustics calculation [only used when WakeMod=1 or 2] 
AeroDyn 
14 
AA_InputFile 
“unused” AA_InputFile  Aeroacoustics input file 
AeroDyn 
35 
[separator line] 
====== OLAF cOnvecting LAgrangian Filaments (Free Vortex Wake) Theory Options ================== [used only when WakeMod=3] 
AeroDyn 
36 
OLAFInputFileName 
“Elliptic_OLAF.dat” OLAFInputFileName  Input file for OLAF [used only when WakeMod=3] 
AirFoilTables 
4* 
BL_file 
“unused” BL_file  The file name including the boundary layer characteristics of the profile. Ignored if the aeroacoustic module is not called. 
Modified in OpenFAST v2.4.0 


Module 
Line 
New Flag Name 
Example Value 
Previous Flag Name/Value 
AirFoilTables 
40* 
filtCutOff 
“DEFAULT” filtCutOff  Reduced frequency cutoff for lowpass filtering the AoA input to UA, as well as the 1st and 2nd deriv () [default = 0.5] 
[default = 20] 
InflowWind 
17 
Filename_Uni 
“unused” Filename_Uni  Filename of time series data for uniform wind field. () 
Filename 
InflowWind 
18 
RefHt_Uni 
90 RefHt_Uni  Reference height for horizontal wind speed (m) 
RefHt 
InflowWind 
35 
RefHt_Hawc 
90 RefHt_Hawc  reference height; the height (in meters) of the vertical center of the grid (m) 
RefHt 
InflowWind 
47 
PLExp_Hawc 
0.2 PLExp_Hawc  Power law exponent () (used for PL wind profile type only) 
PLExp 
InflowWind 
49 
XOffset 
0 XOffset  Initial offset in +x direction (shift of wind box) 
InitPosition(x) 
*noncomment line count, excluding lines contained if NumCoords is not 0.
OpenFAST v2.2.0 to OpenFAST v2.3.0¶
Removed in OpenFAST v2.3.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn Airfoil Input File  Airfoil Tables 
2 
Ctrl 
0 Ctrl ! Control setting (must be 0 for current AirfoilInfo) 
Added in OpenFAST v2.3.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn Airfoil Input File  Airfoil Tables 
2 
UserProp 
0 UserProp ! User property (control) setting 
AeroDyn 
37 
AFTabMod 
1 AFTabMod  Interpolation method for multiple airfoil tables {1=1D interpolation on AoA (first table only); 2=2D interpolation on AoA and Re; 3=2D interpolation on AoA and UserProp} () 
OpenFAST v2.1.0 to OpenFAST v2.2.0¶
No changes required.
OpenFAST v2.0.0 to OpenFAST v2.1.0¶
Added in OpenFAST v2.1.0 


Module 
Line 
Flag Name 
Example Value 
BeamDyn driver 
21 
GlbRotBladeT0 
True GlbRotBladeT0  Reference orientation for BeamDyn calculations is aligned with initial blade root? 
OpenFAST v1.0.0 to OpenFAST v2.0.0¶
Removed in OpenFAST v2.0.0 


Module 
Line 
Flag Name 
Example Value 
BeamDyn 
5 
analysis_type 
analysis_type  1: Static analysis; 2: Dynamic analysis 
Added in OpenFAST v2.0.0 


Module 
Line 
Flag Name 
Example Value 
AeroDyn 
22 
SkewModFactor 
“default” SkewModFactor  Constant used in Pitt/Peters skewed wake model {or “default” is 15/32*pi} () [used only when SkewMod=2; unused when WakeMod=0] 
AeroDyn 
30 
Section header 
====== Dynamic BladeElement/Momentum Theory Options ============================================== [used only when WakeMod=2] 
AeroDyn 
31 
DBEMT_Mod 
2 DBEMT_Mod  Type of dynamic BEMT (DBEMT) model {1=constant tau1, 2=timedependent tau1} () [used only when WakeMod=2] 
AeroDyn 
32 
tau1_const 
4 tau1_const  Time constant for DBEMT (s) [used only when WakeMod=2 and DBEMT_Mod=1] 
BeamDyn 
5 
QuasiStaticInit 
True QuasiStaticInit  Use quasistatic preconditioning with centripetal accelerations in initialization (flag) [dynamic solve only] 
BeamDyn 
11 
load_retries 
DEFAULT load_retries  Number of factored load retries before quitting the simulation 
BeamDyn 
14 
tngt_stf_fd 
DEFAULT tngt_stf_fd  Flag to use finite differenced tangent stiffness matrix () 
BeamDyn 
15 
tngt_stf_comp 
DEFAULT tngt_stf_comp  Flag to compare analytical finite differenced tangent stiffness matrix () 
BeamDyn 
16 
tngt_stf_pert 
DEFAULT tngt_stf_pert  perturbation size for finite differencing () 
BeamDyn 
17 
tngt_stf_difftol 
DEFAULT tngt_stf_difftol  Maximum allowable relative difference between analytical and fd tangent stiffness () 
BeamDyn 
18 
RotStates 
True RotStates  Orient states in the rotating frame during linearization? (flag) [used only when linearizing] 
FAST v8.16 to OpenFAST v1.0.0¶
The transition from FAST v8 to OpenFAST is described in detail at FAST v8 and the transition to OpenFAST.
Removed in OpenFAST v1.0.0 


Module 
Line 
Flag Name 
Example Value 
OpenFAST 
18 
CompSub 
0 CompSub  Compute substructural dynamics (switch) {0=None; 1=SubDyn} 
Added in OpenFAST v1.0.0 


Module 
Line 
Flag Name 
Example Value 
OpenFAST 
18 
CompSub 
0 CompSub  Compute substructural dynamics (switch) {0=None; 1=SubDyn; 2=External Platform MCKF} 
AeroDyn 
12 
CavityCheck 
False CavitCheck  Perform cavitation check? (flag) 
AeroDyn 
17 
Patm 
9999.9 Patm  Atmospheric pressure (Pa) [used only when CavitCheck=True] 
AeroDyn 
18 
Pvap 
9999.9 Pvap  Vapor pressure of fluid (Pa) [used only when CavitCheck=True] 
AeroDyn 
19 
FluidDepth 
9999.9 FluidDepth  Water depth above midhub height (m) [used only when CavitCheck=True] 
Input file formats¶
OpenFAST uses two primary input file formats: value column where the first value on the line is read, and key+value where a value and keyword pair are read. Both formats are line number based where a specific input is expected on a specific line, with some exceptions.
Value column input files¶
Only the first column in a value column based input file is read. This is the historical format used by OpenFAST and its predecessors (the keyword was often referenced in the source code and documentation, but OpenFAST did not process the keyword or description). Everything after the first value read is simply ignored by the code. This allowed the user to keep old values while modifying things. So for example, and input line like
2 20 TMax  Total run time (s)
would be read as 2 and the 20 and everything after it ignored.
This format and associated parsing methodology is somewhat limited in informing the user of errors in parsing, and limited the ability to pass entire inpute files as text strings from another code (such as a Python driver code).
Key + Value input files¶
The first two columns are read in key + value input files. One of these two columns must contain the exact keyword, and the other must contain the value that corresponds to it. For example, an input line
20 TMax  Total run time (s)
is equivalent to
TMax 20  Total run time (s)
One additional feature of this input file format is the ability to add an arbitrary number of comment lines wherever the user wishes. Any line starting with !, #, or % will be treated as a comment line and ignored. For example,
! This is a comment line that will be skipped
% and this is also a comment line that will be skipped
# as is this comment line
20 TMax  Total run time (s)
! the first two columns in the above line will be read as the value + key
The parser for this format of input file also tracks which lines were comments, and which lines contained the value and key pair. If a keyname is not found the parser will return an error with information about which line it was reading from.
Modules using Key + Value Format¶
The following modules use the key + value format input files (all other modules use the value column format):
Module 
Input file 

AeroDyn 
Main AD15 input file 
AeroDyn 
Airfoil files 
HydroDyn 
Main HD input file 
InflowWind 
Main IfW input file 
InflowWind 
Uniform wind input file 
InflowWind 
Bladed wind summary file 
ServoDyn 
Main ServoDyn input file 
ServoDyn 
Structural control submodule input file 
ServoDyn 
Structural control sumbodule prescribed force input file 
SubDyn 
SubDyn SSI matrix input files 
Note that key + value format and value column input files can be identical if the value is stated before the key.
Reasons for change¶
The main reason for the change in the input file parsing was to allow for the passing of a complete input file in memory from a wrapper code into OpenFAST or a module. For example, when including the AeroDyn module into a Python code, the input file can be passed in directly in memory without writing to disk first. This helps reduce the IO overhead in optimization loops where the module might be called many times sequentially with very small changes to the input file. NOTE: this is still a work in progress, so not all modules can be linked this way yet.
To accomplish this, the file parser written by Marshall Buhl for parsing airfoil tables in AeroDyn 15 in FAST8 was used. This parser included the more robust key + value input format.
Troubleshooting input files¶
When troubleshooting an input file error, try the following procedure:
An error message containing a line number and variable name, the file format being parsed is a key + value format. Check that the key is spelled exactly as the input file. See Section 4.1.3.2 below.
An error message containing only the variable name but no line number is a value column input file format. See Section 4.1.3.1 below.
Turn on echo option in the input file and check the resulting .ech for which line the file parsing stopped at. This may help isolate where the input file parsing failed when no line number is given in the error message.
Compare the problematic input file with an input file of the same type from the regression test suite distributed with OpenFAST. See section Section 3 for details on the regression tests, or check the repository at rtest .
Workshop material, legacy documentation, and other resources are listed below.
FAST modularization framework for wind turbine simulation: fullsystem linearization
FullSystem Linearization for Floating Offshore Wind Turbines in OpenFAST
OutListParameters.xlsx
 Contains the full list of outputs for each module.
Module Documentation¶
This section contains documentation for the OpenFAST modulecoupling environment and its underlying modules. Documentation covers usage of models, underlying theory, and in some cases module verification.
AeroDyn Users Guide and Theory Manual¶
This document offers a quick reference guide for the AeroDyn software program. It is intended to be used by the general user in combination with other OpenFAST manuals. The manual will be updated as new releases are issued and as needed to provide further information on advancements or modifications to the software. For reference, additional materials such as presentation slides, development plans, and publications can be downladed from the list below.
Development and Validation of a New Blade Element Momentum SkewedWake Model within AeroDyn
AddedMass Effects on a HorizontalAxis Tidal Turbine Using FAST v8
Predicting Cavitation on Marine and Hydrokinetic Turbine Blades with AeroDyn V15.04
Development Plan for the Aerodynamic Linearization of OpenFAST
Calculation of Buoyancy on a Marine Hydrokinetic Turbine in AeroDyn
The documentation here was derived from AeroDyn Manual for AeroDyn version 15.04 by J.Jonkman et al.
Introduction¶
AeroDyn is a timedomain wind turbine aerodynamics module that is coupled in the OpenFAST multiphysics engineering tool to enable aeroelastic simulation of horizontalaxis turbines. AeroDyn can also be driven as a standalone code to compute wind turbine aerodynamic response uncoupled from OpenFAST. When coupled to OpenFAST, AeroDyn can also be linearized as part of the linearization of the full coupled solution (linearization is not available in standalone mode). AeroDyn was originally developed for modeling wind turbine aerodynamics. However, the module equally applies to the hydrodynamics of marine hydrokinetic (MHK) turbines (the terms “wind turbine”, “tower”, “aerodynamics” etc. in this document imply “MHK turbine”, “MHK support structure”, “hydrodynamics” etc. for MHK turbines). Additional physics important for MHK turbines, not applicable to wind turbines, computed by AeroDyn include a cavitation check. This documentation pertains version of AeroDyn in the OpenFAST github repository. The AeroDyn version released of OpenFAST 1.0.0 is most closely related to AeroDyn version 15 in the legacy version numbering. AeroDyn version 15 was a complete overhaul from earlier version of AeroDyn. AeroDyn version 15 and newer follows the requirements of the FAST modularization framework.
AeroDyn calculates aerodynamic loads on both the blades and tower. Aerodynamic calculations within AeroDyn are based on the principles of actuator lines, where the threedimensional (3D) flow around a body is approximated by local twodimensional (2D) flow at cross sections, and the distributed pressure and shear stresses are approximated by lift forces, drag forces, and pitching moments lumped at a node in a 2D cross section. Analysis nodes are distributed along the length of each blade and tower, the 2D forces and moment at each node are computed as distributed loads per unit length, and the total 3D aerodynamic loads are found by integrating the 2D distributed loads along the length. When AeroDyn is coupled to OpenFAST, the blade and tower analysis node discretization may be independent from the discretization of the nodes in the structural modules. The actuator line approximations restrict the validity of the model to slender structures and 3D behavior is either neglected, captured through corrections inherent in the model (e.g., tiploss, hubloss, or skewedwake corrections), or captured in the input data (e.g., rotational augmentation corrections applied to airfoil data).
AeroDyn assumes the turbine geometry consists of a one, two, or threebladed rotor atop a single tower. While the undeflected tower is assumed to be straight and vertical, an undeflected blade may consider outofplane curvature and inplane sweep. For blades, the 2D cross sections where the aerodynamic analysis take place may follow the outofplane curvature, but inplane sweep is assumed to be accomplished by shearing, rather than rotation of the 2D cross section. Aerodynamic imbalances are possible through the use of geometrical differences between each blade.
When AeroDyn is coupled to OpenFAST, AeroDyn receives the instantaneous (possibly displaced/deflected) structural position, orientation, and velocities of analysis nodes in the tower, hub, and blades. As with curvature and sweep, the 2D cross sections where the blade aerodynamic analysis takes place will follow the outofplane deflection, but inplane deflection is assumed to be accomplished by shearing, rather than rotation of the 2D cross section. AeroDyn also receives the local freestream (undisturbed) fluid velocities at the tower and blade nodes. (Fluid and structural calculations take place outside of the AeroDyn module and are passed as inputs to AeroDyn by the driver code.) The fluid and structural motions are provided at each coupling time step and then AeroDyn computes the aerodynamic loads on the blade and tower nodes and returns them back to OpenFAST as part of the aeroelastic calculation. In standalone mode, the inputs to AeroDyn are prescribed by a simple driver code, without aeroelastic coupling.
AeroDyn consists of four submodels: (1) rotor wake/induction, (2) blade airfoil aerodynamics, (3) tower influence on the fluid local to the blade nodes, and (4) tower drag. Nacelle, hub, and tailvane fluid influence and loading, aeroacoustics, and wake and array effects between multiple turbines in a wind plant, are not yet available in AeroDyn v15 and newer.
For operating wind and MHK turbine rotors, AeroDyn calculates the influence of the wake via induction factors based on the quasisteady BladeElement/Momentum (BEM) theory, which requires an iterative nonlinear solve (implemented via Brent’s method). By quasisteady, it is meant that the induction reacts instantaneously to loading changes. The induction calculation, and resulting inflow velocities and angles, are based on flow local to each analysis node of each blade, based on the relative velocity between the fluid and structure (including the effects of local inflow skew, shear, turbulence, tower flow disturbances, and structural motion, depending on features enabled). The Glauert’s empirical correction (with Buhl’s modification) replaces the linear momentum balance at high axial induction factors. In the BEM solution, Prandtl tiploss, Prandtl hubloss, and Pitt and Peters skewedwake are all 3D corrections that can optionally be applied. When the skewedwake correction is enabled, it is applied after the BEM iteration. Additionally, the calculation of tangential induction (from the angular momentum balance), the use of drag in the axialinduction calculation, and the use of drag in the tangentialinduction calculation are all terms that can optionally be included in the BEM iteration (even when drag is not used in the BEM iteration, drag is still used to calculate the nodal loads once the induction has been found). The wake/induction calculation can be bypassed altogether for the purposes of modeling rotors that are parked or idling, in which case the inflow velocity and angle are determined purely geometrically. During linearization analyses with AeroDyn coupled to OpenFAST and BEM enabled, the wake can be assumed to be frozen (i.e., the axial and tangential induces velocities, \(V_x a\) and \(V_y a'\), are fixed at their operatingpoint values during linearization) or the induction can be recalculated during linearization using BEM theory. Dynamic wake that accounts for induction dynamics as a result of transient conditions are not yet available in AeroDyn v15 and newer.
The blade airfoil aerodynamics can be steady or unsteady, except in the case that a cavitation check is requested for MHK, in which case only steady aerodynamics are supported. In the steady model, the supplied static airfoil data — including the lift force, drag force, and optional pitching moment and minimum pressure coefficients versus angle of attack (AoA) — are used directly to calculate nodal loads. The AirfoilPrep preprocessor can be used to generate the needed static airfoil data based on uncorrected 2D data (based, e.g., on airfoil tests in a wind tunnel or XFoil), including features to blend data between different airfoils, apply 3D rotational augmentation, and extrapolate to high AoA. The unsteady airfoil aerodynamic (UA) models account for flow hysteresis, including unsteady attached flow, trailingedge flow separation, dynamic stall, and flow reattachment. The UA models can be considered as 2D dynamic corrections to the static airfoil response as a result of timevarying inflow velocities and angles. Three semiempirical UA models are available: the original theoretical developments of BeddoesLeishman (BL), extensions to the BL developed by González, and extensions to the BL model developed by Minnema/Pierce. While all of the UA models are documented in this manual, the original BL model is not yet functional. Testing has shown that the González and Minnema/Pierce models produce reasonable hysteresis of the normal force, tangential force, and pitchingmoment coefficients if the UA model parameters are set appropriately for a given airfoil, Reynolds number, and/or Mach number. However, the results will differ a bit from earlier versions of AeroDyn, (which was based on the Minnema/Pierce extensions to BL) even if the default UA model parameters are used, due to differences in the UA model logic between the versions. We recommend that users run test cases with uniform wind inflow and fixed yaw error (e.g., through the standalone AeroDyn driver) to examine the accuracy of the normal force, tangential force, and pitchingmoment coefficient hysteresis and to adjust the UA model parameters appropriately. The airfoil, Reynolds, and Machdependent parameters of the UA models may be derived from the static airfoil data. These UA models are valid for small to moderate AoA under normal rotor operation; the steady model is more appropriate under parked or idling conditions. The static airfoil data is always used in the BEM iteration; when UA is enabled, it is applied after the BEM iteration and after the skewedwake correction. The UA models are not set up to support linearization, so, UA must be disabled during linearization analyses with AeroDyn coupled to OpenFAST. The interpolation of airfoil data based on Reynolds number or aerodynamiccontrol setting (e.g., flaps) is not yet available in AeroDyn v15 and newer.
The influence of the tower on the fluid flow local to the blade is based on a potentialflow and/or a towershadow model. The potentialflow model uses the analytical potentialflow solution for flow around a cylinder to model the tower dam effect on upwind rotors. In this model, the freestream (undisturbed) flow at each blade node is disturbed based on the location of the blade node relative to the tower and the tower diameter, including lower velocities upstream and downstream of the tower, higher velocities to the left and right of the tower, and crossstream flow. The Bak correction can optionally be included in the potentialflow model, which augments the tower upstream disturbance and improves the tower wake for downwind rotors based on the tower drag coefficient. The tower shadow model can also be enabled to account for the tower wake deficit on downwind rotors. This model includes an axial flow deficit on the freestream fluid at each blade node dependent on the location of the blade node relative to the tower and the tower diameter and drag coefficient, based on the work of Powles. Both towerinfluence models are quasisteady models, in that the disturbance is applied directly to the freestream fluid at the blade nodes without dynamics, and are applied within the BEM iteration.
The aerodynamic load on the tower is based directly on the tower diameter and drag coefficient and the local relative fluid velocity between the freestream (undisturbed) flow and structure at each tower analysis node (including the effects of local shear, turbulence, and structural motion, depending on features enabled). The tower drag load calculation is quasisteady and independent from the tower influence on flow models.
The primary AeroDyn input file defines modeling options, environmental conditions (except freestream flow), airfoils, tower nodal discretization and properties, as well as output file specifications. Airfoil data properties are read from dedicated inputs files (one for each airfoil) and include coefficients of lift force, drag force, and optional pitching moment and minimum pressure versus AoA, as well as UA model parameters. (Minimum pressure coefficients versus AoA are also included in the airfoil input files in case that a cavitation check is requested.) Blade nodal discretization, geometry, twist, chord, and airfoil identifier are likewise read from separate input files (one for each blade).
Section 4.2.1.2 describes the AeroDyn input files. Section 4.2.1.3 discusses the output files generated by AeroDyn; these include an echo file, summary file, and the results file. Section 4.2.1.4 provides modeling guidance when using AeroDyn. Example input files are included in Section 4.2.1.9.1. A summary of available output channels are found Section 4.2.1.9.2.
Input Files¶
The user configures the aerodynamic model parameters via a primary AeroDyn input file, as well as separate input files for airfoil and blade data. When used in standalone mode, an additional driver input file is required. The AeroDyn driver and driver input file are detailed in Section 4.2.1.5. The driver file specifies initialization inputs normally provided to AeroDyn by OpenFAST, as well as the pertimestep inputs to AeroDyn.
As an example, the driver.dvr
file is the main driver, the input.dat
is
the primary input file, the blade.dat
file contains the blade geometry data,
and the airfoil.dat
file contains the airfoil angle of attack, lift, drag,
moment coefficients, and pressure coefficients. Example input files are
included in Section 4.2.1.9.
No lines should be added or removed from the input files, except in tables where the number of rows is specified and comment lines in the AeroDyn airfoil data files.
Units¶
AeroDyn uses the SI system (kg, m, s, N). Angles are assumed to be in radians unless otherwise specified.
AeroDyn Primary Input File¶
The primary AeroDyn input file defines modeling options, environmental conditions (except freestream flow), airfoils, tower nodal discretization and properties, as well as output file specifications.
The file is organized into several functional sections. Each section corresponds to an aspect of the aerodynamics model. A sample AeroDyn primary input file is given in Section 4.2.1.9.
The input file begins with two lines of header information which is for your use, but is not used by the software.
Set the Echo
flag to TRUE if you wish to have AeroDyn echo the
contents of the AeroDyn primary, airfoil, and blade input files (useful
for debugging errors in the input files). The echo file has the naming
convention of OutRootFile.AD.ech. OutRootFile
is either
specified in the I/O SETTINGS section of the driver input file when
running AeroDyn standalone, or by the OpenFAST program when running a
coupled simulation.
DTAero
sets the time step for the aerodynamic calculations. For
accuracy and numerical stability, we recommend that DTAero
be set
such that there are at least 200 azimuth steps per rotor revolution.
However, when AeroDyn is coupled to OpenFAST, OpenFAST may require time steps
much smaller than this rule of thumb. If UA is enabled while using very
small time steps, you may need to recompile AeroDyn in double precision
to avoid numerical problems in the UA routines. The keyword DEFAULT
for DTAero
may be used to indicate that AeroDyn should employ the
time step prescribed by the driver code (OpenFAST or the standalone driver
program).
Set WakeMod
to 0 if you want to disable rotor wake/induction effects or 1 to
include these effects using the (quasisteady) BEM theory model. When
WakeMod
is set to 2, a dynamic BEM theory model (DBEMT) is used (also
referred to as dynamic inflow or dynamic wake model). When WakeMod
is set
to 3, the free vortex wake model is used, also referred to as OLAF (see
Section 4.2.2). WakeMod
cannot be set to 2 or 3 during linearization
analyses.
Set AFAeroMod
to 1 to include steady blade airfoil aerodynamics or 2
to enable UA; AFAeroMod
must be 1 during linearization analyses
with AeroDyn coupled to OpenFAST.
Set TwrPotent
to 0 to disable the
potentialflow influence of the tower on the fluid flow local to the
blade, 1 to enable the standard potentialflow model, or 2 to include
the Bak correction in the potentialflow model.
Set the TwrShadow
to 0 to disable to the tower shadow model,
1 to enable the Powles tower shadow model, or 2 to use the Eames tower
shadow model. These models calculate the influence of the tower on the
flow local to the blade based on the downstream tower shadow model. If
the tower influence from potential flow and tower shadow are both
enabled, the two influences will be superimposed.
Set the TwrAero
flag to TRUE to calculate fluid drag loads on the
tower or FALSE to disable these effects.
During linearization analyses
with AeroDyn coupled OpenFAST and BEM enabled (WakeMod = 1
), set the
FrozenWake
flag to TRUE to employ frozenwake assumptions during
linearization (i.e. to fix the axial and tangential induces velocities,
and, at their operatingpoint values during linearization) or FALSE to
recalculate the induction during linearization using BEM theory.
Set the CavitCheck
flag to TRUE to perform a cavitation check for MHK
turbines or FALSE to disable this calculation. If CavitCheck
is
TRUE, AFAeroMod
must be set to 1 because the cavitation check does
not function with unsteady airfoil aerodynamics.
Set the CompAA
flag to TRUE to run aeroacoustic calculations. This
option is only available for WakeMod = 1
or 2
. See section
Section 4.2.3 for information on how to use this feature.
The AA_InputFile
is used to specify the input file for the aeroacoustics
submodule. See Section 4.2.3 for information on how to use this
feature.
Environmental conditions are now specified in driver input files but are left in
the AeroDyn primary input file for legacy compatibility. Use the keyword
DEFAULT
to pass in values specified by the driver input file. Otherwise,
values given in the AeroDyn primary input file will overwrite those given in the
driver input file. AirDens
specifies the fluid density and must be a value
greater than zero; a typical value is around 1.225 kg/m^{3} for air (wind
turbines) and 1025 kg/m^{3} for seawater (MHK turbines).
KinVisc
specifies the kinematic viscosity of the fluid (used in the
Reynolds number calculation); a typical value is around 1.460E5
m^{2}/s for air (wind turbines) and 1.004E6 m^{2}/s for
seawater (MHK turbines). SpdSound
is the speed of sound in the fluid
(used to calculate the Mach number within the unsteady airfoil
aerodynamics calculations); a typical value is around 340.3 m/s for air. The
last two parameters in this section are only used when
CavitCheck = TRUE
for MHK turbines. Patm
is the atmospheric
pressure above the free surface; typically around 101,325 Pa. Pvap
is the vapor pressure of the fluid; for seawater this is typically
around 2,000 Pa.
The input parameters in this section are not used when WakeMod = 0
.
SkewMod
determines the skewedwake correction model. Set
SkewMod
to 1 to use the uncoupled BEM solution technique without
an additional skewedwake correction. Set SkewMod
to 2 to include
the Pitt/Peters correction model. The coupled model ``SkewMod=
3`` is not available in this version of AeroDyn.
SkewModFactor
is used only when SkewMod = 2
. Enter a scaling factor to use
in the Pitt/Peters correction model, or enter "default"
to use the default
value of \(\frac{15 \pi}{32}\).
Set TipLoss
to TRUE to include the Prandtl tiploss model or FALSE
to disable it. Likewise, set HubLoss
to TRUE to include the
Prandtl hubloss model or FALSE to disable it.
Set TanInd
to TRUE to include tangential induction (from the
angular momentum balance) in the BEM solution or FALSE to neglect it.
Set AIDrag
to TRUE to include drag in the axialinduction
calculation or FALSE to neglect it. If TanInd = TRUE
, set
TIDrag
to TRUE to include drag in the tangentialinduction
calculation or FALSE to neglect it. Even when drag is not used in the
BEM iteration, drag is still used to calculate the nodal loads once the
induction has been found,
IndToler
sets the convergence threshold for the iterative
nonlinear solve of the BEM solution. The nonlinear solve is in terms of
the inflow angle, but IndToler
represents the tolerance of the
nondimensional residual equation, with no physical association possible.
When the keyword DEFAULT
is used in place of a numerical value,
IndToler
will be set to 5E5 when AeroDyn is compiled in single
precision and to 5E10 when AeroDyn is compiled in double precision; we
recommend using these defaults. MaxIter
determines the maximum
number of iterations steps in the BEM solve. If the residual value of
the BEM solve is not less than or equal to IndToler
in
MaxIter
, AeroDyn will exit the BEM solver and return an error
message.
The input parameters in this section are used only when WakeMod = 2
.
Set DBEMT_Mod
to 1 for the constanttau1 model, set DBEMT_Mod
to 2
to use a model where tau1 varies with time, or set DBEMT_Mod
to 3
to use a continuousstate model with constant tau1.
If DBEMT_Mod=1
(constanttau1 model) or DBEMT_Mod=3
(continuousstate constanttau1 model),
set tau1_const
to the time constant to use for DBEMT.
The input parameters in this section are used only when WakeMod = 3
.
The settings for the free vortex wake model are set in the OLAF input file
described in Section 4.2.2.4. OLAFInputFileName
is the filename
for this input file.
The input parameters in this section are used only when AFAeroMod
= 2
.
UAMod
determines the UA model. It has the following options:
1
: the original theoretical developments of BL (not currently functional),2
: the extensions to BL developed by González3
: the extensions to BL developed by Minnema/Pierce4
: a continuousstate model developed by Hansen, Gaunna, and Madsen (HGM)5
: a model similar to HGM with an additional state for vortex generation6
: Oye’s dynamic stall model7
: BoeingVertol model
The models are described in Section 4.2.1.7.
While all of the UA models are documented in this manual, the original BL model is not yet functional. Testing has shown that the González and Minnema/Pierce models produce reasonable hysteresis of the normal force, tangential force, and pitchingmoment coefficients if the UA model parameters are set appropriately for a given airfoil, Reynolds number, and/or Mach number. However, the results will differ a bit from earlier versions of AeroDyn, (which was based on the Minnema/Pierce extensions to BL) even if the default UA model parameters are used, due to differences in the UA model logic between the versions. We recommend that users run test cases with uniform inflow and fixed yaw error (e.g., through the standalone AeroDyn driver) to examine the accuracy of the normal force, tangential force, and pitchingmoment coefficient hysteresis and to adjust the UA model parameters appropriately.
FLookup
determines how the nondimensional separation distance
value, f’, will be calculated. When FLookup
is set to TRUE, f’
is determined via a lookup into the static liftforce coefficient and
dragforce coefficient data. Using bestfit exponential equations
(``FLookup = FALSE``) is not yet available, so ``FLookup`` must be
``TRUE`` in this version of AeroDyn. Note, FLookup
is not used
when UAMod=4
or UAMod=5
.
UAStartRad
is the starting rotor radius where dynamic stall
will be turned on. Enter a number between 0 and 1, representing a fraction of rotor radius,
to indicate where unsteady aerodynamics should begin turning on. If this line is
omitted from the input file, UAStartRad
will default to 0 (turning on at the blade root).
All blade nodes that are located at a rotor radius less than UAStartRad
will have
unsteady aerodynamics turned off for the entire simulation.
UAEndRad
is the ending rotor radius where dynamic stall
will be turned on. Enter a number between 0 and 1, representing a fraction of rotor radius,
to indicate the last rotor radius where unsteady aerodynamics should be turned on. If this line is
omitted from the input file, UAEndRad
will default to 1 (the blade tip).
All blade nodes that are located at a rotor radius greater than UAEndRad
will have
unsteady aerodynamics turned off for the entire simulation.
This section defines the airfoil data input file information. The airfoil data input files themselves (one for each airfoil) include tables containing coefficients of lift force, drag force, and optionally pitching moment, and minimum pressure versus AoA, as well as UA model parameters, and are described in Section 4.2.1.2.3.
The first 5 lines in the AIRFOIL INFORMATION section relate to the
format of the tables of static airfoil coefficients within each of the
airfoil input files. InCol_Alfa
, InCol_Cl
,
InCol_Cd
, InCol_Cm,
and InCol_Cpmin
are column
numbers in the tables containing the AoA, liftforce coefficient,
dragforce coefficient, pitchingmoment coefficient, and minimum
pressure coefficient, respectively (normally these are 1, 2, 3, 4, and
5, respectively). If pitchingmoment terms are neglected with
UseBlCm = FALSE
, InCol_Cm
may be set to zero, and if the
cavitation check is disabled with CavitCheck = FALSE
,
InCol_Cpmin
may be set to zero.
Specify the number of airfoil data input files to be used using
NumAFfiles
, followed by NumAFfiles
lines of filenames. The
file names should be in quotations and can contain an absolute path or a
relative path e.g., “C:\airfoils\S809_CLN_298.dat” or
“airfoils\S809_CLN_298.dat”. If you use relative paths, it is
relative to the location of the file in which it is specified. The blade
data input files will reference these airfoil data using their line
identifier, where the first airfoil file is numbered 1 and the last
airfoil file is numbered NumAFfiles
.
Set UseBlCm
to TRUE to include pitchingmoment terms in the blade
airfoil aerodynamics or FALSE to neglect them; if UseBlCm = TRUE
,
pitchingmoment coefficient data must be included in the airfoil data
tables with InCol_Cm
not equal to zero.
The blade nodal discretization, geometry, twist, chord, and airfoil
identifier are set in separate input files for each blade, described in
Section 4.2.1.2.4. ADBlFile(1)
is the filename for blade 1,
ADBlFile(2)
is the filename for blade 2, and ADBlFile(3)
is
the filename for blade 3, respectively; the latter is not used for
twobladed rotors and the latter two are not used for onebladed rotors.
The file names should be in quotations and can contain an absolute path
or a relative path. The data in each file need not be identical, which
permits modeling of aerodynamic imbalances.
The input parameters in this section pertain to the tower influence
and/or tower drag calculations and are only used when TwrPotent
>
0, TwrShadow
> 0, or TwrAero = TRUE
.
NumTwrNds
is the userspecified number of tower analysis nodes and
determines the number of rows in the subsequent table (after two table
header lines). NumTwrNds
must be greater than or equal to two; the
higher the number, the finer the resolution and longer the computational
time; we recommend that NumTwrNds
be between 10 and 20 to balance
accuracy with computational expense. For each node, TwrElev
specifies the local elevation of the tower node above ground (or above
MSL for offshore wind turbines or above the seabed for MHK turbines),
TwrDiam
specifies the local tower diameter, TwrCd
specifies the
local tower dragforce coefficient, and TwrTI
specifies the
turbulence intensity used in the Eames tower shadow model
(TwrShadow
= 2) as a fraction (rather than a percentage) of the
wind fluctuation. TwrElev
must be entered in monotonically
increasing order—from the lowest (towerbase) to the highest
(towertop) elevation. Values of TwrTI
between 0.05 and 0.4 are
recommended. Values larger than 0.4 up to 1 will trigger a warning
that the results will need to be interpreted carefully, but the code
will allow such values for scientific investigation purposes.
See Fig. 4.1.
Specifying SumPrint
to TRUE causes AeroDyn to generate a summary
file with name <OutFileRoot>.AD.sum
. <OutFileRoot>
is either
specified in the I/O SETTINGS section of the driver input file when
running AeroDyn standalone, or by the OpenFAST program when running a
coupled simulation. See Section 4.2.1.3.2 for summary file details.
If AFAeroMod=2
, the unsteady aero module will also generate a file
called <OutFileRoot>.UA.sum
that will list all of the UA parameters
used in the airfoil tables. This allows the user to check what values
are being used in case the code has computed the parameters
without user input.
AeroDyn can output aerodynamic and kinematic quantities at up to nine nodes specified along the tower and up to nine nodes along each blade. For outputs at every blade node, see Section 4.2.1.2.2.11.
NBlOuts
specifies the number of blade nodes that output is
requested for (0 to 9) and BlOutNd
on the next line is a list
NBlOuts
long of node numbers between 1 and NumBlNds
(corresponding to a row number in the blade analysis node table in the
blade data input files), separated by any combination of commas,
semicolons, spaces, and/or tabs. All blades have the same output node
numbers. NTwOuts
specifies the number of tower nodes that output
is requested for (0 to 9) and TwOutNd
on the next line is a list
NTwOuts
long of node numbers between 1 and NumTwrNds
(corresponding to a row number in the tower analysis node table above),
separated by any combination of commas, semicolons, spaces, and/or tabs.
The outputs specified in the OutList
section determine which
quantities are actually output at these nodes.
The OutList
section controls output quantities generated by
AeroDyn. Enter one or more lines containing quoted strings that in turn
contain one or more output parameter names. Separate output parameter
names by any combination of commas, semicolons, spaces, and/or tabs. If
you prefix a parameter name with a minus sign, “”, underscore, “_”, or
the characters “m” or “M”, AeroDyn will multiply the value for that
channel by –1 before writing the data. The parameters are written in the
order they are listed in the input file. AeroDyn allows you to use
multiple lines so that you can break your list into meaningful groups
and so the lines can be shorter. You may enter comments after the
closing quote on any of the lines. Entering a line with the string “END”
at the beginning of the line or at the beginning of a quoted string
found at the beginning of the line will cause AeroDyn to quit scanning
for more lines of channel names. Blade and tower noderelated quantities
are generated for the requested nodes identified through the
BlOutNd
and TwOutNd
lists above. If AeroDyn encounters an
unknown/invalid channel name, it warns the users but will remove the
suspect channel from the output file. Please refer to Appendix E for a
complete list of possible output parameters.
In addition to the named outputs in Section 4.2.1.2.2.10 above, AeroDyn allows
for outputting the full set blade node motions and loads (tower nodes
unavailable at present). Please refer to the AeroDyn_Nodes tab in the
Excel file OutListParameters.xlsx
for a complete list of possible output parameters.
This section follows the END statement from normal Outputs section described above, and includes a separator description line followed by the following optinos.
BldNd_BladesOut specifies the number of blades to output. Possible values are 0 through the number of blades AeroDyn is modeling. If the value is set to 1, only blade 1 will be output, and if the value is 2, blades 1 and 2 will be output.
BldNd_BlOutNd specifies which nodes to output. This is currently unused.
The OutList section controls the nodal output quantities generated by AeroDyn. In this section, the user specifies the name of the channel family to output. The output name for each channel is then created internally by AeroDyn by combining the blade number, node number, and channel family name. For example, if the user specifies AxInd as the channel family name, the output channels will be named with the convention of B\(\mathbf{\beta}\)N###AxInd where \(\mathbf{\beta}\) is the blade number, and ### is the three digit node number.
This sample includes the END
statement from the regular outputs section.
1END of input file (the word "END" must appear in the first 3 columns of this last OutList line)
2 NODE OUTPUTS 
3 3 BldNd_BladesOut  Blades to output
4 99 BldNd_BlOutNd  Blade nodes on each blade (currently unused)
5 OutList  The next line(s) contains a list of output parameters. See OutListParameters.xlsx, AeroDyn_Nodes tab for a listing of available output channels, ()
6"VUndx"  xcomponent of undisturbed wind velocity at each node
7"VUndy"  ycomponent of undisturbed wind velocity at each node
8"VUndz"  zcomponent of undisturbed wind velocity at each node
9"VDisx"  xcomponent of disturbed wind velocity at each node
10"VDisy"  ycomponent of disturbed wind velocity at each node
11"VDisz"  zcomponent of disturbed wind velocity at each node
12"STVx"  xcomponent of structural translational velocity at each node
13"STVy"  ycomponent of structural translational velocity at each node
14"STVz"  zcomponent of structural translational velocity at each node
15"VRel"  Relvative wind speed at each node
16"DynP"  Dynamic pressure at each node
17"Re"  Reynolds number (in millions) at each node
18"M"  Mach number at each node
19"Vindx"  Axial induced wind velocity at each node
20"Vindy"  Tangential induced wind velocity at each node
21"AxInd"  Axial induction factor at each node
22"TnInd"  Tangential induction factor at each node
23"Alpha"  Angle of attack at each node
24"Theta"  Pitch+Twist angle at each node
25"Phi"  Inflow angle at each node
26"Curve"  Curvature angle at each node
27"Cl"  Lift force coefficient at each node
28"Cd"  Drag force coefficient at each node
29"Cm"  Pitching moment coefficient at each node
30"Cx"  Normal force (to plane) coefficient at each node
31"Cy"  Tangential force (to plane) coefficient at each node
32"Cn"  Normal force (to chord) coefficient at each node
33"Ct"  Tangential force (to chord) coefficient at each node
34"Fl"  Lift force per unit length at each node
35"Fd"  Drag force per unit length at each node
36"Mm"  Pitching moment per unit length at each node
37"Fx"  Normal force (to plane) per unit length at each node
38"Fy"  Tangential force (to plane) per unit length at each node
39"Fn"  Normal force (to chord) per unit length at each node
40"Ft"  Tangential force (to chord) per unit length at each node
41"Clrnc"  Tower clearance at each node (based on the absolute distance to the nearest point in the tower from blade node B#N# minus the local tower radius, in the deflected configuration); please note that this clearance is only approximate because the calculation assumes that the blade is a line with no volume (however, the calculation does use the local tower radius); when blade node B#N# is above the tower top (or below the tower base), the absolute distance to the tower top (or base) minus the local tower radius, in the deflected configuration, is output
42"Vx"  Local axial velocity
43"Vy"  Local tangential velocity
44"GeomPhi"  Geometric phi? If phi was solved using normal BEMT equations, GeomPhi = 1; otherwise, if it was solved geometrically, GeomPhi = 0.
45"Chi"  Skew angle (used in skewed wake correction)  not available for OLAF
46"UA_Flag"  Flag indicating if UA is turned on for this node.  not available for OLAF
47"CpMin"  Pressure coefficient
48"SgCav"  Cavitation number
49"SigCr"  Critical cavitation number
50"Gam"  Gamma  circulation on blade
51"Cl_Static"  Static portion of lift force coefficient at each node, without unsteady effects  not available for BEMT/DBEMT
52"Cd_Static"  Static portion of drag force coefficient at each node, without unsteady effects  not available for BEMT/DBEMT
53"Cm_Static"  Static portion of pitching moment coefficient at each node, without unsteady effects  not available for BEMT/DBEMT
54"Uin"  Axial induced velocity in rotating hub coordinates. Axial aligned with hub axis. rotor plane polar hub rotating coordinates
55"Uit"  Tangential induced velocity in rotating hub coordinates. Tangential to the rotation plane. Perpendicular to blade aziumth. rotor plane polar hub rotating coordinates
56"Uir"  Radial induced velocity in rotating hub coordinates. Radial outwards in rotation plane. Aligned with blade azimuth. rotor plane polar hub rotating coordinates
57END of input file (the word "END" must appear in the first 3 columns of this last OutList line)
58
Airfoil Data Input File¶
The airfoil data input files themselves (one for each airfoil) include tables containing coefficients of lift force, drag force, and pitching moment versus AoA, as well as UA model parameters. In these files, any line whose first nonblank character is an exclamation point (!) is ignored (for inserting comment lines). The noncomment lines should appear within the file in order, but comment lines may be intermixed as desired for reading clarity. A sample airfoil data input file is given in Section 4.2.1.9.
InterpOrd
is the order the static airfoil data is interpolated
when AeroDyn uses table lookup to find the lift, drag, and optional
pitchingmoment, and minimum pressure coefficients as a function of AoA.
When InterpOrd
is 1, linear interpolation is used; when
InterpOrd
is 3, the data will be interpolated with cubic splines;
if the keyword DEFAULT
is entered in place of a numerical value,
InterpOrd
is set to 1.
RelThickness
is the nondimensional thickness of the airfoil
(thickness over chord ratio), expressed as a fraction (not a percentage),
typically between 0.1 and 1.
The parameter is currently used when UAMod=7
, but might be used more in the future.
The default value of 0.2 if provided for convenience.
NonDimArea
is the nondimensional airfoil area (normalized by the
local BlChord
squared), but is currently unused by AeroDyn.
NumCoords
is the number of points to define the exterior shape of
the airfoil, plus one point to define the aerodynamic center, and
determines the number of rows in the subsequent table; NumCoords
must be exactly zero or greater than or equal to three. For each point,
the nondimensional X and Y coordinates are specified in the table,
X_Coord
and Y_Coord
(normalized by the local
BlChord
). The first point must always locate the aerodynamic
center (reference point for the airfoil lift and drag forces, likely not
on the surface of the airfoil); the remaining points should define the
exterior shape of the airfoil. The airfoil shape is currently unused by
AeroDyn, but when AeroDyn is coupled to OpenFAST, the airfoil shape will be
used by OpenFAST for blade surface visualization when enabled.
BL_file
is the name of the file containing boundarylayer characteristics
of the profile. It is ignored if the aeroacoustic module is not used.
This parameter may also be omitted from the file if the aeroacoustic module is not used.
Specify the number of Reynolds number or aerodynamiccontrol
settingdependent tables of data for the given airfoil via the
NumTabs
setting. The remaining parameters in the
airfoil data input files are entered separately for each table.
Re
and UserProp
are the Reynolds number (in millions) and
aerodynamiccontrol (or user property) setting for the included table.
These values are used only when the AFTabMod
parameter in the
primary AeroDyn input file is set to use 2D interpolation based on
Re
or UserProp
. If 1D interpolation (based only on angle of attack)
is used, only the first table in the file will be used.
Set InclUAdata
to TRUE if you are including the UA model
parameters. If this is set to FALSE, all of the UA model parameters
will be determined by the code. Any lines that are missing from this section
will have their values determined by the code, either using a default value
or calculating it based on the polar coefficient data in the airfoil table:
alpha0
specifies the zerolift AoA (in degrees);alpha1
specifies the AoA (in degrees) larger thanalpha0
for which f equals 0.7; approximately the positive stall angle; This parameter is used whenflookup=false
and when determining a default value ofCn1
.alpha2
specifies the AoA (in degrees) less thanalpha0
for which f equals 0.7; approximately the negative stall angle; This parameter is used whenflookup=false
and when determining a default value ofCn2
.alphaUpper
specifies the AoA (in degrees) of the upper boundary of fullyattached region of the cn or cl curve. It is used to compute the separation function whenUAMod=5
.alphaLower
specifies the AoA (in degrees) of the lower boundary of fullyattached region of the cn or cl curve. It is used to compute the separation function whenUAMod=5
. (The separation function will have a value of 1 betweenalphaUpper
andalphaLower
.)eta_e
is the recovery factor and typically has a value in the range [0.85 to 0.95] forUAMod = 1
; if the keywordDEFAULT
is entered in place of a numerical value,eta_e
is set to 0.9 forUAMod = 1
, buteta_e
is set to 1.0 for otherUAMod
values and wheneverFLookup = TRUE
;C_nalpha
is the slope of the 2D normal force coefficient curve in the linear region;T_f0
is the initial value of the time constant associated with Df in the expressions of Df and f’; if the keywordDEFAULT
is entered in place of a numerical value,T_f0
is set to 3.0;T_V0
is the initial value of the time constant associated with the vortex lift decay process, used in the expression ofCvn
; it depends on Reynolds number, Mach number, and airfoil; if the keywordDEFAULT
is entered in place of a numerical value,T_V0
is set to 6.0;T_p
is the boundarylayer leading edge pressure gradient time constant in the expression for Dp and should be tuned based on airfoil experimental data; if the keywordDEFAULT
is entered in place of a numerical value,T_p
is set to 1.7;T_VL
is the time constant associated with the vortex advection process, representing the nondimensional time in semichords needed for a vortex to travel from the leading to trailing edges, and used in the expression of Cvn; it depends on Reynolds number, Mach number (weakly), and airfoil; valued values are in the range [6 to 13]; if the keywordDEFAULT
is entered in place of a numerical value,T_VL
is set to 11.0;b1
is a constant in the expression of \(\phi_\alpha^c\) and \(\phi_q^c\); this value is relatively insensitive for thin airfoils, but may be different for turbine airfoils; if the keywordDEFAULT
is entered in place of a numerical value,b1
is set to 0.14, based on experimental results;b2
is a constant in the expression of \(\phi_\alpha^c\) and \(\phi_q^c\); this value is relatively insensitive for thin airfoils, but may be different for turbine airfoils; if the keywordDEFAULT
is entered in place of a numerical value,b2
is set to 0.53, based on experimental results;b5
is a constant in the expression of \(K^{'''}_q\), \(Cm_q^{nc}\), and \(K_{m_q}\); if the keywordDEFAULT
is entered in place of a numerical value,b5
is set to 5, based on experimental results;A1
is a constant in the expression \(\phi_\alpha^c\) and \(\phi_q^c\); this value is relatively insensitive for thin airfoils, but may be different for turbine airfoils; if the keywordDEFAULT
is entered in place of a numerical value,A1
is set to 0.3, based on experimental results;A2
is a constant in the expression \(\phi_\alpha^c\) and \(\phi_q^c\); this value is relatively insensitive for thin airfoils, but may be different for turbine airfoils; if the keywordDEFAULT
is entered in place of a numerical value,A2
is set to 0.7, based on experimental results;A5
is a constant in the expression \(K^{'''}_q\), \(Cm_q^{nc}\), and \(K_{m_q}\); if the keywordDEFAULT
is entered in place of a numerical value,A5
is set to 1, based on experimental results;S1
is the constant in the best fit curve of f foralpha0
\(\le\) AoA \(\le\)alpha1
forUAMod = 1
(and is unused otherwise); by definition, it depends on the airfoil;S2
is the constant in the best fit curve of f for AoA >alpha1
forUAMod = 1
(and is unused otherwise); by definition, it depends on the airfoil;S3
is the constant in the best fit curve of f foralpha2
\(\le\) AoA \(\le\)alpha0
forUAMod = 1
(and is unused otherwise); by definition, it depends on the airfoil;S4
is the constant in the best fit curve of f for AoA <alpha2
forUAMod = 1
(and is unused otherwise); by definition, it depends on the airfoil;Cn1
is the critical value of \(C^{\prime}_n\) at leadingedge separation for positive AoA and should be extracted from airfoil data at a given Reynolds number and Mach number;Cn1
can be calculated from the static value of Cn at either the break in the pitching moment or the loss of chord force at the onset of stall;Cn1
is close to the condition of maximum lift of the airfoil at low Mach numbers;Cn2
is the critical value of \(C^{\prime}_n\) at leadingedge separation for negative AoA and should be extracted from airfoil data at a given Reynolds number and Mach number;Cn2
can be calculated from the static value of Cn at either the break in the pitching moment or the loss of chord force at the onset of stall;Cn2
is close to the condition of maximum lift of the airfoil at low Mach numbers;St_sh
is the Strouhal’s shedding frequency; if the keywordDEFAULT
is entered in place of a numerical value,St_sh
is set to 0.19;Cd0
is the dragforce coefficient at zerolift AoA;Cm0
is the pitchingmoment coefficient about the quarterchord location at zerolift AoA, positive for nose up;k0
is a constant in the best fit curve of \(\hat{x}_{cp}\) and equals for \(\hat{x}_{AC}0.25\)UAMod = 1
(and is unused otherwise);k1
is a constant in the best fit curve of \(\hat{x}_{cp}\) forUAMod = 1
(and is unused otherwise);k2
is a constant in the best fit curve of \(\hat{x}_{cp}\) forUAMod = 1
(and is unused otherwise);k3
is a constant in the best fit curve of \(\hat{x}_{cp}\) forUAMod = 1
(and is unused otherwise);k1_hat
is a constant in the expression of Cc due to leadingedge vortex effects forUAMod = 1
(and is unused otherwise);x_cp_bar
is a constant in the expression of \(\hat{x}_{cp}^{\nu}\) forUAMod = 1
(and is unused otherwise); if the keywordDEFAULT
is entered in place of a numerical value,x_cp_bar
is set to 0.2; andUACutOut
is the AoA (in degrees) in absolute value above which UA are disabled; if the keywordDEFAULT
is entered in place of a numerical value,UACutOut
is set to 45.UACutOut_delta
is the AoA difference (in degrees) which, together withUACutOut
determines when unsteady aero begins to turn off; if the keywordDEFAULT
is entered in place of a numerical value,UACutOut_delta
is set to 5 degrees. The unsteady solution is used at angles of attack less thanUACutOut  UACutout_delta
degrees. AboveUACutout
, the steady solution is used (i.e., UA is disabled). The steady and unsteady solutions are blended between those two angles.filtCutOff
is the cutoff reduced frequency of the lowpass filter applied to the AoA input to UA, as well as to the pitch rate and pitch acceleration derived from AoA within UA; if the keywordDEFAULT
is entered in place of a numerical value,filtCutOff
is set to 0.5. This nondimensional value corresponds to a frequency of \(\frac{U \times \mathrm{filtCutOff}}{\pi \times \mathrm{chord}}\) Hz.
NumAlf
is the number of distinct AoA entries and determines the
number of rows in the subsequent table of static airfoil coefficients;
NumAlf
must be greater than or equal to one (NumAlf = 1
implies constant coefficients, regardless of the AoA).
AeroDyn will
interpolate on AoA using the data provided via linear interpolation or via cubic
splines, depending on the setting of input InterpOrd
above.
If AFTabMod
is set to 1
, only the first airfoil table in each file
will be used. If AFTabMod
is set to 2
, AeroDyn will find the
airfoil tables that bound the computed Reynolds number,
and linearly interpolate between the tables, using the logarithm of the Reynolds numbers.
If AFTabMod
is set to 3
, it will find the bounding airfoil
tables based on the UserProp
field and linearly interpolate the tables
based on it. Note that OpenFAST currently sets the UserProp
input value to 0
unless the DLL controller is used and sets the value,
so using this feature may require a code change.
For each AoA, you must set the AoA (in degrees), alpha
, the liftforce
coefficient, Coefs
(:,1), the dragforce coefficient,
Coefs(:,2)
, and optionally the pitchingmoment coefficient,
Coefs(:,3)
, and minimum pressure coefficient,
Coefs(:,4)
, but the column order depends on the settings of
InCol_Alfa
, InCol_Cl
, InCol_Cd
, InCol_Cm
,
and InCol_Cpmin
in the AIRFOIL INFORMATION section of the AeroDyn
primary input file. AoA must be entered in monotonically increasing
order—from lowest to highest AoA; the first row should be for AoA =
–180 degrees and the last should be for AoA = +180 (unless NumAlf = 1
, in
which case AoA is unused). If pitchingmoment terms are neglected with
UseBlCm = FALSE
in the ROTOR/BLADE PROPERTIES section of the
AeroDyn primary input file, the column containing pitchingmoment
coefficients may be absent from the file. Likewise, if the cavitation
check is neglected with CavitCheck = FALSE
in the GENERAL OPTIONS
section of the AeroDyn primary input file, the column containing the
minimum pressure coefficients may be absent from the file.
Blade Data Input File¶
The blade data input file contains the nodal discretization, geometry, twist, chord, and airfoil identifier for a blade. Separate files are used for each blade, which permits modeling of aerodynamic imbalances. A sample blade data input file is given in Section 4.2.1.9.
The input file begins with two lines of header information which is for your use, but is not used by the software.
NumBlNds
is the userspecified number of blade analysis nodes and
determines the number of rows in the subsequent table (after two table
header lines). NumBlNds
must be greater than or equal to two; the
higher the number, the finer the resolution and longer the computational
time; we recommend that NumBlNds
be between 10 and 20 to balance
accuracy with computational expense. Even though NumBlNds
is
defined in each blade file, all blades must have the same number of
nodes. For each node:
BlSpn
specifies the local span of the blade node along the (possibly preconed) bladepitch axis from the root;BlSpn
must be entered in monotonically increasing order—from the most inboard to the most outboard—and the first node must be zero, and when AeroDyn is coupled to OpenFAST, the last node should be located at the blade tip;BlCrvAC
specifies the local outofplane offset (when the bladepitch angle is zero) of the aerodynamic center (reference point for the airfoil lift and drag forces), normal to the bladepitch axis, as a result of blade curvature;BlCrvAC
is positive downwind; upwind turbines have negativeBlCrvAC
for improved tower clearance;BlSwpAC
specifies the local inplane offset (when the bladepitch angle is zero) of the aerodynamic center (reference point for the airfoil lift and drag forces), normal to the bladepitch axis, as a result of blade sweep; positiveBlSwpAC
is opposite the direction of rotation;BlCrvAng
specifies the local angle (in degrees) from the bladepitch axis of a vector normal to the plane of the airfoil, as a result of blade outofplane curvature (when the bladepitch angle is zero);BlCrvAng
is positive downwind; upwind turbines have negativeBlCrvAng
for improved tower clearance;BlTwist
specifies the local aerodynamic twist angle (in degrees) of the airfoil; it is the orientation of the local chord about the vector normal to the plane of the airfoil, positive to feather, leading edge upwind; the bladepitch angle will be added to the local twist;BlChord
specifies the local chord length; andBlAFID
specifies which airfoil data the local blade node is associated with; valid values are numbers between 1 andNumAFfiles
(corresponding to a row number in the airfoil file table in the AeroDyn primary input file); multiple blade nodes can use the same airfoil data.
See Fig. 4.2. Twist is shown in Fig. 4.6 of Section 4.2.1.9.
Output Files¶
AeroDyn produces three types of output files: an echo file, a summary file, and a timeseries results file. The following sections detail the purpose and contents of these files.
Echo Files¶
If you set the Echo
flag to TRUE
in the AeroDyn driver file or the
AeroDyn primary input file, the contents of those files will be echoed
to a file with the naming conventions, OutFileRoot.ech for the
driver input file and OutFileRoot.AD.ech for the AeroDyn primary
input file. OutFileRoot
is either specified in the I/O SETTINGS
section of the driver input file when running AeroDyn standalone, or by
the FAST program when running a coupled simulation. The echo files are
helpful for debugging your input files. The contents of an echo file
will be truncated if AeroDyn encounters an error while parsing an input
file. The error usually corresponds to the line after the last
successfully echoed line.
Summary File¶
AeroDyn generates a summary file with the naming convention,
OutFileRoot.AD.sum if the SumPrint
parameter is set to TRUE
.
OutFileRoot
is either specified in the I/O SETTINGS section of the
driver input file when running AeroDyn standalone, or by the FAST
program when running a coupled simulation. This file summarizes key
information about your aerodynamics model, including which features have
been enabled and what outputs have been selected.
Results Files¶
In standalone mode, the AeroDyn timeseries results (a separate file for
each case) are written to textbased files with the naming convention
OutFileRoot.#.out, where OutFileRoot
is specified in the I/O
SETTINGS section of the driver input file and the ‘#’ character is
an integer number corresponding to a test case line found in the
COMBINEDCASE ANALYSIS section. If AeroDyn is coupled to FAST, then FAST
will generate a master results file that includes the AeroDyn results
and AeroDyn will not write out its own results. The results are in table
format, where each column is a data channel (the first column always
being the simulation time), and each row corresponds to a simulation
output time step. The data channels are specified in the OUTPUTS section
of the AeroDyn primary input file. The column format of the
AeroDyngenerated files is specified using the OutFmt
parameter of
the driver input file.
Modeling Considerations¶
AeroDyn was designed as an extremely flexible tool for modeling a widerange of aerodynamic conditions and turbine configurations. This section provides some general guidance to help you construct models that are compatible with AeroDyn.
Please refer to the theory of Section 7 for detailed information about the implementation approach we have followed in AeroDyn.
Environmental Conditions¶
For air, typical values for AirDens
, KinVisc
,
SpdSound
, and Patm
are around 1.225 kg/m^{3}, 1.460E5
m^{2}/s, 340.3 m/s, and 101,325 Pa, respectively. For seawater,
typical values for AirDens
, KinVisc
, and Pvap
are
around 1025 kg/m^{3}, 1.004E6 m^{2}/s, and 2000 Pa,
respectively.
Temporal and Spatial Discretization¶
For accuracy and numerical stability, we recommend that DTAero
be
set such that there are at least 200 azimuth steps per rotor revolution.
However, when AeroDyn is coupled to FAST, FAST may require time steps
much smaller than this rule of thumb. If UA is enabled while using very
small time steps, you may need to recompile AeroDyn in double precision
to avoid numerical problems in the UA routines.
For the blade and tower spatial discretization, using higher number of analysis nodes will result in a more accurate solution at the expense of longer computational time. When AeroDyn is coupled to FAST, the blade and tower analysis node discretization may be independent from the discretization of the nodes in the structural modules.
We recommend that NumBlNds
be between 10 and 20 to balance
accuracy with computational expense for the rotor aerodynamic load
calculation. It may be beneficial to use a finer resolution of nodes
where large gradients are expected in the aerodynamic loads e.g. near
the blade tip. Aerodynamic imbalances are possible through the use of
geometrical differences between each blade.
When the tower potentialflow (TwrPotent > 0
), tower shadow
(TwrShadow > 0
), and/or the tower aerodynamic load
(TwrAero = TRUE
) models are enabled, we also recommend that
NumTwrNds
be between 10 and 20 to balance accuracy with
computational expense. Normally the local elevation of the tower node
above ground (or above MSL for offshore wind turbines or above the
seabed for MHK turbines) (TwrElev
), must be entered in
monotonically increasing order from the lowest (towerbase) to the
highest (towertop) elevation. However, when AeroDyn is coupled to FAST,
the towerbase node in AeroDyn cannot be set lower than the lowest point
where wind is specified in the InflowWind module. To avoid truncating
the lower section of the tower in AeroDyn, we recommend that the wind be
specified in InflowWind as low to the ground (or MSL for offshore wind
turbines or above the seabed for MHK turbines) as possible (this is a
particular issue for fullfield wind file formats).
Model Options Under Operational and Parked/Idling Conditions¶
To model an operational rotor, we recommend to include the dynamic BEM model
(WakeMod = 2
) and UA (AFAeroMod = 2
). Normally, the Pitt and
Peters skewedwake (SkewMod = 2
), Prandtl tiploss (TipLoss
= TRUE
), Prandtl hubloss (HubLoss = TRUE
), and tangential
induction (TanInd = TRUE
) models should all be enabled, but
SkewMod = 2
is invalid for very large yaw errors (much greater
than 45 degrees). The nonlinear solve in the BEM solution is in terms of the
inflow angle, but IndToler
represents the tolerance of the
nondimensional residual equation, with no physical association possible;
we recommend setting IndToler
to DEFAULT
.
While all of the UA models are documented in this manual, the original BL model is not yet functional. Testing has shown that the González and Minnema/Pierce models produce reasonable hysteresis of the normal force, tangential force, and pitchingmoment coefficients if the UA model parameters are set appropriately for a given airfoil, Reynolds number, and/or Mach number. However, the results will differ a bit from earlier versions of AeroDyn, (which was based on the Minnema/Pierce extensions to BL) even if the default UA model parameters are used, due to differences in the UA model logic between the versions. We recommend that users run test cases with uniform inflow and fixed yaw error (e.g., through the standalone AeroDyn driver) to examine the accuracy of the normal force, tangential force, and pitchingmoment coefficient hysteresis and to adjust the UA model parameters appropriately.
To model a parked or idling rotor, we recommend to disable induction
(WakeMod = 0
) and UA (AFAeroMod = 1
), in which case the
inflow velocity and angle are determined purely geometrically and the
airfoil data is determined statically.
The direct aerodynamic load on the tower often dominates the aerodynamic
load on the rotor for parked or idling conditions above the cutout wind
speed, in which case we recommend that TwrAero = TRUE
. Otherwise,
TwrAero = FALSE
may be satisfactory.
We recommend to include the influence of the tower on the fluid local to
the blade for both operational and parked/idling rotors. We recommend
that TwrPotent > 0
for upwind rotors and that TwrPotent = 2
or TwrShadow > 0
for downwind rotors.
Linearization¶
When coupled to FAST, AeroDyn can be linearized as part of the
linearization of the full coupled solution. When induction is enabled
(WakeMod = 1
), we recommend to base the linearized solution on the
frozenwake assumption, by setting FrozenWake = TRUE
. The UA
models are not set up to support linearization, so, UA must be disabled
during linearization by setting AFAeroMod = 1
.
AeroDyn Driver¶
A standalone AeroDyn driver is provided to perform aerodynamic simulations of rigid turbines undergoing rigid body motion (fixed, sinusoidal, or arbitrary). The standalone AeroDyn driver code improves on the functionality previously available in the separate wind turbine rotorperformance tool WT_Perf. The driver also supports turbine configurations that are not currently supported by OpenFAST.
Examples of applications are:
Simulation of horizontal/vertical axis wind turbine, kites, quadrotors, multiple rotors and wings.
Simulation with prescribed time series of wind speed, pitch, yaw, rotor speed.
Combined case analyses to evaluate the turbine response at different operating conditions, for instance to compute the surfaces of power coefficient (C_{P}), thrust coefficient (C_{T}), and/or torque coefficient (C_{Q}) as a function of tipspeed ratio (TSR) and bladepitch angle.
Simulations with oscillatory motion of the tower base at different amplitudes and frequencies.
More details are provided below.
Compiling the driver¶
The compilation steps for the AeroDyn driver are similar to the ones of OpenFAST (see Section 2). When using the CMake workflow, the driver is compiled automatically when running make. To compile only the driver, use make aerodyn_driver. The driver will be located in the folder /build/modules/aerodyn/. A Visual Studio solution is available for Windows, in the folder /vsbuild/AeroDyn.
Driver inputs and options¶
Main concepts
The driver supports:
two kinds of turbine definitions: basic (HAWT), and advanced.
two kinds of inflow definition: basic (uniform power law), and advanced (InflowWind)
three types of analyses (AnalysisType): 1) one simulation of one or multiple turbines, 2) one simulation of one wind turbine under timedependent inputs, 3) combined cases of one wind turbine
The current limitations are:
The number of nodes per blades have to be the same for all blades and all rotors
A turbine has only one (optional) tower
Analysis Types 2 and 3 are limited to 1 turbine
More details are provided below, where the different sections of the input file are described.
Header and input configuration
The input file starts with a header, the user can place a relevant description of the model on the second line. The input configuration section follows. The user can toggle the flag Echo to write back the input file, as parsed by the driver, to disk. The MHK switch allows the user to specify whether or not the turbine is an MHK turbine. MHK=0 denotes not an MHK turbine, MHK=1 denotes a fixed MHK turbine, and MHK=2 denotes a floating MHK turbine. Currently, only MHK=0 can be specified, although users can still select a cavitation check. The driver supports three kinds of analyses, but not all turbine formats and inflow types are available for each analysis type:
AnalysisType=1: Simulation of one or multiple rotors with basic (HAWT) or arbitrary geometries (HAWT/VAWT, quadrotor, etc.), with basic or advanced wind inputs, and optional timevarying motion of the tower base, nacelle and individual pitch angles. Arbitrary motion or sinusoidal motion of the tower base are possible.
AnalysisType=2: Simulation of one turbine with basic timevarying wind, nacelle motion, pitch. See “Timedependent analysis” below.
AnalysisType=3: Combined cases analyses of one turbine with basic steady wind. A table of cases is run sequentially by the driver. See “CombinedCase analysis” below.
The section follows with the definition of the total simulation time (TMax) and the time step used for the simulation (DT). These inputs are used for AnalysisType=1 and AnalysisType=2. The user specifies the location of the AeroDyn primary file via the variable AeroFile. The path can be absolute or relative to the AeroDyn driver file.
An example of header and input configuration is given below:
 AeroDyn Driver Input File 
Three bladed wind turbine, using basic geometry input
 Input Configuration 
False Echo  Echo input parameters to "<rootname>.ech"?
0 MHK  MHK turbine type (switch) {0: not an MHK turbine, 1: fixed MHK turbine, 2: floating MHK turbine}
3 AnalysisType  {1: multiple turbines, one simulation, 2: one turbine, one timedependent simulation, 3: one turbine, combinedcases}
11.0 TMax  Total run time [used only when AnalysisType/=3] (s)
0.5 DT  Simulation time step [used only when AnalysisType/=3] (s)
"AD.dat" AeroFile  Name of the primary AeroDyn input file
Environmental conditions
Environmental conditions are specified here and passed to AeroDyn. FldDens (equivalent to AirDens in the AeroDyn primary input file) specifies the fluid density and must be a value greater than zero; a typical value is around 1.225 kg/m^{3} for air (wind turbines) and 1025 kg/m^{3} for seawater (MHK turbines). KinVisc specifies the kinematic viscosity of the fluid (used in the Reynolds number calculation); a typical value is around 1.460E5 m^{2}/s for air (wind turbines) and 1.004E6 m^{2}/s for seawater (MHK turbines). SpdSound is the speed of sound in the fluid (used to calculate the Mach number within the unsteady airfoil aerodynamics calculations); a typical value is around 340.3 m/s for air. The next two parameters in this section are only used when CavitCheck = TRUE for MHK turbines. Patm is the atmospheric pressure above the free surface; typically around 101,325 Pa. Pvap is the vapor pressure of the fluid; for seawater this is typically around 2,000 Pa. WtrDpth is the water depth from the seabed to the mean sea level (MSL).
Inflow data
The inflow can be provided in two ways:
basic (CompInflow=0): uniform wind with a power law shear. The wind is defined using a reference height (RefHt), a power law exponent (PLExp), and the wind speed at reference height (HWindSpeed). With AnalysisType=2, the reference wind speed and power law are defined separately as time series (see “timedependent analysis”). With AnalysisType=3, these parameters are provided in a separate table (see “CombinedCase analyses”). The reference height is used for all analyses types, since this height may be different than the hub height. The wind at a given node is determined using the following equation, where \(Z\) is the instantaneous elevation of the node above the ground for landbased wind turbines, above the mean sea level (MSL) for offshore wind turbines, or above the seabed for MHK turbines.
advanced (CompInflow=1): the InflowWind module is used to compute the inflow, and all available options of InflowWind are then available. The user needs to provide the (relative or absolute) path of the InflowWind input file (InflowFile). This feature is limited to AnalysisType=1.
An example of inputs is given below:
 Inflow Data 
0 CompInflow  Compute inflow wind velocities (switch) {0=Steady Wind; 1=InflowWind}
"unused" InflowFile  Name of the InflowWind input file [used only when CompInflow=1]
9.0 HWindSpeed  Horizontal wind speed [used only when CompInflow=0 and AnalysisType=1] (m/s)
140 RefHt  Reference height for horizontal wind speed [used only when CompInflow=0] (m)
0.10 PLExp  Power law exponent [used only when CompInflow=0 and AnalysisType=1] ()
Turbine data
The user specifies the number of turbines as follows:
 Turbine Data 
1 NumTurbines  Number of turbines (should be 1 for AnalysisType=2 or AnalysisType=3)
As noted in the comment, the number of turbines should be 1 for AnalysisType=2 and AnalysisType=3. After this section, the geometry and motion is provided for each turbine. Inputs for each turbine must have the suffix (i) where i is the turbine number (even with NumTurbines=1, then i=1). Outputs for each turbine will be written to distinct files, with the suffix .Ti where i is the turbine number (the suffix is not added when only 1 turbine is used).
An example of configuration with two wind turbines is shown in Fig. 4.3. The figure defines the different frames and origin associated with each turbine: the turbine base frame (t), nacelle frame (n), hub frame (h), and blade frames (b). The notations and conventions follow the OpenFAST frames, except that the turbine frame does not have its origin at the tower base. Prescribed motions of the turbine occur at the turbine origin. Yawing occurs around the \(z_n\) axis, the rotor rotates about the \(x_h\) axis, and blade pitching occurs around the individual \(z_b\) axes. The definitions of the different frames are standardized when using a basic (HAWT) input format definition, and are arbitrarily defined when using the advanced input format. More details are given in the next paragraph.
Turbine geometry definition
Two turbine input formats are supported:
basic (BasicHAWTFormat=True): Basic horizontal axis wind turbine (HAWT) format. In this format, the turbine geometry is entirely determined by the number of blades (NumBlades), the hub radius (HubRad), the hub height (HubHt), the overhang (Overhang), the shaft tilt (ShftTilt), the precone (Precone), and the vertical distance from the towertop to the rotor shaft (Twr2Shft), as shown in Fig. 4.4. The definition of each parameter follows the ElastoDyn convention. For example, HubRad specifies the radius from the centerofrotation to the blade root along the (possibly preconed) bladepitch axis and must be greater than zero. HubHt specifies the elevation of the hub center above the ground for landbased wind turbines, above the mean sea level (MSL) for offshore wind turbines, or above the seabed for MHK turbines. Overhang specifies the distance along the (possibly tilted) rotor shaft between the tower centerline and hub center and is positive downwind (use a negative number for upwind rotors). ShftTilt is the angle (in degrees) between the rotor shaft and the horizontal plane, and positive ShftTilt means that the downwind end of the shaft is the highest (upwind turbines have negative ShftTilt for improved tower clearance). Precone is the angle (in degrees) between a flat rotor disk and the cone swept by the blades, positive downwind (upwind turbines have negative Precone for improved tower clearance).
Additionally, the user needs to provide the origin of the turbine base at t=0 (BaseOriginInit). An example of basic input is given below:
 Turbine(1) Geometry 
True BasicHAWTFormat(1)  Flag to switch between basic or generic input format {True: next 7 lines are basic inputs, False: Base/Twr/Nac/Hub/Bld geometry and motion must follow}
0,0,0 BaseOriginInit(1)  Coordinates of turbine base in global coordinates (m)
3 NumBlades(1)  Number of blades ()
3. HubRad(1)  Hub radius (m)
140.82513 HubHt(1)  Hub height (m)
7 Overhang(1)  Overhang (m)
6 ShftTilt(1)  Shaft tilt (deg)
4 Precone(1)  Blade precone (deg)
3.09343 Twr2Shft(1)  Vertical distance from the towertop to the rotor shaft (m)
advanced (BasicHAWTFormat=False): The position and orientation of the tower base, nacelle, hub, and individual blades can be arbitrarily defined. This can be used for HAWT and any other turbine concepts. The definition of the different frames are given in Fig. 4.3. The position (BaseOriginInit) and orientation (BaseOrientationInit) of the turbine base frame are defined with respect to the global frame. Orientations are given using the values of three successive rotations (xyz Euler angle sequence). If the base undergoes a motion, the orientation of the base frame will consist of the timevarying rotations followed by these initial rotations.
A flag indicating whether the turbine has a tower is given on the next line (HasTower). This flag currently affects the VTK outputs and does not have an impact on AeroDyn yet. The user still has to provide tower input data in AeroDyn for each turbine (see Section 4.2.1.5.3). The next line indicates which projection AeroDyn is to use in its calculation. It is recommended to use HAWTprojection=True for HAWT, which is the default projection used in AeroDyn (projects on the conedpitched axis). For other rotor concepts, set HAWTprojection=False. The following lines indicate the position and orientations of the tower, nacelle and hub.
The tower and the nacelle are defined with respect to the turbine base (t) origin and frame. The tower top is assumed to coincide with the nacelle origin. The tower stations defined in the AeroDyn input file are assumed to be given with respect to the tower origin, unlike OpenFAST which uses ground/MSL as a reference (see Section 4.2.1.5.3). The hub is defined with respect to the nacelle origin and frame (n).
The definitions of the blades follow, starting with the number of blades NumBlades. A rotor with zero blades is supported and can be used to model an isolated tower. If tower shadow/potential is used in AeroDyn, then the isolated tower will disturb the flow of the vortex wake when OLAF is used. When BEM is used, the flow of the blades of a given turbine are disturbed only by that turbine’s tower. The inputs for turbine i and blade j are labelled (i_j). The origin (BldOrigin_h) and orientation (BldOrientation_h) of each blade are given with respect to the hub origin and frame (h). Hub radius inputs (BldHubRad_Bl) are provided for convenience. They will effectively offset the blades origin along the \(z_b\) axis. An example of input for an advanced geometry definition is given below. This example corresponds to typical values for a 3bladed upwind HAWT, with 6 degrees of tilt (6 in OpenFAST) and 4 degrees of precone (blades inclined upstream).
 Turbine(1) Geometry 
False BasicHAWTFormat(1)  Flag to switch between basic or generic input format {True: next 7 lines are basic inputs, False: Base/Twr/Nac/Hub/Bld geometry and motion must follow}
0,0,0 BaseOriginInit(1)  x,y,z coordinates of turbine base origin (m)
0,0,0 BaseOrientationInit(1)  successive rotations (theta_x, theta_y, theta_z) defining initial orientation of the base frame from the global frame (e.g. roll, tilt, yaw) (deg)
True HasTower(1)  True if turbine has a tower (flag)
True HAWTprojection(1)  True if turbine is a horizontal axis turbine (for AeroDyn projections) (flag)
0,0,0 TwrOrigin_t(1)  Coordinate of tower base in base coordinates [used only when HasTower is True] (m)
0,0,137 NacOrigin_t(1)  x,y,z coordinates of nacelle origin (and tower top) from base, in base coordinates (m)
6.96,0.,3.82 HubOrigin_n(1)  x,y,z coordinates of hub origin from nacelle origin, in nacelle coordinates (m)
0,6,0 HubOrientation_n(1)  successive rotations (theta_x, theta_y, theta_z) defining initial orientation of the hub frame from the nacelle frame (e.g. roll, tilt, yaw). The x axis needs to be aligned with the rotational speed. (deg)
 Turbine(1) Blades 
3 NumBlades(1)  Number of blades for current rotor ()
0,0,0 BldOrigin_h(1_1)  Origin of blade 1 wrt. hub origin in hub coordinates (m)
0,0,0 BldOrigin_h(1_2)  Origin of blade 2 wrt. hub origin in hub coordinates (m)
0,0,0 BldOrigin_h(1_3)  Origin of blade 3 wrt. hub origin in hub coordinates (m)
0 ,4,0 BldOrientation_h(1_1)  successive rotations (theta_x, theta_y, theta_z) defining initial orientation of the blade frame from the hub frame such that the "z" is along span, "y" along trailing edge without pitch (azimuth, precone, pitch) (deg)
120,4,0 BldOrientation_h(1_2)  successive rotations (theta_x, theta_y, theta_z) defining initial orientation of the blade frame from the hub frame such that the "z" is along span, "y" along trailing edge without pitch (azimuth, precone, pitch) (deg)
240,4,0 BldOrientation_h(1_3)  successive rotations (theta_x, theta_y, theta_z) defining initial orientation of the blade frame from the hub frame such that the "z" is along span, "y" along trailing edge without pitch (azimuth, precone, pitch) (deg)
3.0 BldHubRad_bl(1_1)  zoffset in blade coordinates of blade 1 where radial input data start (m)
3.0 BldHubRad_bl(1_2)  zoffset in blade coordinates of blade 2 where radial input data start (m)
3.0 BldHubRad_bl(1_3)  zoffset in blade coordinates of blade 3 where radial input data start (m)
Turbine motion definition
The definition of the turbine motion is only used when AnalysisType=1, but must always be present in the input file.
The base motion is given in the same way for basic or advanced geometries. The motion of the base may be: fixed (BaseMotionType=0), sinusoidal (BaseMotionType=1) or arbitrary (BaseMotionType=2). The turbine base motion is applied at each time step before applying the initial position and orientation of the turbine base. A sinusoidal motion implies that one degree of freedom (DegreeOfFreedom) of the turbine base is moving according to a sine function of a given amplitude (Amplitude) and frequency (Frequency, in Hz), with zero phase. The 6 possible degrees of freedom correspond to translations or rotations of the base frame in global coordinates (g) (e.g. surge, sway, heave, roll, pitch, yaw). An arbitrary motion is specified via a CSV file (BaseMotionFileName) which contains 19 columns: time, 3 translations (global), three successive rotations (global), 3 translation velocities, 3 rotational velocities (omega, in global), 3 translational accelerations and 3 rotational accelerations (alpha, in global). Example of arbitrary input files are given in Section 4.2.1.5.4. The time vector in the motion file has to be ascending, but does not need to be linear. Linear interpolation is used by the driver to determine inputs at a given time. The displacements/orientations, velocities, and accelerations are not checked internally for consistency.
An example of inputs for a sinusoidal surge motion is given below:
 Turbine(1) Motion [used only when AnalysisType=1] 
1 BaseMotionType(1)  Type of motion prescribed for this base {0: fixed, 1: Sinusoidal motion, 2: arbitrary motion} (flag)
1 DegreeOfFreedom(1)  {1:xg, 2:yg, 3:zg, 4:theta_xg, 5:theta_yg, 6:theta_zg} [used only when BaseMotionType=1] (flag)
5.0 Amplitude(1)  Amplitude of sinusoidal motion [used only when BaseMotionType=1] (m or rad)
0.1 Frequency(1)  Frequency of sinusoidal motion [used only when BaseMotionType=1] (Hz)
"unused" BaseMotionFileName(1)  Filename containing arbitrary base motion (19 columns: Time, x, y, z, theta_x, ..., alpha_z) [used only when BaseMotionType=2]
The different inputs for the basic and advanced geometries are given below:
basic: The motion of a basic turbine consists of a constant nacelle yaw (NacYaw, positive rotation of the nacelle about the vertical tower axis, counterclockwise when looking downward), rotor speed (RotSpeed, positive clockwise looking downwind), and blade pitch (BldPitch, negative around \(z_b\)). Examples are given below:
0 NacYaw(1)  Yaw angle (about z_t) of the nacelle (deg)
7 RotSpeed(1)  Rotational speed of rotor in rotor coordinates (rpm)
1 BldPitch(1)  Blades pitch (deg)
advanced: When an advanced geometry is provided and when the number of blades is nonzero, the motion section contains options for the nacelle motion, rotor motion and individual blade pitch motion. The syntax for each of these motions consists of defining a type (fixed or timevarying), a value for the fixed case or a file for the timevarying case. The input files are CSV files containing time, position, speed and acceleration. Examples of files are given in Section 4.2.1.5.4. The displacements/orientations, velocities, and accelerations are not checked internally for consistency. The time vector in the motion file has to be ascending, but does not need to be linear. Linear interpolation is used by the driver to determine inputs at a given time. The angular and rotational data in the CSV file are defined in rad and rad/s, whereas they are defined in deg and rpm in the driver input file. An example is given below for a fixed rotational speed:
0 NacMotionType(1)  Type of motion prescribed for the nacelle {0: fixed yaw, 1: time varying yaw angle} (flag)
0 NacYaw(1)  Yaw angle (about z_t) of the nacelle [user only when NacMotionType=0] (deg)
"unused" NacMotionFileName(1)  Filename containing yaw motion [used only when NacMotionType=1]
0 RotMotionType(1)  Type of motion prescribed for this rotor {0: constant rotation, 1: time varying rotation} (flag)
6.0 RotSpeed(1)  Rotational speed of rotor in rotor coordinates [used only when RotorMotionType=0] (rpm)
"unused" RotMotionFileName(1)  Filename containing rotor motion [used only when RotorMotionType=1]
0 BldMotionType(1)  Type of pitch motion prescribed for the blades {0: fixed, 1: time varying pitch} (flag)
0 BldPitch(1_1)  Blade 1 pitch [used only when BldMotionType=0] (deg)
0 BldPitch(1_2)  Blade 2 pitch [used only when BldMotionType=0] (deg)
0 BldPitch(1_3)  Blade 3 pitch [used only when BldMotionType=0] (deg)
"unused" BldMotionFileName(1_1)  Filename containing blade pitch motion [used only when BldMotionType=1]
"unused" BldMotionFileName(1_2)  Filename containing blade pitch motion [used only when BldMotionType=1]
"unused" BldMotionFileName(1_3)  Filename containing blade pitch motion [used only when BldMotionType=1]
Timedependent analysis
Timedependent analyses are used to vary a few standard variables during the simulation. The variables are: reference wind speed (HWndSpeed), power law exponent (PLExp), rotor speed (RotSpd), collective pitch (Pitch), and nacelle yaw (Yaw). The time series of each variable are provided in a CSV file (TimeAnalysisFileName). Timedependent analyses are selected using AnalysisType=2. They are restricted to one turbine (numTurbines=1).
 Timedependent Analysis [used only when AnalysisType=2 and numTurbines=1] 
"TimeSeries.csv" TimeAnalysisFileName  Filename containing time series (6 column: Time, HWndSpeed, PLExp, RotSpd, Pitch, Yaw).
Combinedcase analyses
Combinedcase analyses are used to run parametric studies in one single run. They are selected using AnalysisType=3, and are restricted to one turbine (numTurbines=1). The variables that can be changed for each simulation are: reference wind speed (HWndSpeed), power law exponent (PLExp), rotor speed (RotSpd), collective pitch (Pitch), nacelle yaw (Yaw), time step (dT), simulation time (Tmax), and sinusoidal motion parameters (degree of freedom, DOF, amplitude and frequency). When DOF=0, the turbine base is fixed.
 CombinedCase Analysis [used only when AnalysisType=3 and numTubines=1] 
4 NumCases  Number of cases to run
HWndSpeed PLExp RotSpd Pitch Yaw dT Tmax DOF Amplitude Frequency
(m/s) () (rpm) (deg) (deg) (s) (s) () (m or rad) (Hz)
8. 0.0 6. 0. 0. 1.0 100 0 0 0.0
8. 0.0 6. 0. 0. 1.0 100 0 0 0.0
9. 0.1 7. 1. 0. 0.5 50 1 5.0 0.1
9. 0.2 8. 2. 0. 0.5 50 1 2.0 0.2
Outputs
The output section controls the format of the tabular output file and VTK files, similar to the OpenFAST outputs. The user can control the hub radius and nacelle dimension for the VTK visualization. The hub is represented as a sphere of radius (VTKHubRad), and the nacelle with a parallelepiped defined using an origin and three lengths parallel to the nacelle coordinates (VTKNacDim).
 Output Settings 
"ES15.8E2" OutFmt  Format used for text tabular output, excluding the time channel. Resulting field should be 10 characters. (quoted string)
2 OutFileFmt  Format for tabular (timemarching) output file (switch) {1: text file [<RootName>.out], 2: binary file [<RootName>.outb], 3: both}
0 WrVTK  VTK visualization data output: (switch) {0=none; 1=init; 2=animation}
2 VTKHubRad  HubRadius for VTK visualization (m)
1,1,1,2,2,2 VTKNacDim  Nacelle Dimension for VTK visualization x0,y0,z0,Lx,Ly,Lz (m)
AeroDyn inputs for multiple turbines¶
No changes are required to the AeroDyn input files when one turbine is used. To minimize the impact of the multipleturbines implementation, the driver currently uses only one AeroDyn input file for all turbines. This means that the AeroDyn options are currently the same for all rotors.
The definition of the blade files and tower inputs needs to be adapted when more than three blades are used and more than one turbine is used.
Blade files
The legacy AeroDyn format requires a minimum of three blade file names. For this reason, the blades of all rotors are currently indicated successively in the ADBlFile list. The list is populated by looping on turbines and turbine blades, with the blade index being the fastest index. For now, the number of stations have to be the same for all blades.
An example is given below for two turbines, the first one having 3 blades, the second 2 blades:
====== Rotor/Blade Properties =====================================================================
True UseBlCm  Include aerodynamic pitching moment in calculations? (flag)
"AD_Turbine1_blade1.dat" ADBlFile(1)  Name of file containing distributed aerodynamic properties for Blade #1 ()
"AD_Turbine1_blade1.dat" ADBlFile(2)  Name of file containing distributed aerodynamic properties for Blade #2 ()
"AD_Turbine1_blade3.dat" ADBlFile(3)  Name of file containing distributed aerodynamic properties for Blade #3 ()
"AD_Turbine2_blade1.dat" ADBlFile(4)  Name of file containing distributed aerodynamic properties for Blade #4 ()
"AD_Turbine2_blade2.dat" ADBlFile(5)  Name of file containing distributed aerodynamic properties for Blade #5 ()
Aerodynamic tower inputs
The entire tower input section of AeroDyn has to be reproduced for each turbine, including turbines that are set not to have a tower (hasTower=False). The number of stations may differ for each turbine. The tower stations defined in the AeroDyn input file are assumed to be given with respect to the tower origin, unlike OpenFAST which uses ground/MSL as a reference.
An example is given below for two turbines:
====== Turbine(1) Tower Influence and Aerodynamics ================================================ [used only when TwrPotent/=0, TwrShadow=True, or TwrAero=True]
2 NumTwrNds  Number of tower nodes used in the analysis () [used only when TwrPotent/=0, TwrShadow=True, or TwrAero=True]
TwrElev TwrDiam TwrCd TwrTI
(m) (m) () ()
0.0 2.0 1.0 0.1
10.0 1.0 1.0 0.1
====== Turbine(2) Tower Influence and Aerodynamics ================================================ [used only when TwrPotent/=0, TwrShadow=True, or TwrAero=True]
3 NumTwrNds  Number of tower nodes used in the analysis () [used only when TwrPotent/=0, TwrShadow=True, or TwrAero=True]
TwrElev TwrDiam TwrCd TwrTI
(m) (m) () ()
0.0 4.0 1.0 0.1
15.0 3.0 1.0 0.1
30.0 2.0 1.0 0.1
Examples of driver input files¶
Working examples that use the different features of the driver are given in the rtest repository:
An example of an AeroDyn driver for a basic inflow, basic HAWT, and combined case analyses is given below:
 AeroDyn Driver Input File 
Three bladed wind turbine, using basic geometry input
 Input Configuration 
False Echo  Echo input parameters to "<rootname>.ech"?
3 AnalysisType  {1: multiple turbines, one simulation, 2: one turbine, one timedependent simulation, 3: one turbine, combined cases}
11.0 TMax  Total run time [used only when AnalysisType/=3] (s)
0.5 DT  Simulation time step [used only when AnalysisType/=3] (s)
"./AD.dat" AeroFile  Name of the primary AeroDyn input file
 Inflow Data 
0 CompInflow  Compute inflow wind velocities (switch) {0=Steady Wind; 1=InflowWind}
"unused" InflowFile  Name of the InflowWind input file [used only when CompInflow=1]
9.0 HWindSpeed  Horizontal wind speed [used only when CompInflow=0 and AnalysisType=1] (m/s)
140 RefHt  Reference height for horizontal wind speed [used only when CompInflow=0] (m)
0.10 PLExp  Power law exponent [used only when CompInflow=0 and AnalysisType=1] ()
 Turbine Data 
1 NumTurbines  Number of turbines
 Turbine(1) Geometry 
True BasicHAWTFormat(1)  Flag to switch between basic or generic input format {True: next 7 lines are basic inputs, False: Base/Twr/Nac/Hub/Bld geometry and motion must follow}
0,0,0 BaseOriginInit(1)  Coordinate of tower base in base coordinates (m)
3 NumBlades(1)  Number of blades ()
3. HubRad(1)  Hub radius (m)
140.82513 HubHt(1)  Hub height (m)
7 Overhang(1)  Overhang (m)
6 ShftTilt(1)  Shaft tilt (deg)
4 Precone(1)  Blade precone (deg)
3.09343 Twr2Shft(1)  Vertical distance from the towertop to the rotor shaft (m)
 Turbine(1) Motion [used only when AnalysisType=1] 
1 BaseMotionType(1)  Type of motion prescribed for this base {0: fixed, 1: Sinusoidal motion, 2: arbitrary motion} (flag)
1 DegreeOfFreedom(1)  {1:xg, 2:yg, 3:zg, 4:theta_xg, 5:theta_yg, 6:theta_zg} [used only when BaseMotionType=1] (flag)
5.0 Amplitude(1)  Amplitude of sinusoidal motion [used only when BaseMotionType=1] (m or rad)
0.1 Frequency(1)  Frequency of sinusoidal motion [used only when BaseMotionType=1] (Hz)
"" BaseMotionFileName(1)  Filename containing arbitrary base motion (19 columns: Time, x, y, z, theta_x, ..., alpha_z) [used only when BaseMotionType=2]
0 NacYaw(1)  Yaw angle (about z_t) of the nacelle (deg)
7 RotSpeed(1)  Rotational speed of rotor in rotor coordinates (rpm)
1 BldPitch(1)  Blade 1 pitch (deg)
 Timedependent Analysis [used only when AnalysisType=2, numTurbines=1] 
"unused" TimeAnalysisFileName  Filename containing time series (6 column: Time, HWndSpeed, PLExp, RotSpd, Pitch, Yaw).
 CombinedCase Analysis [used only when AnalysisType=3, numTurbines=1 
4 NumCases  Number of cases to run
HWndSpeed PLExp RotSpd Pitch Yaw dT Tmax DOF Amplitude Frequency
(m/s) () (rpm) (deg) (deg) (s) (s) () () (Hz)
8.0 0.0 6. 0. 0. 1.0 100 0 0 0
8.0 0.0 6. 0. 0. 1.0 100 0 0 0
9.0 0.1 7. 1. 0. 0.5 51 1 5.0 0.1
9.0 0.2 8. 2. 0. 0.51 52 1 2.0 0.2
 Output Settings 
"ES15.8E2" OutFmt  Format used for text tabular output, excluding the time channel. Resulting field should be 10 characters. (quoted string)
2 OutFileFmt  Format for tabular (timemarching) output file (switch) {1: text file [<RootName>.out], 2: binary file [<RootName>.outb], 3: both}
0 WrVTK  VTK visualization data output: (switch) {0=none; 1=init; 2=animation}
2 VTKHubRad  HubRadius for VTK visualization (m)
1,1,1,2,2,2 VTKNacDim  Nacelle Dimension for VTK visualization x0,y0,z0,Lx,Ly,Lz (m)
The time vector in the motion files has to be ascending, but does not need to be linear. Linear interpolation is used by the driver to determine inputs at a given time.
Arbitrary base motion file:
time_[s] , x_[m] , y_[m] , z_[m] , theta_x_[rad] , theta_y_[rad] , theta_z_[rad] , xdot_[m/s] , ydot_[m/s] , zdot_[m/s] , omega_x_g_[rad/s] , omega_y_g_[rad/s] , omega_z_g_[rad/s] , xddot_[m^2/s] , yddot_[m^2/s] , zddot_[m^2/s] , alpha_x_g_[rad/s] , alpha_y_g_[rad/s] , alpha_z_g_[rad/s]
0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 10.053096 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000
0.100000 , 0.000000 , 0.000000 , 0.963507 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 8.809596 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 0.000000 , 24.344157 , 0.000000 , 0.000000 , 0.000000
Yaw motion file:
time_[s] , yaw_[rad] , yaw_rate_[rad/s] , yaw_acc_[rad/s^2]
0.000000 , 0.000000 , 0.000000 , 0.000000
0.100000 , 0.007277 , 0.212647 , 4.029093
Rotor motion file:
time_[s] , azimuth_[rad] , omega_[rad/s] , rotacc_[rad/s^2]
0.000000 , 0.000000 , 0.000000 , 0.000000
0.100000 , 0.000000 , 0.000000 , 0.000000
Pitch motion file:
time_[s] , pitch_[rad] , pitch_rate_[rad/s] , pitch_acc_[rad/s^2]
0.000000 , 0.000000 , 0.000000 , 0.000000
0.100000 , 0.000000 , 0.000000 , 0.000000
0.200000 , 0.000000 , 0.000000 , 0.000000
AeroDyn Theory¶
This theory manual is work in progress, please refer to the AeroDyn 14 manual for more details [adMH05]. Many changes have occured since AeroDyn 14 (e.g. BEM formulation, coordinate system used in the BEM equations, dynamic stall, dynamic BEM), but these changes are not yet documented here.
Steady BEM¶
The steady blade element momentum (BEM) equations are solved as a constrained equation, and the formulation follows the description from Ning [adNin14].
Tower shadow models¶
Powles tower shadow model (TwrShadow=1) is given by:
where \(\overline{r} = \sqrt{ \overline{x}^2 + \overline{y}^2 }\).
Eames tower shadow model (TwrShadow=2) is given by:
where \(TI\) is the turbulence intensity at the tower node.
Unsteady aerodynamics¶
The Unsteady Aerodynamic (UA) models account for flow hysteresis, including unsteady attached flow, trailingedge flow separation, dynamic stall, and flow reattachment. Dynamic stall refers to rapid aerodynamic changes that may bring about or delay stall behavior [adBra17]. Rapid changes in wind speed (for example, when the blades pass through the tower shadow) cause a sudden detachment and then reattachment of air flow along the airfoil. Such effects at the blade surface cannot be predicted with steady state aerodynamics, but may affect turbine operation, not only when the blades encounter tower shadow, but also during operation in skewed flows and turbulent wind conditions. Dynamic stall effects occur on time scales of the order of the time for the relative wind at the blade to traverse the blade chord, approximately \(c/\Omega r\). For large wind turbines, this might be on the order of \(0.5\) seconds at the blade root to \(0.001\) seconds at the blade tip. Dynamic stall can result in high transient forces as the wind speed increases, but stall is delayed.
Theory¶
The different dynamic stall models implemented in AeroDyn are presented below.
See Section 4.2.1.2.3 for a comprehensive description of all the inputs present in the profile input file (including some of the ones repeated below).
The airfoil section coordinate system and main variables are presented in Fig. 4.5 and further described below:
Aerodynamic Center (AC): point of the airfoil cross section where the aerodynamic forces and moment are assumed to act. Usually close to the 1/4 chord point for a regular airfoil and at the center for a circular cross section
“3/4” chord point: in the original formulation this point refers to the point on the chord axis located 3/4 chord behind the leading edge. This concept is here generalized to the point located midway between the aerodynamic center and the trailing edge, to account for aerodynamic center positions that differ strongly from a 1/4 chord point. The notation \(3/4\) is kept in this document.
\(\omega\): rotational speed of the airfoil section (pitching/torsional rate) positive around z.
\(\boldsymbol{v}_{ac}\): velocity vector at the aerodynamic center \(\boldsymbol{v}_{ac}=[v_{x,ac}, v_{y,ac}]\) (coordinates assumed to be expressed in the airfoil section coordinate system)
\(\boldsymbol{v}_{34}\): velocity vector at the 3/4 chord point \(\boldsymbol{v}_{34}=[v_{x,34}, v_{y,34}]\)(coordinates assumed to be expressed in the airfoil section coordinate system) The velocity is obtained from the velocity at the 1/4 chord point and the rotational speed of the section: \(\boldsymbol{v}_{34}=\boldsymbol{v}_{ac}+\omega d_{34} \hat{\boldsymbol{x}}_s\) where \(d_{34}\) is the distance between the aerodynamic center and the 3/4 chord point.
\(U_{ac}\): velocity norm at the aerodynamic center. \(U_{ac}=\lVert\boldsymbol{v}_{ac}\rVert=\sqrt{v_{x,ac}^2 + v_{y,ac}^2}\)
\(\alpha_{ac}\): angle of attack at the aerodynamic center \(\alpha_{ac}=\operatorname{atan2}(v_{x,ac},v_{y,ac})\)
\(\alpha_{34}\): angle of attack at the 3/4 chord point \(\alpha_{34}=\operatorname{atan2}(v_{x,34},v_{y,34})\)
\(\boldsymbol{x}\): the vector of states used by the continuous formulations
\(c\): airfoil chord
\(C_l^{st}, C_d^{st}, C_m^{st}\): static airfoil coefficients
\(\alpha_0\): angle of attack at zero lift, \(C_l^{st}(\alpha_0)=0\)
\(\alpha_1\): angle of attack close to positive stall.
\(\alpha_2\): angle of attack close to negative stall.
\(C_{l,\alpha}\): slope of the steady lift curve about \(\alpha_0\).
\(f^{st}_s(\alpha)\): is the steady separation function, determined from the lift curve \(C_l^{st}(\alpha)\) (see below, and e.g. [adHGAM04])
\(A_1\), \(A_2\), \(b_1\), \(b_2\): are four constants, characteristic of the propagation of the wake vorticity (Wagner constants)
Time constants:
\(T_u(t) = \frac{c}{2U_{ac}(t)} \in [0.001, 50]\): Time for the flow to go over half the airfoil section. The value is plateaued to avoid unphysical values.
\(T_{f,0}\): Dimensionless time constant associated with leading edge separation. Default is 3.
\(T_{p,0}\): Dimensionless time constant for the boundarylayer,leading edge pressure gradient. Default is 1.7
Separation function:
The steady separation function, \(f_s^{st}\), is defined as the separation point on a flat plate for a potential Kirchhoff flow [adHGAM04]:
When \(\alpha=\alpha_0\), \(f_s^{st}(\alpha_0)=1\). Away from \(\alpha_0\), the function drops progressively to \(0\). As soon as the function reaches \(0\) on both sides of \(\alpha_0\), then \(f_s^{st}\) is kept at the constant value \(0\).
Note that for UAMod=5, a different separation function is formed.
We define an offset for the \(C_n\) function, cn_offset
, where
\(C_{n,offset}=\frac{C_n\left(\alpha^{Lower}\right)+C_n\left(\alpha^{Upper}\right)}{2}\). Then, the separation function
is a value between 0 and 1, given by the following equation:
with the fullyattached \(C_n\) curve defined as \(C_n\) between \(alpha^{Lower}\) and \(alpha^{Upper}\) and linear functions outside of that range:
Note that to avoid numerical issues at the \(\pm180\) degree boundary, this function changes slope when the separation function is 0 above \(alpha^{Upper}\) and below \(alpha^{Lower}\). This allow the fullyattached linear sections to be periodic and avoid numerical issues with large magnitudes of angle of attack.
Inviscid and fully separated lift coefficient:
The inviscid lift coefficient is \(C_{l,\text{inv}}= C_{l,\alpha} (\alpha\alpha_0)\). The fully separated lift coefficient may be modelled in different ways ([adBra17]). In most engineering models, the slope of the fully separated lift coefficient around \(\alpha_0\) is \(C_{l,\alpha}/2\). In the Unsteady AeroDynamics submodule, the fully separated lift coefficient is derived from the steady separation function as:
The BeddoesLeishman model account for attached flows and trailing edge stall [adLB89].
Two variants are implemented in the Unsteady Aerodynamic module. These two (compressible) models are currently described in the following reference: [adDH19]. The models use \(C_n\) and \(C_c\) as main physical quantities. The models use discrete states and cannot be used with linearization.
The 4states (incompressible) dynamic stall model from HansenGaunaaMadsen (HGM) is described in [adHGAM04] and enabled using UAMod=4
. The model uses \(C_l\) as main physical quantity.
Linearization of the model will be available in the future.
State equation: The state equation of the model is:
with
Output equation: The unsteady airfoil coefficients \(C_{l,\text{dyn}}\), \(C_{d,\text{dyn}}\), \(C_{m,\text{dyn}}\) are obtained from the states as follows:
with:
The 5states (incompressible) dynamic stall model is similar to the BeddoesLeishman 4states model (UAMod=4), but
adds a 5th state to represent vortex generation.
It is enabled using UAMod=5
. The model uses \(C_n\) and \(C_c\) as main physical quantities.
Linearization of the model will be available in the future.
Oye’s dynamic stall model is a onestate (continuous) model, formulated in [adOye91] and described e.g. in [adBra17]. The model attempts to capture trailing edge stall. Linearization of the model will be available in the future.
State equation: Oye’s dynamic stall model uses one state, \(\boldsymbol{x}=[f_s]\) where \(f_s\) is the unsteady separation function. The state equation is a firstorder differential equation:
where \(T_f=T_{f,0} T_u\) is the time constant of the flow separation and \(f_s^{st}\) is the steady state separation function described in Section 4.2.1.7.1.1. The value \(T_{f,0}\) is usually chosen around 6 (different from the default value). It is readily seen that \(f_s\) reaches the value \(f_s^{st}\) when the system is in a steady state (i.e. when \(\frac{df_s(t)}{dt}=0\)).
Output equation: The unsteady lift coefficient is computed as a linear combination of the inviscid lift coefficient, \(C_{l, \text{inv}}\), and the fully separated lift coefficient \(C_{l,\text{fs}}\). Both of these lift coefficients are determined from the steady lift coefficient, usually provided as tabulated data, noted \(C_l^{st}(\alpha)\), where the superscript \(st\) stands for “steady”. The unsteady lift coefficient is modelled as:
where \(\alpha_{34}\) is the instantaneous angle of attack at the 3/4 chord. \(f_s\) is seen to act as a relaxation factor between the two flow situations.
The BoeingVertol is mentioned in the following paper [adMB11]. Details of the model were omitted in this reference, so the documentation presented here is inspired from the implementation done in the vortex code CACTUS, which was reproduced to quasiidentity in AeroDyn. Linearization is not possible with this model.
The model as presented in [adMB11] is an outputonly model, where the dynamic angle of attack is determined using the quasi steady angle of attack and the rate of change of the angle of attack:
where \(k_1\) and \(\gamma\) are constants of the model. In practice, the implementation is different for the lift and drag coefficients, and for negative and positive stall. The model needs a discrete state to calculate the rate of change of the angle of attack and two discrete states to keep track of whether the model is activated or not.
Airfoil constants:
The constants \(k_1\), for positive and negative rates of angle of attack, are set to:
The extent of the transition region is computed as:
where \(\alpha_1\) and \(\alpha_2\) are the angle of attack at positive and negative stall respectively (taken as the values from the airfoil input file). The factor 0.9 is a margin to prevent the effective angle of attack to reach \(\alpha_0\) during stall.
Intermediate variables:
The variables \(\gamma\) for the lift and drag are computed as function of the thickness to chord ratio of the airfoil \(t_c\) and the Mach number \(M_a\) (assumed to be 0 in the current implementation):
where \(\delta = 0.06t_c\).
Update of discrete states (and intermediate variables):
The rate of change of the angle of attack is computed as:
An additional state was introduced to avoid sudden jump of \(\dot{\alpha}\), by storing its value. Rates that are beyond a fraction of \(\pi \Delta t\) are replaced with the values at the previous time step. This feature is not present in the CACTUS implementation.
The dynamic angle of attack offsets (lags) for the lift and drag are computed as:
The value of \(k_1\) is taken as \(k_{1,n}\) if \(\dot{\alpha}(\alpha_{34}\alpha_0)<0\), and taken as \(k_{1,p}\) otherwise. The lagged angle of attacks for the lift and drag are:
The distances to positive and negative stall are computed as follows. If \(\dot{\alpha}(\alpha_{34}\alpha_0)<0\) and the dynamic stall is active:
If \(\dot{\alpha}(\alpha_{34}\alpha_0)<0\) and the dynamic stall is not active:
If \(\dot{\alpha}(\alpha_{34}\alpha_0)\ge0\):
The effective angle of attack for the lift coefficient is taken as the lagged angle of attack:
The effective angle of attack for the drag coefficient is obtained from the lagged angle of attack and the deltas to stall:
where \(T=2\Delta\alpha_\text{max}\) is the extent of the “transition” region.
The lift dynamic stall state is activated if \(\dot{\alpha}(\alpha_{34}\alpha_0) \ge 0\) and if the angle of attack is above \(\alpha_1\) or below \(\alpha_2\). The state is turned off if \(\dot{\alpha}(\alpha_{34}\alpha_0) < 0\) and the effective angle of attack is below \(\alpha_1\) and above \(\alpha_2\).
The drag dynamic stall state is activated if any of the condition below are true:
The state is turned off otherwise.
Calculation of outputs: The calculation of the dynamic lift and drag coefficients is done as follows
Recalculation of intermediate variables are necessary to obtain \(\alpha_{e,L}\) and \(\alpha_{e,D}\). The moment coefficient is calculated based on values at the aerodynamic center and midchord (“50”):
where \(\alpha_{50}\) is computed the same way as \(\alpha_{34}\) (using the velocity at the aerodynamic center and the rotational rate of the airfoil) but using the distance from the aerodynamic center to the midchord (see Section 4.2.1.7.1.1).
Inputs¶
See Section 4.2.1.2.2.6 for a description of the inputs necessary in the AeroDyn primary file (e.g. UAMod
)
See Section 4.2.1.2.3 for a more comprehensive description of all the inputs present in the profile input file. Their default values are described in Section 4.2.1.7.3
See Section 4.2.1.7.1.1 for a list of notations and definitions specific to unsteady aerodynamic inputs.
An example of profile data (containing some of the unsteady aerodynamic parameters) is available here
(here)
.
Calculating Default Airfoil Coefficients¶
The default value for cd0
is the minimum value of the \(C_d\) curve between \(\pm20\) degrees angle of attack.
\(\alpha_{c_{d0}}\) is defined to be the angle of attack where cd0
occurs.
After computing cd0
, the \(C_n\) curve is computed by
The slope of the \(C_n\) curve is computed as follows:
\(C_{n,smooth}^{Slope}\) is a smoothed version of \(C_{n}^{Slope}\), calculated using a triweight kernel with a window of 2 degrees.
Using \(C_{n,smooth}^{Slope}\), alphaUpper
and alphaLower
are computed:
alphaUpper
is the smallest angle of attack value between \(\alpha_{c_{d0}}\) and 20 degrees where the \(C_{n,smooth}^{Slope}\) curve has started to decrease to 90% of its maximum slope.
alphaLower
is the largest angle of attack value between 20 degrees and \(\alpha_{c_{d0}}\) where the \(C_{n,smooth}^{Slope}\) curve has started to decrease to 90% of its maximum slope.
Cn1
is the value of \(C_n(\alpha)\) at the smallest value of \(\alpha\) where \(\alpha >= \alpha^{Upper}\) and the separation function, \(f_{st}(\alpha)\) = 0.7.
Cn2
is the value of \(C_n(\alpha)\) at the largest value of \(\alpha\) where \(\alpha <= \alpha^{Lower}\) and the separation function, \(f_{st}(\alpha)\) = 0.7.
Cn_offset
is the average value of the \(C_n\) curve at alphaUpper
and alphaLower
:
C_nalpha
is defined as the maximum slope of the smoothed \(C_n\) curve, \(C_{n,smooth}^{Slope}\) between \(\pm20\) degrees angle of attack.
C_lalpha
is defined as the maximum slope of the (unsmoothed) \(C_l\) curve, \(C_{l}^{Slope}\) between \(\pm20\) degrees angle of attack.
The default alpha0
is computed as the zerocrossing of a line with a slope equal to C_lalpha
that goes through the \(C_l\) curve at \(\alpha = \frac{\alpha^{Upper} + \alpha^{Lower}}{2}\)
Cm0
is the value of the \(C_m\) curve at alpha0
: \(C_{m,0} = C_m\left(\alpha_0\right)\). If the \(C_m\) polar values have not been included, \(C_{m,0} =0\).
alpha1
is the angle of attack above alphaUpper
where the separation function, \(f_s^{st}\) is 0.7.
alpha2
is the angle of attack below alphaLower
where the separation function, \(f_s^{st}\) is 0.7.
Cn1
is the value of the \(C_n\) curve at alpha1
.
Cn2
is the value of the \(C_n\) curve at alpha2
.
Outputs¶
Outputting variables of the dynamic stall models is possible, but requires
to set preprocessor variable UA_OUTS
and recompile the program (OpenFAST, AeroDyn Driver, or Unsteady Aero driver).
The outputs are written in output files with extension *.UA.out.
To activate these outputs with cmake, compile using DCMAKE_Fortran_FLAGS="DUA_OUTS=ON"
Driver¶
A driver is available to run simulations for a single airfoil, using sinusoidal variation of the angle of attack, or user defined time series of angle of attack, relative wind speed and pitch rate.
Using cmake, the driver is compiled using make unsteadyaero_driver, resulting as an executable in the aerodyn folder.
An example of driver input file is available here: here
.
An example of time series input is available here: here
References¶
 adBra17
E. Branlard. Wind Turbine Aerodynamics and VorticityBased Methods: Fundamentals and Recent Applications. Springer International Publishing, 2017. ISBN 9783319551630. doi:10.1007/9783319551647.
 adDH19
R. Damiani and G. Hayman. The unsteady aerodynamics module for fast 8. Technical Report, National Renewable Energy Laboratory, 2019. NREL/TP500066347.
 adHGAM04
M.H. Hansen, Mac Gaunaa, and Helge Aagaard Madsen. A beddoesleishman type dynamic stall model in statespace and indicial formulations. Technical Report, Risø National Laboratory, Roskilde, Denmark, 2004.
 adLB89
J. G. Leishman and T.S. Beddoes. A semiempirical model for dynamic stall. Journal of the American Helicopter Society, 34(3):p3–17, 1989.
 adMH05
P. J. Moriarty and A. Craig Hansen. Aerodyn theory manual. Technical Report, National Renewable Energy Laboratory, December 2005. NREL/EL50036881.
 adMB11
J. Murray and M. Barone. The development of cactus : a wind and marine turbine performance simulation code. Technical Report, 49th AIAA Aerospace Sciences Meeting, Orlando, Florida, 2011.
 adNin14
S. Andrew Ning. A simple solution method for the blade element momentum equations with guaranteed convergence. Wind Energy, 17(9):1327–1345, 2014. doi:https://doi.org/10.1002/we.1636.
 adOye91
S. Øye. Dynamic stall, simulated as a time lag of separation. Proceedings of the 4th IEA Symposium on the Aerodynamics of Wind Turbines, 1991.
Appendix¶
AeroDyn Input Files¶
In this appendix we describe the AeroDyn inputfile structure and provide examples.
1) Baseline AeroDyn Driver Input File:
(driver input file example)
:
The driver input file is only needed for the standalone version of AeroDyn and contains inputs normally generated by OpenFAST, and necessary to control the aerodynamic simulation for uncoupled models.
AeroDyn Driver Timeseries Input File
(driver timeseries input file example)
:
The timeseries input file for a case in the AeroDyn driver allows the parameters
to vary with time. This feature can be useful for debugging the aerodynamic response
outside of OpenFAST.
2) Multirotor AeroDyn Driver Input File
(driver input file example)
:
3) AeroDyn Primary Input File
(primary input file example)
:
The primary AeroDyn input file defines modeling options, environmental conditions (except freestream flow), airfoils, tower nodal discretization and properties, as well as output file specifications.
The file is organized into several functional sections. Each section corresponds to an aspect of the aerodynamics model.
The input file begins with two lines of header information which is for your use, but is not used by the software.
Airfoil Data Input File
The airfoil data input files themselves (one for each airfoil) include tables containing coefficients of lift force, drag force, and pitching moment versus AoA, as well as UA model parameters. In these files, any line whose first nonblank character is an exclamation point (!) is ignored (for inserting comment lines). The noncomment lines should appear within the file in order, but comment lines may be intermixed as desired for reading clarity.
5) Blade Data Input File
(blade data input file example)
:
The blade data input file contains the nodal discretization, geometry, twist, chord, and airfoil identifier for a blade. Separate files are used for each blade, which permits modeling of aerodynamic imbalances.
AeroDyn List of Output Channels¶
This is a list of all possible output parameters for the AeroDyn module. The names are grouped by meaning, but can be ordered in the OUTPUTS section of the AeroDyn input file as you see fit. \(B \alpha N \beta\), refers to output node \(\beta\) of blade \(\alpha\), where \(\alpha\) is a number in the range [1,3] and \(\beta\) is a number in the range [1,9], corresponding to entry \(\beta\) in the \(\textit{BlOutNd}\) list. \(\textit{TwN}\beta\) refers to output node \(\beta\) of the tower and is in the range [1,9], corresponding to entry \(\beta\) in the \(\textit{TwOutNd}\) list.
The local tower coordinate system is shown in Fig. 4.1 and the local blade coordinate system is shown in Fig. 4.6 below. Figure Fig. 4.6 also shows the direction of the local angles and force components.
OLAF User’s Guide and Theory Manual (Free Vortex Wake in AeroDyn15)¶
This document offers a quick reference guide for the free vortex wake module named OLAF that is included in the AeroDyn module of OpenFAST. It is intended to be used by the general user in combination with other features of AeroDyn and other OpenFAST modules. The manual will be updated as new releases are issued and as needed to provide further information on advancements or modifications to the software.
The documentation here was derived from the OLAF users manual by K. Shaler, E. Branlard, and A. Platt. (https://www.nrel.gov/docs/fy20osti/75959.pdf)
Introduction¶
Over the past few decades, substantial reductions in the cost of wind energy have come from large increases in rotor size. One important consideration for such large turbines is increased blade flexibility. In particular, large blade deflections may lead to a swept area that deviates significantly from the rotor plane. Such deviations violate assumptions used by common aerodynamic models, such as the blade element momentum (BEM) method. Such methods rely on actuatordisk assumptions that are only valid for axisymmetric rotor loads contained in a plane. Large blade deflections may also cause near wake of the turbine to diverge from a uniform helical shape. Further, interactions between turbine blades and the local near wake may increase, thus violating assumptions of models that do not account for the position and dynamics of the near wake. Additionally, highly flexible blades will likely cause increased unsteadiness and threedimensionality of aerodynamic effects, increasing the importance of accurate and robust dynamic stall models. There are many other complex wind turbine situations that violate simple engineering assumptions. Such situations include obtaining accurate aerodynamic loads for nonstraight blade geometries (e.g., builtin curvature or sweep); skewed flow caused by yawed inflow or turbine tilt; and large rotor motion as a result of placing the turbine atop a compliant offshore floating platform.
Higherfidelity aerodynamic models are necessary to account for the increased complexity of flexible and floating rotors. Although computational fluid dynamics (CFD) methods are able to capture such features, their computational cost limits the number of simulations that can be feasibly performed, which is an important consideration in load analysis for turbine design. FVW methods are less computationally expensive than CFD methods while modeling similarly complex physics. As opposed to the BEM methods, FVW methods do not rely on adhoc engineering models to account for dynamic inflow, skewed wake, tip losses, or ground effects. These effects are inherently part of the model. Numerous vorticitybased tools have been implemented, ranging from the early treatments by Rosenhead ([olafRos31]), the formulation of vortex particle methods by Winckelmans and Leonard ([olafWL93]), to the recent mixed EulerianLagrangian compressible formulations of Papadakis ([olafPap14]). Examples of longstanding codes that have been applied in the field of wind energy are GENUVP ([olafVou06]), using vortex particles methods, and AWSM ([olafvG03]), using vortex filament methods. Both tools have successfully been coupled to structural solvers. The method was extended by Branlard et al. ([olafBPG+15]) to consistently use vortex methods to perform aeroelastic simulations of wind turbines in sheared and turbulent inflow. Most formulations rely on a liftingline representation of the blades, but recently, a viscousinviscid representation was used in combination with a structural solver ([olafSGarciaSorensenS17]).
cOnvecting LAgrangian Filaments (OLAF) is a free vortex wake (FVW) module used to compute the aerodynamic forces on moving two or threebladed horizontalaxis wind turbines. This module has been incorporated into the National Renewable Energy Laboratory physicsbased engineering tool, OpenFAST, which solves the aerohydroservoelastic dynamics of individual wind turbines. OLAF is incorporated into the OpenFAST module, AeroDyn15, as an alternative to the traditional bladeelement momentum (BEM) option, as shown in Figures Fig. 4.8 and Fig. 4.9.
Incorporating the OLAF module within OpenFAST allows for the modeling of highly flexible turbines along with the aerohydroservoelastic response capabilities of OpenFAST. The OLAF module follows the requirements of the OpenFAST modularization framework ([olafJon13, olafSJJ15]).
The OLAF module uses a liftingline representation of the blades, which is characterized by a distribution of bound circulation. The spatial and time variation of the bound circulation results in free vorticity being emitted in the wake. OLAF solves for the turbine wake in a timeaccurate manner, which allows the vortices to convect, stretch, and diffuse. The OLAF model is based on a Lagrangian approach, in which the turbine wake is discretized into Lagrangian markers. There are many methods of representing the wake with Lagrangian markers ([olafBra17]). In this work, a hybrid lattice/filament method is used, as depicted in Figure Fig. 4.10.
Here, the position of the Lagrangian markers is defined in terms of wake age, \(\zeta\), and azimuthal position, \(\psi\). A lattice method is used in the near wake of the blade. The near wake spans over a userspecified angle or distance for nonrotating cases. Though past research has indicated that a nearwake region of \(30^\circ\) is sufficient ([olafALR02, olafLei06]), it has been shown that a larger near wake is required for high thrust and other challenging conditions. After the near wake region, the wake is assumed to instantaneously roll up into a tip vortex and a root vortex, which are assumed to be the most dominant features for the remainder of the wake ([olafLBB02]). Each Lagrangian marker is connected to adjacent markers by straightline vortex filaments, approximated to secondorder accuracy ([olafGL02]). The wake is discretized based on the spanwise location of the blade sections and a specified time step (\(dt\)), which may be different from the time step of AeroDyn. After an optional initialization period, the wake is allowed to move and distort, thus changing the wake structure as the markers are convected downstream. To limit computational expense, the root and tip vortices are truncated after a specified distance (WakeLength) downstream from the turbine. The wake truncation violates Helmholtz’s first law and hence introduces an erroneous boundary condition. To alleviate this, the wake is “frozen” in a buffer zone between a specified buffer distance, FreeWakeLength, and WakeLength. In this buffer zone, the markers convect at the average ambient velocity. In this way, truncation error is minimized~([olafLBB02]). The buffer zone is typically chosen as the convected distance over one rotor revolution.
As part of OpenFAST, induced velocities at the lifting line/blade are transferred to AeroDyn15 and used to compute the effective blade angle of attack at each blade section, which is then used to compute the aerodynamic forces on the blades. The OLAF method returns the same information as the BEM method, but allows for more accurate calculations in areas where BEM assumptions are violated, such as those discussed above. As the OLAF method is more computationally expensive than BEM, both methods remain available in OpenFAST, and the user may specify in the AeroDyn15 input file which method is used.
The OLAF input file defines the wake convection and circulation solution methods; wake size and length options; Lagrangian marker regularization (viscous core) method; and other simulation and output parameters. The extents of the near and far wakes are specified by a nondimensional length in terms of rotor diameter. Different regularization functions for the vortex elements are available. Additionally, different methods to compute the regularization parameters of the bound and wake vorticity may be selected. In particular, viscous diffusion may be accounted for by dynamically changing the regularization parameter. Wake visualization output options are also available.
This document is organized as follows. Section 4.2.2.3.1 covers downloading, compiling, and running OLAF. Section 4.2.2.4 describes the OLAF input file and modifications to the AeroDyn15 input file. Section 4.2.2.5 details the OLAF output file. Section 4.2.2.6 provides an overview of the OLAF theory, including the free vortex wake method as well as integration into the AeroDyn15 module. Example input files and a list of output channels are detailed in Appendices A, B, and C.
List of Symbols¶
BEM 
bladeelement momentum 
CFD 
computational fluid dynamics 
DOE 
U.S. Department of Energy 
\(F_v\) 
core radius factor 
\(t\) 
time 
FVW 
free vortex wake 
\(N\) 
number of rotor revolutions before wake cutoff condition 
\(\vec{r}\) 
vector between point of interest and vortex segment 
\(\vec{r}(\psi,\zeta)\) 
position vector of Lagrangian markers 
\(r_c\) 
core radius 
\(r_{c0}\) 
initial core radius 
OLAF 
cOnvecting LAgrangian Filaments 
\(\alpha\) 
numerical constant \(=1.25643\) 
\(\Gamma\) 
circulation strength 
\(\delta\) 
measure of viscous diffusion 
\(\epsilon\) 
measure of strain 
\(\Delta \psi\) 
step size for blade rotation 
\(\Omega\) 
rotational speed of wind turbine 
\(\zeta\) 
vortex wake age 
\(\zeta_0\) 
vortex wake age offset 
\(\nu\) 
kinematic viscosity 
\(\psi\) 
azimuth blade position 
Working with OLAF¶
Running OLAF¶
As OLAF is a module of OpenFAST, the process of downloading, compiling, and running OLAF is the same as that for OpenFAST. Such instructions are available in the Installing OpenFAST documentation.
Note
To improve the speed of FVW module, the user may wish to compile with OpenMP. To do so, add the DOPENMP=ON option with CMake.
Guidelines¶
Most options of OLAF can be left to default. The results will depend on the time discretization, wake length, and regularization parameters. We provide guidelines for these parameters in this section, together with a simple python code to compute these parameters. Please check this section again as we might further refine our guidelines with time.
Time step and wake length We recommend to set OLAF’s time step (DTfvw) such that it corresponds to \(\Delta \psi = 6\) degrees of one rotor revolution:
If the structural solver requires a smaller time step, the time step for the glue code can be set to a different value than DTfvw as long as DTfvw is a multiple of the glue code time step.
We recommend to set the near wake length to the number of time steps needed to reach two rotor revolutions. For the far wake, we recommend 10 rotor revolutions. For the free farwake, we recommend to set the distance to a value somewhere between 25% and 50% of the far wake length, (e.g. 3 revolutions).
The following python script computes the parameters according to these guidelines.
def OLAFParams(omega_rpm, deltaPsiDeg=6, nNWrot=2, nFWrot=10, nFWrotFree=3, nPerAzimuth=None):
"""
Computes recommended time step and wake length based on the rotational speed in RPM
INPUTS:
 omega_rpm: rotational speed in RPM
 deltaPsiDeg : azimuthal discretization in deg
 nNWrot : number of near wake rotations
 nFWrot : total number of far wake rotations
 nFWrotFree : number of far wake rotations that are free
deltaPsiDeg  nPerAzimuth
5 72
6 60
7 51.5
8 45
"""
omega = omega_rpm*2*np.pi/60
T = 2*np.pi/omega
if nPerAzimuth is not None:
dt_wanted = np.around(T/nPerAzimuth,3)
else:
dt_wanted = np.around(deltaPsiDeg/(6*omega_rpm),3)
nPerAzimuth = int(2*np.pi /(deltaPsiDeg*np.pi/180))
nNWPanel = nNWrot*nPerAzimuth
nFWPanel = nFWrot*nPerAzimuth
nFWPanelFree = nFWrotFree*nPerAzimuth
print(dt_wanted , ' DTfvw')
print(int (nNWPanel ), ' nNWPanel ')
print(int (nFWPanel ), ' WakeLength ')
print(int (nFWPanelFree), ' FreeWakeLength')
return dt_wanted, nNWPanel, nFWPanel, nFWPanelFree
Regularization parameters
One critical parameter of vortex methods is the regularization parameter, also referred to as core radius. We currently recommend to set the regularization parameter as a fraction of the spanwise discretization, that is: RegDetMethod=3 , WakeRegFactor=0.6, WingRegFactor=0.6. We will likely update these guidelines in the future.
We also recommend to have the regularization increasing with downstream distance: WakeRegMethod=3.
The factor with which the regularization parameter will increase with downstream distance can be set as CoreSpreadEddyVisc=1000 for modern multiMW turbines. Further guidelines will follow for this parameter in the future.
Input Files¶
No lines should be added or removed from the input files, except in tables where the number of rows is specified.
Units¶
OLAF uses the International System of Units (e.g., kg, m, s, N). Angles are assumed to be in degrees unless otherwise specified.
OLAF Primary Input File¶
The primary OLAF input file defines general free wake options, circulation model selection and specification, near and farwake length, and wake visualization options. Each section within the file corresponds to an aspect of the OLAF model. For most parameters, the user may specify the value “default” (with or without quotes), in which case a default value, defined below, is used by the program.
See Section 4.2.2.10 for a sample OLAF primary input file.
IntMethod [switch] specifies which integration method will be used to convect the Lagrangian markers. There are four options: 1) fourthorder RungeKutta [1], 2) fourthorder AdamsBashforth [2], 3) fourthorder AdamsBashforthMoulton [3], and 4) firstorder forward Euler [5]. The default option is [5]. Currently only options [1] and [5] are implemented. These methods are specified in Section 4.2.2.6.4.
DTfvw [sec] specifies the time interval at which the module will update the wake. The time interval must be a multiple of the time step used by AeroDyn15. The blade circulation is updated at each intermediate time step based on the intermediate blades positions and wind velocities. The default value is \(dt_{aero}\), where \(dt_{aero}\) is the time step used by AeroDyn.
FreeWakeStart [sec] specifies at what time the wake evolution is classified as “free.” Before this point is reached, the Lagrangian markers are simply convected with the freestream velocity. After this point, induced velocities are computed and affect the marker convection. If a time less than or equal to zero is given, the wake is “free” from the beginning of the simulation. The default value is \(0\).
FullCircStart [sec] specifies at what time the blade circulation reaches its full strength. If this value is specified to be \(>0\), the circulation is multiplied by a factor of \(0\) at \(t=0\) and linearly increasing to a factor of \(1\) for \(t>\textit{FullCircStart}\). The default value is \(0\).
CircSolvMethod [switch] specifies which circulation method is used. There are three options: 1) \(C_l\)based iterative procedure [1], 2) noflow through [2], and 3) prescribed [3]. The default option is [1]. These methods are described in Section 4.2.2.6.3.
CircSolvConvCrit [] specifies the dimensionless convergence criteria used for solving the circulation. This variable is only used if CircSolvMethod = [1]. The default value is \(0.001\), corresponding to \(0.1\%\) error in the circulation between two iterations.
CircSolvRelaxation [] specifies the relaxation factor used to solve the circulation. This variable is only used if CircSolvMethod = [1]. The default value is \(0.1\).
CircSolvMaxIter [] specifies the maximum number of iterations used to solve the circulation. This variable is only used if CircSolvMethod = [1]. The default value is \(30\).
PrescribedCircFile [quoted string] specifies the file containing the prescribed blade circulation. This option is only used if CircSolvMethod = [3]. The circulation file format is a delimited file with one header line and two columns. The first column is the dimensionless radial position [r/R]; the second column is the bound circulation value in [m\(^2\)/s]. The radial positions do not need to match the AeroDyn node locations. A sample prescribed circulation file is given in Section 4.2.2.11.
nNWPanel [] specifies the number of FVW time steps (DTfvw) for which the nearwake lattice is computed. In the future, this value will be defined as an azimuthal span in degrees or a downstream distance in rotor diameter.
WakeLength [D] specifies the length, in rotor diameters, of the far wake. The default value is \(8\). 1
FreeWakeLength [D] specifies the length, in rotor diameters, for which the turbine wake is convected as “free.” If FreeWakeLength is greater than WakeLength, then the entire wake is free. Otherwise, the Lagrangian markers located within the buffer zone delimited by FreeWakeLength and WakeLength are convected with the average velocity. The default value is \(6\). 2
FWShedVorticity [flag] specifies whether shed vorticity is included in the far wake. The default value is [False], specifying that the far wake consists only of the trailed vorticity from the root and tip vortices.
DiffusionMethod [switch] specifies which diffusion method is used to account for viscous diffusion. There are two options: 1) no diffusion [0] and 2) the corespreading method [1]. The default option is [0].
RegDetMethod [switch] specifies which method is used to determine the regularization parameters. There are four options: 1) constant [0] and 2) optimized [1], 3) chord [2], and 4) span [3]. The optimized option determines all the parameters in this section for the user. The optimized option is still work in progress and not recommended. The constant option requires the user to specify all the parameters present in this section. The default option is [0]. When RegDetMethod==0, the regularization parameters is set constant:
When RegDetMethod==2, the regularization parameters is set according to the local chord:
When RegDetMethod==3, the regularization parameters is set according to the spanwise discretization:
where \(Delta r\) is the length of the spanwise station.
RegFunction [switch] specifies the regularization function used to remove the singularity of the vortex elements, as specified in Section 4.2.2.6.4. There are five options: 1) no correction [0], 2) the Rankine method [1], 3) the LambOseen method [2], 4) the Vatistas method [3], and 5) the denominator offset method [4]. The functions are given in . The default option is [3].
WakeRegMethod [switch] specifies the method of determining viscous core radius (i.e., the regularization parameter). There are three options: 1) constant [1], 2) stretching [2], and 3) age [3]. The methods are described in Section 4.2.2.6.7.4. The default option is [1].
WakeRegParam [m, or ] specifies the wake regularization parameter, which is the regularization value used at the initialization of a vortex element. If the regularization method is “constant”, this value is used throughout the wake.
BladeRegParam [m, or ] specifies the bound vorticity regularization parameter, which is the regularization value used for the vorticity elements bound to the blades.
CoreSpreadEddyVisc [] specifies the eddy viscosity parameter \(\delta\). The parameter is used for the corespreading method (DiffusionMethod = [1]) and the regularization method with age (WakeRegMethod = [3]). The variable \(\delta\) is described in Section 4.2.2.6.7.4. The default value is \(100\).
TwrShadowOnWake [flag] specifies whether the tower potential flow and tower shadow have an influence on the wake convection. The tower shadow model, when activated in AeroDyn, always has an influence on the lifting line, hence the induction and loads on the blade. This option only concerns the wake. The default option is [False].
ShearVorticityModel [switch] specifies whether shear vorticity is modeled in addition to the sheared inflow prescribed by InflowWind. There are two options: 1) no treatment [0] and 2) mirrored vorticity [1]. The mirrored vorticity accounts for the ground effect. Dedicated options to account for the shear vorticity will be implemented at a later time. The shear velocity profile is handled by InflowWind irrespective of this input. The default option is [0].
VelocityMethod [switch] specifies the method used to determine the velocity. There are four options: 1) \(N^2\) BiotSavart computation on the vortex segments [1], 2) ParticleTree formulation [2], 3) \(N^2\) BiotSavart computation using a particle representation, 4) SegmentTree formulation. The default option is [1]. Option [2] and [3] requires the specification of PartPerSegment (see below). Option [4] is expected to give results close to option [1] while offering significant speedup, and this option does not require the specification of PartPerSegment.
TreeBranchFactor [] specifies the dimensionless distance, in branch radius, above which a multipole calculation is used instead of a direct evaluation. This option is only used in conjunction with the tree code (VelocityMethod = [2]).
PartPerSegment [] specifies the number of particles that are used when a vortex segment is represented by vortex particles. The default value is \(1\).
WrVTK [flag] specifies if Visualization Toolkit (VTK) visualization files
are to be written out. WrVTK = [0] does not write out any VTK files. WrVTK
= [1] outputs VTK files at time steps defined by VTK_fps.
WrVTK*= *[2], outputs at time steps defined by VTK_fps, but ensures that
a file is written at the beginning and the end of the simulation (typically
used with VTK_fps=0 to output only at the end of the simulation).
The outputs are written in the
folder, vtk_fvw.
The parameters WrVTK, VTKCoord, and VTK_fps are
independent of the glue code VTK output options.
VTKBlades [] specifies how many blade VTK files are to be written out. VTKBlades \(= n\) outputs VTK files for \(n\) blades, with \(0\) being an acceptable value. The default value is \(1\).
VTKCoord [switch] specifies in which coordinate system the VTK files are written. There are two options: 1) global coordinate system [1] and 2) hub coordinate system [2]. The default option is [1].
VTK_fps [\(1\)/sec] specifies the output frequency of the VTK files. The provided value is rounded to the nearest allowable multiple of the time step. The default value is \(1/dt_\text{fvw}\). Specifying VTK_fps = [all], is equivalent to using the value \(1/dt_\text{aero}\). If VTK_fps<0, then no outputs are created, except if WrVTK=2.
nGridOut [] specifies the number of grid outputs. The default value is 0. The grid outputs are fields (velocity, vorticity) that are exported on a regular Cartesian grid. They are defined using a table that follows on the subsequent lines, with two lines of headers. The user needs to specify a name (GridName) used for the VTK output filename, a grid type (GridType), a start time (TStart), an end time (TEnd), a time interval (DTOut), and the grid extent in each directions, e.g. XStart, XEnd, nX. When GridType is 1, the velocity field is written to disk, when GridType is 2, both the velocity field and the vorticity field (computed using finite differences) are written. It is possible to export fields at a point (nX=nY=nZ=1), a line, a plane, or a 3D grid. When set to “default”, the start time is 0 and the end time is set to the end of the simulation. The outputs are done for \(t_{Start}\leq t \leq t_{End}\) When the variable DTOut is set to “all”, the AeroDyn time step is used, when it is set to “default”, the OLAF time step is used. An example of input is given below:
3 nGridOut Number of grid outputs
GridName GridType TStart TEnd DTOut XStart XEnd nX YStart YEnd nY ZStart ZEnd nZ
() () (s) (s) (s) (m) (m) () (m) (m) () (m) (m) ()
"box" 2 default default all 200 1000. 5 150. 150. 20 5. 300. 30
"vert" 1 default default default 200 1000. 100 0. 0. 1 5. 300. 30
"hori" 1 default default 2.0 200 1000. 100 150. 150. 20 100. 100. 1
In this example, the first grid, named “box”, is exported at the AeroDyn time step, and consists of a box of shape 5x20x30 and dimension 1200x300x295. The grid contains both the velocity and vorticity. The two other grids are vertical and horizontal planes containing only the velocity.
AeroDyn15 Input File¶
As OLAF is incorporated into the AeroDyn15 module, a wake computation option has been added to the AeroDyn15 input file and a line has been added. These additions are as follows.
WakeMod specifies the type of wake model that is used. WakeMod = [3] has been added to allow the user to switch from the traditional BEM method to the OLAF method.
FVWFile [string] specifies the OLAF module file, the path is relative to the AeroDyn file, unless an absolute path is provided.
The BEM options (e.g. tiploss, skew, and dynamic models) are read and discarded when WakeMod = [3]. The following sections and parameters remain relevant and are used by the vortex code:
general options (e.g., airfoil and tower modeling);
environmental conditions;
dynamic stall model options;
airfoil and blade information;
tower aerodynamics; and
outputs.
Output Files¶
The OLAF module itself does not produce its own output file. However, additional
output channels are made available in AeroDyn15. As such, the AeroDyn15
output file is briefly described as well as the outputs made available with
OLAF. Visualization files are generated by using the parameter, WrVTK. This
parameter is available in the OLAF input file, in which case the VTK files are
written to the folder vtk_fvw
, or the primary .fst
file, in which case
the VTK files are written to the folder vtk
.
Velocity field outputs can be exported as VTK files. The user can control these outputs using nGridOut and the subsequent table.
Results File¶
OpenFAST generates a master results file that includes the AeroDyn15 results. The results are in table format, where each column is a data channel, and each row corresponds to a simulationoutput time step. The data channels are specified in the OUTPUTS section in the AeroDyn15 primary input file. The column format of the AeroDyngenerated files is specified using the OutFmt parameter of the OpenFAST driver input file.
OLAF Theory¶
This section details the OLAF method and provides an overview of the computational method, followed by a brief explanation of its integration with OpenFAST.
Introduction  Vorticity Formulation¶
The vorticity equation for incompressible homogeneous flows in the absence of nonconservative force is given by Eq. (4.1)
Here, \(\vec{\omega}\) is the vorticity, \(\vec{u}\) is the velocity, and \(\nu\) is the viscosity. In free vortex wake methods, the vorticity equation is used to describe the evolution of the wake vorticity. Different approximations are introduced to ease its resolution, such as projecting the vorticity onto a discrete number of vortex elements (here vortex filaments), and separately treating the convection and diffusion steps, known as viscoussplitting. Several complications arise from the method; in particular, the discretization requires a regularization of the vorticity field (or velocity field) to ensure a smooth approximation.
The forces exerted by the blades onto the flow are expressed in vorticity formulation as well. This vorticity is bound to the blade and has a circulation associated with the lift force. A liftingline formulation is used here to model the bound vorticity.
The different models of the implemented free vortex code are described in the following sections.
Discretization  Projection¶
The numerical method uses a finite number of states to model the continuous vorticity distribution. To achieve this, the vorticity distribution is projected onto basis function which is referred to as vortex elements. Vortex filaments are here used as elements that represents the vorticity field. A vortex filament is delimited by two points and hence assumes a direction formed by these two points. A vorticity tube is oriented along the unit vector \(\vec{e}_x\) of cross section \(dS\) and length \(l\). It can then be approximated by a vortex filament of length \(l\) oriented along the same direction. The total vorticity of the tube and the vortex filaments are the same and related by:
where \(\vec{\Gamma}\) is the circulation intensity of the vortex filament. If the vorticity tubes are complex and occupy a large volume, the projection onto vortex filaments is difficult and the projection onto vortex particle is more appropriate. Assuming the wake is confined to a thin vorticity layer which defines a velocity jump of know direction, it is possible to approximate the wake vorticity sheet as a mesh of vortex filaments. This is the basis of vortex filament wake methods. Vortex filaments are a singular representation of the vorticity field, as they occupy a line instead of a volume. To better represent the vorticity field, the filaments are “inflated”, a process referred to as regularization (see Section 4.2.2.6.7). The regularization of the vorticity field also regularizes the velocity field and avoids the singularities that would otherwise occur.
LiftingLine Representation¶
The code relies on a liftingline formulation. Liftingline methods effectively lump the loads at each crosssection of the blade onto the mean line of the blade and do not account directly for the geometry of each crosssection. In the vorticitybased version of the liftingline method, the blade is represented by a line of varying circulation. The line follows the motion of the blade and is referred to as “bound” circulation. The bound circulation does not follow the same dynamic equation as the free vorticity of the wake. Instead, the intensity is linked to airfoil lift via the KuttaJoukowski theorem. Spanwise variation of the bound circulation results in vorticity being emitted into the the wake. This is referred to as “trailed vorticity”. Time changes of the bound circulation are also emitted in the wake, referred to as “shed” vorticity. The subsequent paragraphs describe the representation of the bound vorticity.
The liftingline and wake representation is illustrated in Fig. 4.11. The blade liftingline is discretized into a finite number of panels, each of them forming a four sided vortex rings. The spanwise discretization follows the discretization of the AeroDyn blade input file. The number of spanwise panels, \(n_\text{LL}\), is one less than the total number of AeroDyn nodes, NumBlNds. The sides of the panels coincide with the liftingline and the trailing edge of the blade. The liftingline is currently defined as the 1/4 chord location from the leading edge (LE). More details on the panelling is provided in Section 4.2.2.6.3.2. At a given time step, the circulation of each liftingline panel is determined according to one of the three methods developed in Section 4.2.2.6.3.3. At the end of the time step, the circulation of each liftingline panel is emitted into the wake, forming free vorticity panels. To satisfy the Kutta condition, the circulation of the first near wake panel and the bound circulation are equivalent (see Fig. 4.11 b). The wake panels model the thin shear layer resulting from the continuation of the blade boundary layer. This shear layer can be modelled using a continuous distribution of vortex doublets. A constant doublet strength is assumed on each panel, which in turn is equivalent to a vortex ring of constant circulation.
The current implementation stores the positions and circulations of the panel corner points. In the vortex ring formulation, the boundary between two panels corresponds to a vortex segment of intensity equal to the difference of circulation between the two panels. The convention used to define the segment intensity based on the panels intensity is shown in Fig. 4.11 c. Since the circulation of the bound panels and the first row of near wake panels are equal, the vortex segments located on the trailing edge have no circulation.
The definitions used for the panelling of the blade are given in Fig. 4.11 d, following the notations of van Garrel ([olafvG03]). The leading edge and trailing edge (TE) locations are directly obtained from the AeroDyn mesh. At two spanwise locations, the LE and TE define the corner points: \(\vec{x}_1\), \(\vec{x}_2\), \(\vec{x}_3\), and \(\vec{x}_4\). The current implementation assumes that the aerodynamic center, the liftingline, and the 1/4 chord location all coincide. For a given panel, the liftingline is then delimited by the points \(\vec{x}_9= 3/4\,\vec{x}_1 + 1/4\, \vec{x}_2\) and \(\vec{x}_{10}=3/4\,\vec{x}_4 + 1/4\, \vec{x}_3\). The mid points of the four panel sides are noted \(\vec{x}_5\), \(\vec{x}_6\), \(\vec{x}_7\), and \(\vec{x}_8\). The liftingline vector (\(\vec{dl}\)) as well as the vectors tangential (\(\vec{T}\)) and normal (\(\vec{N}\)) to the panel are defined as:
The area of the panel is obtained as \(dA = (\vec{x}_6\vec{x}_8)\times(\vec{x}_{7}\vec{x}_5)\). For CircSolvMethod=[1], the control points are located on the liftingline at the location \(\vec{x}_9+\eta_j \vec{dl}\). The factor \(\eta_j\) is determined based on the fullcosine approximation of van Garrel. This is based on the spanwise widths of the current panel, \(w_j\), and the neighboring panels \(w_{j1}\) and \(w_{j+1}\):
For an equidistant spacing, this discretization places the control points at the middle of the liftingline (\(\eta=0.5\)). Theoretical circulation results for an elliptic wing with a cosine spacing are retrieved with such discretization since it places the control points closer to stronger trailing segments at the wing extremities (see e.g. [olafKer00]).
Three methods are implemented to determine the bound circulation strength. They are selected using the input CircSolvMethod, and are presented in the following sections.
The Clbased iterative method determines the circulation within a nonlinear iterative solver that makes use of the polar data at each control point located on the lifting line. The algorithm ensures that the lift obtained using the angle of attack and the polar data matches the lift obtained with the KuttaJoukowski theorem. At present, it is the preferred method to compute the circulation along the blade span. It is selected with CircSolvMethod=[1]. The method is described in the work from van Garrel ([olafvG03]). The algorithm is implemented in at iterative approach using the following steps:
The circulation distribution from the previous time step is used as a guessed circulation, \(\Gamma_\text{prev}\).
The velocity at each control points \(j\) is computed as the sum of the wind velocity, the structural velocity, and the velocity induced by all the vorticity in the domain, evaluated at the control point location.
\[\begin{aligned} \vec{v}_j = \vec{V}_0  \vec{V}_\text{elast} + \vec{v}_{\omega,\text{free}} + \vec{v}_{\Gamma_{ll}} \end{aligned}\]\(\vec{v}_{\omega,\text{free}}\) is the velocity induced by all free vortex filaments, as introduced in Eq. (4.10) . The contribution of \(\vec{v}_{\Gamma_{ll}}\) comes from the liftingline panels and the first row of near wake panels, for which the circulation is set to \(\Gamma_\text{prev}\)
The circulation for all liftingline panels \(j\) is obtained as follows.
\[\begin{aligned} \Gamma_{ll,j} =\frac{1}{2} C_{l,j}(\alpha_j) \frac{\left[ (\vec{v}_j \cdot \vec{N})^2 + (\vec{v}_j \cdot \vec{T})^2\right]^2\,dA}{ \sqrt{\left[(\vec{v}_j\times \vec{dl})\cdot\vec{N}\right]^2 + \left[(\vec{v}_j\times \vec{dl})\cdot\vec{T}\right]^2} } %\label{eq:} ,\quad\text{with} \quad \alpha_j = \operatorname{atan}\left(\frac{\vec{v}_j\cdot\vec{N}}{\vec{v}_j \cdot \vec{T}} \right) \end{aligned}\]The function \(C_{l,j}\) is the lift coefficient obtained from the polar data of blade section \(j\) and \(\alpha_j\) is the angle of attack at the control point.
The new circulation is set using the relaxation factor \(k_\text{relax}\) (CircSolvRelaxation):
\[\begin{aligned} \Gamma_\text{new}= \Gamma_\text{prev} + k_\text{relax} \Delta \Gamma ,\qquad \Delta \Gamma = \Gamma_{ll}  \Gamma_\text{prev} %\label{eq:} \end{aligned}\]Convergence is checked using the criterion \(k_\text{crit}\) (CircSolvConvCrit):
\[\begin{aligned} \frac{ \operatorname{max}(\Delta \Gamma}{\operatorname{mean}(\Gamma_\text{new})} < k_\text{crit} \end{aligned}\]If convergence is not reached, steps 25 are repeated using \(\Gamma_\text{new}\) as the guessed circulation \(\Gamma_\text{prev}\).
A WeissingerLbased representation ([olafWei47]) of the lifting surface is also available ([olafBL94, olafGup06, olafRib07]). In this method, the circulation is solved by satisfying a noflow through condition at the 1/4chord points. It is selected with CircSolvMethod=[2].
The final available method prescribes a constant circulation. A user specified spanwise distribution of circulation is prescribed onto the blades. It is selected with CircSolvMethod=[3].
Free Vorticity Convection¶
The governing equation of motion for a vortex filament is given by the convection equation of a Lagrangian marker:
where \(\vec{r}\) is the position of a Lagrangian marker. The Lagrangian markers are the end points of the vortex filaments. The Lagrangian convection of the filaments stretches the filaments and thus automatically accounts for strain in the vorticity equation.
At present, the RungeKutta 4th order (IntMethod=[1]) or first order forward Euler (IntMethod=[5]) methods are implemented to numerically solve the lefthand side of Eq. (4.4) for the vortex filament location. In the case of the first order Euler method, the convection is then simply: Eq. (4.5).
Free Vorticity Convection in Polar Coordinates¶
The governing equation of motion for a vortex filament is given by:
Using the chain rule, Eq. (4.6) is rewritten as:
where \(d\psi/dt=\Omega\) and \(d\psi=d\zeta\) ([olafLBB02]). Here, \(\vec{r}(\psi,\zeta)\) is the position vector of a Lagrangian marker, and \(\vec{V}[\vec{r}(\psi,\zeta)]\) is the velocity.
Induced Velocity and Velocity Field¶
The velocity term on the righthand side of Eq. (4.4) is a nonlinear function of the vortex position, representing a combination of the freestream and induced velocities ([olafHan08]). The induced velocities at point \(\vec{x}\), caused by each straightline filament, are computed using the BiotSavart law, which considers the locations of the Lagrangian markers and the intensity of the vortex elements ([olafLBB02]):
Here, \(\Gamma\) is the circulation strength of the filament, \(\vec{dl}\) is an elementary length along the filament, \(\vec{r}\) is the vector between a point on the filament and the control point \(\vec{x}\), and \(r=\vec{r}\) is the norm of the vector. The integration of the BiotSavart law along the filament length, delimited by the points \(\vec{x}_1\) and \(\vec{x}_2\) leads to:
with \(\vec{r}_1= \vec{x}\vec{x}_1\) and \(\vec{r}_2= \vec{x}\vec{x}_2\). The factor \(F_\nu\) is a regularization parameter, discussed in Section 4.2.2.6.7.3. \(r_0\) is the filament length, where \(\vec{r}_0= \vec{x}_2\vec{x}_1\). The distance orthogonal to the filament is:
The velocity at any point of the domain is obtained by superposition of the velocity induced by all vortex filaments, and by superposition of the primary flow, \(\vec{V}_0\), (here assumed divergence free):
where the sum is over all the vortex filaments, each of intensity \(\Gamma_k\). The intensity of each filament is determined by spanwise and time changes of the bound circulation, as discussed in Section 4.2.2.6.3. In treebased methods, the sum over all vortex elements is reduced by lumping together the elements that are far away from the control points.
Regularization¶
The singularity that occurs in Eq. (4.8) greatly affects the numerical accuracy of vortex methods. By regularizing the “1overr” kernel of the BiotSavart law, it is possible to obtain a numerical method that converges to the NavierStokes equations. The regularization is used to improve the regularity of the discrete vorticity field, as compared to the “true” continuous vorticity field. This regularization is usually obtained by convolution with a smooth function. In this case, the regularization of the vorticity field and the velocity field are the same. Some engineering models also perform regularization by directly introducing additional terms in the denominator of the BiotSavart velocity kernel. The factor, \(F_\nu\), was introduced in Eq. (4.9) to account for this regularization.
In the convergence proofs of vortex methods, regularization and viscous diffusion are two distinct aspects. It is common practice in vortex filament methods to blur the notion of regularization with the notion of viscous diffusion. Indeed, for a physical vortex filament, viscous effects prevent the singularity from occurring and diffuse the vortex strength with time. The circular zone where the velocity drops to zero around the vortex is referred to as the vortex core. A length increase of the vortex segment will result in a vortex core radius decrease, and vice versa. Diffusion, on the other hand, continually spreads the vortex radially.
Because of the previously mentioned analogy, practitioners of vortex filament methods often refer to regularization as “viscouscore” models and regularization parameters as “coreradii.” Additionally, viscous diffusion is often introduced by modifying the regularization parameter in space and time instead of solving the diffusion from the vorticity equation. The distinction is made explicit in this document when clarification is required, but a loose terminology is used when the context is clear.
The regularization parameter is both a function of the physics being modeled (blade boundary layer and wake) and the choice of discretization. Contributing factors are the chord length, the boundary layer height, and the volume that each vortex filament is approximating. Currently the choice is left to the user (RegDetMethod=[0]). Empirical results for a rotating blade are found in the work of Gupta ([olafGup06]). As a guideline, the regularization parameter may be chosen as twice the average spanwise discretization of the blade. This guideline is implemented when the user chooses RegDetMethod=[1]. Further refinement of this option will be considered in the future.
Several regularization functions have been developed ([olafRan58, olafScu75, olafVKM91]). At present, five options are available: 1) No correction, 2) the Rankine method, 3) the LambOseen method, 4) the Vatistas method, or 5) the denominator offset method. If no correction method is used, (RegFunction=[0]), \(F_\nu=1\). The remaining methods are detailed in the following sections. Here, \(r_c\) is the regularization parameter (WakeRegParam) and \(\rho\) is the distance to the filament. Both variables are expressed in meters.
The Rankine method ([olafRan58]) is the simplest regularization model. With this method, the Rankine vortex has a finite core with a solid body rotation near the vortex center and a potential vortex away from the center. If this method is used (RegFunction=[1]), the viscous core correction is given by Eq. (4.11).
Here, \(r_c\) is the viscous core radius of a vortex filament, detailed in Section 4.2.2.6.7.4.
If the LambOseen method is used [RegFunction=[2]], the viscous core correction is given by Eq. (4.12).
If the Vatistas method is used [RegFunction=[3]], the viscous core correction is given by Eq. (4.13).
Here, \(\rho\) is the distance from a vortex segment to an arbitrary point ([olafAbe16]). Research from rotorcraft applications suggests a value of \(n=2\), which is used in this work ([olafBL93]).
If the denominator offfset method is used [RegFunction=[4]], the viscous core correction is given by Eq. (4.14)
Here, the singularity is removed by introducing an additive factor in the denominator of Eq. (4.9), proportional to the filament length \(r_0\). In this case, \(F_\nu=1\). This method is found in the work of van Garrel ([olafvG03]).
There are four available methods by which the regularization parameter may evolve with time: 1) constant value, 2) stretching, 3) wake age, or 4) stretching and wake age. The three latter methods blend the notions of viscous diffusion and regularization. The notation \(r_{c0}\) used in this section corresponds to input file parameter value WakeRegParam.
If a constant value is selected, (WakeRegMethod=[1]), the value of \(r_c\) remains unchanged for all Lagrangian markers throughout the simulation and is taken as the value given with the parameter WakeRegParam in meters.
Here, \(\zeta\) is the vortex wake age, measured from its emission time.
If the stretching method is selected, (WakeRegMethod=[2]), the viscous core radius is modeled by Eq. (4.16).
Here, \(\epsilon\) is the vortexfilament strain, \(l\) is the filament length, and \(\Delta l\) is the change of length between two time steps. The integral in Eq. (4.16) represents strain effects.
This option is not yet implemented.
If the wake age method is selected, (WakeRegMethod=[3]), the viscous core radius is modeled by Eq. (4.17).
where \(\alpha=1.25643\), \(\nu\) is kinematic viscosity, and \(\delta\) is a viscous diffusion parameter (typically between \(1\) and \(1,000\)). The parameter \(\delta\) is provided in the input file as CoreSpreadEddyVisc. Here, the term \(4\alpha\delta\nu \zeta\), accounts for viscous effects as the wake propagates downstream. The higher the background turbulence, the more diffusion of the vorticity with time, and the higher the value of \(\delta\) should be. This method partially accounts for viscous diffusion of the vorticity while neglecting the interaction between the wake vorticity itself or between the wake vorticity and the background flow. It is often referred to as the corespreading method. Setting DiffusionMethod=[1] is the same as using the wake age method (WakeRegMethod=[3]).
The time evolution of the core radius is implemented as:
and \(\frac{d r_c}{dt}=0\) on the blades.
Diffusion¶
The viscoussplitting assumption is used to solve for the convection and diffusion of the vorticity separately. The diffusion term \(\nu \Delta \vec{\omega}\) represents molecular diffusion. This term allows for viscous connection of vorticity lines. Also, turbulent flows will diffuse the vorticity in a similar manner based on a turbulent eddy viscosity.
The parameter DiffusionMethod is used to switch between viscous diffusion methods. Currently, only the corespreading method is implemented. The method is described in Section 4.2.2.6.7.4 since it is equivalent to the increase of the regularization parameter with the wake age.
StateSpace Representation and Integration with OpenFAST¶
State, Constraint, Input, and Output Variables¶
The OLAF module has been integrated into the latest version of OpenFAST via AeroDyn15, following the OpenFAST modularization framework ([olafJon13, olafSJJ15]). To follow the OpenFAST framework, the vortex code is written as a module, and its formulation comprises state, constraint, and output equations. The data manipulated by the module include the following vectors: constant parameters, \(\vec{p}\); inputs, \(\vec{u}\); constrained state, \(\vec{z}\); states, \(\vec{x}\); and outputs, \(\vec{y}\). The vectors are defined as follows:
Parameters, \(\vec{p}~\) a set of internal system values that are independent of the states and inputs. The parameters can be fully defined at initialization and characterize the system state and output equations.
Inputs, \(\vec{u}~\) a set of values supplied to the module that, along with the states, are needed to calculate future states and the system output.
Constraint states, \(\vec{z}~\) algebraic variables that are calculated using a nonlinear solver, based on values from the current time step.
States, \(\vec{x}~\) a set of internal values of the module. They are influenced by the inputs and used to calculate future state values and output. Continuous states are employed, meaning that the states are differentiable in time and characterized by continuous timedifferential equations.
Outputs, \(\vec{y}~\) a set of values calculated and returned by the module that depend on the states, inputs, and/or parameters through output equations.
The parameters of the vortex code include:
Fluid characteristics: kinematic viscosity, \(\nu\).
Airfoil characteristics: chord \(c\) and polar data – \(C_l(\alpha)\), \(C_d(\alpha)\), \(C_m(\alpha)\)).
Algorithmic methods and parameters, e.g., regularization, viscous diffusion, discretization, wake geometry, and acceleration.
The inputs of the vortex code are:
Position, orientation, translational velocity, and rotational velocity of the different nodes of the lifting lines (\(\vec{r}_{ll}\), \(\Lambda_{ll}\), \(\vec{\dot{r}}_{ll}\), and \(\vec{\omega}_{ll}\), respectively), gathered into the vector, \(\vec{x}_{\text{elast},ll}\), for conciseness. These quantities are handled using the meshmapping functionality and data structure of OpenFAST.
Disturbed velocity field at requested locations, written \(\vec{V}_0=[\vec{V}_{0,ll}, \vec{V}_{0,m}]\). Locations are requested for liftingline points, \(\vec{r}_{ll}\), and Lagrangian markers, \(\vec{r}_m\). Based on the parameters, this disturbed velocity field may contain the following influences: freestream, shear, veer, turbulence, tower, and nacelle disturbance. The locations where the velocity field is requested are typically the location of the Lagrangian markers.
The constraint states are:
The circulation intensity along the lifting lines, \(\Gamma_{ll}\).
The continuous states are:
The position of the Lagrangian markers, \(\vec{r}_m\)
The vorticity associated with each vortex element, \(\vec{\omega}_e\). For a projection of the vorticity onto vortex segments, this corresponds to the circulation, \(\vec{\Gamma}_e\). For each segment, \(\vec{\Gamma}_e= \Gamma_e \vec{dl}_e =\vec{\omega}_e dV_e\), with \(\vec{dl}_e\) and \(dV_e\), the vortex segment length and its equivalent vortex volume.
The outputs are 1:
The induced velocity at the liftingline nodes, \(\vec{v}_{i,ll}\)
The locations where the undisturbed wind is computed, \(\vec{r}_{r}\) (typically \(\vec{r_{r}}=\vec{r}_m\)).
State, Constraint, and Output Equations¶
An overview of the states, constraints, and output equations is given here. More details are provided in Section 4.2.2.6. The constraint equation is used to determine the circulation distribution along the span of each lifting line. For the van Garrel method, this circulation is a function of the angle of attack along the blade and the airfoil coefficients. The angle of attack at a given liftingline node is a function of the undisturbed velocity, \(\vec{v}_{0,ll}\), and the velocity induced by the vorticity, \(\vec{v}_{i,ll}\), at that point. Part of the induced velocity is caused by the vorticity being shed and trailed at the current time step, which in turn is a function of the circulation distribution along the lifting line. This constraint equation may be written as:
where \(\vec{\Gamma}_p\) is the function that returns the circulation along the blade span, according to one of the methods presented in Section 4.2.2.6.3.
The state equation specifies the time evolution of the vorticity and the convection of the Lagrangian markers:
Here,
\(\vec{v}_\omega\) is the velocity induced by the vorticity in the domain;
\(\vec{V}_\omega(\vec{r},\vec{r}_m,\vec{\omega})\) is the function that computes this induced velocity at a given point, \(\vec{r}\), based on the location of the Lagrangian markers and the intensity of the vortex elements;
the subscript \(e\) indicates that a quantity is applied to an element; and
the vorticity, \(\vec{\omega}\), is recovered from the vorticity of the vortex elements by means of discrete convolutions.
For vortexsegment simulations, the viscoussplitting algorithm is used, and the convection step (Eq. (4.19)) is the main state equation being solved for. The vorticity stretching is automatically accounted for, and the diffusion is performed a posteriori. The velocity function, \(\vec{V}_\omega\), uses the BiotSavart law. The output equation is:
Integration with AeroDyn15¶
The vortex code has been integrated as a submodule of the aerodynamic module of OpenFAST, AeroDyn15. The data workflow between the different modules and submodules of OpenFAST is illustrated in Fig. 4.12. AeroDyn inputs such as BEM options (e.g., tiploss factor), skew model, and dynamic inflow are discarded when the vortex code is used. The environmental conditions, tower shadow, and dynamic stall model options are used. This integration required a restructuring of the AeroDyn15 module to isolate the parts of the code related to tower shadow modeling, induction computation, liftinglineforces computations, and dynamic stall. The dynamic stall model is adapted when used in conjunction with the vortex code to ensure the effect of shed vorticity is not accounted for twice. The interface between AeroDyn15 and the inflow module, InflowWind, was accommodated to include the additionally requested points by the vortex code.
 1
The loads on the lifting line are not an output of the vortex code; their calculation is handled by a separate submodule of AeroDyn.
Future Work¶
This first implementation phase focused on singleturbine capabilities, fulfilling the basic requirements for the design of large and novel rotor concepts. Future development work will turn toward the implementation of features enabling multipleturbine simulations on mediumtolargescale computational clusters. The reduction of the computational time will also be of focus. This may be achieved using tree techniques such as the fast multipole method. Further algorithmic options, such as vortex amalgamation in the far wake, will be considered to speed up the simulation. The framework presented in this manual is compatible with gridfree or gridbased vortex particle formulations. Such particlebased implementations will also be envisaged in the future. Further validation of the code against measurements and higherorder tools will be pursued. Applications to cases known to be challenging for the BEM algorithm will also be investigated, such as highly flexible rotors, offshore floating turbines, smallscale wind farms, multiplerotor turbines, or kites.
The following list contains future work on OLAF software:
Lagrangian particles
Multiple turbines, integration into FAST.Farm
Code speedup
Dedicated dynamic stall model
References¶
 olafAbe16
H. Abedi. Development of Vortex Filament Method for Wind Power Aerodynamics. PhD thesis, Chalmers University of Technology, Gothenburg, Sweden, 2016.
 olafALR02
S. Ananthan, J. G. Leishman, and M. Ramasamy. The role of filament stretching in the freevortex modeling of rotor wakes. In 58th Annual Forum and Technology Display of the American Helicopter Society International. Montreal, Canada, 2002.
 olafBL93
A. Bagai and J. G. Leishman. Flow visualization of compressible vortex structures using density gradient techniques. Experiments in Fluids, 15(6):431–442, 1993.
 olafBL94
A. Bagai and J. G. Leishman. Rotor freewake modeling using a pseudoimplicit technique including comparisons with experimental data. In 50th Annual Forum of the American Helicopter Society. Washington, D.C., 1994.
 olafBra17
E. Branlard. Wind Turbine Aerodynamics and VorticityBased Methods: Fundamentals and Recent Applications. Springer International Publishing, 2017. ISBN 9783319551630. doi:10.1007/9783319551647.
 olafBPG+15
E. Branlard, G. Papadakis, M. Gaunaa, G. Winckelmans, and T. J. Larsen. Aeroelastic large eddy simulations using vortex methods: unfrozen turbulent and sheared inflow. Journal of Physics: Conference Series (Online), 2015. doi:10.1088/17426596/625/1/012019.
 olafGup06
S. Gupta. Development of a TimeAccurate Viscous Lagrangian Vortex Wake Model for Wind Turbine Applications. PhD thesis, Univeristy of Maryland, College Park, MD, 2006.
 olafGL02
S. Gupta and J. G. Leishman. Freevortex filament methods for the analysis of helicopter rotor wakes. Journal of Aircraft, 39(5):759–775, 2002.
 olafHan08
M. O. L. Hansen. Aerodynamics of Wind Turbines. Earthscan, London; Sterling, VA, 2008.
 olafJon13
J. Jonkman. The new modularization framework for the fast wind turbine cae tool. Technical report NREL/CP500057228, National Renewable Energy Laboratory, 2013.
 olafKer00
J. Kerwin. Lecture notes hydrofoil and propellers. Technical Report, M.I.T., 2000.
 olafLei06
J. Leishman. Principles of Helicopter Aerodynamics. Cambridge Univ. Press, Cambridge, MA, 2006.
 olafLBB02
J. G. Leishman, M. J. Bhagwat, and A. Bagai. Freevortex filament methods for the analysis of helicopter rotor wakes. Journal of Aircraft, 39(5):759–775, 2002.
 olafPap14
G. Papadakis. Development of a hybrid compressible vortex particle method and application to external problems including helicopter flows. PhD thesis, National Technical University of Athens, 2014.
 olafRan58
W. J. M. Rankine. Manual of Applied Mechanics. Griffen Co., London, 1858.
 olafRib07
M. Ribera. Helicopter Flight Dynamics Simulation with a TimeAccurate FreeVortex Wake Model. PhD thesis, University of Maryland, College Park, MD, 2007.
 olafRos31
L. Rosenhead. The formation of vortices from a surface of discontinuity. Proceedings of the Royal Society of London. Series A, Containing Papers of a Mathematical and Physical Character, 134(823):170–192, 1931. URL: http://www.jstor.org/stable/95835.
 olafScu75
M. P. Scully. Computation of Helicopter Rotor Wake Geometry and Its Influence on Rotor Harmonic Airloads. PhD thesis, Massachusetts Institute of Technology, Cambridga, MA, 1975.
 olafSGarciaSorensenS17
M. Sessarego, N. Ramos García, J. N. Sørensen, and W. Z. Shen. Development of an aeroelastic code based on threedimensional viscousinviscid method for wind turbine computations. Wind Energy, 20(7):1145–1170, 2017. doi:10.1002/we.2085.
 olafSJJ15
Michael A. Sprague, Jason M. Jonkman, and Bonnie J. Jonkman. Fast modular framework for wind turbine simulation: new algorithms and numerical examples. Technical Report NREL/CP2C0063203, National Renewable Energy Laboratory, 2015.
 olafvG03
A. van Garrel. Development of a wind turbine aerodynamics simulation module. Technical Report ECNC–03079, ECN, 2003.
 olafVKM91
G. H. Vatistas, V. Koezel, and W. C. Mih. A simpler model for concentrated vortices. Experiments in Fluids, 11(1):73–76, 1991.
 olafVou06
S. G. Voutsinas. Vortex methods in aeronautics: how to make things work. International Journal of Computational Fluid Dynamics, 2006.
 olafWei47
J. Weissinger. The lift distribution of sweptback wings. Technical report TM 1120, NACA, 1947.
 olafWL93
G. S. Winckelmans and A. Leonard. Contributions to vortex particle methods for the computation of 3dimensional incompressible unsteady flows. Journal Of Computational Physics, 109(2):247–273, 1993.
Appendix A: OLAF Primary Input File¶
Check the regression test cases for updates to this input file.
1 OLAF (cOnvecting LAgrangian Filaments) INPUT FILE 
2Free wake input file for the Helix test case
3 GENERAL OPTIONS 
45 IntMethod Integration method {1: RungeKutta 4th order, 5: Forward Euler 1st order, default: 5} (switch)
50.2 DTfvw Time interval for wake propagation. {default: dtaero} (s)
6default FreeWakeStart Time when wake is free. () value = always free. {default: 0.0} (s)
7default FullCircStart Time at which full circulation is reached. {default: 0.0} (s)
8 CIRCULATION SPECIFICATIONS 
91 CircSolvingMethod Circulation solving method {1: ClBased, 2: NoFlow Through, 3: Prescribed, default: 1 }(switch)
10default CircSolvConvCrit Convergence criteria {default: 0.001} [only if CircSolvingMethod=1] ()
11default CircSolvRelaxation Relaxation factor {default: 0.1} [only if CircSolvingMethod=1] ()
12default CircSolvMaxIter Maximum number of iterations for circulation solving {default: 30} ()
13 "NA" PrescribedCircFile File containing prescribed circulation [only if CircSolvingMethod=3] (quoted string)
14===============================================================================================
15 WAKE OPTIONS 
16 WAKE EXTENT AND DISCRETIZATION 
17150 nNWPanel Number of nearwake panels [integer] ()
18400 WakeLength Total wake distance [integer] (number of time steps)
19default FreeWakeLength Wake length that is free [integer] (number of time steps) {default: WakeLength}
20False FWShedVorticity Include shed vorticity in the far wake {default: false}
21 WAKE REGULARIZATIONS AND DIFFUSION 
220 DiffusionMethod Diffusion method to account for viscous effects {0: None, 1: Core Spreading, "default": 0}
232 RegDeterMethod Method to determine the regularization parameters {0: Constant, 1: Optimized, 2: Chordscaled, 3: drscaled, default: 0 }
242 RegFunction Viscous diffusion function {0: None, 1: Rankine, 2: LambOseen, 3: Vatistas, 4: Denominator, "default": 3} (switch)
253 WakeRegMethod Wake regularization method {1: Constant, 2: Stretching, 3: Age, default: 1} (switch)
260.25 WakeRegFactor Wake regularization factor (m or )
270.25 BladeRegFactor Blade regularization factor (m or )
281000 CoreSpreadEddyVisc Eddy viscosity in core spreading methods, typical values 11000
29 WAKE TREATMENT OPTIONS 
30False TwrShadowOnWake Include tower flow disturbance effects on wake convection {default:false} [only if TwrPotent or TwrShadow]
310 ShearModel Shear Model {0: No treatment, 1: Mirrored vorticity, default: 0}
32 SPEEDUP OPTIONS 
332 VelocityMethod Method to determine the velocity {1:BiotSavart Segment, 2:Particle tree, 3: Segment tree, default: 1}
341.5 TreeBranchFactor Branch radius fraction above which a multipole calculation is used {default: 2.0} [only if VelocityMethod=2]
351 PartPerSegment Number of particles per segment [only if VelocityMethod=2]
36===============================================================================================
37 OUTPUT OPTIONS 
381 WrVTk Outputs Visualization Toolkit (VTK) (independent of .fst option) {0: NoVTK, 1: Write VTK at each time step} (flag)
391 nVTKBlades Number of blades for which VTK files are exported {0: No VTK per blade, n: VTK for blade 1 to n} ()
402 VTKCoord Coordinate system used for VTK export. {1: Global, 2: Hub, "default": 1}
411 VTK_fps Frame rate for VTK output (frames per second) {"all" for all glue code timesteps, "default" for all OLAF timesteps} [used only if WrVTK=1]
420 nGridOut Number of grid outputs
43GridName GridType TStart TEnd DTOut XStart XEnd nX YStart YEnd nY ZStart ZEnd nZ
44() () (s) (s) (s) (m) (m) () (m) (m) () (m) (m) ()
45
Appendix B: Prescribed Circulation Input File¶
Check the regression tests for updated versions of this file.
1r/R [], Gamma [m^2/s]
20.048488, 0.000000
30.087326, 0.442312
40.126163, 6.909277
50.165000, 23.678557
60.203837, 55.650700
70.242674, 74.091529
80.281512, 84.205843
90.320349, 88.740429
100.359186, 89.730814
110.398023, 88.568114
120.436860, 87.114743
130.475698, 86.110557
140.514535, 85.705529
150.553372, 85.215829
160.592209, 84.547371
170.631047, 83.774329
180.669884, 82.889157
190.708721, 81.635600
200.747558, 79.788700
210.786395, 77.195200
220.825233, 73.765100
230.864070, 69.275900
240.902907, 62.965400
250.941744, 53.603300
260.980581, 39.854000
Appendix C: OLAF List of Output Channels¶
This is a list of all possible output parameters from the OLAF module. The names are grouped by meaning, but can be ordered in the OUTPUTS section of the AeroDyn15 primary input file, as the user sees fit. \(N\beta\) refers to output node, \(\beta\), where \(\beta\) is a number in the range [1,9], corresponding to entry, \(\beta\), in the OutNd list. \(B\alpha\) is prefixed to each output name, where \(\alpha\) is a number in the range [1,3], corresponding to the blade number.
Channel Name(s) 
Units 
Description 

\(B \alpha N \beta Gam\) 
\(m^2/s\) 
Circulation along the blade 
Aeroacoustics Noise Model of OpenFAST¶
This report describes theory and application of a newly released model of OpenFAST to simulate the aeroacoustics noise generated by the rotor of an arbitrary wind turbine. OpenFAST is a fully opensource, publicly available wind turbine analysis tool actively developed at the National Renewable Energy Laboratory. The aeroacoustics model, which is also fully open source and publicly available, is based on work performed over the past three decades. Frequencybased models for turbulent inflow; turbulent boundary layer – trailing edge; laminar boundary layer – vortex shedding; tip vortex; and trailing edge bluntness – vortex shedding noise mechanisms are included. A simple directivity model is also included.
The noise models are exercised simulating the aeroacoustics noise emissions of the International Energy Agency Wind Task 37 landbased reference wind turbine. A codetocode comparison between the implementation presented here and the implementation available at the Wind Energy Institute of the Technical University of Munich, Germany, is also presented.
The documentation here was derived from NREL Technical Report TP500075731 by P. Bortolotti et al. (https://www.nrel.gov/docs/fy20osti/75731.pdf)
List of Acronyms¶
BPM 
BrooksPopeMarcolini airfoil noise model 
dB 
decibels 
dBA 
Aweighted decibels 
deg 
degrees 
Hz 
hertz 
IEA 
International Energy Agency 
kg 
kilograms 
kHz 
kilohertz 
LFC 
lowfrequency correction 
m 
meters 
N 
newtons 
NREL 
National Renewable Energy Laboratory 
rad 
radians 
s 
seconds 
SPL 
sound pressure level 
TBL 
turbulent boundary layer 
TBLTE 
turbulent boundary layer – trailing edge 
TNO 
a Netherlands organization for applied scientific research 
TE 
trailing edge 
TI 
turbulent inflow 
TUM 
Technical University of Munich 
List of Symbols¶
\({}_{l}\) 
low frequency 

\({}_{h}\) 
high frequency 

\({}_{p}\) 
airfoil pressure side 

\({}_{s}\) 
airfoil suction side 

\({}_{t}\) 
turbulence 

\({}_{0}\) 
reference 

\({}_{1}\) 
parallel to airfoil chord 

\({}_{2}\) 
normal to airfoil chord 

\({}_{3}\) 
blade spanwise direction 

\(\alpha\) 
angle of attack 
[rad] 
\(\beta^{2}\) 
PrandtlGlauert correction factor 
[] 
\(\delta\) 
airfoil boundary layer thickness 
[] 
\(\delta^{*}\) 
airfoil boundary layer displacement thickness 
[] 
\(\theta\) 
airfoil boundary layer momentum thickness 
[] 
\(\Theta_{e},\ \Phi_{e}\) 
angles between emitter and observer 
[rad] 
\(\rho\) 
air density 
[kg/m^{3}] 
\(\omega\) 
radial frequency 
[rad/s] 
\(A_{w}\) 
Aweight 
[dB] 
\(c\) 
speed of sound 
[m/s] 
\(c_{i}\) 
chord at blade spanwise position i 
[m] 
\(d\) 
blade span at station i 
[m] 
\(\overline{D}\) 
directivity function 
[] 
\(f\) 
frequency 
[Hz] 
\(G\) 
empirical function 
[] 
\(h\) 
height of the trailing edge thickness 
[m] 
\(H\) 
airfoil kinematic shape factor 
[] 
\(I\) 
turbulence intensity 
[] 
\(k\) 
wave number 
[m^{1}] 
\(\overline{k},\ \widehat{k}\) 
nondimensional wave number 
[] 
\({\mathrm{\Delta}K_{1},\ K}_{1}\),\(\ K_{2}\) 
empirical parameters of the BPM model 
[] 
\(l\) 
spanwise extent of the separation zone from blade tip 
[m] 
\(L\) 
lift force 
[N] 
\(L_{t}\) 
length scale 
[m] 
\(M\) 
Mach number 
[] 
\(M_{c}\) 
Mach number past the trailing edge 
[] 
\(r_{e}\) 
effective observer distance 
[m] 
\(\text{Re}\) 
Reynolds number 
[] 
\(S^{2}\) 
Sears function 
[] 
\(\text{St}\) 
Strouhal number 
[] 
\(t_{x}\) 
relative thickness of the airfoil at chordwise position x 
[] 
\(U\) 
local inflow velocity 
[m/s] 
\(y\) 
blade spanwise position 
[m] 
\(z\) 
height above the ground 
[m] 
\(z_{0}\) 
ground surface roughness 
[m] 
Introduction¶
The increasing penetration of wind energy into the electricity mix has been possible thanks to a constantly growing installed capacity, which has so far been mostly located on land. Landbased installations are, however, increasingly constrained by local ordinances and an oftenlimiting factor that comprises maximum allowable levels of noise. To further increase the number of landbased installations, it is important to develop accurate modeling tools to estimate the noise generated by wind turbines. This allows for a more accurate assessment of the noise emissions and the possibility to design quieter wind turbines.
Wind turbines emit two main sources of noise:
Aeroacoustics noise from the interaction between rotor blades and the turbulent atmospheric boundary layer
Mechanical noise from the nacelle component, mostly the gearbox, generator, and yaw mechanism.
This work targets the first class of noise generation and aims at providing a set of opensource models to estimate the aeroacoustics noise generated by an arbitrary wind turbine rotor. The models are implemented in Fortran and are fully coupled to the aeroservoelastic wind turbine simulator OpenFAST. The code is available in the GitHub repository of OpenFAST. 1 The code builds on the implementation of NAFNoise and the documentation presented in [aaMM03] and [aaMor05]. OpenFAST is implemented as a modularization framework and the aeroacoustics model is implemented as a submodule of AeroDyn ([aaMH05]).
The set of models is described in Section 4.2.3.4 and exercised on the noise estimate of the International Energy Agency (IEA) landbased reference wind turbine in Section 4.2.3.5. In Section 4.2.3.5, we also show a comparison to results obtained running the noise models implemented at the Technical University of Munich. This documentation closes with conclusions, an outlook on future work, and appendices, where the input files to OpenFAST are presented.
Aeroacoustics Noise Models¶
The aeroacoustics noise of wind turbine rotors emanates from pressure oscillations that are generated along the blades and propagate in the atmosphere. This source of noise has been historically simulated with models characterized by different fidelity levels. At lower fidelity, models correlated aeroacoustics noise with rotor thrust and torque ([aaLow70, aaVit81]). At higher fidelity, threedimensional incompressible computational fluid dynamics models are coupled with the Ffowcs WilliamsHawkings model to propagate pressure oscillations generated along the surface of the rotor blades to the far field ([aaKGW+18]). The latter models are often only suitable to estimate noise at low frequency because capturing noise in the audible range, which is commonly defined between 20 (hertz) Hz and 20 kilohertz (kHz), requires a very fine spacetime discretization with enormous computational costs.
For the audible range, a variety of models is available in the public domain, and [aaSBCB18] offers the most recent literature review. These models have inputs that match the inputs and outputs of modern aeroservoelastic solvers, such as OpenFAST, and have therefore often been coupled together. Further, the computational costs of these acoustic models are similar to the costs of modern aeroservoelastic solvers, which has facilitated the coupling.
Models have targeted different noise generation mechanisms following the distinction defined by [aaBPM89], and the mechanism of turbulent inflow noise. The latter represents a broadband noise source that is generated when a body of arbitrary shape experiences an unsteady lift because of the presence of an incident turbulent flow. For an airfoil, this phenomenon can be interpreted as leadingedge noise. Turbulent inflow noise was the topic of multiple investigations over the past decades and, as a result, multiple models have been published ([aaSBCB18]). The BPM model includes five mechanisms of noise generation for an airfoil immersed in a flow:
Turbulent boundary layer – trailing edge (TBLTE)
Separation stall
Laminar boundary layer – vortex shedding
Tip vortex
Trailingedge bluntness – vortex shedding.
For the five mechanisms, semiempirical models were initially defined for the NACA 0012 airfoil. The BPM model is still a popular model for wind turbine noise prediction, and subsequent studies have improved the model by removing some of the assumptions originally adopted. Recent studies have especially focused on the TBLTE mechanism, which is commonly the dominant noise source of modern wind turbines. As a result, each noise source defined in the BPM model now has a variety of permutations.
The following subsections describe the details of each mechanism and the models implemented in this model of OpenFAST.
Turbulent Inflow¶
A body of any arbitrary shape, when immersed in a turbulent flow, generates surface pressure fluctuations. Over the years, several formulations of the turbulent inflow noise model have been developed ([aaSBCB18]). In this model of OpenFAST, the formulation defined in [aaMGM04] is adopted. The formulation is based on the model of Amiet ([aaAmi75, aaPA76]) and is presented in Section 4.2.3.4.1.1. Additionally, the user can activate the correction defined by [aaMH05], which builds upon the Amiet model and accounts for the thickness of the airfoils adopted along the blade span. This second model is named Simplified Guidati and is presented in Section 4.2.3.4.1.2.
The formulation is based on work from [aaAmi75] and [aaPA76], and it represents the blade as a flat plate and neglects the shape of the airfoil.
The model starts by first computing the wave number, \(k_{1}\), for a given frequency \(f\):
where \(U_{1}\) is the incident inflow velocity on the profile. From \(k_{1}\), the wave numbers \({\overline{k}}_{1}\) and \({\widehat{k}}_{1}\) are computed:
where \(c_{i}\) is the local chord, and \(k_{e}\) is the wave number range of energy containing eddies, defined as:
L_{t} is the turbulent length scale, and many different formulations have been proposed over the years. As default implementation, \(L_{t}\) is defined following the formulation proposed in [aaZHS05]:
where \(z\) is the height above the ground of the leading edge of section \(i\) at a given instant, \(t\), while \(z_{0}\) is the surface roughness. Note that setting \(L_{t}\) appropriately is a challenge, and advanced users of this model may want to validate this formulation against experimental data.
The value of sound pressure level (\(\text{SPL}\)) is expressed in onethird octave bands at the given frequency, \(f\), originated at the given blade station, \(i\), which can be computed as:
where \(\rho\) is the air density, \(c\) the speed of sound, \(d\) the blade element span, \(r_{e}\) the effective distance between leading edge and observer, \(M\) the Mach number, \(I_{1}\) the turbulence intensity of the airfoil inflow, and \(\overline{D}\) the directivity term. \(\overline{D}\) is different below (\({\overline{D}}_{l}\)) and above (\({\overline{D}}_{h}\)) a certain frequency, which is named “cutoff” and defined as:
The formulations of \({\overline{D}}_{h}\ \)and \({\overline{D}}_{l}\) are presented in Section 4.2.3.4.6.
The current implementation offers two approaches to estimate \(I_{1}\). The first one is through a userdefined grid of \(I_{1}\); see Section 4.2.3.7.4. The second option is to have the code reconstructing \(I_{1}\) from the turbulent wind grid, where the code computes the airfoil relative position of each blade section, \(i\), at every time instant and, given the rotor speed, reconstructs the inflow component, \(I_{1}\), of the turbulence intensity.
Two corrections to this model are also implemented. The first one comprises a correction for the angle of attack, \(\alpha\), in which the effect is neglected in the original formulation from [aaAmi75] and Amiet and Peterson (1976). This correction is formulated as:
The second correction is called lowfrequency correction (\(\text{LFC}\)), and is formulated as:
In (4.28) and (4.29), \(S^{2}\) represents the squared Sears function, and \(\beta^{2}\) is the PrandtlGlauert correction factor, which is defined as:
It is worth stressing that numerous alternative formulations of the turbulent inflow noise model exist ([aaSBCB18]), where the main differences comprise different definitions of \(L_{t}\) and \(k_{1}\).
Sound spectra are often overpredicted by the Amiet model implemented here. Guidatai ([aaGBW+97]) derived a correction to the sound pressure levels by adding a term considering shape and camber of the airfoil profiles, but the method proved computationally too expensive for wind turbine simulations. Moriarty et al. ([aaMGM05]) proposed a simplified model based on geometric characteristics of six wind turbine airfoils. The validity of the correction is limited to Mach numbers on the order of 0.1 ≈ 0.2 and Strouhal number \(\text{St}\) below 75. \(\text{St}\) is defined based on airfoil chord and mean inflow velocity:
The formula for the correction to the noise spectra is provided in Eq. 4 in [aaMGM05]:
where \(t_{x\%}\) is the relative thickness of the profile at \(x\) position along the chord (i.e., 0% being the leading edge and 100% the trailing edge).
It should be highlighted here that a validation campaign was conducted in a wind tunnel on twodimensional airfoils ([aaMGM04]), returning a fairly poor match between the Simplified Guidati model and the experimental results. Therefore, a correction of +10 decibels (dB) on the SPL levels across the whole frequency spectrum was proposed. This correction is still implemented, but a validation at turbine level should assess the accuracy of the models for turbulent inflow. It should also be noted that the code currently does not check whether Mach and Strouhal numbers are within the range of validity of this model.
Turbulent Boundary Layer – Trailing Edge¶
Airfoils immersed in a flow develop a boundary layer, which at high Reynolds numbers is turbulent. When the turbulence passes over the trailing edge, noise is generated. This noise source was named TBLTE in [aaBPM89] and it is a relevant source of aeroacoustics noise for modern wind turbine rotors. Two formulations of TBLTE noise are implemented in the code: (1) the original formulation from the BPM model, described in Section 4.2.3.4.1.1, and (2) a more recent model developed at the Dutch research institute, TNO, described in Section 4.2.3.4.1.2. Both models take as input the characteristics of the airfoil boundary layer. These must be provided by the user and are discussed in Section 4.2.3.7.2.
The \(\text{SPL}\) of the TBLTE noise in the BPM model is made from three contributions:
where the subscripts _{p}, _{s}, and _{α} refer to the contributions of pressure side, suction side, and angle of attack, respectively. The equations describing the three contributions are described in great detail in Section 5.1.2, in [aaBPM89], and are summarized here.
For the suction and pressure contributions, the equations are:
The terms in the equations, which are also described in the nomenclature at the beginning of this document, list \(\delta^{*}\) as the boundary layer displacement thickness on either side of the airfoil, \(St,\) as the Strouhal number based on \(\delta^{*}\), and \(A\), \(A'\), \(B\), \({\Delta K}_{1}\), \(K_{1}\), and \(K_{2}\) as empirical functions based on \(\text{St}\).
For the angleofattack contribution, a distinction is made above and below the stall angle, which in the original BPM model is set equal to 12.5 degrees, whereas it is here assumed to be the actual stall angle of attack of the airfoil at blade station i. Below stall, \(\text{SPL}_{\alpha}\) is equal to:
At angles of attack above the stall point, the flow along the profile is fully separated and noise radiates from the whole chord.\(\ \text{SPL}_{p}\) and \(\text{SPL}_{s}\) are then set equal to ∞, whereas \(\text{SPL}_{\alpha}\) becomes:
Notably, above stall the lowfrequency directivity \({\overline{D}}_{l}\) is adopted in Eqs. 18 and 19 (see Section 4.2.3.4.6).
The TNO model is a more recent model to simulate the noise emitted by the vortices shed at the trailing edge of the blades and was formulated by Parchen ([aaPar98]). The implementation adopted here is the one described in Moriarty et al. (2005). The TNO model uses the spectrum of the wave number, \(\overline{k}\), of unsteady surface pressures to estimate the farfield noise. The spectrum, \(P\), is assumed to be:
In the equation, the indices 1, 2, and 3 refer to the directions parallel to the airfoil chord, normal to the airfoil chord, and along span, respectively; \(\phi_{22}\) is the vertical velocity fluctuation spectrum; \(\phi_{m}\) is the moving axis spectrum; and \(U_{c}\) is the convection velocity of the eddies along the trailing edge. Lastly, \(L_{2}\) is the vertical correlation length, perpendicular to the chord length, which indicates the vertical extension of the vortices that convect over the trailing edge. In this work, \(L_{2}\) is assumed equal to the mixing length, \(L_{m}\) (Moriarty et al. 2005). This decision is partially arbitrary, and dedicated research should better assess the correct integral length to be adopted within the TNO model.
From \(P\), the farfield spectrum, \(S\left( \omega \right)\), is computed as:
The implementation of the TNO model is identical to the one described in [aaMGM05]. The inputs to the model are generated from the boundary layer characteristics provided by the user (see Section 4.2.3.7.2).
Laminar Boundary Layer – Vortex Shedding¶
Another source of airfoil selfnoise noise included in the BPM model is the noise generated by a feedback loop between vortices being shed at the trailing edge and instability waves in the laminar boundary layer. This noise is typically distributed on a narrow band of frequencies and occurs when the boundary layer of the airfoil remains laminar. This may occur in the inboard region of smaller wind turbines, where the Reynolds number can be smaller than 1 million, but hardly occurs in modern rotors that operate at a Reynolds number one order of magnitude larger. The formula to estimate the noise spectrum in a onethirdoctave presentation is:
where \(G\) represents empirical functions, \({St'}_{\text{peak}}\) is the peak Strouhal number function of \(\text{Re}_{c}\), which is the Reynolds number at chord, \(c_{i}\). The subscript _{0} refers to a reference Reynolds number that is a function of the angle of attack (Brooks et al. 1989).
Tip Vortex¶
The vortices generated at blade tips are another source of noise of the BPM model. Although rarely relevant in modern wind turbines, the possibility to include this noise source is offered. The sound pressure level is estimated as:
where \(M_{\max}\ = \ M_{\max}\left( \alpha_{\text{tip}} \right)\) is the maximum Mach number, measured near the blade tip within the separated flow region that is assumed to depend on \(\alpha_{\text{tip}}\), which is the angle of attack at the tip; \(l\) is the spanwise extent of the separation zone; and \(St'''\) is the Strouhal number based on \(l\). For a round shape of the tip, \(l\) is estimated as:
where \(\alpha_{\text{tip}}\) is the angle of attack of the tip region to the incoming flow. For a square tip, the BPM model estimates \(l\) based on the quantity, \({\alpha'}_{\text{tip}}\), which is defined as:
where \(L'\) is the lift per unit span along the blade at position \(y\). For \({\alpha'}_{\text{tip}}\) between 0 and 2 degrees, \(l\) becomes:
while for \({\alpha'}_{\text{tip}}\) larger than 2 degrees, \(l\) is:
However, it must be noted that, unfortunately, \(\alpha_{\text{tip}}\) is not a reliable output of standard aeroelastic models and the impossibility to accurately determine \(\alpha_{\text{tip}}\) weakens the formulation of the tip vortex noise.
TrailingEdge Bluntness – Vortex Shedding¶
Lastly, wind turbine blades are often characterized by a finite height of the trailing edge, which generates noise as a result of vortex shedding. The frequency and amplitude of this noise source depends on the geometry of the trailing edge and is typically characterized by a tonal nature. Adopting flatback and truncated airfoils far outboard along the blade may strengthen this noise source. When this noise source is activated, the user is asked to provide the distribution along the blade span of the blunt thickness of the trailing edge, \(h\), and the solid angle between the suction and pressure sides of the airfoil, \(\Psi\) (see Section 4.2.3.4.2). \(h\) and \(\Psi\) are inputs to the equation:
In the equation, \(\delta_{\text{avg}}^{*}\) is the average displacement thickness for both sides of the airfoil. Note that this noise source is very sensitive to \(h\) and \(\Psi\), which, therefore, should be estimated accurately.
Directivity¶
The position of one or more observers is specified by the user, as described in Section 4.2.3.7.3. The directivity from the BPM model is adopted in this implementation ([aaBPM89]). The directivity term, \(\overline{D}\), corrects the \(\text{SPL}\) depending on the relative position of the observer to the emitter. The position is described by the spanwise directivity angle, \(\Phi_{e}\), and by the chordwise directivity angle, \(\Theta_{e}\), which are schematically represented in Fig. 4.13 and defined as:
The reference axis is located at each blade node and \(x_{e}\) is aligned with the chord, \(y_{e}\) is aligned with the span pointing to the blade tip, and \(z_{e}\) is aligned toward the airfoil suction side. Note that in OpenFAST the local airfoiloriented reference system is used, and a rotation is applied.
Given the angles \(\Theta_{e}\) and \(\Phi_{e}\), at high frequency, \(\overline{D}\) for the trailing edge takes the expression:
where \(M_{c}\) represents the Mach number past the trailing edge and that is here for simplicity assumed equal to 80% of freestream M.
For the leading edge, and therefore for the turbulent inflow noise model, at high frequency, \(\overline{D}\) is:
Note that this equation was not reported in the NREL Tech Report NREL/TP500075731!
At low frequency, the equation is identical for both leading and trailing edges:
Each model distinguishes a different value between low and high frequency. For the TI noise model, the shift between low and high frequency is defined based on \({\overline{k}}_{1}\). For the TBLTE noise, the model differences instead shift between below and above stall, where\(\ {\overline{D}}_{h}\)and \({\overline{D}}_{l}\) are used, respectively.
AWeighting¶
The code offers the possibility to weigh the aeroacoustics outputs by Aweighting, which is an experimental coefficient that aims to take into account the sensitivity of human hearing to different frequencies. The Aweight, \(A_{w}\), is computed as:
The Aweighting is a function of frequency and is added to the values of sound pressure levels:
Model Verification¶
Reference Wind Turbine¶
The noise model of OpenFAST is exercised by simulating the aeroacoustics noise emissions of the IEA Wind Task 37 landbased reference wind turbine ([aaBTD+19]). The main characteristics of the reference wind turbine are presented in Table 4.2.
Data 
Value 
Data 
Value 

Wind class 
International
Electrotechnical
Commision 3A

Rated
electrical
power

3.37 megawatts 
Rated
aerodynamic
power

3.6 megawatts 
Drivetrain &
generator
efficiency

93.60% 
Rotor diameter 
130 meters 
Hub height 
110 meters 
Cutin wind speed 
4 meters/second 
Cutout wind speed 
25 meters/second 
Rotor cone angle 
3 degrees 
Nacelle tilt angle 
5 degrees 
Max blade tip speed 
80 meters/second 
Rated
tipspeed
ratio

8.16 
Maximum
aerodynamic Cp

0.481 
Rated rotor speed 
11.75
revolutions per
minute

The OpenFAST model of the wind turbine is available at https://github.com/OpenFAST/rtest and is optionally coupled to the Reference OpenSource Controller. 2
CodetoCode Comparison¶
A detailed codetocode comparison was conducted to verify the implementation of the noise models linked to OpenFAST with the implementation available at the Wind Energy Institute of the Technical University of Munich, Germany. The latter is described in Sucameli ([aaSBCB18]) and is implemented in the wind turbine design framework CpMax, which adopts the multibodybased aeroservoelastic solver CpLambda.
The comparison is conducted for the main noise sources—turbulent inflow and the TBLTE noise—for both the single airfoil profile and full turbine. This helped resolve a few implementation mistakes and small inconsistencies. The comparison is performed with a steady wind of 8 meters per second (m/s), no shear, a rated pitch angle of 1.17 degrees (deg), and a fixed rotor speed of 10.04 revolutions per minute (rpm). A fixed value of 0.1 is assumed for the incident turbulent intensity, \(I_{1}\).
Fig. 4.14 shows the predictions in terms of SPL for the Amiet model with the angleofattack correction from OpenFAST, the Simplified Guidati model generated by OpenFAST, and the Amiet model from CpMax.
The two implementations of the turbulent inflow Amiet model return a perfect match between OpenFAST and CpMax. The chosen scenario sees the blade operating at optimal angles of attack and, therefore, the effect of the angle of attack correction is negligible. The plots also show the great difference between the Amiet model and the Simplified Guidati model. It may be useful to keep in mind that the Simplified Guidati model has, in the past, been corrected with a factor of +10 dB, which is applied here.
For the same inflow and rotor conditions, the BPM and TNO TBLTE noise models are compared in Fig. 4.15. The match is again satisfactory, although slightly larger differences emerge that are attributed to differences in the angles of attack between the two aeroelastic solvers and in different integration schemes in the TNO formulations.
The last comparison looked at the directivity models and the overall sound pressure levels at various observer locations. Simulations are run distributing 200 observers in a horizontal square of 500 meters (m) by 500 m (see Fig. 4.16). The noise is computed from the Amiet and the BPM turbulent boundary layertrailing edge models. The codetocode comparison returns similar predictions between OpenFAST and CpMax. The comparison is shown in Fig. 4.17.
The main conclusion of this codetocode comparison is that, to the best of authors’ knowledge, the models are now implemented correctly and generate similar SPL and overall SPL levels for any arbitrary observer. Nonetheless, it is clear that all of the presented models are imperfect, and improvements could be made both at the theoretical implementation levels.
Model Usage¶
The aeroacoustics model of OpenFAST has four options for the outputs:
Overall sound pressure level (dB/Aweighted decibels [dBA])—one value per time step per observer is generated
Total sound pressure level spectra (dB/dBA)—one spectrum per time step per observer is generated between 10 Hz and 20 kHz
Mechanismdependent sound pressure level spectra (dB/dBA)—one spectrum per active noise mechanism per time step per observer is generated between 10 Hz and 20 kHz.
Overall sound pressure level (dB/Aweighted decibels [dBA])—one value per blade per node per time step per observer is generated
The overall SPL from the first option can be used to plot directivity maps of the noise. An example, which was generated using a Python script, 3 is shown in Fig. 4.18. The noise map, which shows the overall SPL averaged over 1 rotor revolution, is generated for a steady wind speed of 8 m/s, a fixed rotor speed of 10.04 rpm, and a 1.17deg pitch angle. In a horizontal circle of 500 m in diameter, 1681 observers are placed at a 2m height. Only the Simplified Guidati and the BPM TBLTE noise models are activated.
The second output can be used to generate SPL spectra. These spectra can be computed for various observers and optionally Aweighted to account for human hearing. Fig. 4.19 shows the total SPL spectra computed for the same rotor conditions of the previous example. The Aweight greatly reduces the curve at frequency below 1,000 Hz while slightly increasing those between 1 kHz and 8 kHz.
The third output distinguishes the SPL spectrum per mechanism. Fig. 4.20 shows the various SPL spectra estimated by each noise model for the same rotor conditions reported earlier. The total spectrum is visibly dominated by the turbulent inflow, TBLTE, and trailingedge bluntness noise mechanisms. Notably, the latter is extremely sensitive to its inputs, \(\Psi\) and \(h\). The reference wind turbine is a purely numerical model, and these quantities have been arbitrarily set. Users should pay attention to these inputs when calling the trailingedge bluntness model. Consistent with literature, the laminar boundary layervortex shedding and tip vortex noise mechanisms have negative dB values and are, therefore, not visible. Notably, these spectra are not Aweighted, but users can activate the flag and obtain Aweighted spectra.
Finally, the fourth output can be used to visualize the noise emission across the rotor. Fig. 4.21 shows the noise generation of the rotor as seen from an observer located 175 meters downwind at a height of 2 meters. The map is generated by plotting the overall SPL generated by one blade during one rotor revolution. The plot shows that higher noise is observed when the blade is descending (the rotor from behind is seen rotating counterclockwise). This effect, which matches the results shown in [aaMM03], is explained by the asymmetry of (4.50). Noise is indeed higher when the observer faces the leading edge of an airfoil (high \(\Theta_e\)), than when it faces the trailing edge (low \(\Theta_e\)).
Conclusions¶
This document describes a set of frequencybased aeroacoustics models coupled to the opensource aeroservoelastic solver OpenFAST. The goal of these models is to predict the aeroacoustics emissions of wind turbine rotors. The document shows a codetocode comparison between the models coupled to OpenFAST and the models implemented at the Technical University of Munich and coupled to the aeroservoelastic solver CpLambda. The comparison is performed simulating the aeroacoustics emissions of the IEA Wind Task 37 landbased reference wind turbine. The results show a good agreement between the two implementations. The same turbine model is later used to exercise the aeroacoustics model showcasing its capabilities. Finally, the appendices describe the entries of the input files of OpenFAST to run the aeroacoustics analysis.
Future work will focus on the validation of the aeroacoustics models. In parallel, propagation models will be investigated and implemented. Finally, attention will be dedicated to infrasound noise and to the timedomain models that can simulate it.
Using the Aeroacoustics Model in AeroDyn¶
A live version of this documentation is available at https://openfast.readthedocs.io/. To run the aeroacoustics model, the flag CompAA needs to be set to True at line 13 of the AeroDyn15 main input file in the inputs block General Options. When the flag is set to True, the following line must include the name of the file containing the inputs to the aeroacoustics model, which is discussed in Section 4.2.3.7.2.
1 AERODYN INPUT FILE 
2IEA Wind Task 37 landbased reference wind turbine
3====== General Options ===================================================
4False Echo  Echo the input to "<rootname>.AD.ech"? (flag)
5"default" DT_AA  Time interval for aerodynamic calculations {or "default"} (s)
61 WakeMod  Type of wake/induction model (switch) {0=none, 1=BEMT}
72 AFAeroMod  Type of blade airfoil aerodynamics model (switch
80 TwrPotent  Type of tower influence on wind around the tower (switch)
90 TwrShadow  Type of tower influence on wind based on downstream tower shadow (switch) {0=none, 1=Powles model, 2=Eames model}
10False TwrAero  Calculate tower aerodynamic loads? (flag)
11False FrozenWake  Assume frozen wake during linearization? (flag
12False CavitCheck  Perform cavitation check? (flag)
13True CompAA  Flag to compute AeroAcoustics calculation
14"AeroAcousticsInput.dat" AA_InputFile
15====== Environmental Conditions ==========================================
161.225. AirDens  Air density (kg/m^3)
17
18File continues...
Main Input File¶
The aeroacoustics main input file comprises a series of inputs and flags that should be set appropriately depending on the analysis that should be run. These are split into the subfields General Options, Aeroacoustics Models, Observer Input, and Outputs.
Starting from the General Options, these are:
Echo – True/False: option to rewrite the input file with the correct template
DT_AA – Float: time step of the aeroacoustics computations. Only multiples of the time step DTAero of AeroDyn can be used. If set to default, the time step DTAero is adopted.
AAStart – Float: time after which the AeroAcoustics module is run.
BldPrcnt – Float: percentage value of blade span measured from blade tip that contributes to the noise emissions; 100% corresponds to the entire blade from tip to root.
The field Aeroacoustics Models lists all the flags for the actual noise models:
TIMod – Integer 0/1/2: flag to set the turbulent inflow noise model; 0 turns it off, 1 corresponds to the Amiet model discussed in Section 4.2.3.4.1.1, and 2 corresponds to the Simplified Guidati model presented in Section 4.2.3.4.1.2.
TICalcMeth – Integer 1/2: flag to set the calculation method for the incident turbulence intensity. When set to 1, incident turbulence intensity is defined in a userdefined grid; see Section 4.2.3.7.4. When set to 2, incident turbulence intensity is estimated from the time history of the incident flow.
TICalcTabFile – String: name of the text file with the userdefined turbulence intensity grid; see Section 4.2.3.7.4.
Lturb – Float: value of \(L_{turb}\) used to estimate the turbulent lengthscale used in the Amiet model.
TBLTEMod – Integer 0/1/2: flag to set the TBLTE noise model; 0 turns off the model, 1 uses the BrooksPopeMarcolini (BPM) airfoil noise model (see Section 4.2.3.4.2.1), and 2 uses the TNO model described in Section 4.2.3.4.2.2.
BLMod – Integer 1/2: flag to set the calculation method for the boundary layer characteristics; 1 uses the simplified equations from the BPM model, 2 loads the files as described in Section 4.2.3.7.2. Only used if TBLTEMod is different than zero.
TripMod – Integer 0/1/2: if BLMod is set to 1, different semiempirical parameters are used for a nontripped boundary layer (TRipMod=0), heavily tripped boundary layer (TRipMod=1), or lightly tripped boundary layer (TRipMod=2); 2 is typically used for operational wind turbines, whereas 1 is often used for wind tunnel airfoil models.
LamMod – Integer 0/1: flag to activate the laminar boundary layer – vortex shedding model, presented in Section 4.2.3.4.3.
TipMod – Integer 0/1: flag to activate the tip vortex model, presented in Section 4.2.3.4.4.
RoundedTip – True/False: if TipMod=1, this flag switches between a round tip (True) and a square tip (False), see Section 4.2.3.4.4.
Alprat – Float: value of the slope of the lift coefficient curve at blade tip; see Section 4.2.3.4.4.
BluntMod – Integer 0/1: flag to activate (BluntMod=1) the trailingedge bluntness – vortex shedding model, see Section 4.2.3.4.5. If the flag is set to 1, the trailingedge geometry must be specified in the files as described in Section 4.2.3.7.2.
The field Observer Locations contains the path to the file where the number of observers (NrObsLoc) and the respective locations are specified; see Section 4.2.3.7.3.
Finally, the set Outputs contains a few options for the output data:
AWeighting – True/False: flag to set whether the sound pressure levels are reported with (True) or without (False) the Aweighting correction; see Section 4.2.3.5.3.
NAAOutFile – Integer 1/2/3: flag to set the desired output file. When set to 1, a value of overall sound pressure level at every DT_AA time step per observer is printed to file. When set to 2, the first output is accompanied by a second file where the total sound pressure level spectrum is printed per time step per observer. When set to 3, the two first outputs are accompanied by a third file where the sound pressure level spectrum per noise mechanism is printed per time step per observer. When set to 4, a fourth file is generated with the values of overall sound pressure levels per node, per blade, per observer, and per time step.
The following line contains the file name used to store the outputs. The file name is attached with a 1, 2, 3, and 4 flag based on the NAAOutFile options.
The file must be closed by an END command.
1 AeroAcoustics Module INPUT FILE 
2IEA task 37 RWT turbine  https://github.com/IEAWindTask37/IEA3.4130RWT
3====== General Options ============================================================================
4False Echo  Echo the input to "<rootname>.AD.NN.ech"? (flag)
50.1 DT_AA  Time interval for aeroacoustics calculations (s), must be a multiple of DT_Aero from AeroDyn15 (or "default")
60 AAStart  Time after which the AeroAcoustics module is run (s)
770 BldPrcnt  Percentage of the blade span, starting from the tip, that will contribute to the overall noise levels. (float)
8====== Aeroacoustic Models ============================================================================
92 TIMod  Turbulent Inflow noise model {0: none, 1: Amiet 2: Amiet + Simplified Guidati} (switch)
101 TICalcMeth  Method to estimate turbulence intensity incident to the profile {1: given table, 2: computed on the fly} (switch) [Only used if TIMod!=0]
11"TIGrid_InVerify.txt" TICalcTabFile  Name of the file containing the table for incident turbulence intensity () [Only used if TiCalcMeth == 1]
120.5 SurfRoughness Surface roughness value used to estimate the turbulent length scale in Amiet model (m)
131 TBLTEMod  Turbulent Boundary LayerTrailing Edge noise calculation {0: none, 1:BPM, 2: TNO} (switch)
141 BLMod  Calculation method for boundary layer properties, {1: BPM, 2: Pretabulated} (switch)
151 TripMod  Boundary layer trip model {0:no trip, 1: heavy trip, 2: light trip} (switch) [Only used if BLMod=1]
160 LamMod  Laminar boundary layer noise model {0:none, 1: BPM} (switch)
170 TipMod  Tip vortex noise model {0:none, 1: BPM} (switch)
18True RoundedTip  Logical indicating rounded tip (flag) [Only used if TipMod=1]
191.0 Alprat  Tip lift curve slope (Default = 1.0) [Only used if TipMod=1]
200 BluntMod  Trailingedgebluntness – Vortexshedding model {0:none, 1: BPM} (switch)
21"AABlade1.dat" AABlFile(1)  Name of file containing distributed aerodynamic properties for Blade #1 ()
22"AABlade1.dat" AABlFile(2)  Name of file containing distributed aerodynamic properties for Blade #2 ()
23"AABlade1.dat" AABlFile(3)  Name of file containing distributed aerodynamic properties for Blade #3 ()
24====== Observer Input ===================================================================
25"AA_ObserverLocations.dat" ObserverLocations  Name of file containing all observer locations X Y Z ()
26====== Outputs ====================================================================================
27False AWeighting  Aweighting Flag (flag)
283 NrOutFile  Number of Output files. 1 for Time Dependent Overall SPL, 2 for both 1 and Frequency and Time Dependent SPL as well, or 3 for both 1 and 2 and Acoustics mechanism dependent, 4 for 13 and the overall sound pressure levels per blade per node per observer
29"IEA_LB_RWTAeroAcoustics_" AAOutFile  No Extension needed the resulting file will have .out Name of file containing
30END of input file (the word "END" must appear in the first 3 columns of this last OutList line)
31
Boundary Layer Inputs and Trailing Edge Geometry¶
When the flag BLMod is set equal to 2, pretabulated properties of the boundary layer must be provided and are used by the turbulent boundary layer – trailingedge noise models. The file name is to be specified in the field BL_file among the inputs of the file with the airfoil polar coefficients. One airfoil file must be specified per aerodynamic station.
1!  AirfoilInfo Input File 
2! AeroElasticSE FAST driver
3!
4!
5! 
6DEFAULT InterpOrd ! Interpolation order to use for quasisteady table lookup {1=linear; 3=cubic spline; "default"} [default=1]
71 NonDimArea ! The nondimensional area of the airfoil (area/chord^2) (set to 1.0 if unsure or unneeded)
8@"AF20_Coords.txt" NumCoords ! The number of coordinates in the airfoil shape file. Set to zero if coordinates not included.
9AF20_BL.txt BL_file ! The file name including the boundary layer characteristics of the profile. Optional and ignored if the aeroacoustic module is not called.
101 NumTabs ! Number of airfoil tables in this file. Each table must have lines for Re and Ctrl.
11! 
12! data for table 1
The file, in this example named AF20_BL.txt, contains 8 inputs, which are tabulated for a given number of Reynolds numbers, ReListBL, and a given number of angles of attack, aoaListBL. The inputs, which are defined nondimensionally and must be provided for the suction and pressure side of the airfoil above and below the trailing edge, are:
Ue_Vinf – flow velocity at the top of the boundary layer
Dstar – \(\delta^{*}\), boundary layer displacement thickness
Delta – \(\delta\), nominal boundary layer thickness
Cf – friction coefficient.
In the following example, the file was generated thanks to a Python script 4 that runs the boundary layer solver, XFoil. Notably, XFoil, by default, does not return \(\delta\), but the boundary layer momentum thickness, \(\theta\). \(\delta\) can be reconstructed using the expression from [aaDG87]:
where \(H\) is the kinematic shape factor, which is also among the standard outputs of XFoil. Because it is usually impossible to obtain these values for the whole ranges of Reynolds numbers and angles of attack, the code is set to adopt the last available values and print to screen a warning.
When the flag BluntMod is set to 1, the detailed geometry of the trailing edge must also be defined along the span. Two inputs must be provided, namely the angle, \(\Psi\) between the suction and pressure sides of the profile, right before the trailingedge point, and the height, \(h\), of the trailing edge. \(\Psi\) must be defined in degrees, while \(h\) is in meters. Note that the BPM trailingedge bluntness model is very sensitive to these two parameters, which, however, are often not easy to determine for real blades. Fig. 4.22 shows the two inputs.
One value of \(\Psi\) and one value of \(h\) per file must be defined. These values are not used if the flag BluntMod is set to 0.
1! Boundary layer characteristics at the trailing edge for the airfoil coordinates of /Users/pbortolo/work/2_openfast/noise/verifyAA/OpenFAST_IEA_LB_RWT/Airfoils/AF20_Coords.txt
2! Legend: aoa  angle of attack (deg), Re  Reynolds number (, millions), PS  pressure side, SS  suction side, Ue_Vinf  edge velocity (), Dstar  displacement thickness (), Delta  nominal boundary layer thickness () Cf  friction coefficient ()
34 ReListBL  Number of Reynolds numbers (it corresponds to the number of tables)
430 aoaListBL  Number of angles of attack (it corresponds to the number of rows in each table)
50.50  Re
6aoa Ue_Vinf_SS Ue_Vinf_PS Dstar_SS Dstar_PS Delta_SS Delta_PS Cf_SS Cf_PS
7(deg) () () () () () () () ()
85.00000 8.39390e01 8.37360e01 7.43700e03 1.07730e02 2.75094e02 5.15849e02 1.13200e03 1.58200e03
93.96552 8.42050e01 8.40230e01 8.26600e03 9.29500e03 2.98650e02 4.87153e02 1.04400e03 1.85700e03
102.93103 8.45320e01 8.43690e01 9.08800e03 8.10000e03 3.19790e02 4.70045e02 9.58000e04 2.16500e03
111.89655 8.48230e01 8.46710e01 9.97400e03 7.33700e03 3.44024e02 4.50456e02 8.90000e04 2.35800e03
120.86207 8.51550e01 8.50140e01 1.09130e02 6.54100e03 3.68822e02 4.30884e02 8.26000e04 2.59900e03
13 0.17241 8.55000e01 8.53670e01 1.18900e02 5.92900e03 3.96199e02 4.27416e02 7.79000e04 2.87100e03
14 1.20690 8.63820e01 1.04207e+00 1.22130e02 9.89500e03 4.18890e02 1.68156e02 8.18000e04 1.77000e04
15 2.24138 8.61500e01 8.60210e01 1.40420e02 4.88700e03 4.51813e02 3.93105e02 6.78000e04 3.28700e03
16 3.27586 8.64430e01 8.63080e01 1.52900e02 4.57300e03 4.85938e02 3.82233e02 6.39000e04 3.44000e03
17 4.31034 8.67960e01 8.66600e01 1.65660e02 4.09100e03 5.17768e02 3.63749e02 5.96000e04 3.69000e03
18 5.34483 8.72300e01 8.70850e01 1.81000e02 3.81700e03 5.43379e02 3.52278e02 5.09000e04 3.86300e03
19 6.37931 8.77930e01 8.76410e01 1.98500e02 3.39700e03 5.69109e02 3.31481e02 4.18000e04 4.13900e03
20 7.41379 8.86840e01 8.85140e01 2.22250e02 3.15000e03 5.81316e02 3.19040e02 2.64000e04 4.36900e03
21 8.44828 9.00620e01 8.98660e01 2.54290e02 2.75900e03 5.91946e02 2.95298e02 1.01000e04 4.76300e03
22 9.48276 9.20300e01 9.17700e01 2.99830e02 2.48300e03 6.07767e02 2.75551e02 5.00000e06 5.16000e03
2310.51724 9.48080e01 9.44440e01 3.80160e02 2.13200e03 6.65531e02 2.48447e02 1.60000e05 5.76800e03
2411.55172 9.89560e01 9.84930e01 5.83630e02 1.85700e03 8.76076e02 2.18890e02 1.50000e05 6.49000e03
2512.58621 1.02883e+00 1.02353e+00 8.80990e02 1.66700e03 1.21588e01 2.00072e02 1.30000e05 7.20200e03
2613.62069 1.05789e+00 1.05226e+00 1.18914e01 1.51000e03 1.57264e01 1.78004e02 1.10000e05 7.74800e03
2714.65517 1.07975e+00 1.07394e+00 1.48726e01 1.41900e03 1.91423e01 1.65710e02 1.00000e05 8.15600e03
2815.68966 1.09657e+00 1.09067e+00 1.76430e01 1.34400e03 2.22657e01 1.56180e02 9.00000e06 8.50600e03
2916.72414 1.11040e+00 1.10441e+00 2.02883e01 1.26100e03 2.52158e01 1.43276e02 9.00000e06 8.80900e03
3017.75862 1.12290e+00 1.11682e+00 2.29606e01 1.20600e03 2.81695e01 1.35432e02 8.00000e06 9.07600e03
3118.79310 1.13461e+00 1.12844e+00 2.55478e01 1.15500e03 3.10143e01 1.28744e02 8.00000e06 9.34700e03
3219.82759 1.14605e+00 1.13974e+00 2.80923e01 1.08200e03 3.37970e01 1.16844e02 8.00000e06 9.61200e03
3320.86207 1.15722e+00 1.15073e+00 3.05117e01 1.03800e03 3.64240e01 1.10866e02 7.00000e06 9.87000e03
3421.89655 1.16808e+00 1.16138e+00 3.27770e01 9.81000e04 3.88826e01 1.02373e02 7.00000e06 1.01370e02
3522.93103 1.17845e+00 1.17148e+00 3.48909e01 9.33000e04 4.11299e01 9.52780e03 7.00000e06 1.03870e02
3623.96552 1.18930e+00 1.18205e+00 3.70277e01 8.93000e04 4.34300e01 9.01762e03 7.00000e06 1.06550e02
3725.00000 1.19987e+00 1.19227e+00 3.90503e01 8.36000e04 4.55921e01 8.12755e03 7.00000e06 1.09080e02
381.00  Re
39aoa Ue_Vinf_SS Ue_Vinf_PS Dstar_SS Dstar_PS Delta_SS Delta_PS Cf_SS Cf_PS
40(deg) () () () () () () () ()
415.00000 8.34300e01 8.32480e01 6.49600e03 7.74600e03 2.28566e02 3.97467e02 8.39000e04 1.54900e03
423.96552 8.37330e01 8.35790e01 7.10100e03 6.55800e03 2.45059e02 3.67266e02 7.84000e04 1.80000e03
432.93103 8.40670e01 8.39370e01 7.75600e03 5.65600e03 2.62162e02 3.42658e02 7.27000e04 2.03700e03
441.89655 8.44170e01 8.43070e01 8.45300e03 4.96000e03 2.79616e02 3.22259e02 6.72000e04 2.25700e03
450.86207 8.47840e01 8.46890e01 9.21600e03 4.45100e03 2.98142e02 3.07238e02 6.18000e04 2.45400e03
46 0.17241 8.51730e01 8.50900e01 1.00790e02 3.95100e03 3.18738e02 2.89503e02 5.65000e04 2.66300e03
47 1.20690 8.55470e01 8.54730e01 1.09340e02 3.54400e03 3.37289e02 2.74209e02 5.12000e04 2.86100e03
48 2.24138 8.59040e01 8.58320e01 1.18130e02 3.25200e03 3.55603e02 2.64490e02 4.62000e04 3.03800e03
49 3.27586 8.63480e01 8.62770e01 1.29500e02 2.91700e03 3.78947e02 2.47691e02 4.08000e04 3.23200e03
50 4.31034 8.67590e01 8.66830e01 1.40320e02 2.69800e03 3.97441e02 2.39342e02 3.50000e04 3.40400e03
51 5.34483 8.72380e01 8.71540e01 1.53110e02 2.43000e03 4.18407e02 2.22446e02 2.92000e04 3.59200e03
52 6.37931 8.78360e01 8.77360e01 1.68420e02 2.23600e03 4.38267e02 2.12352e02 2.20000e04 3.78300e03
53 7.41379 8.86030e01 8.84810e01 1.87390e02 2.00100e03 4.60113e02 1.94428e02 1.44000e04 4.00100e03
54 8.44828 8.96310e01 8.94850e01 2.13480e02 1.83100e03 4.88127e02 1.83696e02 5.90000e05 4.24200e03
55 9.48276 9.25990e01 9.23230e01 2.81520e02 1.56900e03 5.51012e02 1.62260e02 1.00000e06 4.73700e03
5610.51724 9.66170e01 9.62320e01 4.28900e02 1.36700e03 7.03103e02 1.45187e02 9.00000e06 5.34800e03
5711.55172 1.00255e+00 9.97860e01 6.33540e02 1.21700e03 9.26255e02 1.29836e02 7.00000e06 5.90200e03
5812.58621 1.03100e+00 1.02578e+00 8.62500e02 1.10600e03 1.18923e01 1.16999e02 6.00000e06 6.34900e03
5913.62069 1.05406e+00 1.04857e+00 1.10634e01 1.04100e03 1.47132e01 1.09721e02 6.00000e06 6.70700e03
6014.65517 1.07334e+00 1.06769e+00 1.35720e01 9.66000e04 1.76016e01 9.96935e03 5.00000e06 7.01900e03
6115.68966 1.08881e+00 1.08308e+00 1.60129e01 9.17000e04 2.03832e01 9.33244e03 5.00000e06 7.27400e03
6216.72414 1.10158e+00 1.09579e+00 1.83765e01 8.82000e04 2.30423e01 8.89329e03 5.00000e06 7.49000e03
6317.75862 1.11342e+00 1.10758e+00 2.08205e01 8.32000e04 2.57695e01 8.20477e03 4.00000e06 7.69800e03
6418.79310 1.12407e+00 1.11817e+00 2.32504e01 8.01000e04 2.84583e01 7.81234e03 4.00000e06 7.88600e03
6519.82759 1.13501e+00 1.12904e+00 2.57953e01 7.76000e04 3.12682e01 7.52201e03 4.00000e06 8.07500e03
6620.86207 1.14614e+00 1.14008e+00 2.83630e01 7.33000e04 3.41005e01 6.90325e03 4.00000e06 8.27100e03
6721.89655 1.15868e+00 1.15248e+00 3.10888e01 7.07000e04 3.71055e01 6.60979e03 4.00000e06 8.48600e03
6822.93103 1.17050e+00 1.16410e+00 3.35623e01 6.81000e04 3.98279e01 6.28286e03 3.00000e06 8.69100e03
6923.96552 1.18348e+00 1.17683e+00 3.61314e01 6.45000e04 4.26528e01 5.81057e03 3.00000e06 8.91700e03
7025.00000 1.19753e+00 1.19058e+00 3.87323e01 6.21000e04 4.54991e01 5.52432e03 3.00000e06 9.15800e03
715.00  Re
72aoa Ue_Vinf_SS Ue_Vinf_PS Dstar_SS Dstar_PS Delta_SS Delta_PS Cf_SS Cf_PS
73(deg) () () () () () () () ()
745.00000 8.23420e01 8.21880e01 4.67200e03 4.76700e03 1.77334e02 2.96859e02 6.92000e04 1.41000e03
753.96552 8.25550e01 8.24400e01 5.04400e03 4.14000e03 1.88321e02 2.75480e02 6.57000e04 1.55000e03
762.93103 8.27930e01 8.27220e01 5.46200e03 3.53900e03 2.00407e02 2.52464e02 6.21000e04 1.70500e03
771.89655 8.30490e01 8.30120e01 5.91700e03 3.10400e03 2.13254e02 2.34284e02 5.86000e04 1.84000e03
780.86207 8.33100e01 8.33000e01 6.40000e03 2.77600e03 2.26264e02 2.19701e02 5.50000e04 1.95800e03
79 0.17241 8.35520e01 8.35690e01 6.86100e03 2.45300e03 2.37731e02 2.03359e02 5.15000e04 2.08300e03
80 1.20690 8.38270e01 8.38660e01 7.40600e03 2.17500e03 2.51176e02 1.87906e02 4.79000e04 2.20700e03
81 2.24138 8.41350e01 8.41880e01 8.04900e03 1.95800e03 2.66635e02 1.75032e02 4.40000e04 2.31900e03
82 3.27586 8.43950e01 8.44520e01 8.65200e03 1.80300e03 2.79650e02 1.65339e02 4.03000e04 2.40900e03
83 4.31034 8.48180e01 8.48810e01 9.58300e03 1.61000e03 3.00737e02 1.51804e02 3.59000e04 2.53200e03
84 5.34483 8.53570e01 8.54090e01 1.08300e02 1.48600e03 3.27612e02 1.43249e02 3.08000e04 2.63700e03
85 6.37931 8.72880e01 8.73060e01 1.51570e02 1.28200e03 4.16833e02 1.28096e02 1.92000e04 2.88700e03
86 7.41379 8.92130e01 8.91760e01 1.98220e02 1.14700e03 4.87740e02 1.17767e02 8.30000e05 3.11600e03
87 8.44828 9.17360e01 9.16020e01 2.50640e02 9.92000e04 5.31945e02 1.04181e02 2.00000e06 3.41900e03
88 9.48276 9.42910e01 9.40410e01 3.17040e02 8.85000e04 5.85499e02 9.42477e03 1.00000e06 3.70700e03
8910.51724 9.64800e01 9.61630e01 4.02300e02 7.96000e04 6.64893e02 8.47323e03 2.00000e06 3.96100e03
9011.55172 9.86420e01 9.82570e01 5.11880e02 7.23000e04 7.76623e02 7.65452e03 2.00000e06 4.20700e03
9112.58621 1.00657e+00 1.00210e+00 6.43270e02 6.71000e04 9.20001e02 7.06023e03 2.00000e06 4.43100e03
9213.62069 1.02475e+00 1.01984e+00 7.93340e02 6.16000e04 1.09051e01 6.35528e03 1.00000e06 4.64000e03
9314.65517 1.04370e+00 1.03850e+00 9.84840e02 5.79000e04 1.31195e01 5.91001e03 1.00000e06 4.84500e03
9415.68966 1.06004e+00 1.05467e+00 1.18503e01 5.43000e04 1.54410e01 5.44594e03 1.00000e06 5.02500e03
9516.72414 1.07448e+00 1.06905e+00 1.39604e01 5.14000e04 1.78759e01 5.05912e03 1.00000e06 5.18500e03
9617.75862 1.08720e+00 1.08175e+00 1.61656e01 4.93000e04 2.03997e01 4.79726e03 1.00000e06 5.32500e03
9718.79310 1.09867e+00 1.09324e+00 1.84226e01 4.68000e04 2.29525e01 4.45243e03 1.00000e06 5.45500e03
9819.82759 1.10970e+00 1.10430e+00 2.08500e01 4.51000e04 2.56774e01 4.24858e03 1.00000e06 5.57800e03
9920.86207 1.11936e+00 1.11397e+00 2.32097e01 4.34000e04 2.83065e01 4.03443e03 1.00000e06 5.69000e03
10021.89655 1.12815e+00 1.12274e+00 2.54679e01 4.14000e04 3.07965e01 3.77358e03 1.00000e06 5.79400e03
10122.93103 1.13774e+00 1.13227e+00 2.78750e01 4.00000e04 3.34530e01 3.60784e03 1.00000e06 5.90600e03
10223.96552 1.14721e+00 1.14164e+00 3.02299e01 3.84000e04 3.60352e01 3.41109e03 1.00000e06 6.01800e03
10325.00000 1.15816e+00 1.15244e+00 3.27151e01 3.68000e04 3.87710e01 3.21949e03 1.00000e06 6.14600e03
10410.00  Re
105aoa Ue_Vinf_SS Ue_Vinf_PS Dstar_SS Dstar_PS Delta_SS Delta_PS Cf_SS Cf_PS
106(deg) () () () () () () () ()
1075.00000 8.19760e01 8.18060e01 4.17800e03 4.54900e03 1.65706e02 2.88150e02 6.56000e04 1.23100e03
1083.96552 8.21540e01 8.20450e01 4.52500e03 3.74000e03 1.76308e02 2.59028e02 6.23000e04 1.39100e03
1092.93103 8.23580e01 8.22970e01 4.89400e03 3.21700e03 1.87333e02 2.38284e02 5.91000e04 1.51700e03
1101.89655 8.25560e01 8.25320e01 5.25400e03 2.85300e03 1.97567e02 2.22669e02 5.60000e04 1.62100e03
1110.86207 8.27870e01 8.28060e01 5.67900e03 2.46600e03 2.09522e02 2.03860e02 5.28000e04 1.74400e03
112 0.17241 8.30330e01 8.30840e01 6.14400e03 2.18100e03 2.22219e02 1.88758e02 4.96000e04 1.84900e03
113 1.20690 8.32880e01 8.33650e01 6.64800e03 1.94100e03 2.35312e02 1.74735e02 4.63000e04 1.94900e03
114 2.24138 8.35130e01 8.36090e01 7.13000e03 1.75100e03 2.46910e02 1.62700e02 4.31000e04 2.03800e03
115 3.27586 8.39970e01 8.41060e01 8.09900e03 1.56800e03 2.72181e02 1.50508e02 3.88000e04 2.14300e03
116 4.31034 8.50470e01 8.51560e01 1.01990e02 1.37300e03 3.25448e02 1.36378e02 3.18000e04 2.29400e03
117 5.34483 8.64450e01 8.65280e01 1.32660e02 1.23700e03 3.92329e02 1.26866e02 2.31000e04 2.45100e03
118 6.37931 8.78610e01 8.79110e01 1.65810e02 1.08900e03 4.49765e02 1.14397e02 1.47000e04 2.62200e03
119 7.41379 8.91030e01 8.91080e01 1.96290e02 9.93000e04 4.89936e02 1.06282e02 7.60000e05 2.76500e03
120 8.44828 9.08900e01 9.08620e01 2.35230e02 8.71000e04 5.22284e02 9.45732e03 2.00000e06 2.96800e03
121 9.48276 9.32700e01 9.30700e01 2.84210e02 7.79000e04 5.52443e02 8.61055e03 0.00000e+00 3.20000e03
12210.51724 9.51380e01 9.48770e01 3.46600e02 6.96000e04 6.05165e02 7.64709e03 1.00000e06 3.39700e03
12311.55172 9.71740e01 9.68450e01 4.35850e02 6.37000e04 6.90670e02 6.98615e03 1.00000e06 3.59500e03
12412.58621 9.91260e01 9.87290e01 5.44080e02 5.84000e04 8.03205e02 6.33577e03 1.00000e06 3.78700e03
12513.62069 1.00996e+00 1.00542e+00 6.74960e02 5.36000e04 9.47613e02 5.73102e03 1.00000e06 3.97000e03
12614.65517 1.02771e+00 1.02275e+00 8.31660e02 5.06000e04 1.12645e01 5.35979e03 1.00000e06 4.13700e03
12715.68966 1.04427e+00 1.03905e+00 1.00836e01 4.71000e04 1.33082e01 4.88548e03 1.00000e06 4.29600e03
12816.72414 1.06019e+00 1.05485e+00 1.21136e01 4.45000e04 1.56673e01 4.55077e03 1.00000e06 4.44600e03
12917.75862 1.07407e+00 1.06868e+00 1.42220e01 4.22000e04 1.81035e01 4.24533e03 1.00000e06 4.57900e03
13018.79310 1.08623e+00 1.08087e+00 1.64037e01 4.01000e04 2.06006e01 3.94306e03 0.00000e+00 4.69600e03
13119.82759 1.09748e+00 1.09215e+00 1.87080e01 3.86000e04 2.32142e01 3.76503e03 0.00000e+00 4.80500e03
13220.86207 1.10794e+00 1.10267e+00 2.10804e01 3.67000e04 2.58816e01 3.50553e03 0.00000e+00 4.90800e03
13321.89655 1.11776e+00 1.11253e+00 2.35256e01 3.54000e04 2.86067e01 3.34709e03 0.00000e+00 5.00500e03
13422.93103 1.12664e+00 1.12138e+00 2.58366e01 3.43000e04 3.11568e01 3.20986e03 0.00000e+00 5.09600e03
13523.96552 1.13635e+00 1.13106e+00 2.83067e01 3.28000e04 3.38816e01 3.02058e03 0.00000e+00 5.19400e03
13625.00000 1.14573e+00 1.14034e+00 3.06604e01 3.16000e04 3.64612e01 2.86692e03 0.00000e+00 5.29100e03
Observer Positions¶
The number and position of observers is set in the file ObserverLocations, which is explained in Section 4.2.3.7.1. The positions must be specified in the OpenFAST global inertial frame coordinate system, which is located at the tower base and has the xaxis pointing downwind, the yaxis pointing laterally, and the zaxis pointing vertically upward. A scheme of the coordinate system for the observers is shown in Fig. 4.23.
The International Energy Agency Wind Task 37 landbased reference wind turbine, which is shown in Table 4.2, has a hub height of 110 meters and a rotor radius of 65 meters, and has the International Electrotechnical Commission 6140011 standards compliant observer located at:
x = 175 [m]
y = 0 [m]
z = 0 [m].
An example of a file listing four observers located at a 2meter height is shown here:
14 NrObsLoc  Total Number of observer locations
2X Observer location in towerbase coordinate X horizontal (m), Y Observer location in towerbase coordinate Y Lateral (m), Z Observer location in towerbase coordinate Z Vertical (m)
3200 200 2
4200 +200 2
5+200 200 2
6+200 +200 2
Turbulence Grid¶
When the flag TICalcMeth is set equal to 1, the grid of turbulence intensity of the wind \(TI\) must be defined by the user. This is done by creating a file called TIGrid_In.txt, which mimics a TurbSim output file and contains a grid of turbulence intensity, which is defined as a fraction value. The file defines a grid centered at hub height and oriented with the OpenFAST global inertial frame coordinate system; see Fig. 4.23. A userdefined number of lateral and vertical points equally spaced by a userdefined number of meters must be specified. Note that an average wind speed must be defined to convert the turbulence intensity of the wind to the incident turbulent intensity \(I_{1}\). An example file for a 160 (lateral) by 180 (vertical) meters grid looks like the following:
1Average Inflow Wind Speed
28.0
3Total Grid points In Y (lateral), Starts from  radius goes to + radius+
44
5Total Grid points In Z (vertical), Starts from bottom tip (hubradius)
63
7Grid spacing In Y (lateral)
840
9Grid spacing In Z (vertical)
1060
110.1200 0.1200 0.1200 0.1200
120.1100 0.1100 0.1100 0.1100
130.1000 0.1000 0.1000 0.1000
References¶
 aaAmi75
Roy K. Amiet. Acoustic radiation from an airfoil in a turbulent stream. Journal of Sound and Vibration, 41(4):407–420, 1975. doi:10.1016/S0022460X(75)801052.
 aaBTD+19
Pietro Bortolotti, Helena Canet Tarres, Katherine Dykes, Karl Merz, Latha Sethuraman, David Verelst, and Frederik Zahle. Systems engineering in wind energy  wp2.1 reference wind turbines. Technical Report, IEA Technical Report, 2019. URL: https://www.nrel.gov/docs/fy19osti/73492.pdf.
 aaBPM89
Thomas F. Brooks, D. Stuart Pope, and Michael A. Marcolini. Airfoil selfnoise and prediction. Reference Publication 1218, NASA, 1989.
 aaDG87
Mark Drela and Michael B. Giles. Viscousinviscid analysis of transonic and low reynolds number airfoils. AIAA Journal, 25(10):1347–1355, 1987. doi:10.2514/3.9789.
 aaGBW+97
Gianfranco Guidati, Rainer Bareiss, Siegfried Wagner, Rene Parchen, Gianfranco Guidati, Rainer Bareiss, Siegfried Wagner, and Rene Parchen. Simulation and measurement of inflowturbulence noise on airfoils. In 3rd AIAA/CEAS Aeroacoustics Conference. 1997. doi:10.2514/6.19971698.
 aaKGW+18
Levin Klein, Jonas Gude, Florian Wenz, Thorsten Lutz, and Ewald Krämer. Advanced computational fluid dynamics (cfd)–multibody simulation (mbs) coupling to assess lowfrequency emissions from wind turbines. Wind Energy Science Journal, 3:713–728, 2018. doi:10.5194/wes37132018.
 aaLow70
Martin V. Lowson. Theoretical analysis of compressor noise evaluation. The Journal of the Acoustical Society of America, 47:371–385, 1970. doi:10.1121/1.1911508.
 aaMGM04
Patrick Moriarty, Gianfranco Guidati, and Paul Migliore. Recent improvement of a semiempirical aeroacoustic prediction code for wind turbines. In 10th AIAA/CEAS Aeroacoustics Conference. 2004. doi:10.2514/6.20043041.
 aaMGM05
Patrick Moriarty, Gianfranco Guidati, and Paul Migliore. Prediction of turbulent inflow and trailingedge noise for wind turbines. In 11th AIAA/CEAS Aeroacoustics Conference. 2005. doi:10.2514/6.20052881.
 aaMor05
Patrick J. Moriarty. Nafnoise user's guide. Technical Report, National Renewable Energy Laboratory, Golden, CO, 2005. URL: https://github.com/NREL/NAFNoise/blob/master/NAFNoise.pdf.
 aaMH05
Patrick J. Moriarty and A. C. Hansen. Aerodyn theory manual. Technical Report NREL/TP50036881, National Renewable Energy Laboratory, Golden, CO, 2005. URL: https://www.nrel.gov/docs/fy05osti/36881.pdf.
 aaMM03
Patrick J. Moriarty and Paul G. Migliore. Semiempirical aeroacoustic noise prediction code for wind turbines. Technical Report NREL/TP50034478, National Renewable Energy Laboratory, Golden, CO, 2003. URL: https://www.nrel.gov/docs/fy04osti/34478.pdf.
 aaPar98
René R. Parchen. Progress report DRAW: a prediction scheme for trailing edge noise based on detailed boundary layer characteristics. Technical Report, TNO Institute of Applied Physics, 1998.
 aaPA76
R. Paterson and R. Amiet. Acoustic radiation and surface pressure characteristics of an airfoil due to incident turbulence. In 3rd Aeroacoustics Conference. AIAA, 1976. doi:10.2514/6.1976571.
 aaSBCB18
CR Sucameli, P Bortolotti, A Croce, and CL Bottasso. Comparison of some wind turbine noise emission models coupled to BEM aerodynamics. Journal of Physics: Conference Series, 1037:022038, jun 2018. doi:10.1088/17426596/1037/2/022038.
 aaVit81
Larry A. Viterna. Method for predicting impulsive noise generated by wind turbine rotors. Technical Report DOE/NASA/2032036, 1981. URL: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19820013840.pdf.
 aaZHS05
Wei J. Zhu, Nicolai Heilskov, and Wen Zhong Shen. Modeling of aerodynamically generated noise from wind turbines. Journal of Solar Energy Engineering, 127(4):517–528, 2005. doi:10.1115/1.2035700.
BeamDyn User Guide and Theory Manual¶
This document offers a quick reference guide for the BeamDyn software program. It is intended to be used by the general user in combination with other OpenFAST manuals. The manual will be updated as new releases are issued and as needed to provide further information on advancements or modifications to the software. For reference, additional materials such as presentation slides, development plans, and publications can be downladed from the list below.
The authors are grateful to the U.S. Department of Energy Wind and Water Power Program and the NREL Laboratory Directed Research and Development (LDRD) program through the grant “HighFidelity Computational Modeling of WindTurbine Structural Dynamics” for supporting the development of this software.
Introduction¶
BeamDyn is a timedomain structuraldynamics module for slender structures created by the National Renewable Energy Laboratory (NREL) through support from the U.S. Department of Energy Wind and Water Power Program and the NREL Laboratory Directed Research and Development (LDRD) program through the grant “HighFidelity Computational Modeling of WindTurbine Structural Dynamics”, see References [WJSJ15, WS13, WSJJ14, WYS13]. The module has been coupled into the FAST aerohydroservoelastic wind turbine multiphysics engineering tool where it used to model blade structural dynamics. The BeamDyn module follows the requirements of the FAST modularization framework, see References [Jon13]; [GSJ13, JJ13, SJJ14], couples to FAST version 8, and provides new capabilities for modeling initially curved and twisted composite wind turbine blades undergoing large deformation. BeamDyn can also be driven as a standalone code to compute the static and dynamic responses of slender structures (blades or otherwise) under prescribed boundary and applied loading conditions uncoupled from FAST.
The model underlying BeamDyn is the geometrically exact beam theory (GEBT) [Hod06]. GEBT supports full geometric nonlinearity and large deflection, with bending, torsion, shear, and extensional degreeoffreedom (DOFs); anisotropic composite material couplings (using full \(6 \times 6\) mass and stiffness matrices, including bendtwist coupling); and a reference axis that permits blades that are not straight (supporting builtin curve, sweep, and sectional offsets). The GEBT beam equations are discretized in space with Legendre spectral finite elements (LSFEs). LFSEs are ptype elements that combine the accuracy of global spectral methods with the geometric modeling flexibility of the htype finite elements (FEs) [Pat84]. For smooth solutions, LSFEs have exponential convergence rates compared to loworder elements that have algebraic convergence [SG03, WS13] . Two spatial numerical integration schemes are implemented for the finite element inner products: reduced Gauss quadrature and trapezoidalrule integration. Trapezoidalrule integration is appropriate when a large number of sectional properties are specified along the beam axis, for example, in a long wind turbine blade with material properties that vary dramatically over the length. Time integration of the BeamDyn equations of motion is achieved through the implicit generalized \(\alpha\) solver, with userspecified numerical damping. The combined GEBTLSFE approach permits users to model a long, flexible, composite wind turbine blade with a single highorder element. Given the theoretical foundation and powerful numerical tools introduced above, BeamDyn can solve the complicated nonlinear composite beam problem in an efficient manner. For example, it was recently shown that a gridindependent dynamic solution of a 50m composite wind turbine blade and with dozens of crosssection stations could be achieved with a single \(7^{th}\)order LSFE [WSJJ16].
When coupled with FAST, loads and responses are transferred between BeamDyn, ElastoDyn, ServoDyn, and AeroDyn via the FAST driver program (glue code) to enable aeroelastoservo interaction at each coupling time step. There is a separate instance of BeamDyn for each blade. At the root node, the inputs to BeamDyn are the six displacements (three translations and three rotations), six velocities, and six accelerations; the root node outputs from BeamDyn are the six reaction loads (three translational forces and three moments). BeamDyn also outputs the blade displacements, velocities, and accelerations along the beam length, which are used by AeroDyn to calculate the local aerodynamic loads (distributed along the length) that are used as inputs for BeamDyn. In addition, BeamDyn can calculate member internal reaction loads, as requested by the user. Please refers to Figure [fig:FlowChart] for the coupled interactions between BeamDyn and other modules in FAST. When coupled to FAST, BeamDyn replaces the more simplified blade structural model of ElastoDyn that is still available as an option, but is only applicable to straight isotropic blades dominated by bending. When uncoupled from FAST, the root motion (boundary condition) and applied loads are specified via a standalone BeamDyn driver code.
The BeamDyn input file defines the blade geometry; crosssectional material mass, stiffness, and damping properties; FE resolution; and other simulation and outputcontrol parameters. The blade geometry is defined through a curvilinear blade reference axis by a series of key points in threedimensional (3D) space along with the initial twist angles at these points. Each member contains at least three key points for the cubic spline fit implemented in BeamDyn; each member is discretized with a single LSFE with a parameter defining the order of the element. Note that the number of key points defining the member and the order (\(N\)) of the LSFE are independent. LSFE nodes, which are located at the \(N+1\) GaussLegendreLobatto points, are not evenly spaced along the element; node locations are generated by the module based on the mesh information. Blade properties are specified in a nondimensional coordinate ranging from 0.0 to 1.0 along the blade reference axis and are linearly interpolated between two stations if needed by the spatial integration method. The BeamDyn applied loads can be either distributed loads specified at quadrature points, concentrated loads specified at FE nodes, or a combination of the two. When BeamDyn is coupled to FAST, the blade analysis node discretization may be independent between BeamDyn and AeroDyn.
This document is organized as follows. Section Running BeamDyn details how to obtain the BeamDyn and FAST software archives and run either the standalone version of BeamDyn or BeamDyn coupled to FAST. Section Input Files describes the BeamDyn input files. Section Output Files discusses the output files generated by BeamDyn. Section BeamDyn Theory summarizes the BeamDyn theory. Section Future Work outlines potential future work. Example input files are shown in Appendix Section 4.2.4.8.1. A summary of available output channels is found in Appendix BeamDyn List of Output Channels.
Running BeamDyn¶
This section discusses how to obtain and execute BeamDyn from a personal computer. Both the standalone version and the FASTcoupled version of the software are considered.
Downloading the BeamDyn Software¶
There are two forms of the BeamDyn software to choose from: standalone and coupled to the FAST simulator. Although the user may not necessarily need both forms, he/she would likely need to be familiar with and run the standalone model if building a model of the blade from scratch. The standalone version is also helpful for model troubleshooting, even if the goal is to conduct aerohydroservoelastic simulations of onshore/offshore wind turbines within FAST.
Users can download the standalone BeamDyn archive from our Web server
at https://nwtc.nrel.gov/BeamDyn. The file has a name similar to
BD_v1.00.00a.exe
, but may have a different version number. The user
can then download the selfextracting archive (.exe) to expand the
archive into a folder he/she specifies.
The archive contains the bin
, CertTest
, Compiling
,
Docs
, and Source
folders. The bin
folder includes the
main executable file, BeamDyn_Driver.exe
, which is used to execute
the standalone BeamDyn program. The CertTest
folder contains a
collection of sample BeamDyn input files and driver input files that can
be used as templates for the user’s own models. This document may be
found in the Docs
folder. The Compiling
folder contains files
for compiling the standalone BeamDyn_v1.00.00.exe
file with either
Visual Studio or gFortran. The Fortran source code is located in the
Source
folder.
Download the FAST archive, which includes BeamDyn, from our Web server
at https://nwtc.nrel.gov/FAST8. The file has a name similar to
FAST_v8.12.00.exe
, but may have a different version number. Run the
downloaded selfextracting archive (.exe
) to expand the archive into a
userspecified folder. The FAST executable file is located in the
archive’s bin
folder. An example model using the NREL 5MW
reference turbine is located in the CertTest
folder.
Running BeamDyn¶
The standalone BeamDyn program, BeamDyn_Driver.exe
, simulates static
and dynamic responses of the user’s input model, without coupling to
FAST. Unlike the coupled version, the standalone software requires the
use of a driver file in addition to the primary and blade BeamDyn input
files. This driver file specifies inputs normally provided to BeamDyn by
FAST, including motions of the blade root and externally applied loads.
Both the BeamDyn summary file and the results output file are available
when using the standalone BeamDyn (see Section Output Files for
more information regarding the BeamDyn output files).
Run the standalone BeamDyn software from a DOS command prompt by typing, for example:
>BeamDyn_Driver.exe Dvr_5MW_Dynamic.inp
where, Dvr_5MW_Dynamic.inp
is the name of the BeamDyn driver input
file, as described in Section BeamDyn Driver Input File.
Run the coupled FAST software from a DOS command prompt by typing, for example:
>FAST_Win32.exe Test26.fst
where Test26.fst
is the name of the primary FAST input file. This
input file has a feature switch to enable or disable the BeamDyn
capabilities within FAST, and a corresponding reference to the BeamDyn
input file. See the documentation supplied with FAST for further
information.
Input Files¶
Users specify the blade model parameters; including its geometry, crosssectional properties, and FE and output control parameters; via a primary BeamDyn input file and a blade property input file. When used in standalone mode, an additional driver input file is required. This driver file specifies inputs normally provided to BeamDyn by FAST, including simulation range, root motions, and externally applied loads.
No lines should be added or removed from the input files, except in tables where the number of rows is specified.
Units¶
BeamDyn uses the SI system (kg, m, s, N). Angles are assumed to be in radians unless otherwise specified.
BeamDyn Driver Input File¶
The driver input file is needed only for the standalone version of BeamDyn. It contains inputs that are normally set by FAST and that are necessary to control the simulation for uncoupled models.
The driver input file begins with two lines of header information, which is for the user but is not used by the software. If BeamDyn is run in the standalone mode, the results output file will be prefixed with the same name of this driver input file.
A sample BeamDyn driver input file is given in Section 4.2.4.8.1.
DynamicSolve
is a logical variable that specifies if BeamDyn should use dynamic analysis (DynamicSolve = true
)
or static analysis (DynamicSolve = false
).
t_initial
and t_final
specify the starting time of the simulation and ending time of the simulation, respectively.
dt
specifies the time step size.
Gx
, Gy
, and Gz
specify the components of gravity vector along \(X\), \(Y\), and \(Z\) directions in the global coordinate system, respectively.
In FAST, this is normally 0, 0, and 9.80665.
This section defines the relation between two inertial frames, the global coordinate system and initial blade reference coordinate system.
GlbPos(1)
, GlbPos(2)
, and GlbPos(3)
specify three components of the initial global position vector along \(X\), \(Y\), and \(Z\) directions resolved in the global coordinate system, see Figure Fig. 4.25.
And the following \(3 \times 3\) direction cosine matrix (GlbDCM
) relates the rotations from the global coordinate system to the initial blade reference coordinate system.
This section specifies the parameters that define the blade floating reference frame, which is a bodyattached floating frame; the blade root is cantilevered at the origin of this frame. Based on the driver input file, the floating blade reference fame is assumed to be in a constant rigidbody rotation mode about the origin of the global coordinate system, that is,
where \(v_{rt}\) is the root (origin of the floating blade reference frame) translational velocity vector; \(\omega_r\) is the constant root (origin of the floating blade reference frame) angular velocity vector; and \(r_t\) is the global position vector introduced in the previous section at instant \(t\), see Fig. 4.25.
The floating blade reference frame coincides with the initial floating blade reference frame at the beginning \(t=0\).
RootVel(4)
, RootVel(5)
, and RootVel(6)
specify the three components of the constant root angular velocity vector about \(X\), \(Y\), and \(Z\) axises in global coordinate system, respectively.
RootVel(1)
, RootVel(2)
, and RootVel(3)
, which are the three components of the root translational velocity vector along \(X\), \(Y\), and \(Z\) directions in global coordinate system, respectively, are calculated based on Eq. (4.57).
BeamDyn can handle more complicated root motions by changing, for example, the BD_InputSolve
subroutine in the Driver_Beam.f90
(requiring a recompile of standalone BeamDyn).
The blade is initialized in the rigidbody motion mode, i.e., based on the root velocity information defined in this section and the position information defined in the previous section, the motion of other points along the blade are initialized as
where \(a_{0}\) is the initial translational acceleration vector along the blade; \(v_0\) and \(\omega_0\) the initial translational and angular velocity vectors along the blade, respectively; and \(P\) is the position vector along the blade relative to the root. Note that these equations are actually implemented with a call to the NWTC Library’s mesh mapping routines.
This section defines the applied loads, including distributed, point (lumped), and tipconcentrated loads, for the standalone analysis.
The first six entries DistrLoad(i)
, \(i \in [1,6]\), specify three
components of uniformly distributed force vector and three components of
uniformly distributed moment vector in the global coordinate systems,
respectively.
The following six entries TipLoad(i)
,
\(i \in [1,6]\), specify three components of concentrated tip force
vector and three components of concentrated tip moment vector in the
global coordinate system, respectively.
NumPointLoads
defines how many point loads along the blade will be applied. The table
following this input contains two header lines with seven columns and NumPointLoads
rows.
The first column is the nondimensional distance along the local blade reference axis,
ranging from \([0.0,1.0]\). The next three columns, Fx
, Fy
, and Fz
specify three
components of pointforce vector. The remaining three columns, Mx
, My
, and Mz
specify three
components of a moment vector.
The distributed load defined in this section is assumed to be uniform along the blade and constant throughout the simulation. The tip load is a constant concentrated load applied at the tip of a blade.
It is noted that all the loads defined in this section are dead loads, i.e., they are not rotating with the blade following the rigidbody rotation defined in the previous section.
BeamDyn is capable of handling more complex loading cases, e.g.,
timedependent loads, through customization of the source code
(requiring a recompile of standalone BeamDyn). The user can define such
loads in the BD_InputSolve
subroutine in the Driver_Beam.f90
file,
which is called every time step. The following section can be modified
to define the concentrated load at each FE node:
u%PointLoad%Force(1:3,u%PointLoad%NNodes) = u%PointLoad%Force(1:3,u%PointLoad%NNodes) + DvrData%TipLoad(1:3)
u%PointLoad%Moment(1:3,u%PointLoad%NNodes) = u%PointLoad%Moment(1:3,u%PointLoad%NNodes) + DvrData%TipLoad(4:6)
where the first index in each array ranges from 1 to 3 for load vector
components along three global directions and the second index of each
array ranges from 1 to u%PointLoad%NNodes
, where the latter is the total
number of FE nodes. Note that u%PointLoad%Force(1:3,:)
and u%PointLoad%Moment(1:3,:)
have been populated with the pointload loads read from the BeamDyn driver input file
using the call to Transfer_Point_to_Point
earlier in the subroutine.
For example, a timedependent sinusoidal force acting along the \(X\) direction applied at the \(2^{nd}\) FE node can be defined as
u%PointLoad%Force(:,:) = 0.0D0
u%PointLoad%Force(1,2) = 1.0D+03*SIN((2.0*pi)*t/6.0 )
u%PointLoad%Moment(:,:) = 0.0D0
with 1.0D+03
being the amplitude and 6.0
being the
period. Note that this particular implementation overrides the tipload and pointloads
defined in the driver input file.
Similar to the concentrated load, the distributed loads can be defined in the same subroutine
DO i=1,u%DistrLoad%NNodes
u%DistrLoad%Force(1:3,i) = DvrData%DistrLoad(1:3)
u%DistrLoad%Moment(1:3,i)= DvrData%DistrLoad(4:6)
ENDDO
where u%DistrLoad%NNodes
is the number of nodes input to BeamDyn (on the quadrature points),
and DvrData%DistrLoad(:)
is the constant uniformly distributed load BeamDyn reads from the driver
input file. The user can modify DvrData%DistrLoad(:)
to define the loads based on need.
We note that the distributed loads are defined at the quadrature points
for numerical integrations. For example, if Gauss quadrature is chosen,
then the distributed loads are defined at
Gauss points plus the two end points of the beam (root and tip). For
trapezoidal quadrature, p%ngp
stores the number of trapezoidal
quadrature points.
InputFile
is the file name of the primary BeamDyn input file. This
name should be in quotations and can contain an absolute path or a
relative path.
BeamDyn Primary Input File¶
The BeamDyn primary input file defines the blade geometry, LSFEdiscretization and simulation options, output channels, and name of the blade input file. The geometry of the blade is defined by keypoint coordinates and initial twist angles (in units of degree) in the blade local coordinate system (IEC standard blade system where \(Z_r\) is along blade axis from root to tip, \(X_r\) directs normally toward the suction side, and \(Y_r\) directs normally toward the trailing edge).
The file is organized into several functional sections. Each section corresponds to an aspect of the BeamDyn model.
A sample BeamDyn primary input file is given in Section 4.2.4.8.
The primary input file begins with two lines of header information, which are for the user but are not used by the software.
The user can set the Echo
flag to TRUE
to have BeamDyn echo the
contents of the BeamDyn input file (useful for debugging errors in the
input file).
The QuasiStaticInit
flag indicates if BeamDyn should perform a quasistatic
solution at initialization to better initialize its states. In general, this should
be set to true for better numerical performance (it reduces startup transients).
rhoinf
specifies the numerical damping parameter (spectral radius
of the amplification matrix) in the range of \([0.0,1.0]\) used in
the generalized\(\alpha\) time integrator implemented in BeamDyn
for dynamic analysis. For rhoinf = 1.0
, no
numerical damping is introduced and the generalized\(\alpha\)
scheme is identical to the Newmark scheme; for
rhoinf = 0.0
, maximum numerical damping is
introduced. Numerical damping may help produce numerically stable
solutions.
Quadrature
specifies the spatial numerical integration scheme.
There are two options: 1) Gauss quadrature; and 2) Trapezoidal
quadrature. We note that in the current version, Gauss quadrature is
implemented in reduced form to improve efficiency and avoid shear
locking. In the trapezoidal quadrature, only one member (FE element) can
be defined in the following GEOMETRY section of the primary input file.
Trapezoidal quadrature is appropriate when the number of “blade input
stations” (described below) is significantly greater than the order of
the LSFE.
Refine
specifies a refinement parameter used in trapezoidal
quadrature. An integer value greater than unity will split the space
between two input stations into “Refine factor” of segments. The keyword
“DEFAULT” may be used to set it to 1, i.e., no refinement is needed.
This entry is not used in Gauss quadrature.
N_Fact
specifies a parameter used in the modified NewtonRaphson
scheme. If N_Fact = 1
a full Newton
iteration scheme is used, i.e., the global tangent stiffness matrix is
computed and factorized at each iteration; if
N_Fact > 1
a modified Newton iteration
scheme is used, i.e., the global stiffness matrix is computed and
factorized every N_Fact
iterations within each time step. The
keyword “DEFAULT” sets N_Fact = 5
.
DTBeam
specifies the constant time increment of the
timeintegration in seconds. The keyword “DEFAULT” may be used to
indicate that the module should employ the time increment prescribed by
the driver code (FAST/standalone driver program).
load_retries
specifies the maximum number of load retries allowed. This option
currently works only for static analysis. For every load retry, the applied load is
halved to promote convergence of the NewtonRaphson scheme in iteration of smaller
load steps as opposed to one single large load step which may cause divergence of the
NewtonRaphson scheme. The keyword “DEFAULT” sets load_retries = 20
.
NRMax
specifies the maximum number of iterations per time step in
the NewtonRaphson scheme. If convergence is not reached within this
number of iterations, BeamDyn returns an error message and terminates
the simulation. The keyword “DEFAULT” sets
NRMax = 10
.
Stop_Tol
specifies a tolerance parameter used in convergence
criteria of a nonlinear solution that is used for the termination of the
iteration. The keyword “DEFAULT” sets
Stop_Tol = 1.0E05
. Please refer to
Section 4.2.4.5.7 for more details.
tngt_stf_fd
is a boolean that sets the flag to compute the tangent stiffness
matrix using finite differencing instead of analytical differentiation. The
finite differencing is performed using a central scheme. The keyword “DEFAULT”
sets tngt_stf_fd = FALSE
.
tngt_stf_comp
is a boolean that sets the flag to compare the analytical tangent
stiffness matrix against the finite differenced tangent stiffness matrix. Information is
written to the terminal regarding the dof where the maximum difference is observed. If
tngt_stf_fd = FALSE
and tngt_stf_comp = TRUE
, the analytical tangent stiffness
matrix is used to solve the system of equations while the finite difference tangent stiffness
matrix is used only to perform the comparison of the two matrices. The keyword “DEFAULT”
sets tngt_stf_comp = FALSE
.
tngt_stf_pert
sets the perturbation size for finite differencing. The “DEFAULT” value
based on experience is set to 1e06
.
tngt_stf_difftol
is the maximum allowable relative difference between the analytical
and finite differenced tangent stiffness matrices. If for any entry in the matrices,
the relative difference exceeds this value the simulation will terminate. The “DEFAULT” value
is currently set to 1e01
.
RotStates
is a flag that indicates if BeamDyn’s continuous states should be
oriented in the rotating frame during linearization analysis when coupled to OpenFAST.
If multiblade coordinate (MBC3) analysis is performed, RotStates
must be true
.
The blade geometry is defined by a curvilinear local blade reference axis. The blade reference axis locates the origin and orientation of each a local coordinate system where the crosssectional 6x6 stiffness and mass matrices are defined in the BeamDyn blade input file. It should not really matter where in the cross section the 6x6 stiffness and mass matrices are defined relative to, as long as the reference axis is consistently defined and closely follows the natural geometry of the blade.
The blade beam model is composed of several members in contiguous series and each member is defined by at least three key points in BeamDyn. A cubicsplinefit preprocessor implemented in BeamDyn automatically generates the member based on the key points and then interconnects the members into a blade. There is always a shared key point at adjacent members; therefore the total number of key points is related to number of members and key points in each member.
member_total
specifies the total number of beam members used in
the structure. With the LSFE discretization, a single member and a
sufficiently high element order, order_elem
below, may well be
sufficient.
kp_total
specifies the total number of key points used to define
the beam members.
The following section contains member_total
lines. Each line has
two integers providing the member number (must be 1, 2, 3, etc.,
sequentially) and the number of key points in this member, respectively.
It is noted that the number of key points in each member is not
independent of the total number of key points and they should satisfy
the following equality:
where \(n_i\) is the number of key points in the \(i^{th}\) member. Because cubic splines are implemented in BeamDyn, \(n_i\) must be greater than or equal to three. Figures Fig. 4.26 and Fig. 4.27 show two cases for member and keypoint definition.
The next section defines the keypoint information, preceded by two
header lines. Each key point is defined by three physical coordinates
(kp_xr
, kp_yr
, kp_zr
) in the IEC standard blade
coordinate system (the blade reference coordinate system) along with a
structural twist angle (initial_twist
) in the unit of degrees.
The structural twist angle is also following the IEC standard which is
defined as the twist about the negative \(Z_l\) axis. The key points
are entered sequentially (from the root to tip) and there should be a
total of kp_total
lines for BeamDyn to read in the information,
after two header lines. Please refer to Fig. 4.28 for
more details on the blade geometry definition.
Order_Elem
specifies the order of shape functions for each finite
element. Each LSFE will have Order_Elem
+1 nodes located at the
GLL quadrature points. All LSFEs will have the same order. With the LSFE
discretization, an increase in accuracy will, in general, be better
achieved by increasing Order_Elem
(i.e., \(p\)refinement)
rather than increasing the number of members (i.e.,
\(h\)refinement). For Gauss quadrature, Order_Elem
should be
greater than one.
BldFile
is the file name of the blade input file. This name should
be in quotations and can contain an absolute path or a relative path.
In this release, the pitch actuator implemented in BeamDyn is not
available. The UsePitchAct
should be set to “FALSE” in this
version, whereby the input bladepitch angle prescribed by the driver
code is used to orient the blade directly. PitchJ
, PitchK
,
and PitchC
specify the pitch actuator inertial, stiffness, and
damping coefficient, respectively. In future releases, specifying
UsePitchAct
\(=\) TRUE will enable a secondorder pitch
actuator, whereby the pitch angular orientation, velocity, and
acceleration are determined by the actuator based on the input
bladepitch angle prescribed by the driver code.
In this section of the primary input file, the user sets flags and switches for the desired output behavior.
Specifying SumPrint = TRUE
causes BeamDyn to generate a
summary file with name InputFile.sum
. See
Section 4.2.4.4.2 for summary file details.
OutFmt
parameter controls the formatting of the results within the
standalone BeamDyn output file. It needs to be a valid Fortran format
string, but BeamDyn currently does not check the validity. This input is
unused when BeamDyn is used coupled to FAST.
NNodeOuts
specifies the number of nodes where output can be
written to a file. Currently, BeamDyn can output quantities at a maximum
of nine nodes.
OutNd
is a list NNodeOuts
long of node numbers between 1 and the number of
nodes on the output mesh, separated by any
combination of commas, semicolons, spaces, and/or tabs. The nodal
positions are given in the summary file, if output.
For Gassian quadrature, the number of nodes on the output mesh is the total number of FE nodes;
for trapezoidal quadrature, this is the number of quadrature nodes.
The OutList
block contains a list of output parameters. Enter one
or more lines containing quoted strings that in turn contain one or more
output parameter names. Separate output parameter names by any
combination of commas, semicolons, spaces, and/or tabs. If you prefix a
parameter name with a minus sign, ““, underscore, “_”, or the
characters “m” or “M”, BeamDyn will multiply the value for that channel
by 1 before writing the data. The parameters are written in the order
they are listed in the input file. BeamDyn allows you to use multiple
lines so that you can break your list into meaningful groups and so the
lines can be shorter. You may enter comments after the closing quote on
any of the lines. Entering a line with the string “END” at the beginning
of the line or at the beginning of a quoted string found at the
beginning of the line will cause BeamDyn to quit scanning for more lines
of channel names. Noderelated quantities are generated for the
requested nodes identified through the OutNd list above. If BeamDyn
encounters an unknown/invalid channel name, it warns the users but will
remove the suspect channel from the output file. Please refer to
Appendix Section 4.2.4.8.2 for a complete list of possible output
parameters and their names.
In addition to the named outputs in Section 4.2.4.3.3.6 above, BeamDyn allows
for outputting the full set blade node motions and loads (tower nodes
unavailable at present). Please refer to the BeamDyn_Nodes tab in the
Excel file OutListParameters.xlsx
for a complete list of possible output parameters.
This section follows the END statement from normal Outputs section described above, and includes a separator description line followed by the following optinos.
BldNd_BlOutNd specifies which nodes to output. This is currently unused.
The OutList section controls the nodal output quantities generated by BeamDyn. In this section, the user specifies the name of the channel family to output. The output name for each channel is then created internally by BeamDyn by combining the blade number, node number, and channel family name. For example, if the user specifies TDxr as the channel family name, the output channels will be named with the convention of B\(\mathbf{\beta}\)N###TDxr where \(\mathbf{\beta}\) is the blade number, and ### is the three digit node number.
This sample includes the END
statement from the regular outputs section.
1END of input file (the word "END" must appear in the first 3 columns of this last OutList line)
2 NODE OUTPUTS 
3 99 BldNd_BlOutNd  Blade nodes on each blade (currently unused)
4 OutList  The next line(s) contains a list of output parameters. See OutListParameters.xlsx, BeamDyn_Nodes tab for a listing of available output channels, ()
5"FxL"  Sectional force resultants at each node expressed in l l: a floating coordinate system local to the deflected beam (N)
6"FyL"  Sectional force resultants at each node expressed in l l: a floating coordinate system local to the deflected beam (N)
7"FzL"  Sectional force resultants at each node expressed in l l: a floating coordinate system local to the deflected beam (N)
8"MxL"  Sectional moment resultants at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm)
9"MyL"  Sectional moment resultants at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm)
10"MzL"  Sectional moment resultants at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm)
11"Fxr"  Sectional force resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
12"Fyr"  Sectional force resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
13"Fzr"  Sectional force resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
14"Mxr"  Sectional moment resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
15"Myr"  Sectional moment resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
16"Mzr"  Sectional moment resultants at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
17"TDxr"  Sectional translational deflection (relative to the undeflected position) at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m)
18"TDyr"  Sectional translational deflection (relative to the undeflected position) at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m)
19"TDzr"  Sectional translational deflection (relative to the undeflected position) at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m)
20"RDxr"  Sectional angular/rotational deflection WienerMilenkovic parameter (relative to the undeflected orientation) at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system ()
21"RDyr"  Sectional angular/rotational deflection WienerMilenkovic parameter (relative to the undeflected orientation) at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system ()
22"RDzr"  Sectional angular/rotational deflection WienerMilenkovic parameter (relative to the undeflected orientation) at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system ()
23"AbsXg"  Node position in X (global coordinate) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (m)
24"AbsYg"  Node position in Y (global coordinate) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (m)
25"AbsZg"  Node position in Z (global coordinate) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (m)
26"AbsXr"  Node position in X (relative to root) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m)
27"AbsYr"  Node position in Y (relative to root) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m)
28"AbsZr"  Node position in Z (relative to root) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m)
29"TVxg"  Sectional translational velocities (absolute) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (m/s)
30"TVyg"  Sectional translational velocities (absolute) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (m/s)
31"TVzg"  Sectional translational velocities (absolute) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (m/s)
32"TVxl"  Sectional translational velocities (absolute) l: a floating coordinate system local to the deflected beam (m/s)
33"TVyl"  Sectional translational velocities (absolute) l: a floating coordinate system local to the deflected beam (m/s)
34"TVzl"  Sectional translational velocities (absolute) l: a floating coordinate system local to the deflected beam (m/s)
35"TVxr"  Sectional translational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m/s)
36"TVyr"  Sectional translational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m/s)
37"TVzr"  Sectional translational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m/s)
38"RVxg"  Sectional angular/rotational velocities (absolute) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (deg/s)
39"RVyg"  Sectional angular/rotational velocities (absolute) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (deg/s)
40"RVzg"  Sectional angular/rotational velocities (absolute) g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system (deg/s)
41"RVxl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (deg/s)
42"RVyl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (deg/s)
43"RVzl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (deg/s)
44"RVxr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (deg/s)
45"RVyr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (deg/s)
46"RVzr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (deg/s)
47"TAxl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (m/s^2)
48"TAyl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (m/s^2)
49"TAzl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (m/s^2)
50"TAxr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m/s^2)
51"TAyr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m/s^2)
52"TAzr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (m/s^2)
53"RAxl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (deg/s^2)
54"RAyl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (deg/s^2)
55"RAzl"  Sectional angular/rotational velocities (absolute) l: a floating coordinate system local to the deflected beam (deg/s^2)
56"RAxr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (deg/s^2)
57"RAyr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (deg/s^2)
58"RAzr"  Sectional angular/rotational velocities (absolute) r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (deg/s^2)
59"PFxL"  Applied point forces at each node expressed in l l: a floating coordinate system local to the deflected beam (N)
60"PFyL"  Applied point forces at each node expressed in l l: a floating coordinate system local to the deflected beam (N)
61"PFzL"  Applied point forces at each node expressed in l l: a floating coordinate system local to the deflected beam (N)
62"PMxL"  Applied point moments at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm)
63"PMyL"  Applied point moments at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm)
64"PMzL"  Applied point moments at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm)
65"DFxL"  Applied distributed forces at each node expressed in l l: a floating coordinate system local to the deflected beam (N/m)
66"DFyL"  Applied distributed forces at each node expressed in l l: a floating coordinate system local to the deflected beam (N/m)
67"DFzL"  Applied distributed forces at each node expressed in l l: a floating coordinate system local to the deflected beam (N/m)
68"DMxL"  Applied distributed moments at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm/m)
69"DMyL"  Applied distributed moments at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm/m)
70"DMzL"  Applied distributed moments at each node expressed in l l: a floating coordinate system local to the deflected beam (Nm/m)
71"DFxR"  Applied distributed forces at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N/m)
72"DFyR"  Applied distributed forces at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N/m)
73"DFzR"  Applied distributed forces at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N/m)
74"DMxR"  Applied distributed forces at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm/m)
75"DMyR"  Applied distributed forces at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm/m)
76"DMzR"  Applied distributed forces at each node expressed in r r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm/m)
77"FFbxl"  Gyroscopic force x l: a floating coordinate system local to the deflected beam (N)
78"FFbyl"  Gyroscopic force y l: a floating coordinate system local to the deflected beam (N)
79"FFbzl"  Gyroscopic force z l: a floating coordinate system local to the deflected beam (N)
80"FFbxr"  Gyroscopic force x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
81"FFbyr"  Gyroscopic force y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
82"FFbzr"  Gyroscopic force z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
83"MFbxl"  Gyroscopic moment about x l: a floating coordinate system local to the deflected beam (Nm)
84"MFbyl"  Gyroscopic moment about y l: a floating coordinate system local to the deflected beam (Nm)
85"MFbzl"  Gyroscopic moment about z l: a floating coordinate system local to the deflected beam (Nm)
86"MFbxr"  Gyroscopic moment about x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
87"MFbyr"  Gyroscopic moment about y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
88"MFbzr"  Gyroscopic moment about z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
89"FFcxl"  Elastic restoring force Fc x l: a floating coordinate system local to the deflected beam (N)
90"FFcyl"  Elastic restoring force Fc y l: a floating coordinate system local to the deflected beam (N)
91"FFczl"  Elastic restoring force Fc z l: a floating coordinate system local to the deflected beam (N)
92"FFcxr"  Elastic restoring force Fc x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
93"FFcyr"  Elastic restoring force Fc y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
94"FFczr"  Elastic restoring force Fc z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
95"MFcxl"  Elastic restoring moment Fc about x l: a floating coordinate system local to the deflected beam (Nm)
96"MFcyl"  Elastic restoring moment Fc about y l: a floating coordinate system local to the deflected beam (Nm)
97"MFczl"  Elastic restoring moment Fc about z l: a floating coordinate system local to the deflected beam (Nm)
98"MFcxr"  Elastic restoring moment Fc about x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
99"MFcyr"  Elastic restoring moment Fc about y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
100"MFczr"  Elastic restoring moment Fc about z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
101"FFdxl"  Elastic restoring force Fd x l: a floating coordinate system local to the deflected beam (N)
102"FFdyl"  Elastic restoring force Fd y l: a floating coordinate system local to the deflected beam (N)
103"FFdzl"  Elastic restoring force Fd z l: a floating coordinate system local to the deflected beam (N)
104"FFdxr"  Elastic restoring force Fd x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
105"FFdyr"  Elastic restoring force Fd y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
106"FFdzr"  Elastic restoring force Fd z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
107"MFdxl"  Elastic restoring moment Fd about x l: a floating coordinate system local to the deflected beam (Nm)
108"MFdyl"  Elastic restoring moment Fd about y l: a floating coordinate system local to the deflected beam (Nm)
109"MFdzl"  Elastic restoring moment Fd about z l: a floating coordinate system local to the deflected beam (Nm)
110"MFdxr"  Elastic restoring moment Fd about x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
111"MFdyr"  Elastic restoring moment Fd about y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
112"MFdzr"  Elastic restoring moment Fd about z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
113"FFgxl"  Gravity force x l: a floating coordinate system local to the deflected beam (N)
114"FFgyl"  Gravity force y l: a floating coordinate system local to the deflected beam (N)
115"FFgzl"  Gravity force z l: a floating coordinate system local to the deflected beam (N)
116"FFgxr"  Gravity force x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
117"FFgyr"  Gravity force y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
118"FFgzr"  Gravity force z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
119"MFgxl"  Gravity moment about x l: a floating coordinate system local to the deflected beam (Nm)
120"MFgyl"  Gravity moment about y l: a floating coordinate system local to the deflected beam (Nm)
121"MFgzl"  Gravity moment about z l: a floating coordinate system local to the deflected beam (Nm)
122"MFgxr"  Gravity moment about x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
123"MFgyr"  Gravity moment about y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
124"MFgzr"  Gravity moment about z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
125"FFixl"  Inertial force x l: a floating coordinate system local to the deflected beam (N)
126"FFiyl"  Inertial force y l: a floating coordinate system local to the deflected beam (N)
127"FFizl"  Inertial force z l: a floating coordinate system local to the deflected beam (N)
128"FFixr"  Inertial force x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
129"FFiyr"  Inertial force y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
130"FFizr"  Inertial force z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (N)
131"MFixl"  Inertial moment about x l: a floating coordinate system local to the deflected beam (Nm)
132"MFiyl"  Inertial moment about y l: a floating coordinate system local to the deflected beam (Nm)
133"MFizl"  Inertial moment about z l: a floating coordinate system local to the deflected beam (Nm)
134"MFixr"  Inertial moment about x r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
135"MFiyr"  Inertial moment about y r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
136"MFizr"  Inertial moment about z r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system (Nm)
137END of input file (the word "END" must appear in the first 3 columns of this last OutList line)
138
Blade Input File¶
The blade input file defines the crosssectional properties at various stations along a blade and six damping coefficient for the whole blade. A sample BeamDyn blade input file is given in Section 4.2.4.8. The blade input file begins with two lines of header information, which is for the user but is not used by the software.
Station_Total
specifies the number crosssectional stations along
the blade axis used in the analysis.
Damp_Type
specifies if structural damping is considered in the
analysis. If Damp_Type = 0
, then no damping is
considered in the analysis and the six damping coefficient in the next
section will be ignored. If Damp_Type = 1
, structural
damping will be included in the analysis.
This section specifies six damping coefficients, \(\mu_{ii}\) with \(i \in [1,6]\), for six DOFs (three translations and three rotations). Viscous damping is implemented in BeamDyn where the damping forces are proportional to the strain rate. These are stiffnessproportional damping coefficients, whereby the \(6\times6\) damping matrix at each cross section is scaled from the \(6 \times 6\) stiffness matrix by these diagonal entries of a \(6 \times 6\) scaling matrix:
where \(\mathcal{\underline{F}}^{Damp}\) is the damping force, \(\underline{\underline{S}}\) is the \(6 \times 6\) crosssectional stiffness matrix, \(\dot{\underline{\epsilon}}\) is the strain rate, and \(\underline{\underline{\mu}}\) is the damping coefficient matrix defined as
This section specifies the crosssectional properties at each of the
Station_Total
stations. For each station, a nondimensional
parameter \(\eta\) specifies the station location along the local
blade reference axis ranging from \([0.0,1.0]\). The first and last
station parameters must be set to \(0.0\) (for the blade root) and
\(1.0\) (for the blade tip), respectively.
Following the station location parameter \(\eta\), there are two \(6 \times 6\) matrices providing the structural and inertial properties for this crosssection. First is the stiffness matrix and then the mass matrix. We note that these matrices are defined in a local coordinate system along the blade axis with \(Z_{l}\) directing toward the unit tangent vector of the blade reference axis. For a crosssection without coupling effects, for example, the stiffness matrix is given as follows:
where \(K_{ShrEdg}\) and \(K_{ShrFlp}\) are the edge and flap shear stiffnesses, respectively; \(EA\) is the extension stiffness; \(EI_{Edg}\) and \(EI_{Flp}\) are the edge and flap stiffnesses, respectively; and \(GJ\) is the torsional stiffness. It is pointed out that for a generic crosssection, the sectional property matrices can be derived from a sectional analysis tool, e.g. VABS, BECAS, or NuMAD/BPE.
A generalized sectional mass matrix is given by:
where \(m\) is the mass density per unit span; \(X_{cm}\) and \(Y_{cm}\) are the local coordinates of the sectional center of mass, respectively; \(i_{Edg}\) and \(i_{Flp}\) are the edge and flap mass moments of inertia per unit span, respectively; \(i_{plr}\) is the polar moment of inertia per unit span; and \(i_{cp}\) is the sectional crossproduct of inertia per unit span. We note that for beam structure, the \(i_{plr}\) is given as (although this relationship is not checked by BeamDyn)
Output Files¶
BeamDyn produces three types of output files, depending on the options selected: an echo file, a summary file, and a timeseries results file. The following sections detail the purpose and contents of these files.
Echo File¶
If the user sets the Echo
flag to TRUE in the BeamDyn primary
input file, the contents of this file will be echoed to a file with the
naming convention InputFile.ech
. The echo file is helpful for
debugging the input files. The contents of an echo file will be
truncated if BeamDyn encounters an error while parsing an input file.
The error usually corresponds to the line after the last successfully
echoed line.
Summary File¶
In standalone mode, BeamDyn generates a summary file with the naming
convention, InputFile.sum
if the SumPrint
parameter is set
to TRUE. When coupled to FAST, the summary file is named
InputFile.BD.sum
. This file summarizes key information about the
simulation, including:
Blade mass.
Blade length.
Blade center of mass.
Initial global position vector in BD coordinate system.
Initial global rotation tensor in BD coordinate system.
Analysis type.
Numerical damping coefficients.
Time step size.
Maximum number of iterations in the NewtonRaphson solution.
Convergence parameter in the stopping criterion.
Factorization frequency in the NewtonRaphson solution.
Numerical integration (quadrature) method.
FE mesh refinement factor used in trapezoidal quadrature.
Number of elements.
Number of FE nodes.
Initial position vectors of FE nodes in BD coordinate system.
Initial rotation vectors of FE nodes in BD coordinate system.
Quadrature point position vectors in BD coordinate system. For Gauss quadrature, the physical coordinates of Gauss points are listed. For trapezoidal quadrature, the physical coordinates of the quadrature points are listed.
Sectional stiffness and mass matrices at quadrature points in local blade reference coordinate system. These are the data being used in calculations at quadrature points and they can be different from the section in Blade Input File since BeamDyn linearly interpolates the sectional properties into quadrature points based on need.
Initial displacement vectors of FE nodes in BD coordinate system.
Initial rotational displacement vectors of FE nodes in BD coordinate system.
Initial translational velocity vectors of FE nodes in BD coordinate system.
Initial angular velocity vectors of FE nodes in BD coordinate system.
Requested output information.
All of these quantities are output in this file in the BD coordinate system, the one being used internally in BeamDyn calculations. The initial blade reference coordinate system, denoted by a subscript \(r0\) that follows the IEC standard, is related to the internal BD coordinate system by Table 4.3 in Section 4.2.4.5.
Results File¶
The BeamDyn timeseries results are written to a textbased file with
the naming convention DriverInputFile.out
where
DriverInputFile
is the name of the driver input file when BeamDyn
is run in the standalone mode. If BeamDyn is coupled to FAST, then FAST
will generate a master results file that includes the BeamDyn results.
The results in DriverInputFile.out
are in table format, where each
column is a data channel (the first column always being the simulation
time), and each row corresponds to a simulation time step. The data
channel are specified in the OUTPUT section of the primary input file.
The column format of the BeamDyngenerated file is specified using the
OutFmt
parameters of the primary input file.
BeamDyn Theory¶
This section focuses on the theory behind the BeamDyn module. The theoretical foundation, numerical tools, and some special handling in the implementation will be introduced. References will be provided in each section detailing the theories and numerical tools.
In this chapter, matrix notation is used to denote vectorial or vectoriallike quantities. For example, an underline denotes a vector \(\underline{u}\), an over bar denotes unit vector \(\bar{n}\), and a double underline denotes a tensor \(\underline{\underline{\Delta}}\). Note that sometimes the underlines only denote the dimension of the corresponding matrix.
Coordinate Systems¶
Fig. 4.28 (in Section 4.2.4.3) and Fig. 4.29 show the coordinate system used in BeamDyn.
The global coordinate system is denoted as X
, Y
, and Z
in Fig. 4.29. This is an inertial frame and in FAST its
origin is usually placed at the bottom of the tower as shown.
The BD coordinate system is denoted as \(x_1\), \(x_2\), and \(x_3\) respectively in Fig. 4.29. This is an inertial frame used internally in BeamDyn (i.e., doesn’t rotate with the rotor) and its origin is placed at the initial position of the blade root point.
The blade reference coordinate system is denoted as \(X_{rt}\), \(Y_{rt}\), and \(Z_{rt}\) in Fig. 4.29 at initialization (\(t = 0\)). The blade reference coordinate system is a floating frame that attaches at the blade root and is rotating with the blade. Its origin is at the blade root and the directions of axes following the IEC standard, i.e., \(Z_r\) is pointing along the blade axis from root to tip; \(Y_r\) pointing nominally towards the trailing edge of the blade and parallel with the chord line at the zerotwist blade station; and \(X_r\) is orthogonal with the \(Y_r\) and \(Z_r\) axes, such that they form a righthanded coordinate system (pointing nominally downwind). We note that the initial blade reference coordinate system, denoted by subscript \(r0\), coincides with the BD coordinate system, which is used internally in BeamDyn and introduced in the previous section. The axis convention relations between the initial blade reference coordinate system and the BD coordinate system can be found in Table 4.3.
Blade Frame 
\(X_{r0}\) 
\(Y_{r0}\) 
\(Z_{r0}\) 
BD Frame 
\(x_2\) 
\(x_3\) 
\(x_1\) 
The local blade coordinate system is used for some input and output quantities, for example, the crosssectional mass and stiffness matrices and the the sectional force and moment resultants. This coordinate system is different from the blade reference coordinate system in that its \(Z_l\) axis is always tangent to the blade axis as the blade deflects. Note that a subscript \(l\) denotes the local blade coordinate system.
Geometrically Exact Beam Theory¶
The theoretical foundation of BeamDyn is the geometrically exact beam theory. This theory features the capability of beams that are initially curved and twisted and subjected to large displacement and rotations. Along with a proper twodimensional (2D) crosssectional analysis, the coupling effects between all six DOFs, including extension, bending, shear, and torsion, can be captured by GEBT as well . The term, “geometrically exact” refer to the fact that there is no approximation made on the geometries, including both initial and deformed geometries, in formulating the equations [Hod06].
The governing equations of motion for geometrically exact beam theory can be written as [Bau10]
where \({\underline{h}}\) and \({\underline{g}}\) are the linear and angular momenta resolved in the inertial coordinate system, respectively; \({\underline{F}}\) and \({\underline{M}}\) are the beam’s sectional force and moment resultants, respectively; \({\underline{u}}\) is the onedimensional (1D) displacement of a point on the reference line; \({\underline{x}}_0\) is the position vector of a point along the beam’s reference line; and \({\underline{f}}\) and \({\underline{m}}\) are the distributed force and moment applied to the beam structure. The notation \((\bullet)^\prime\) indicates a derivative with respect to beam axis \(x_1\) and \(\dot{(\bullet)}\) indicates a derivative with respect to time. The tilde operator \(({\widetilde{\bullet}})\) defines a skewsymmetric tensor corresponding to the given vector. In the literature, it is also termed as “crossproduct matrix”. For example,
The constitutive equations relate the velocities to the momenta and the 1D strain measures to the sectional resultants as
where \(\underline{\underline{\mathcal{M}}}\) and \(\underline{\underline{\mathcal{C}}}\) are the \(6 \times 6\) sectional mass and stiffness matrices, respectively (note that they are not really tensors); \(\underline{\epsilon}\) and \(\underline{\kappa}\) are the 1D strains and curvatures, respectively; and, \(\underline{\omega}\) is the angular velocity vector that is defined by the rotation tensor \(\underline{\underline{R}}\) as \(\underline{\omega} = axial(\dot{\underline{\underline{R}}}~\underline{\underline{R}}^T)\). The axial vector \({\underline{a}}\) associated with a secondorder tensor \({\underline{\underline{A}}}\) is denoted \({\underline{a}}=axial({\underline{\underline{A}}})\) and its components are defined as
The 1D strain measures are defined as
where \({\underline{k}} = axial [({\underline{\underline{R R_0}}})^\prime ({\underline{\underline{R R_0}}})^T]\) is the sectional curvature vector resolved in the inertial basis; \({\underline{\underline{R}}}_0\) is the initial rotation tensor; and \(\bar{\imath}_1\) is the unit vector along \(x_1\) direction in the inertial basis. These three sets of equations, including equations of motion Eq. (4.65), constitutive equations Eq. (4.66), and kinematical equations Eq. (4.68), provide a full mathematical description of the beam elasticity problems.
Numerical Implementation with Legendre Spectral Finite Elements¶
For a displacementbased finite element implementation, there are six degreeoffreedoms at each node: three displacement components and three rotation components. Here we use \({\underline{q}}\) to denote the elemental displacement array as \(\underline{q}=\left[ \underline{u}^T~~\underline{c}^T\right]\) where \({\underline{u}}\) is the displacement and \({\underline{c}}\) is the rotationparameter vector. The acceleration array can thus be defined as \(\underline{a}=\left[ \ddot{\underline{u}}^T~~ \dot{\underline{\omega}}^T \right]\). For nonlinear finiteelement analysis, the discretized and incremental forms of displacement, velocity, and acceleration are written as
where \({\underline{\underline{N}}}\) is the shape function matrix and \((\hat{\cdot})\) denotes a column matrix of nodal values.
The displacement fields in an element are approximated as
where \(h^k(\xi)\), the component of shape function matrix \({\underline{\underline{N}}}\), is the \(p^{th}\)order polynomial Lagrangianinterpolant shape function of node \(k\), \(k=\{1,2,...,p+1\}\), \({\underline{\hat{u}}}^k\) is the \(k^{th}\) nodal value, and \(\xi \in \left[1,1\right]\) is the element natural coordinate. However, as discussed in [BEH08], the 3D rotation field cannot simply be interpolated as the displacement field in the form of
where \({\underline{c}}\) is the rotation field in an element and \({\underline{\hat{c}}}^k\) is the nodal value at the \(k^{th}\) node, for three reasons:
rotations do not form a linear space so that they must be “composed” rather than added;
a rescaling operation is needed to eliminate the singularity existing in the vectorial rotation parameters;
the rotation field lacks objectivity, which, as defined by [JelenicC99], refers to the invariance of strain measures computed through interpolation to the addition of a rigidbodymotion.
Therefore, we adopt the more robust interpolation approach proposed by [JelenicC99] to deal with the finite rotations. Our approach is described as follows
 Step 1:
Compute the nodal relative rotations, \({\underline{\hat{r}}}^k\), by removing the reference rotation, \({\underline{\hat{c}}}^1\), from the finite rotation at each node, \({\underline{\hat{r}}}^k = ({\underline{\hat{c}}}^{1}) \oplus {\underline{\hat{c}}}^k\). It is noted that the minus sign on \({\underline{\hat{c}}}^1\) denotes that the relative rotation is calculated by removing the reference rotation from each node. The composition in that equation is an equivalent of \({\underline{\underline{R}}}({\underline{\hat{r}}}^k) = {\underline{\underline{R}}}^T({\underline{\hat{c}}}^1)~{\underline{\underline{R}}}({\underline{{\underline{c}}}}^k).\)
 Step 2:
Interpolate the relativerotation field: \({\underline{r}}(\xi) = h^k(\xi) {\underline{\hat{r}}}^k\) and \({\underline{r}}^\prime(\xi) = h^{k \prime}(\xi) {\underline{\hat{r}}}^k\). Find the curvature field \({\underline{\kappa}}(\xi) = {\underline{\underline{R}}}({\underline{\hat{c}}}^1) {\underline{\underline{H}}}({\underline{r}}) {\underline{r}}^\prime\), where \({\underline{\underline{H}}}\) is the tangent tensor that relates the curvature vector \({\underline{k}}\) and rotation vector \({\underline{c}}\) as
()¶\[ {\underline{k}} = {\underline{\underline{H}}}~ {\underline{c}}^\prime\] Step 3:
Restore the rigidbody rotation removed in Step 1: \({\underline{c}}(\xi) = {\underline{\hat{c}}}^1 \oplus {\underline{r}}(\xi)\).
Note that the relativerotation field can be computed with respect to any of the nodes of the element; we choose node 1 as the reference node for convenience. In the LSFE approach, shape functions (i.e., those composing \({\underline{\underline{N}}}\)) are \(p^{th}\)order Lagrangian interpolants, where nodes are located at the \(p+1\) GaussLobattoLegendre (GLL) points in the \([1,1]\) element naturalcoordinate domain. Fig. 4.30 shows representative LSFE basis functions for fourth and eighthorder elements. Note that nodes are clustered near element endpoints. More details on the LSFE and its applications can be found in References [Pat84, RP87, SG03, SG04].
WienerMilenković Rotation Parameter¶
In BeamDyn, the 3D rotations are represented as WienerMilenković parameters defined in the following equation:
where \(\phi\) is the rotation angle and \(\bar{n}\) is the unit vector of the rotation axis. It can be observed that the valid range for this parameter is \(\phi < 2 \pi\). The singularities existing at integer multiples of \(\pm 2 \pi\) can be removed by a rescaling operation at \(\pi\) as:
where \({\underline{p}}\), \({\underline{q}}\), and \({\underline{r}}\) are the vectorial parameterization of three finite rotations such that \({\underline{\underline{R}}}({\underline{r}}) = {\underline{\underline{R}}}({\underline{p}}) {\underline{\underline{R}}}({\underline{q}})\), \(p_0 = 2  {\underline{p}}^T {\underline{p}}/8\), \(q_0 = 2  {\underline{q}}^T {\underline{q}}/8\), \(\Delta_1 = (4p_0)(4q_0)\), and \(\Delta_2 = p_0 q_0  {\underline{p}}^T {\underline{q}}\). It is noted that the rescaling operation could cause a discontinuity of the interpolated rotation field; therefore a more robust interpolation algorithm has been introduced in Section Numerical Implementation with Legendre Spectral Finite Elements where the rescalingindependent relativerotation field is interpolated.
The rotation tensor expressed in terms of WienerMilenković parameters is
where \({\underline{c}} = \left[ c_1~~c_2~~c_3\right]^T\) is the WienerMilenković parameter and \(c_0 = 2  \frac{1}{8}{\underline{c}}^T {\underline{c}}\). The relation between rotation tensor and direction cosine matrix (DCM) is
Interested users are referred to [BEH08] and [WYS13] for more details on the rotation parameter and its implementation with GEBT.
Linearization Process¶
The nonlinear governing equations introduced in the previous section are solved by NewtonRaphson method, where a linearization process is needed. The linearization of each term in the governing equations are presented in this section.
According to [Bau10], the linearized governing equations in Eq. (4.65) are in the form of
where the \(\hat{{\underline{\underline{M}}}}\), \(\hat{{\underline{\underline{G}}}}\), and \(\hat{{\underline{\underline{K}}}}\) are the elemental mass, gyroscopic, and stiffness matrices, respectively; \(\hat{{\underline{F}}}\) and \(\hat{{\underline{F}}}^{ext}\) are the elemental forces and externally applied loads, respectively. They are defined for an element of length \(l\) along \(x_1\) as follows
where \(\mathcal{{\underline{F}}}^{ext}\) is the applied load vector. The new matrix notations in Eqs. (4.78) to are briefly introduced here. \(\mathcal{{\underline{F}}}^C\) and \(\mathcal{{\underline{F}}}^D\) are elastic forces obtained from Eq. (4.65) as
where \(\underline{\underline{0}}\) denotes a \(3 \times 3\) null matrix. The \({\underline{\underline{\mathcal{G}}}}^I\), \({\underline{\underline{\mathcal{K}}}}^I\), \(\mathcal{{\underline{\underline{O}}}}\), \(\mathcal{{\underline{\underline{P}}}}\), \(\mathcal{{\underline{\underline{Q}}}}\), and \({\underline{\mathcal{F}}}^I\) in Eqs. (4.78) are defined as
where \(m\) is the mass density per unit length, \({\underline{\eta}}\) is the location of the sectional center of mass, \({\underline{\underline{\varrho}}}\) is the moment of inertia tensor, and the following notations were introduced to simplify the above expressions
Damping Forces and Linearization¶
A viscous damping model has been implemented into BeamDyn to account for the structural damping effect. The damping force is defined as
where \({\underline{\underline{\mu}}}\) is a userdefined dampingcoefficient diagonal matrix. The damping force can be recast in two separate parts, like \({\underline{\mathcal{F}}}^C\) and \({\underline{\mathcal{F}}}^D\) in the elastic force, as
The linearization of the structural damping forces are as follows:
where the newly introduced matrices are defined as
where \({\underline{\underline{O}}}_{12}\) and \({\underline{\underline{G}}}_{12}\) are the \(3 \times 3\) sub matrices of \(\mathcal{{\underline{\underline{O}}}}\) and \(\mathcal{{\underline{\underline{G}}}}\) as \({\underline{\underline{C}}}_{12}\) in Eq. (4.81).
Convergence Criterion and Generalized\(\alpha\) Time Integrator¶
The system of nonlinear equations in Eqs. (4.65) are solved using the NewtonRaphson method with the linearized form in Eq. (4.77). In the present implementation, an energylike stopping criterion has been chosen, which is calculated as
where \(\cdot\) denotes the absolute value, \(\Delta \mathbf{U}\) is the incremental displacement vector, \(\mathbf{R}\) is the vector of externally applied nodal point loads, \(\mathbf{F}\) is the vector of nodal point forces corresponding to the internal element stresses, and \(\epsilon_E\) is the userdefined energy tolerance. The superscript on the left side of a variable denotes the timestep number (in a dynamic analysis), while the one on the right side denotes the NewtonRaphson iteration number. As pointed out by [BC80], this criterion provides a measure of when both the displacements and the forces are near their equilibrium values.
Time integration is performed using the generalized\(\alpha\) scheme in BeamDyn, which is an unconditionally stable (for linear systems), secondorder accurate algorithm. The scheme allows for users to choose integration parameters that introduce highfrequency numerical dissipation. More details regarding the generalized\(\alpha\) method can be found in [Bau10, CH93].
Calculation of Reaction Loads¶
Since the root motion of the wind turbine blade, including displacements and rotations, translational and angular velocities, and translational and angular accelerates, are prescribed as inputs to BeamDyn either by the driver (in standalone mode) or by FAST glue code (in FASTcoupled mode), the reaction loads at the root are needed to satisfy equality of the governing equations. The reaction loads at the root are also the loads passing from blade to hub in a full turbine analysis.
The governing equations in Eq. (4.65) can be recast in a compact form
with all the vectors defined in Section [sec:LinearProcess]. At the blade root, the governing equation is revised as
where \({\underline{\mathcal{F}}}^R = \left[ {\underline{F}}^R~~~{\underline{M}}^R\right]^T\) is the reaction force vector and it can be solved from Eq. (4.88) given that the motion fields are known at this point.
Calculation of Blade Loads¶
BeamDyn can also calculate the blade loads at each finite element node along the blade axis. The governing equation in Eq. (4.87) are recast as
where the inertial force vector \({\underline{\mathcal{F}}}^I\) is split into \({\underline{\mathcal{F}}}^A\) and \({\underline{\mathcal{F}}}^V\):
The blade loads are thus defined as
We note that if structural damping is considered in the analysis, the \({\underline{\mathcal{F}}}^{C}_d\) and \({\underline{\mathcal{F}}}^D_d\) are incorporated into the internal elastic forces, \({\underline{\mathcal{F}}}^C\) and \({\underline{\mathcal{F}}}^D\), for calculation.
Future Work¶
The following list contains future work on BeamDyn software:
Eliminating numerical problems in single precision.
Implementing eigenvalue analysis.
Improving input options for standalone version to make it more userfriendly.
Implementing GEBT based on modal method for computational efficiency.
Adding more options for blade crosssectional properties inputs. For example, for general isotropic beams, engineering parameters including sectional offsets, material properties, etc will be used to generate the 6 \(\times\) 6 matrices needed by BeamDyn.
Writing a general guidance on modeling composite beam structures using BeamDyn, , for example, how to select a time step, how to select the model discretization, how to define the blade reference axis, where to get 6x6 mass/stiffness matrices, etc.
Extending applications in FAST to other slender structures in the wind turbine system, for example, tower, mooring lines, and shaft.
Developing a simplified form of GEBT with only rotational DOFs (bending, torsion) for computational efficiency.
References¶
 BC80
K. J. Bathe and A. P. Cimento. Some practical procedures for the solution of nonlinear finite element equations. Computer Methods in Applied Mechanics and Engineering, 22:59–85, 1980. http://web.mit.edu/kjb/www/Publications_Prior_to_1998/Some_Practical_Procedures_for_the_Solution_of_Nonlinear_Finite_Element_Equations.pdf. doi:10.1016/00457825(80)900511.
 Bau10
O. A. Bauchau. Flexible Multibody Dynamics. Springer, 2010. doi:10.1007/9789400703353.
 BEH08
O.A. Bauchau, A. Epple, and S.D. Heo. Interpolation of finite rotations in flexible multibody dynamics simulations. Proceedings of the Institution of Mechanical Engineers, Part K: Journal of Multibody Dynamics, 222:353–366, 2008.
 CH93
J. Chung and G. M. Hulbert. A time integration algorithm for structural dynamics with improved numerical dissipation: the generalizedα method. Journal of Applied Mechanics, 60:371–375, 1993. doi:10.1115/1.2900803.
 GSJ13
A. Gasmi, M.A. Sprague, and J.M. Jonkman. Numerical stability and accuracy of temporally coupled multi physics modules in windturbine cae tools. In Proceedings of the 51st AIAA Aerospace Sciences Meeting including the New Horizons Forum and Aerospace Exposition. Grapevine, Texas, January 2013.
 Hod06
Dewey H. Hodges. Nonlinear Composite Beam Theory. AIAA, 2006.
 JelenicC99
G. Jelenić and M. A. Crisfield. Geometrically exact 3d beam theory: implementation of a straininvariant finite element for statics and dynamics. Computer Methods in Applied Mechanics and Engineering, 171:141–171, 1999.
 Jon13
J.M. Jonkman. The new modularization framework for the fast wind turbine cae tool. In Proceedings of the 51st AIAA Aerospace Sciences Meeting including the New Horizons Forum and Aerospace Exposition. Grapevine, Texas, January 2013.
 JJ13
Jason Jonkman and Bonnie Jonkman. Fast v8. https://nwtc.nrel.gov/FAST8, October 2013. [Online; accessed 29OCTOBER2014].
 Pat84
A. T. Patera. A spectral element method for fluid dynamics: laminar flow in a channel expansion. Journal of Computational Physics, 54:468–488, 1984.
 RP87
E. M. Ronquist and A. T. Patera. A legendre spectral element method for the stefan problem. International Journal for Numerical Methods in Engineering, 24:2273–2299, 1987.
 SG03
M. A. Sprague and T. L. Geers. Spectral elements and field separation for an acoustic fluid subject to cavitation. Journal of Computational Physics, 184:149–162, 2003.
 SG04
M. A. Sprague and T. L. Geers. A spectralelement method for modeling cavitation in transient fluidstructure interaction. International Journal for Numerical Methods in Engineering, 60:2467–2499, 2004.
 SJJ14
M.A. Sprague, J.M. Jonkman, and B.J. Jonkman. Fast modular wind turbine cae tool: non matching spatial and temporal meshes. In Proceedings of the 32nd ASME Wind Energy Symposium. National Harbor, Maryland, January 2014.
 WJSJ15
Q. Wang, N. Johnson, M.A. Sprague, and J. Jonkman. Beamdyn: a highfidelity wind turbine blade solver in the fast modular framework. In Proceedings of the 33rd ASME Wind Energy Symposium. Kissimmee, Florida, January 2015. https://www.nrel.gov/docs/fy15osti/63165.pdf.
 WS13
Q. Wang and M.A. Sprague. A legendre spectral finite element implementation of geometrically exact beam theory. In Proceedings of the 54th Structures, Structural Dynamics, and Materials Conference. Boston, Massachusetts, April 2013.
 WSJJ14
Q. Wang, M.A. Sprague, J. Jonkman, and N. Johnson. Nonlinear legendre spectral finite elements for wind turbine blade dynamics. In Proceedings of the 32nd ASME Wind Energy Symposium. National Harbor, Maryland, January 2014.
 WSJJ16
Q. Wang, M.A. Sprague, J. Jonkman, and B. Jonkman. Partitioned nonlinear structural analysis of wind turbines using beamdyn. In Proceedings of the 34th ASME Wind Energy Symposium. San Diego, California, January 2016.
 WYS13
Q. Wang, W. Yu, and M.A. Sprague. Gemoetrically nonlinear analysis of composite beams using wienermilenković parameters. In Proceedings of the 54th Structures, Structural Dynamics, and Materials Conference. Boston, Massachusetts, April 2013.
Appendix¶
BeamDyn Input Files¶
In this appendix we describe the BeamDyn inputfile structure and provide examples for the NREL 5MW Reference Wind Turbine.
OpenFAST+BeamDyn and standalone BeamDyn (static and dynamic) simulations all require two files:
1) BeamDyn primary input file
(NREL 5MW static example)
: This file includes information on the numericalsolution parameters (e.g., numerical damping, quadrature rules), and the geometric definition of the beam reference line via “members” and “key points”. This file also specifies the “blade input file.”
BeamDyn blade input file
(NREL 5MW example)
:
Standalone BeamDyn simulation also require a driver input file; we list here examples for static and dynamic simulations:
3a) BeamDyn driver for dynamic simulations (NREL 5MW example)
: This file specifies the inputs for a single blade (e.g., forces, orientations, root velocity) and specifies the BeamDyn primary input file.
3b) BeamDyn driver for static simulations (NREL 5MW example)
: Same as above but for static analysis.
BeamDyn List of Output Channels¶
This is a list of all possible output parameters for the BeamDyn module.
The names are grouped by meaning, but can be ordered in the OUTPUTS
section of the BeamDyn primary input file as the user sees fit.
N\(\beta\), refers to output node \(\beta\), where
\(\beta\) is a number in the range [1,9], corresponding to entry
\(\beta\) in the OutNd
list. When coupled to FAST,
“\(B\alpha\)” is prefixed to each output name, where \(\alpha\)
is a number in the range [1,3], corresponding to the blade number. The
outputs are expressed in one of the following three coordinate systems:
r: a floating reference coordinate system fixed to the root of the moving beam; when coupled to FAST for blades, this is equivalent to the IEC blade (b) coordinate system.
l: a floating coordinate system local to the deflected beam.
g: the global inertial frame coordinate system; when coupled to FAST, this is equivalent to FAST’s global inertial frame (i) coordinate system.
SubDyn User Guide and Theory Manual¶
This manual offers both a quick reference guide and a more indepth theory guide for the SubDyn software program. It is intended to be used by the general user in combination with the OpenFAST and HydroDyn manuals. The documentation was started from [DJH15] by Damiani et al. The manual will be updated as new releases are issued and as needed to provide further information on advancements or modifications to the software.
The authors would like to acknowledge the following contributors: R. Damiani, E. Branlard, J. Jonkman, A. Robertson, F. Wendt and B. Barahona. Additional contributors may be found on github. We also are grateful to the U.S. Department of Energy Wind and Water Power Program for supporting the development of this software.
Introduction¶
SubDyn is a timedomain structuraldynamics module for multimember fixedbottom substructures created by the National Renewable Energy Laboratory (NREL) through U.S. Department of Energy Wind and Water Power Program support. The module has been coupled into the FAST aerohydroservoelastic computeraided engineering (CAE) tool. Substructure types supported by SubDyn include monopiles, tripods, jackets, and other nonfloating latticetype substructures common for offshore wind installations in shallow and transitional water depths. SubDyn can also be used to model lattice support structures for landbased wind turbines.
The new SubDyn module follows the requirements of the FAST modularization framework, couples to OpenFAST, and provides new capabilities (relative to prior released versions of the software) for modeling the dynamic loading on multimember substructures. (Refer to Appendix E and the changelog.txt file that is provided in the archives for more details about changes among different versions.) SubDyn can also be driven as a standalone code to compute the mode shapes, natural frequencies, and timedomain responses of substructures under prescribed motion at the interface to the tower, uncoupled from FAST and in the absence of external loading other than gravity.
SubDyn relies on two main engineering schematizations: (1) a linear frame finiteelement beam model (LFEB), and (2) a dynamics system reduction via the CraigBampton(CB) method, together with a staticimprovement method (SIM), greatly reducing the number of modes needed to obtain an accurate solution. More details can be found in Section 6, and in [SDRJ13], [DS13], [DSRJ13], [JBH+20].
In SubDyn, the substructure is considered to be either clamped or supported by springs at the seabed, and rigidly connected to the transition piece (TP) at the substructure top nodes (interface nodes). The spring constants are provided by the user to simulate soilstructureinteraction (SSI). Other restraint formulations may be implemented in the future. Only the substructure structural dynamics are intended to be modeled within SubDyn. When integrated with FAST, the structural dynamics of the TP, tower, and rotornacelle assembly (RNA) are modeled within FAST’s ElastoDyn module and hydrodynamics are modeled within FAST’s HydroDyn module. For full lattice support structures or other structures with no transition piece, however, the entire support structure up to the yaw bearing may be modeled within SubDyn. Modeling the tower in SubDyn as opposed to ElastoDyn, for example, allows for the possibility of including more than the first two foreaft and sidetoside bending modes, thus accounting for more general flexibility of the tower and its segments. However, for tubular towers, the structural model in ElastoDyn tends to be more accurate because ElastoDyn considers geometric nonlinearities not treated in SubDyn.
Loads and responses are transferred between SubDyn, HydroDyn, and ElastoDyn via the FAST driver program (glue code) to enable hydroelastic interaction at each coupling time step. At the interface nodes, the TP six degreeoffreedom (DOF) displacements (three translations and three rotations), velocities, and accelerations are inputs to SubDyn from ElastoDyn; and the six reaction loads at the TP (three forces and three moments) are outputs from SubDyn to ElastoDyn. SubDyn also outputs the local substructure displacements, velocities, and accelerations to HydroDyn in order to calculate the local hydrodynamic loads that become inputs for SubDyn. In addition, SubDyn can calculate member internal reaction loads, as requested by the user (see Figure 1).
The input file defines the substructure geometry, material properties, restraints and SSI data files, finiteelement resolution, number of retained modes in the dynamics system reduction, modal damping coefficients, and auxiliary parameters. The geometry is defined by joint coordinates in the global reference system (inertialframe coordinate system shown in ), with the origin at the intersection of the undeflected tower centerline with mean sea level (MSL) or ground level for landbased structures. A member connects two joints; multiple members may use a common joint. Nodes are the result of the member refinement into multiple (*NDiv* input parameter) elements (nodes are located at the ends of each element, as shown in ), and they are calculated by the module.
In the current release, the geometry of a member is defined by its outer diameter and wall thickness (assuming a tubular geometry), and the material properties are defined by its Young’s modulus, shear modulus, and mass density. Member properties are specified at the joints; if properties change from one joint to the other, they will be linearly interpolated for the inner elements. Thus, a tapered member will be treated as a cylindrical member with stepwise variation of its properties. In a future release, a tapered finiteelement formulation will be implemented, and a more accurate representation of a tapered member will become available.
The hydrodynamic loads (including buoyancy) are computed by HydroDyn and transferred by the glue code at those nodes that are underwater (submerged nodes). Additionally, the selfweight distributed load components (from gravity) are calculated by SubDyn and applied at all the nodes. Note that other load and inertial properties may be input via the HydroDyn module input file, where marine growth and flooding/ballasting of the members can be specified.
This document is organized as follows. Section Running SubDyn details how to obtain the SubDyn and FAST software archives and run either the standalone version of SubDyn or SubDyn coupled to FAST. Section Input Files describes the SubDyn input files. Section 4 discusses the Output Files generated by SubDyn; these include echo files, a summary file, and the results file. Section 5 provides modeling guidance when using SubDyn. The SubDyn theory is covered in Section SubDyn Theory. Section Known Limitations and Future Work outlines future work, and Section 8 contains a list of references. Example input files are shown in Appendices Section 4.2.5.9 and B. A summary of available output channels are found in Appendix Appendix D. List of Output Channels. Instructions for compiling the standalone SubDyn program are detailed in Appendix D. Appendix E tracks the major changes that have been made to SubDyn for each public release.
Running SubDyn¶
This section discusses how to obtain and execute SubDyn from a personal computer. Both the standalone version and the FASTcoupled version of the software are considered.
Downloading the SubDyn Software¶
There are two forms of the SubDyn software to choose from: stand alone and coupled to the FAST simulator. Although the user may not necessarily need both forms, he/she would likely need to be familiar with and run the standalone model if building a model of the substructure from scratch. The standalone version is also helpful for model troubleshooting and may benefit users who are interested in conducting aerohydroservoelastic simulations of an offshore wind turbine.
Users can refer to the OpenFAST installation to download and compile SubDyn.
Running SubDyn¶
The standalone SubDyn program, SubDyn_win32.exe, simulates substructure dynamic responses of the user’s input model, without coupling to FAST. Unlike the coupled version, the standalone software requires the use of a driver file in addition to the primary SubDyn input file. This driver file specifies inputs normally provided to SubDyn by FAST, including motions of the TP reference point. Both the SubDyn summary file and the results output file are available when using the standalone SubDyn (see Section 4 for more information regarding the SubDyn output files).
Run the standalone SubDyn software from a DOS command prompt by typing, for example:
>SubDyn_win32.exe MyDriverFile.dvr
where, MyDriverFile.dvr is the name of the SubDyn driver file, as described in Section 4.2.5.3.3. The SubDyn primary input file is described in Section Section 4.2.5.3.2.
Run the coupled FAST software from a DOS command prompt by typing, for example:
>FAST_Win32.exe Test21.fst
where, Test21.fst is the name of the primary FAST input file. This input file has a feature switch to enable or disable the SubDyn capabilities within FAST, and a corresponding reference to the SubDyn input file. See the documentation supplied with FAST for further information.
Input Files¶
The user specifies the substructure model parameters, including its geometry and properties, via a primary SubDyn input file. When used in standalone mode, an additional driver input file is required. This driver file specifies inputs normally provided to SubDyn by FAST, including motions of the TP reference point.
No lines should be added or removed from the input files, except in tables where the number of rows is specified.
Additional input files containing soilstructure information (SSIfile) can be provided by the user specifying their paths in the main SubDyn input file under the section titled BASE REACTION JOINTS.
Units¶
SubDyn uses the SI system (kg, m, s, N). Angles are assumed to be in radians unless otherwise specified.
SubDyn Driver Input File¶
The driver input file is only needed for the standalone version of SubDyn and contains inputs that are normally set by FAST, and that are necessary to control the simulation for uncoupled models. It is possible to provide pertimestep inputs to SubDyn, even in standalone mode, by tying the driver file to an additional input file containing timehistories of the TP motion (displacements, velocities, and accelerations). A sample SubDyn driver input file is given in Section 4.2.5.10.
Users can set the Echo flag in this file to TRUE so that SubDyn_win32.exe echoes the contents of the driver input file (useful for debugging errors in the driver file). The echo file has the naming convention of OutRootName.dvr.ech. OutRootName is specified in the SUBDYN section of the driver input file (see below).
Set the gravity constant using the Gravity parameter. SubDyn expects a magnitude, so in SI units this would be set to 9.80665 \(\frac{m}{s^{2}}\) for standard gravity. WtrDpth specifies the water depth (depth of the seabed), based on the reference MSL, and must be a value greater than zero.
SDInputFile is the file name of the primary SubDyn input file. This name should be in quotations and can contain an absolute path or a relative path. All SubDyngenerated output files will be prefixed with OutRootName. If this parameter includes a file path, the output will be generated in that folder. If this output is left empty, the driver filename is used (without the extension) is used. NSteps specifies the number of simulation time steps, and TimeStep specifies the time between steps. Next, the user must specify the location of the TP reference point TP_RefPoint (in the global reference system). This is normally set by FAST through the ElastoDyn input file, and it is the socalled platform reference point location. When coupled to FAST, the platform reference point location is identified by only one (Z) coordinate. The interface joints, defined in SubDyn’s main input file, are rigidly connected to this reference point. To utilize the same geometry definition within SubDyn’s main input file, while still allowing for different substructure orientations about the vertical, the user can set SubRotateZ to a prescribed angle in degrees with respect to the global Zaxis. The entire substructure will be rotated by that angle. (This feature is only available in standalone mode.)
Setting InputsMod = 0 sets all TP referencepoint input motions to zero for all time steps. Setting InputsMod = 1 allows the user to provide steady (fixed) inputs for the TP motion in the STEADY INPUTS section of the file—uTPInSteady, uDotTPInSteady, and uDotDotTPInSteady following the same convention as Table 1 (without time). Setting InputsMod = 2 allows the user to input a timeseries file whose name is specified via the InputsFile parameter. The timeseries input file is a textformatted file. This file has no header lines, NSteps rows, and each i^{th} row has the first column showing time as t = ( i – 1 )*TimeStep (the data will not be interpolated to other times). The remainder of each row is made of whitespaceseparated columns of floating point values representing the necessary motion inputs as shown in Table 1. All motions are specified in the global, inertialframe coordinate system. SubDyn does not check for physical consistency between the displacement, velocity, and acceleration motions specified for the TP reference point in the driver file.
Table 1. TP Reference Point Inputs TimeSeries Data File Contents
Column Number 
Input 
Units 

1 
Time step value 
s 
24 
TP reference point translational displacements along X, Y, and Z 
m 
57 
TP reference point rotational displacements about X, Y, and Z (small angle assumptions apply) 
rad/s 
810 
TP reference point translational velocities along X, Y, and Z 
m/s 
1113 
TP reference point rotational velocities about X, Y, and Z 
rad/s 
1416 
TP reference point translational accelerations along X, Y, and Z 
m/s^2 
1719 
TP reference point rotational accelerations about X, Y, and Z 
rad/s^2 
The next section of the input file provides options to apply loads at given joints of the structure. nAppliedLoads [] specifies the number of applied loads listed in the subsequent table. The user can specify a combination of steady loads and unsteady loads (both are added together). The loads are in the global coordinate sytem. The steady loads are given as columns of the table (Fx, Fy, Fz, Mx, My, Mz), whereas the unsteady loads are provided in a CSV file. The CSV filename is provided in the last entry of the table. If the filename is empty, the unsteady loads are not read. An example of applied loads table is given below:
 LOADS 
1 nAppliedLoads  Number of applied loads at given nodes
ALJointID Fx Fy Fz Mx My Mz UnsteadyFile
() (N) (N) (N) (Nm) (Nm) (Nm) ()
15 100 0 0 0 0 0 ""
23 0 0 0 0 0 0 "Force_TS.csv"
In the above example, a steady applied force of 100N is applied at the joint with ID=15 of the structure, and an unsteady load is applied to joint 23. The time series of unsteady loads is a CSV file with 7 columns (Time, Fx, Fy, Fz, Mx, My, Mz) and one line of header. The time vector needs to be increasing, but does not need to be linear or cover the full range of the simulation. Interpolation is done in between time stamps, and the first are last values are used for times smaller and larger than the simulation time range respectively. An example of time series is shown below:
#Time_[s] , Fx_[N] , Fy_[N] , Fz_[N] , Mx_[Nm] , My_[Nm] , Mz_[Nm]
0.0 , 0.0 , 0.0 , 0.0 , 0.0 , 0.0 , 0.0
10.0 , 100.0 , 0.0 , 0.0 , 0.0 , 0.0 , 0.0
11.0 , 0.0 , 0.0 , 0.0 , 0.0 , 0.0 , 0.0
SubDyn Primary Input File¶
The SubDyn input file defines the substructure geometry, integration and simulation options, finiteelement parameters, and output channels. The geometry of members is defined by joint coordinates of the undisplaced substructure in the global reference system (inertialframe coordinate system), with the origin at the intersection of the undeflected tower centerline with MSL or ground level for landbased structures. A member connects two joints; multiple members can use a common joint. The hydrodynamic and gravity loads are applied at the nodes, which are the resultant of member refinement into multiple (NDiv input) elements (nodes are located at the ends of each element), as calculated by the module. Member properties include outer diameter, thickness, material density, and Young’s and shear moduli. Member properties are specified at the joints; if properties change from one joint to the other, they will be linearly interpolated for the inner nodes. Unlike the geometric properties, the material properties are not allowed to change within a single member.
Future releases will allow for members of different crosssections, i.e., noncircular members. For this reason, the input file has (currently unused) sections dedicated to the identification of direction cosines that in the future will allow the module to identify the correct orientation of noncircular members. The current release only accepts tubular (circular) members.
The file is organized into several functional sections. Each section corresponds to an aspect of the SubDyn model and substructure.
If this manual refers to an ID in a table entry, it is an integer identifier for the table entry and must be unique for a given table entry.
A sample SubDyn primary input file is given in Section 4.2.5.9.
The input file begins with two lines of header information, which is for the user but is not used by the software.
Users can set the Echo flag to TRUE to have SubDyn echo the contents of the SubDyn input file (useful for debugging errors in the input file). The echo file has the naming convention of OutRootName.SD.ech. OutRootName is either specified in the SUBDYN section of the driver input file when running SubDyn standalone, or by FAST, when running a coupled simulation, from FAST’s main input file.
SDdeltaT specifies the fixed time step of the integration in seconds. The keyword ‘DEFAULT’ may be used to indicate that the module should employ the time step prescribed by the driver code (FAST/standalone driver program).
IntMethod specifies the integration algorithm to use. There are four options: 1) RungeKutta 4^{th}order explicit (RK4); 2) AdamsBashforth 4^{th}order explicit predictor (AB4); 3) AdamsBashforthMoulton 4^{th}order explicit predictorcorrector (ABM4); 4) AdamsMoulton implicit 2^{nd}order (AM2). See Section on how to properly select this and the previous parameter values.
SttcSolve is a flag that specifies whether the static improvement method (SIM, see Section 4.2.5.6.6.6) shall be employed. Through this method, all (higher frequency) modes that are not considered by the CB reduction are treated quasistatically. This treatment helps minimize the number of retained modes needed to capture effects such as static gravity and buoyancy loads, and highfrequency loads transferred from the turbine. Recommended to set to True.
GuyanLoadCorrection is a flag to specify whether the extra moment due to the lever arm from the Guyan deflection of the structure is to be added to the loads passed to SubDyn, and, whether the FEM representation should be expressed in the rotating frame in the floating case (the rotation is induced by the rigid body Guyan modes). See section Section 4.2.5.6.6.3 for details. Recommended to set to True.
FEMMod specifies one of the following options for finiteelement formulation: 1) EulerBernoulli; 3) Timoshenko. Tapered formulations (2 and 4) have yet to be implemented and will be available in a future release.
NDiv specifies the number of elements per member. Analysis nodes are located at the ends of elements and the number of analysis nodes per member equals NDiv + 1. NDiv is applied uniformly to all members regardless of the member’s length, hence it could result in small elements in some members and long elements in other members. Increasing the number of elements per member may increase accuracy, with the tradeoff of increased memory usage and computation time. We recommend using NDiv > 1 when modeling tapered members.
CBMod is a flag that specifies whether or not the CB reduction should be carried out by the module. If FALSE, then the full finiteelement model is retained and Nmodes is ignored.
Nmodes sets the number of internal CB modal DOFs to retain in the CB reduction. Nmodes = 0 corresponds to a Guyan (static) reduction. Nmodes is ignored if CBMod is set to FALSE, meaning the full finiteelement model is retained by keeping all modes (i.e. a modal analysis is still done, and all the modes are used as DOFs) .
JDampings specifies value(s) of damping coefficients as a percentage of critical damping for the retained CB modes. Distinct damping coefficients for each retained mode should be listed on the same line, separated by white space. If the number of JDampings is less than the number of retained modes, the last value will be replicated for all the remaining modes. (see Section 4.2.5.6.6.5)
GuyanDampMod Guyan damping [0=none, 1=Rayleigh Damping, 2= user specified 6x6 matrix] (see Section 4.2.5.6.6.5)
RayleighDamp Mass and stiffness proportional damping coefficients (\((\alpha,\beta)\) Rayleigh damping) [only if GuyanDampMod=1] Guyan damping matrix (6x6) [only if GuyanDamgMod=2] (see Section 4.2.5.6.6.5)
Guyan damping matrix: The 6 lines following this input line consits of the 6x6 coefficients of the damping matrix to be applied at the interface. (see Section 4.2.5.6.6.5)
For more information on these parameters and guidelines on how to set them, see Sections Section 4.2.5.5 and Section 4.2.5.6.
The finiteelement model is based on a substructure composed of joints interconnected by members. NJoints is the userspecified number of joints, and determines the number of rows in the subsequent table. Because a member connects two joints, NJoints must be greater than or equal to two. Each joint listed in the table is identified by a unique integer, JointID; each integer between one and NJoints must be present in the table, but they need not be sequential. The (X,Y,Z) coordinate of each joint is specified in the substructure (SS) coordinate system, which coincides with the global inertialframe coordinate system via JointXss, JointYss, and JointZss, respectively. This version of SubDyn does not consider overlap when multiple members meet at a common joint, therefore, it tends to overestimate the total substructure mass. Member overlap and node offset calculations will be considered in a future release of SubDyn. The fifth column specifies the JointType (see Section 4.2.5.6.4):
Cantilever joints (JointType=1)
Universal joint (JointType=2)
Pin joint (JointType=3)
Ball joint (JointType=4)
The three following columns specify the vector coordinates of the direction around which rotation is free for a pin joints. The last column, JointStiff specify a value of additional stiffness to be added to the “free” rotational DOFs of Ball, Pin and Universal joints.
Note for HydroDyn coupling: modeling a fixedbottom substructure embedded into the seabed (e.g., through piles or suction buckets) requires that the lowest member joint(s) in HydroDyn lie(s) below the water depth. Placing a joint at or above the water depth will result in static and dynamic pressure loads being applied at the joint. When SubDyn is coupled to FAST, the joints and members need not match between HydroDyn and SubDyn—FAST’s meshmapping utility handles transfer of motion and loads across meshes in a physically relevant manner (Sprague et al. 2014), but consistency between the joints and members in HydroDyn and SubDyn is advised.
An example of joint table is given below
3 NJoints  Number of joints ()
JointID JointXss JointYss JointZss JointType JointDirX JointDirY JointDirZ JointStiff
() (m) (m) (m) () () () () (Nm/rad)
101 0.0 0.0 50.0 1 0.0 0.0 0.0 0.0
111 0.0 0.0 10.0 2 0.0 1.0 0.0 100.0
102 0.0 0.0 45.0 1 0.0 0.0 0.0 0.0
SubDyn requires the user to specify the boundary joints. NReact should be set equal to the number of joints (defined earlier) at the bottom of the structure (i.e., seabed) that are fully constrained; NReact also determines the number of rows in the subsequent table. In SubDyn, NReact must be greater than or equal to one. Each joint listed in the table is identified by a unique integer, RJointID, which must correspond to the JointID value found in the STRUCTURE JOINTS table. The flags RctTDXss, RctTDYss, RctTDZss, RctRDXss, RctRDYss, RctRDZss indicate the fixity value for the three translations (TD) and three rotations (RD) in the SS coordinate system (global inertialframe coordinate system). One denotes fixed and zero denotes free (instead of TRUE/FALSE). SSIfile points to the relative path and filename for an SSI information file. This version of SubDyn can, in fact, handle partially restrained joints by setting one or more DOF flags to 0 and providing the appropriate stiffness and mass matrix elements for that DOF via the SSIfile. If a DOF flag is set to 1, then the node DOF is considered restrained and the associated matrix elements potentially provided in the SSIfile will be ignored.
An example of base reaction and interface table is given below
 BASE REACTION JOINTS
1 NReact  Number of Joints with reaction forces
RJointID RctTDXss RctTDYss RctTDZss RctRDXss RctRDYss RctRDZss SSIfile
() (flag) (flag) (flag) (flag) (flag) (flag) (string)
61 1 1 1 1 1 1 "SSI.txt"
 INTERFACE JOINTS
1 NInterf  Number of interface joints locked to the Transition Piece (TP)
IJointID ItfTDXss ItfTDYss ItfTDZss ItfRDXss ItfRDYss ItfRDZss
() (flag) (flag) (flag) (flag) (flag) (flag)
24 1 1 1 1 1 1
SubDyn requires the user to specify the interface joints. NInterf should be set equal to the number of joints at the top of the structure (i.e., TP); NInterf also determines the number of rows in the subsequent table. In SubDyn, NInterf must be greater than or equal to one. Note that these joints will be assumed to be rigidly connected to the platform reference point of ElastoDyn (see FAST documentation) when coupled to FAST, or to the TP reference point if SubDyn is run in standalone mode. Each joint listed in the table is identified by a unique integer, IJointID, which must correspond to the JointID value found in the STRUCTURE JOINTS table. The flags ItfTDXss, ItfTDYss, ItfTDZss, ItfRDXss, ItfRDYss, ItfRDZss indicate the fixity value for the three translations (TD) and three rotations (RD) in the SS coordinate system (global inertialframe coordinate system). One denotes fixed and zero denotes free (instead of TRUE/FALSE). This version of SubDyn cannot handle partially restrained joints, so all flags must be set to one; different degrees of fixity will be considered in a future release.
NMembers is the userspecified number of members and determines the number of rows in the subsequent table. Each member listed in the table is identified by a unique integer, MemberID. Each integer between one and NMembers must be present in the table, but they need not be sequential. For each member distinguished by MemberID, MJointID1 specifies the starting joint and MJointID2 specifies the ending joint, corresponding to an identifier (JointID) from the STRUCTURE JOINTS table. Likewise, MPropSetID1 corresponds to the identifier PropSetID from the MEMBER XSECTION PROPERTY table (discussed next) for starting crosssection properties and MPropSetID2 specifies the identifier for ending crosssection properties, allowing for tapered members. The sixth column specify the member type MType. A member is one of the three following types (see Section 4.2.5.6.4):
Beams (MType=1), EulerBernoulli (FEMMod=1) or Timoshenko (FEMMod=3)
Pretension cables (MType=2)
Rigid link (MType=3)
COSMID refers to the IDs of the members’ cosine matrices for noncircular members; the current release ignores this column.
An example of member table is given below
2 NMembers  Number of frame members
MemberID MJointID1 MJointID2 MPropSetID1 MPropSetID2 MType COSMID
() () () () () () ()
10 101 102 2 2 1
11 102 103 2 2 1
Members in SubDyn are assumed to be straight, circular, possibly tapered, and hollow cylinders. Future releases will allow for generic crosssections to be employed. These special crosssection members will be defined in the second of two tables in the input file (Member XSection Property data 2/2), which is currently ignored.
For the circular crosssection members, properties needed by SubDyn are material Young’s modulus, YoungE, shear modulus, ShearG, and density, MatDens, member outer diameter, XsecD, and member thickness, XsecT. Users will need to create an entry in the first table within this section of the input file distinguished by PropSetID, for each unique combination of these five properties. The member propertyset table contains NPropSets rows. The member property sets are referred to by their PropSetID in the MEMBERS table, as described in Section . Note, however, that although diameter and thickness will be linearly interpolated within an individual member, SubDyn will not allow material properties to change within an individual member.
The second table in this section of the input file (not to be used in this release) will have NXPropSets rows (assumed to be zero for this release), and have additional entries when compared to the previous table, including: crosssectional area (XsecA), crosssectional shear area along the local principal axes x and y (XsecAsx, XsecAsy), crosssectional area second moment of inertia about x and y (XsecJxx, XsecJyy), and crosssectional area polar moment of inertia (XsecJ0). The member cosine matrix section (see Section ) will help determine the correct orientation of the members within the assembly.
Members that are specified as pretension cables (MType=2), have their properties defined in the cable properties table. The table lists for each cable property: the property ID (PropSetID), the cable tension stiffness (EA), the material density (MatDens), the pretension force (T0), and the control channel (CtrlChannel). The control channel is only used if ServoDyn provides dedicated control signal, in which case the cable tension (given in terms of a length change \(\Delta l\)) is dynamically changed (see Section 4.2.5.6.4.5.3). The FEM representation of pretension cable is given in Section 4.2.5.6.4.5.
An example of cable properties table is given below:
 CABLE PROPERTIES 
2 NCablePropSets  Number of cable cable properties
PropSetID EA MatDens T0 CtrlChannel
() (N) (kg/m) (N) ()
11 210E7 7850.0 2E7 1
10 210E7 7850.0 1E7 0
Members that are specified as rigid links (MType=3), have their properties defined in the rigid link properties table. The table lists the material density (MatDens) for each rigid link property. The FEM representation of rigid links is given in Section 4.2.5.6.4.7.
An example of rigid link properties table is given below
 RIGID LINK PROPERTIES 
1 NRigidPropSets  Number of rigid link properties
PropSetID MatDens
() (kg/m)
12 7850.0
3 7000.0
This table is not currently used by SubDyn, but in future releases it will need to be populated if members with crosssections other than circular will be employed.
NCOSMs rows, one for each unique member orientation set, will need to be provided. Each row of the table will list the nine entries of the direction cosine matrices (COSM11, COSM12,…COSM33) for matrix elements (1,1), (1,2),…(3,3) that establish the orientation of the local member axes (x,y principal axes in the crosssectional plane, z along the member longitudinal axis) with respect to the SS coordinate system (localtoglobal transformation matrices).
SubDyn can accept NCmass lumped masses/inertias defined at the joints. The subsequent table will have NCmass rows, in which for each joint distinguished by CMJointID (corresponding to an identifier, JointID, from the STRUCTURE JOINTS table), JMass specifies the lumped mass value, and JMXX, JMYY, JMZZ specify the mass second moments of inertia with respect to the SS coordinate system (not the element system). Latest version of SubDyn accept 6 additional columns (JMXY, JMXZ, JMYZ, MCGX, MCGY, MCGZ) to specify offdiagonal terms.
The additional mass matrix added to the node is computed in the SS system as follows:
with \(m\) the parameter JMass, and \(x,y,z\), the CG offsets.
An example of concentrated mass table is given below:
2 NCmass  Number of joints with concentrated masses; (SS coord system)
CMJointID JMass JMXX JMYY JMZZ JMXY JMXZ JMYZ MCGX MCGY MCGZ
() (kg) (kgm^2) (kgm^2) (kgm^2) (kgm^2) (kgm^2) (kgm^2) (m) (m) (m)
1 4090 0 0 0 0 0 0 0 0 0
3 4.2e6 0 0 3.3e9 0 0 0 0 0 0
In this section of the input file, the user sets flags and switches for the desired output behavior.
Specifying SDSum = TRUE causes SubDyn to generate a summary file with name OutRootName.SD.sum*. OutRootName is either specified in the SUBDYN section of the driver input file when running SubDyn in standalone mode, or in the FAST input file when running a coupled simulation. See Section 4.2 for summary file details.
The following two inputs specified whether mode shapes should be written to disk. OutCBModes is a flag that controls the output of the Guyan and CraigBampton modes. Similarly, OutFEMModes, controls the output of the FEM modes (full sytem with constraints prior to the CBreduction). For now, only the first 30 FEM modes are written to disk, but all CB modes selected by the users are written. For both inputs, the following options are available: 0, no ouput, 1, outputs in JSON format. The JSON files contain nodes coordinates, connectivity between the nodes, displacements for each modes and nodes, and frequencies for each modes. The reading of these files should be straightforward using Matlab or Python using a JSON format parser. The files can be opened to visualize the modes using the tool viz3danim (see the live version , or its github repository).
Currently, OutCOSM is ignored. In future releases, specifying OutCOSM = TRUE will cause SubDyn to include direction cosine matrices (undeflected) in the summary file for only those members requested in the list of output channels.
Specifying OutAll = TRUE causes SubDyn to output forces and moments at all of the joints (not internal nodes). That is, the static (elastic) and dynamic (inertia) components of the three forces and three moments at the end node of each member connected to a given joint are output for all joints. These outputs are included within the OutRootName.SD.out* output file in addition to those directly specified through the output channels section below.
If OutSwtch is set to one, outputs are sent to a file with the name OutRootName.SD.out*. If OutSwtch is set to two, outputs are sent to the calling program (FAST) for writing in its main output file (not available in standalone mode). If OutSwtch is set to three, both file outputs occur. In standalone mode, setting OutSwtch to two results in no output file being produced.
If TabDelim is set to TRUE and OutSwtch is set to one, the output file OutRootName.SD.out* will be tabdelimited.
With OutDec set to an integer value greater than one, the output file data rate will be decimated, and only every OutDecth value will be written to the file. This applies only to SubDyn’s output file (OutRootName.SD.out*)—not FAST’s.
The OutFmt and OutSFmt parameters control the formatting of SubDyn’s output file for the output data and the channel headers, respectively. SubDyn currently does not check the validity of these format strings. They need to be valid Fortran format strings. OutSFmt is used for the column header and OutFmt is used for the channel data. Therefore, in order for the headers and channel data to align properly, the width specification should match. For example:
SubDyn can output load and kinematic quantities at up to nine locations for up to nine different members, for a total of 81 possible local member output locations. NMOutputs specifies the number of members that output is requested for. The user must create a table entry for each requested member. Within a row of this table, MemberID is the ID specified in the MEMBERS table, and NOutCnt specifies how many nodes along the member will generate output. NodeCnt specifies those node numbers (a separate entry on the same line for each node) for output as an integer index from the startjoint (node 1) to the endjoint (node NDiv + 1) of the member. The outputs specified in the SDOutList section determines which quantities are actually output at these locations.
This section specifies which quantities are output by SubDyn. Enter one or more lines containing quoted strings that in turn contain one or more output parameter names. Separate output parameter names by any combination of commas, semicolons, spaces, and/or tabs. If a parameter name is prefixed with a minus sign, “”, underscore, “_”, or the characters “m” or “M”, SubDyn will multiply the value for that channel by –1 before writing the data. The parameters are written in the order they are listed in the input file. SubDyn allows the use of multiple lines so that users can break their lists into meaningful groups and so the lines can be shorter. Comments may also be entered after the closing quote on any of the lines. Entering a line with the string “END” at the beginning of the line or at the beginning of a quoted string found at the beginning of the line will cause SubDyn to quit scanning for more lines of channel names. Modal kinematics and membernode, base, and interfacerelated kinematic and load quantities can be selected. Membernoderelated data follow the organization described in Section . If SubDyn encounters an unknown/invalid channel name, it prints an error message and halts execution. Please refer to Section 4.2.5.11 for a complete list of possible output parameters and their names.
SSI Input File¶
Individual SSI files (SSIfiles) can be provided for each restrained node, therefore the maximum number of SSIfiles is NReact. In an SSIfile, up to 21 elements for the SSI mass matrix and up to 21 SSI stiffness matrix elements can be provided. The mass and stiffness elements account for both pile and soil effects. No additional damping can be provided at this point.
The order of the elements is not important, because each element value is accompanied by a string label that identifies the actual element. The stiffness matrix accepted labels are: ‘Kxx’, ‘Kxy’, ‘Kyy’, ‘Kxz’, ‘Kyz’, ‘Kzz’, ‘Kxtx’, ‘Kytx’, ‘Kztx’, ‘Ktxtx’, ‘Kxty’, ‘Kyty’,’Kzty’, ‘Ktxty’, ‘Ktyty’, ‘Kxtz’, ‘Kytz’, ‘Kztz’, ‘Ktxtz’, ‘Ktytz’, ‘Ktztz’.
If any matrix element is not provided it will be set to infinity (i.e., machine ‘huge’) by default.
For the mass matrix the accepted labels are: ‘Mxx’,’Mxy’,’Myy’,’Mxz’,’Myz’, ‘Mzz’,’Mxtx’,’Mytx’,’Mztx’, ‘Mtxtx’, ‘Mxty’, ‘Myty’, ‘Mzty’, ‘Mtxty’, ‘Mtyty’, ‘Mxtz’, ‘Mytz’, ‘Mztz’, ‘Mtxtz’, ‘Mtytz’, ‘Mtztz’. If any matrix element is not provided it will be set to 0 by default. The labels contain ‘K’ or ‘M’ to specify stiffness or mass matrix elements, and then the directions they apply to, e.g., ‘Kxy’ refers to the force along x due to a unit displacement along y; the ‘t’ refers to the rotation about one of the ‘x’,’y’, or ’z’ axes in the global coordinate system.
Units are in SI system (N/m; N/m/rad; Nm/rad, Kg, kgm, kgm2).
Note that by selecting fixities of 1 in the various DOFs of the restrained nodes, the columns and rows associated with those DOFs will be removed, therefore the associated matrix elements will be ignored.
A sample SubDyn SSI input file is given in Section 4.2.5.11.
Output Files¶
SubDyn produces three types of output files: an echo file, a summary file, and a timeseries results file. The following sections detail the purpose and contents of these files.
Echo File¶
If the user sets the Echo flag to TRUE in the SubDyn driver file or the primary SubDyn input file, the contents of those files will be echoed to a file with the naming conventions, OutRootName.dvr.ech for the driver input file and OutRootName.SD.ech for the primary SubDyn input file. OutRootName is either specified in the SUBDYN section of the driver input file, or in the FAST input file. The echo files are helpful for debugging the input files. The contents of an echo file will be truncated if SubDyn encounters an error while parsing an input file. The error usually corresponds to the line after the last successfully echoed line.
Summary File¶
SubDyn generates a summary file with the naming convention, OutRootName.SD.sum if the SDSum parameter is set to TRUE. This file summarizes key information about the substructure model, including:
Undisplaced node geometry: a list of all of the (NNodes) nodes and the X,Y,Z coordinates in the global SS coordinate system. Note that NNodes may be greater or equal to NJoints, depending on NDiv (primary input file parameters).
Element connectivity and properties at end nodes: a list of all (NElems) elements, the start and end nodes (Node_I, Node_J) and the ID of the property set (Prop_I, Prop_J) at the start and end nodes. NElems may be greater or equal to NMembers, depending on NDiv (primary input file parameters).
Property sets. If tapered members are used, additional property sets may be included beyond those specified in the main input file, based on interpolated diameter and thickness values. Headers and their meanings are identical to those described in Section .
Reaction DOFs and interface DOFs and their associated fixity; the actual indices of the DOFs (DOF_ID) associated with reaction and interface nodes are listed together with the (1/0) flag to distinguish the fixity level.
Concentrated mass schedule. This is an echo of the equivalent section in the primary input file. Refer to Section .
Member schedule including connectivity to joints, nodes, and their masses. A table lists all of the members by identifier (MemberID), with their start and end nodes (Joint1_ID, Joint2_ID), associated mass (Mass), and list of node identifiers along the length of the members.
Direction cosine matrices for the members. Each row (columns 210) corresponds to the direction cosine matrix entries (DC(1,1) through DC(3,3)) for the member whose identifier is listed in the first column. The direction cosine matrices specify the transformation from the global reference to the local coordinate system for each member.
Sorted eigenfrequencies [in Hertz (Hz)] for the full substructural system (neglecting a possible coupling to ElastoDyn through FAST), assuming the TP reference point is a free end. There are a total of NDOFs eigenfrequencies and eigenvectors.
Sorted eigenfrequencies (in Hz) for the CB reduced system, assuming the TP reference point is a fixed end. There are a total of Nmodes CB reduced eigenfrequencies and eigenvectors.
Full substructural system eigenvectors. Each column represents an eigenvector associated with the corresponding eigenfrequency identified previously in the file.
CB reduced system eigenvectors (PhiM matrix). Each column represents an eigenvector associated with the corresponding eigenfrequency identified previously in the file.
PhiR matrix or displacements of the internal nodes caused by unit rigid body motions of the interface DOFs (see Section ). Each column of the matrix represents the internal DOF displacements for a given unit rigidbody motion along an interface DOF for each base and interface joint.
Substructure equivalent stiffness and mass matrices referred to the TP reference point (KBBt and MBBt), based on a Guyan reduction. These are useful to calculate effects of substructure flexibility while calculating tower eigenmodes for ElastoDyn.
Rigidbodyequivalent mass matrix relative to global origin (MRB); a 6x6 mass matrix.
Substructure total (dry) mass.
Substructure center of mass coordinates in the global coordinate system.
The various sections of the summary file and variables are selfexplanatory and easily identifiable in the file.
Results File¶
The SubDyn timeseries results are written to a textbased file with the naming convention OutRootName.SD.out when OutSwtch is set to either one or three. If SubDyn is coupled to FAST and OutSwtch is set to two or three, then FAST will generate a master results file that includes the SubDyn results. The results in OutRootName.SD.out are in table format, where each column is a data channel (the first column always being the simulation time), and each row corresponds to a simulation time step. The data channels are specified in the SDOutList section of the input file. The column format of the SubDyngenerated file is specified using the OutFmt and OutSFmt parameters of the input file.
Modeling Considerations¶
SubDyn was designed as a flexible tool for modeling a wide range of substructures for both landbased and offshore applications. This section provides some general guidance to help construct models that are compatible with SubDyn.
Please refer to the theory in Section 6 for detailed information about SubDyn’s coordinate systems, and the theoretical approach we have followed in SubDyn.
Model Discretization¶
SubDyn allows for the specification of arbitrary multimember structure geometries. The user defines the geometry of a structure in SubDyn using joints and members. Specifically, the user specifies a list of joints that represent the endpoints of beams, and the connectivity between one or more members at each joint. Members and their crosssectional properties are then defined between two joints. Members can be further subdivided into multiple (NDiv) elements to increase the model resolution. Nodes, where the numerical calculations take place, are located at the endpoints of each element. To keep the mesh as uniform as possible when using NDiv, the initial member definition should also have a roughly uniform mesh. For tapered members, we recommend setting NDiv > 1. Improper discretization of the members may decrease the accuracy of the model.
When SubDyn is coupled to FAST, the joints and members need not match between HydroDyn and SubDyn—FAST’s meshmapping utility handles the transfer of motion and loads across meshes in a physically relevant manner [MJJ14], but consistency between the joints and members in HydroDyn and SubDyn is advised.
For offshore applications, because of the exponential decay of hydrodynamic loads with depth, HydroDyn requires higher resolution near the water free surface to properly capture loads as waves oscillate about the still water level (SWL). We recommend that the HydroDyn discretization not exceed element lengths of 0.5 m in the region of the free surface (5 to 10 m above and below SWL), 1.0 m between 25 and 50m depth, and 2.0 m in deeper waters.
When SubDyn is hydroelastically coupled to HydroDyn through FAST for the analysis of fixedbottom offshore systems, we recommend that the length ratio between elements of SubDyn and HydroDyn not exceed 10 to 1. As such, we recommend that the SubDyn discretization not exceed element lengths of 5 m in the region of the free surface, 10 m down to 25 to 50m depth, and 20 m in deeper waters. These are not absolute rules, but rather a good starting point that will likely require refinement for a given substructure. Additional considerations for SubDyn discretization include aspects that will impact structural accuracy, such as member weight, substructure modes and/or natural frequencies, load transfer, tapered members, and so on.
Members in SubDyn are assumed to be straight circular (and possibly tapered) cylinders. The use of more generic crosssectional shapes will be considered in a future release.
Foundations¶
There are two methods that can be used to model foundation flexibility or soilstructure interaction in SubDyn. The first method makes us of the SSI stiffness and mass matrices at the partially restrained bottom joints as described in Sections 3.3.4, 3.4, and 6. The second method mimics the flexibility of the foundation through the apparent (or effective) fixity (AF) length approach, which idealizes a pile as a cantilever beam that has properties that are different above and below the mudline. The beam above the mudline should have the real properties (i.e., diameter, thickness, and material) of the pile. The beam below the mudline is specified with effective properties and a fictive length (i.e., the distance from the mudline to the cantilevered base) that are tuned to ensure that the overall response of the pile above the mudline is the same as the reality. The response can only be identical under a particular set of conditions; however, it is common for the properties of the fictive beam to be tuned so that the mudline displacement and rotation would be realistic when loaded by a mudline shear force and bending moment that are representative of the loading that exists when the offshore wind turbine is operating under normal conditions.
Note that in HydroDyn, all members that are embedded into the seabed (e.g., through piles or suction buckets) must have a joint that is located below the water depth. In SubDyn, the bottom joint(s) will be considered clamped or partially restrained and therefore need not be located below the seabed when not applying the AF approach. For example, if the water depth is set to 20 m, and the user is modeling a fixedbottom monopile with a rigid foundation, then the bottommost joint in SubDyn can be set at Z = 20 m; HydroDyn, however, needs to have a Zcoordinate such that Z < 20 m. This configuration avoids HydroDyn applying static and dynamic pressure loads from the water on the bottom of the structure. When the AF approach is applied, the bottommost joint in SubDyn should be set at Z < 20 m.
Member Overlap¶
As mentioned earlier, the current version of SubDyn is incapable of treating the overlap of members at the joints, resulting in an overestimate of the mass and potentially of the structure stiffness. One strategy to overcome this shortcoming employs virtual members to simulate the portion of each member within the overlap at a joint. The virtual members should be characterized by low selfmass and high stiffness. This can be achieved by introducing virtual joints at the approximate intersection of the finitesized members, and then specifying additional members from these new joints to the original (centerline) joints. The new virtual members then use reduced material density and increased Young’s and shear moduli. Care is advised in the choice of these parameters as they may render the system matrix singular. Inspection of the eigenvalue results in the summary file should confirm whether acceptable approximations have been achieved.
Substructure Tower/Turbine Coupling¶
When SubDyn is coupled to FAST, the 6 DOFs of the platform in ElastoDyn must be enabled to couple loads and displacements between the turbine and the substructure. The platform referencepoint coordinates in ElastoDyn should also be set equal to the TP referencepoint’s coordinates (commonly indicating either the towerbase flange location, or TP centroid, or TP center of mass) that the user may have set in the standalone mode for checking the SubDyn model. A rigid connection between the SubDyn interface joints and TP reference point (\({\equiv}\) platform reference point) is assumed.
For full lattice support structures or other structures with no transition piece, the entire support structure up to the yaw bearing may be modeled within SubDyn. Modeling the tower in SubDyn as opposed to ElastoDyn, for example, allows the ability to include more than the first two foreaft and sidetoside bending modes, thus accounting for more general flexibility of the tower and its segments; however, for tubular towers, the structural model in ElastoDyn tends to be more accurate because ElastoDyn considers geometric nonlinearities not treated in SubDyn. When modeling fulllattice towers using SubDyn, the platform reference point in ElastoDyn can be located at the yaw bearing; in this case, the towerbending DOFs in ElastoDyn should be disabled.
If FAST is run with SubDyn but not HydroDyn, the water depth will be automatically set to 0 m. This will influence the calculation of the reaction loads. Reactions are always provided at the assumed mudline, therefore, they would not be correctly located for an offshore turbine as a result. Thus, it is recommended that HydroDyn always be enabled when modeling bottomfixed offshore wind turbines.
ElastoDyn also needs tower mode shapes specified (coefficients of bestfit sixthorder polynomials), derived using appropriate towerbase boundary conditions. They can be derived with an appropriate software (finiteelement analysis, energy methods, or analytically) and by making use of the SubDynderived equivalent substructure stiffness and mass matrices (the KBBt and MBBt matrices found in the SubDyn summary file) to prescribe the boundary conditions at the base of the tower.
For instance, using NREL’s BModes software, the SubDynobtained matrices can be used in place of the hydrodynamic stiffness (hydro_K) and mass matrices (hydro_M) (mooring_K can be set to zero). By setting the hub_conn boundary condition to two (freefree), BModes will calculate the mode shapes of the tower when tower crosssectional properties are supplied. To obtain eigenmodes that are compatible with the FAST modal treatment of the tower (i.e., no axial or torsional modes and no distributed rotationalinertia contribution to the eigenmodes), the towerdistributed properties should be modified accordingly in BModes (e.g., by reducing mass moments of inertia towards zero and by increasing torsional and axial stiffness while assuring convergence of the results; see also https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=742).
The rotational inertia of the undeflected tower about its centerline is not currently accounted for in ElastoDyn. Thus, when the nacelleyaw DOF is enabled in ElastoDyn there will not be any rotational inertia of the platformyaw DOF (which rotates the tower about its centerline) when both the platformyaw inertia in ElastoDyn is zero and the tower is undeflected. To avoid a potential divisionbyzero error in ElastoDyn when coupled to SubDyn, we recommend setting the platformyaw inertia (PtfmYIner) in ElastoDyn equal to the total rotational inertia of the undeflected tower about its centerline. Note that the platform mass and inertia in ElastoDyn can be used to model heavy and rigid transition pieces that one would not want to model as a flexible body in either the ElastoDyn tower or SubDyn substructure models.
*Damping of the Guyan modes:*
There are three ways to specify the damping associated with the motion of the interface node.
SubDyn Guyan damping matrix using Rayleigh damping
SubDyn Guyan damping matrix using user defined 6x6 matrix
HydroDyn additional linear damping matrix (AddBLin)
The specificaiton of the Guyan damping matrix in SubDyn is discussed in Section 4.2.5.6.6.5.
Old:
The CB method assumes no damping for the interface modes. This is equivalent to having six undamped rigidbody DOFs at the TP reference point in the absence of aerodynamic or hydrodynamic damping. Experience has shown that negligible platformheave damping can cause numerical problems when SubDyn is coupled to FAST. One way to overcome this problem is to augment overall system damping with an additional linear damping for the platformheave DOF. This augmentation can be achieved quite easily by calculating the damping from Eq. (4.92) and specifying this as the (3,3) element of HydroDyn’s additional linear damping matrix, AddBLin. Experience has shown that a damping ratio of 1% of critical (\({\zeta=0.01}\)) is sufficient. In Eq. (4.92), \({K_{33}^{(SD)}}\) is the equivalent heave stiffness of the substructure (the (3,3) element of the KBBt (i.e., \({\tilde{K}_{BB}}\)) matrix found in the SubDyn summary file, see also Section 6), \({M_{33}^{(SD)}}\) is the equivalent heave mass of the substructure (the (3,3) element of the MBBt (i.e., \({\tilde{M}_{BB}}\)) matrix found in the SubDyn summary file, see also Section 6), and \({M^{(ED)}}\) is the total mass of the rotor, nacelle, tower, and TP (found in the ElastoDyn summary file).
To minimize extraneous excitation of the platformheave DOF, it is useful to set the initial platformheave displacement to its natural staticequilibrium position, which can be approximated by Eq. (4.93), where is the magnitude of gravity. PtfmHeave from Eq. (4.93) should be specified in the initial conditions section of the ElastoDyn input file.
SelfWeight Calculations¶
SubDyn will calculate the selfweight of the members and apply appropriate forces and moments at the element nodes. Lumped masses will also be considered as concentrated gravity loads at prescribed joints. The array of selfweight forces can be seen in the summary file if the code is compiled with DEBUG compiler directives. In general, SubDyn assumes that structural motions of the substructure are small, such that (1) smallangle assumptions apply to structural rotations and (2) the socalled P \({\Delta}\) effect is negligible, and therefore undeflected node locations are used for selfweight calculations.
Note On Other Load Calculations¶
When SubDyn is coupled to HydroDyn through FAST, the hydrodynamic loads, which include buoyancy, marinegrowth weight, and wave and current loads, will be applied to the effective, deflected location of the nodes by the meshmapping routines in the glue code. Those loads, however, are based on wave kinematics at the undeflected position (see Jonkman et al. 2014 for more information).
CraigBampton Guidelines¶
When SubDyn is coupled with FAST, it is important to choose a sufficient number of CB modes, ensuring that the vibrational modes of the coupled system are properly captured by the coupled model. We recommend that all modes up to at least 23 Hz be captured; wind, wave, and turbine excitations are important for frequencies up to 23 Hz. Eigenanalysis of the linearized, coupled system will make checking this condition possible and aid in the selection of the number of retained modes; however, the linearization process has yet to be implemented in FAST v8. Until fullsystem linearization is made available, experience has shown that it is sufficient to enable all CB modes up to 10 Hz (the natural frequencies of the CB modes are written to the SubDyn summary file). If SIM (see Section Section 4.2.5.6.6.6) is not enabled, in addition to capturing physical modes up to a given frequency, the highest CB mode must include the substructure axial modes so that gravity loading from selfweight is properly accounted for within SubDyn. This inclusion likely requires enabling a high number of CB modes, reducing the benefit of the CB reduction. Thus, we recommend employing the CB reduction with SIM enabled. Because of the fixedfixed treatment of the substructure boundary conditions in the CB reduction, the CB modes will always have higher natural frequencies than the physical modes.
Integration Time Step Guidelines¶
Another consideration when creating SubDyn input files is the time step size. SubDyn offers three explicit timeintegrators — the fourthorder RungeKutta (RK4), fourthorder AdamsBashforth (AB4), fourthorder AdamsBashforthMoulton (ABM4) methods — and the implicit secondorder AdamsMoulton (AM2) method. Users have the option of using the global time step from the glue code or an alternative SubDynunique time step that is an integer multiple smaller than the gluecode time step. It is essential that a small enough time step is used to ensure solution accuracy (by providing a sufficient sampling rate to characterize all key frequencies of the system), numerical stability of the selected explicit timeintegrator, and that the coupling with FAST is numerically stable.
For the RK4 and ABM4 methods, we recommend that the SubDyn time step follow the relationship shown in Eq. (4.94), where \({f_{max}}\) is the higher of (1) the highest natural frequency of the retained CB modes and (2) the highest natural frequency of the physical modes when coupled to FAST. Although the former can be obtained from the SubDyn summary file, the latter is hard to estimate before the fullsystem linearization of the coupled FAST model is realized. Until then, experience has shown that the highest physical mode when SubDyn is coupled to FAST is often the platformheave mode of ElastoDyn, with a frequency given by Eq. (4.95), where the variables are defined in Section 5.3.
For the AB4 method, the recommended time step is half the value given by Eq. (4.94).
For AM2, being implicit, the required time step is not driven by natural frequencies within SubDyn, but should still be chosen to ensure solution accuracy and that the coupling to FAST is numerically stable.
SubDyn Theory¶
Overview¶
This section focuses on the theory behind the SubDyn module.
SubDyn relies on two main engineering approaches: (1) a linear frame finiteelement model (LFEM), and (2) a dynamics system reduction via the CraigBampton (CB) method together with a staticimprovement method (SIM), greatly reducing the number of modes needed to obtain an accurate solution.
There are many nonlinearities present in offshore wind substructure models, including material nonlinearity, axial shortening caused by bending, large displacements, and so on. The material nonlinearity is not considered here because most offshore multimember support structures are designed to use steel and the maximum stress is intended to be below the yield strength of the material. [DSRJ13] demonstrate that a linear finiteelement method is suitable when analyzing wind turbine substructures. In this work, several wind turbine configurations that varied in base geometry, load paths, sizes, supported towers, and turbine masses were analyzed under extreme loads using nonlinear and linear models. The results revealed that the nonlinear behavior was mainly caused by the monotower response and had little effect on the multimember support structures. Therefore, an LFEM model for the substructure is considered appropriate for wind turbine substructures. The LFEM can accommodate different element types, including EulerBernoulli and Timoshenko beam elements of either constant or longitudinally tapered cross sections (Timoshenko beam elements account for shear deformation and are better suited to represent low aspect ratio beams that may be used within frames and to transfer the loads within the frame).
The large number of DOFs (~ \({10^3}\)) associated with a standard finiteelement analysis of a typical multimember structure would hamper computational efficiency during wind turbine system dynamic simulations. As a result, the CB system reduction was implemented to speed up processing time while retaining a high level of fidelity in the overall system response. The CB reduction is used to recharacterize the substructure finiteelement model into a reduced DOF model that maintains the fundamental lowfrequency response modes of the structure. In the SubDyn initialization step, the large substructure physical DOFs (displacements) are reduced to a small number of modal DOFs and interface (boundary) DOFs, and during each time step, only the equations of motion of these DOFs need to be solved. SubDyn only solves the equations of motion for the modal DOFs, the motion of the interface (boundary) DOFs are either prescribed when running SubDyn in standalone mode or solved through equations of motion in ElastoDyn when SubDyn is coupled to FAST.
Retaining just a few DOFs may, however, lead to the exclusion of axial modes (normally of very high frequencies), which are important to capture static load effects, such as those caused by gravity and buoyancy. The socalled SIM was implemented to mitigate this problem. SIM computes two static solutions at each time step: one based on the full system stiffness matrix and one based on the CB reduced stiffness matrix. At each time step the timevarying, CB based, dynamic solution is superimposed on the difference between the two static solutions, which amounts to quasistatically accounting for the contribution of those modes not directly included within the dynamic solution.
In SubDyn, the substructure is considered to be clamped, or connected via linear springlike elements, at the bottom nodes (normally at the seabed) and rigidly connected to the TP at the substructure top nodes (interface nodes). The user can provide 6x6, equivalent stiffness and mass matrices for each of the bottom nodes to account for soilpile interaction. As described in other sections of this document, the input file defines the substructure geometry, material properties, and constraints. Users can define: element types; full finiteelement mode or CB reduction; the number of modes to be retained in the CB reduction; modal damping coefficients; whether to take advantage of SIM; and the number of elements for each member.
The following sections discuss the integration of SubDyn within the FAST framework, the main coordinate systems used in the module, and the theory pertaining to the LFEM, the CB reduction, and SIM. The statespace formulations to be used in the timedomain simulation are also presented. The last section discusses the calculation of the base reaction calculation. For further details, see also [