OpenFAST couples four physics models to predict turbine loads

Why the coupling is the point

OpenFAST is described as a physics-based engineering tool for simulating the coupled dynamic response of wind turbines, and the sentence that follows lists what is joined together. It joins aerodynamics models, hydrodynamics models for offshore structures, control and electrical system dynamics models, and structural dynamics models, in order to enable coupled nonlinear aero-hydro-servo-elastic simulation in the time domain. The point of joining them is that the interesting behaviour in a turbine lives in the interaction. A blade pitching to relieve load reacts on the rotor, which bends, which changes the angle of attack, which changes the load again. Simulating the pieces separately and combining the answers afterwards cannot capture that. The models are derived from fundamental laws with appropriate simplifications and assumptions, and they are supplemented where applicable with computational solutions and test data, which is an honest description of how a simulation code of this kind stays verifiable.

What each of the four models does

The README describes each model, and the details are what make the tool usable. The aerodynamic models use wind inflow data and solve for the rotor wake effects and blade element 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 blade pitch, generator torque, nacelle yaw and other control devices, as well as the generator and power converter components of the electrical drive. The structural dynamics models apply the control and electrical system reactions, apply the aerodynamic and hydrodynamic loads, add gravitational loads, and simulate the elasticity of the rotor, the drivetrain and the support structure. Coupling between all of the models is achieved through a modular interface and coupler, which is called glue code in the source tree.

Loads, linearisation and instability

Three capabilities are described in terms of what an engineer does with the model. With OpenFAST you can run large numbers of nonlinear time-domain simulations in approximately real time, which is what makes standards-based loads analysis for predicting ultimate and fatigue loads practical. You can also linearize the underlying nonlinear model about an operating point, which lets you understand the system response and calculate natural frequencies, damping and mode shapes, design controllers, and analyse aero-elastic instabilities. The configuration space the tool covers is wide. It handles two or three blade horizontal axis rotors, pitch or stall regulation, a rigid or teetering hub, an upwind or downwind rotor, and lattice or tubular towers, and the turbine can be modelled on land or offshore on fixed-bottom or floating substructures. The cost of that coverage is that a model file has many switches, which is the price of a general purpose engineering tool.

FAST.Farm takes it to the farm scale

FAST.Farm extends the capabilities of OpenFAST to provide physics-based engineering simulation of multi-turbine wind farms, covering land-based, fixed-bottom offshore and floating offshore configurations. The model is built by simulating each wind turbine in the farm with an OpenFAST model and capturing the relevant physics for prediction of wind farm power performance and structural loads. The phenomena that only exist at the farm scale are named explicitly, which is the interesting part, since they are the reason the farm model is not just OpenFAST run several times. They are farm-wide ambient wind, the super controller, and wake advection, meandering and merging. Wake advection is the movement of a wake with the wind, meandering is its lateral wander, and merging is what happens when two wakes overlap, and all three change the loads on the downstream turbines in ways a single turbine model cannot see.

Two branches and three versions of the documentation

The distribution model is the git-flow convention with two branches. The main branch is stable, well tested and represents the most up to date released versions of OpenFAST and FAST.Farm, and the latest commit on main carries a tag with version information and brief release notes, with the tag history available through the git tag command and in more detail on GitHub Releases. For general use the main branch is highly recommended. The dev branch is generally stable and tested but not static, and it contains new features, bug fixes and documentation updates that have not been compiled into a production release, and it is where new development is expected to start. The documentation is stored and maintained alongside the source code, compiled into HTML with Sphinx and tied to a particular version, and Read the Docs hosts three of them, latest for the latest commit on main, stable for the last tagged release and dev for the latest commit on the dev branch, switchable from a button on the site.

The repository layout mirrors the physics

The top level of the repository is the clearest description of how the code is arranged. The modules/ directory holds the physics modules, and glue-codes/ holds the coupling code, which is the directory the README refers to as glue code, and it is where the interface between the four models lives. There is openfast_io/ for input and output, reg_tests/ for the regression tests and unit_tests/ for the unit tests, with a test/ pattern in the requirements file confirming that both exist. The build is CMake, with a CMakeLists.txt at the root and a cmake/ directory, and there is a vs-build/ directory for the Visual Studio build, which matters because the toolchain for Fortran on Windows is the usual friction point. The documentation lives in docs/ with a .readthedocs.yml for the hosting, share/ holds shared input data, and there is a .gitmodules file, so the build pulls in at least one external component.

Testing, funding and the current state

The Python requirements file exists for the test infrastructure rather than for the simulator, and the comment at the top says so. The packages are numpy, vtk for visualisation, Bokeh pinned to a range that excludes four specific 3.0 releases, pytest, nptdms for reading measurement data and pandas. The presence of nptdms among the test dependencies is a detail that tells you something about the domain the tests serve. The project is primarily developed with the support of the U.S. Department of Energy and is part of the WETO Software Stack, and the models are managed by a dedicated team at the National Laboratory of the Rockies, with the stated objective of ensuring that OpenFAST and FAST.Farm are sustainable software that is well tested and well documented. The README states plainly that OpenFAST is under active development. The releases are v5.0.0 on 2026-03-12, v4.2.1 on 2026-03-10 and v4.2.0 on 2026-01-27, the last push was on 2026-10-09, and the licence is Apache-2.0.

Editorial conclusion

OpenFAST fits a wind energy researcher or a turbine designer who needs loads rather than just power, since the coupled model is the only way to see how a pitch controller interacts with structural flexibility over a long simulation. It does not fit someone who wants a quick power estimate, and it does not fit a team that expects a modern package manager workflow, since the build is CMake with a Fortran toolchain and a test suite that needs Python packages. Before you start, read the FAST to OpenFAST transition notes if you have FAST v8 scripts, and check the branch you want, because main is the released and tested line while dev carries the new work. Note the release state, with v5.0.0 published on 2026-03-12 and the last push on 2026-10-09, under an Apache-2.0 licence.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. OpenFAST/openfast on GitHub
3. Project website
4. README
5. Releases