5. Developer Documentation

Our goal as developers of OpenFAST is to ensure that it is well tested, well documented, and self-sustaining software. To that end, we continually work to improve the documentation and test coverage along with feature additions and improvements. This section of the documentation outlines the processes and procedures we have established for external developers to work with the NREL OpenFAST team on code development.

If you’d like to help with general OpenFAST development or work on a particular feature, then first install OpenFAST following the installation instructions for your machine. Next, verify that your installation is valid by running the test suite following the testing instructions. While OpenFAST is compiling, we encourage reading through the Development Philosophy section to understand the general workflow for individual and coordinated development. Finally, be sure to review the GitHub workflow to avoid any merge or code conflicts.

With development happening in parallel between NREL, industry partners, and universities, NREL relies on GitHub to coordinate efforts:

• GitHub Issues is the place to ask usage or development questions, report bugs, and suggest code enhancements

• GitHub Pull Requests is the place for engaging with the OpenFAST team to have your new code merged into the main repository.

For other questions regarding OpenFAST, please contact Mike Sprague.

Tip

The following sections provide valuable guidance on workflow and development tips which make the process more efficient and effective:

• Working with OpenFAST on GitHub

• Code Style

• Debugging OpenFAST

5.1. API Reference

Some subroutines and derived types throughout the source code have in-source documentation which is compiled with Doxygen. Though this portion of the documentation is always under development, the existing API reference can be found in the following pages:

• Main Page

• Index of Types

• Source Files

5.2. Development Philosophy

OpenFAST is intended to be a self sustaining community developed software. A couple of tenets of this goal are that the code should be reasonably straightforward to comprehend and manageable to improve. With that in mind, we expect that new capabilities will include adequate testing and documentation.

We have the following guidance for developers:

• When fixing a bug, first introduce a unit test that exposes the bug, fix the bug, and submit a Pull Request. See Testing OpenFAST and Working with OpenFAST on GitHub for more information.

• When adding a new feature, create appropriate automated unit and regression tests as described in Testing OpenFAST. The objective is to create a GitHub pull request that provides adequate verification and validation so that the NREL OpenFAST developer team can merge the pull request with confidence that the new feature is “correct” and supports our goal of self-sustaining software. See Pull Requests for more information on submitting a pull request.

• If a code modification affects regression test results in an expected manner, work with the NREL OpenFAST developer team to upgrade the regression test suite via a GitHub issue or pull request at the openfast/r-test repository.

5.3. Development Guidelines

The following sections provide extended guidance on how to develop source code, interacting with the NREL OpenFAST team and other community contributors, and generally debugging and building out features.

• 5.3.1. Working with OpenFAST on GitHub
• 5.3.2. Code Style
• 5.3.3. Developing Documentation
• 5.3.4. Types Files and the OpenFAST Registry
• 5.3.5. Debugging OpenFAST
• 5.3.6. Performance-Profiling and Optimization
• 5.3.7. Versioning

5.4. Other Documentation

Additional documentation exists that may be useful for developers seeking deeper understanding of the solver and mathematics. This documentation is not generally necessary for most development efforts.

• 5.4.1. Other documentation