diff --git a/docs/source/acknowledgements.rst b/docs/source/acknowledgements.rst index 2825ab2357..c4743ec2c8 100644 --- a/docs/source/acknowledgements.rst +++ b/docs/source/acknowledgements.rst @@ -4,11 +4,11 @@ Acknowledgements ================ This software is developed and maintained by researchers at the -`National Renewable Energy Laboratory `_ with funding +`National Laboratory of the Rockies `_ with funding from U.S. Department of Energy Wind Energy Technology Office through the `Atmosphere to electrons (A2e) `_ research initiative. -NREL gratefully acknowledges development contributions from the following +NLR gratefully acknowledges development contributions from the following organizations: - Accelerate Wind @@ -43,5 +43,5 @@ organizations: - Vestas - Windward Engineering -NREL gratefully acknowledges additional development support through designation +NLR gratefully acknowledges additional development support through designation as an `Intel® Parallel Computing Center (IPCC) `_. diff --git a/docs/source/dev/cppapi/index.rst b/docs/source/dev/cppapi/index.rst index 85d7d6e698..f065c11b0c 100644 --- a/docs/source/dev/cppapi/index.rst +++ b/docs/source/dev/cppapi/index.rst @@ -191,7 +191,7 @@ The mapping of loads and deflections to the actuator points is performed in the Test for mapping procedure -------------------------- -The test for the implementation of the mapping procedure is as follows. OpenFAST is run using the C++ API to simulate the NREL-5MW turbine for one time step with a prescribed velocity of :math:`8 m/s` at all the velocity nodes and no induction (:samp:`WakeMod=0`). The number of actuator force nodes is varied from 10 to 100 while the number of velocity nodes is fixed at 17. :numref:`actuator-force-nodes-mapping-test-thrust` and :numref:`actuator-force-nodes-mapping-test-torque` show that the thrust and torque vary by less than :math:`1.1 \times 10^{-6}\%` and :math:`2 \times 10^{-6}\%` respectively when the number of actuator force nodes is varied from :math:`10-100`. +The test for the implementation of the mapping procedure is as follows. OpenFAST is run using the C++ API to simulate the Jonkman 5-MW (formerly known as the NREL 5-MW) turbine for one time step with a prescribed velocity of :math:`8 m/s` at all the velocity nodes and no induction (:samp:`WakeMod=0`). The number of actuator force nodes is varied from 10 to 100 while the number of velocity nodes is fixed at 17. :numref:`actuator-force-nodes-mapping-test-thrust` and :numref:`actuator-force-nodes-mapping-test-torque` show that the thrust and torque vary by less than :math:`1.1 \times 10^{-6}\%` and :math:`2 \times 10^{-6}\%` respectively when the number of actuator force nodes is varied from :math:`10-100`. .. _actuator-force-nodes-mapping-test-thrust: diff --git a/docs/source/dev/github_workflow.rst b/docs/source/dev/github_workflow.rst index 8d690e0873..e973802cd9 100644 --- a/docs/source/dev/github_workflow.rst +++ b/docs/source/dev/github_workflow.rst @@ -7,7 +7,7 @@ on the `GitHub repository `__. There, `issues `__ and `pull requests `__ are discussed and new versions are released. It is the best mechanism for -engaging with the NREL OpenFAST team and other developers throughout +engaging with the NLR OpenFAST team and other developers throughout the OpenFAST community. Issues and work assignment @@ -22,7 +22,7 @@ make clear any intention to complete a task. Pull Requests ------------- When a code modification is ready for review, a pull request should be -submitted along with all appropriate documentation and tests. An NREL OpenFAST +submitted along with all appropriate documentation and tests. An NLR OpenFAST team member will assign a reviewer and work with the developer to have the code merged into the main repository. diff --git a/docs/source/dev/index.rst b/docs/source/dev/index.rst index 96ef271719..7295ce91d7 100644 --- a/docs/source/dev/index.rst +++ b/docs/source/dev/index.rst @@ -8,7 +8,7 @@ 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. +to work with the NLR 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 @@ -20,8 +20,8 @@ understand the general workflow for individual and coordinated development. Finally, be sure to review the :doc:`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: +With development happening in parallel between NLR, industry partners, and +universities, NLR relies on GitHub to coordinate efforts: - `GitHub Issues `_ is the place to ask usage or development questions, report bugs, and @@ -49,15 +49,15 @@ Development Philosophy and Guidelines ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OpenFAST is intended to be a self-sustaining, community developed software. -While the NREL OpenFAST team serves as the gatekeeper of the repository, we +While the NLR OpenFAST team serves as the gatekeeper of the repository, we actively encourage the community to share new ideas and contribute code. Considerations for contributing code are outlined here. -Engagement with NREL --------------------- +Engagement with NLR +------------------- The process for community code contribution starts with engaging directly -with the NREL OpenFAST team to define the scope of the work and coordinate +with the NLR OpenFAST team to define the scope of the work and coordinate development efforts. This is particularly important since many groups work on OpenFAST simultaneously. By engaging early, all developers can stay up to date and minimize conflicts during the code merge. @@ -67,17 +67,17 @@ development work, the areas of the software that will be impacted, and any model validation materials. See :ref:`development_plan` for more information on describing the planned work. -The NREL OpenFAST team is always working on internal projects +The NLR OpenFAST team is always working on internal projects that require the majority of our attention, but we will make every effort to engage with the community and support development efforts in -a reasonable time frame. After posting an Issue, the NREL OpenFAST +a reasonable time frame. After posting an Issue, the NLR OpenFAST team may reach out to schedule a meeting to talk through the details. .. _development_plan: Development Plan / Implementation Plan -------------------------------------- -Significant code development efforts at NREL begin with the development +Significant code development efforts at NLR begin with the development of a detailed implementation plan, and a few such plans are available to download for reference: @@ -147,10 +147,10 @@ as any algorithms or lines of code that are unclear. Ask yourself what you would need to know to fully understand your code if you don't see it again for two years. -Submit for review and NREL feedback +Submit for review and NLR feedback ----------------------------------- -New code can be submitted for review from the NREL OpenFAST team by +New code can be submitted for review from the NLR OpenFAST team by opening a `pull request `_ as described in :ref:`github_workflow`. We will review the code for accuracy, validity, quality, and robustness. Reviewing open source @@ -225,7 +225,7 @@ Additional guidance ------------------- The following sections provide extended guidance on developing source code, -interacting with the NREL OpenFAST team and other community contributors, and +interacting with the NLR OpenFAST team and other community contributors, and generally debugging and building out features. .. toctree:: diff --git a/docs/source/dev/performance.rst b/docs/source/dev/performance.rst index 5d07b55af9..8dbb5d137c 100644 --- a/docs/source/dev/performance.rst +++ b/docs/source/dev/performance.rst @@ -6,7 +6,7 @@ for the most computationally expensive use cases. The process generally involves initial profiling and hotspot analysis, then identifying specific subroutines to target for optimization in the physics modules and glue-codes. -A portion of this work was supported by Intel® through its designation of NREL as an +A portion of this work was supported by Intel® through its designation of NLR as an `Intel® Parallel Computing Center (IPCC) `_. The procedures, findings, and recommended programming practices are presented here. @@ -245,17 +245,17 @@ The physics modules used in this case are: * AeroDyn 15 * ServoDyn -This is a land based NREL 5-MW turbine simulation using BeamDyn as the +This is a land based Jonkman 5-MW (formerly called the NREL 5-MW) turbine simulation using BeamDyn as the structural module. It simulates 20 seconds with a time step size of 0.001 seconds and executes in `3m 55s `__ -on NREL's `Peregrine `__ -supercomputer. +on NLR's former Peregrine +supercomputer (retired). **5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth** Download case files `here `__. -This is an offshore, fixed-bottom NREL 5-MW turbine simulation with the +This is an offshore, fixed-bottom Jonkman 5-MW (formerly called the NREL 5-MW) turbine simulation with the majority of the computational expense occurring in the HydroDyn wave-dynamics calculation. @@ -270,8 +270,8 @@ The physics modules used in this case are: It simulates 60 seconds with a time step size of 0.01 seconds and executes in `20m 27s `__ -on NREL's `Peregrine `__ -supercomputer. +on NLR's former Peregrine +supercomputer (retired). Profiling +++++++++ @@ -324,7 +324,7 @@ Some keys outcomes from the first year of the IPCC project are as follows: * Core algorithms need significant modification to enable OpenMP and SIMD benefits -Tuning the Intel® tools to perform best on NREL's hardware and adding high level +Tuning the Intel® tools to perform best on NLR's hardware and adding high level multithreading yielded a maximum 3.8x time-to-solution improvement for one of the benchmark cases. @@ -373,14 +373,14 @@ areas: .. has continuously contributed code and expertise in this area. -.. Furthermore, NREL is optimizing OpenFAST for the future through profiling on +.. Furthermore, NLR is optimizing OpenFAST for the future through profiling on .. Intel next generation platform (NGP) simulators. .. bd_5MW_dynamic .. ~~~~~~~~~~~~~~ .. Download files `here `__. -.. This is a standalone BeamDyn case of the NREL 5MW wind turbine. It simulates 30 +.. This is a standalone BeamDyn case of the Jonkman 5-MW (formerly called the NREL 5-MW) wind turbine. It simulates 30 .. seconds with a time step size of 0.002 seconds and executes in 24s on NREL's .. Peregrine supercomputer. diff --git a/docs/source/dev/versioning.rst b/docs/source/dev/versioning.rst index 8f742f1962..77d409b991 100644 --- a/docs/source/dev/versioning.rst +++ b/docs/source/dev/versioning.rst @@ -15,7 +15,7 @@ For example, ``OpenFAST-v1.0.0-123-gabcd1234-dirty`` describes OpenFAST as: =================== ============= Version Component Explanation =================== ============= - v1.0.0 MAJOR.MINOR.PATCH numbering system; corresponds to a tagged commit made by NREL on GitHub + v1.0.0 MAJOR.MINOR.PATCH numbering system; corresponds to a tagged commit made by NREL (now called NLR after 2025) on GitHub 123-g Number of additional commits after the most recent tag for a build (the ``-g`` is for ``git``) abcd1234 First 8 characters of the current commit hash dirty Denotes that local changes have been made but not committed; omitted if there are no local changes diff --git a/docs/source/help.rst b/docs/source/help.rst index d0c2fe9692..42a911805a 100644 --- a/docs/source/help.rst +++ b/docs/source/help.rst @@ -6,10 +6,6 @@ Getting Help For possible bugs, enhancement requests, or code questions, please submit an issue at the `OpenFAST Github repository `_. -For OpenFAST usage questions, users should consider the `FAST Forum `_, which provides a large 10+ year legacy of FAST-related Q&A; the forum's search functionality should be used before posting questions to either github issues or the forum. - -Users may find the established FAST v8 through the NWTC Information Portal: -https://nwtc.nrel.gov/ - -Please contact `Michael.A.Sprague@NREL.gov `_. with questions regarding the OpenFAST development plan or how to contribute. +For OpenFAST usage questions, users should consider the `FAST Forum `_, which provides a large 10+ year legacy of FAST-related Q&A; the forum's search functionality should be used before posting questions to either GitHub issues or the forum. +Please contact `Jason.Jonkman@nlr.gov `_ or `Andy.Platt@nlr.gov `_ with questions regarding the OpenFAST development plan or how to contribute. diff --git a/docs/source/install/index.rst b/docs/source/install/index.rst index 39b82f766b..1a9fdbff0c 100644 --- a/docs/source/install/index.rst +++ b/docs/source/install/index.rst @@ -143,9 +143,9 @@ openfast_x64.exe 64-bit single precision openfast_x64_double.exe 64-bit double precision Map_Win32.dll 32-bit MAP++ library Map_x64.dll 64-bit 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 +DISCON_DLLS/<64bit or Win32>/DISCON.dll Controller library for Jonkman 5-MW (formerly called the NREL 5-MW) +DISCON_DLLS/<64bit or Win32>/DISCON_ITIBarge.dll Controller library for Jonkman 5-MW (formerly called the NREL 5-MW) - ITI Barge +DISCON_DLLS/<64bit or Win32>/DISCON_OC3Hywind.dll Controller library for Jonkman 5-MW (formerly called the NREL 5-MW) - OC3 Hywind ================================================== ============================================== After extracting the contents, the OpenFAST executables @@ -248,7 +248,7 @@ For more information and installation options, see the `OpenFAST Python readme < Compile from source ~~~~~~~~~~~~~~~~~~~ -To compile from source code, the NREL OpenFAST team has developed an +To compile from source code, the NLR 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 diff --git a/docs/source/testing/regression_test.rst b/docs/source/testing/regression_test.rst index 099a581564..662b11713b 100644 --- a/docs/source/testing/regression_test.rst +++ b/docs/source/testing/regression_test.rst @@ -153,8 +153,8 @@ executing with the help option: .. 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 + For the Jonkman 5-MW (formerly called the NREL 5-MW) turbine test cases, an external ServoDyn controller must + be compiled and included in the appropriate directory or all Jonkman 5-MW (formerly called the NREL 5-MW) cases will fail without starting. More information is available in the documentation for the `r-test repository `__, but be aware that these three DISCON controllers must exist @@ -200,8 +200,8 @@ be sure to execute the build command with the ``install`` target: .. 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 + REMINDER: For the 5MW turbine test cases, an external ServoDyn controller must + be compiled and included in the appropriate directory or all 5MW cases will fail without starting. More information is available in the documentation for the `r-test repository `__, but be aware that these three DISCON controllers must exist @@ -443,7 +443,7 @@ with the naming scheme ``executeRegressionTest.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. +to coordinate with the NLR team on creating this script. The next step is to add the test case in the appropriate location in the `r-test` submodule. The directory structure in r-test mirrors the @@ -481,4 +481,4 @@ CMake driver, so follow the instructions above to edit ``CTestList.cmake``. Finally, the new test cases in the r-test submodule must be added to the r-test repository. To do this, open a new issue in `r-test Issues `_ -requesting for support from the NREL team to commit your test. +requesting for support from the NLR team to commit your test. diff --git a/docs/source/user/aerodyn-aeroacoustics/02-noise-models.rst b/docs/source/user/aerodyn-aeroacoustics/02-noise-models.rst index 8422a63b62..18219d4c22 100644 --- a/docs/source/user/aerodyn-aeroacoustics/02-noise-models.rst +++ b/docs/source/user/aerodyn-aeroacoustics/02-noise-models.rst @@ -541,7 +541,7 @@ at high frequency, :math:`\overline{D}` is: {\left( 1 + M\cos\Theta_{e} \right)^{3}} :label: aa-eq:33 -Note that this equation was not reported in the NREL Tech Report NREL/TP-5000-75731! +Note that this equation was not reported in the NLR Tech Report NREL/TP-5000-75731! At low frequency, the equation is identical for both leading and trailing edges: diff --git a/docs/source/user/aerodyn-aeroacoustics/03-model-verification.rst b/docs/source/user/aerodyn-aeroacoustics/03-model-verification.rst index 6a3c13712c..3df16a6457 100644 --- a/docs/source/user/aerodyn-aeroacoustics/03-model-verification.rst +++ b/docs/source/user/aerodyn-aeroacoustics/03-model-verification.rst @@ -222,7 +222,7 @@ trailing edge (low :math:`\Theta_e`). .. [2] - https://github.com/NREL/ROSCO + https://github.com/NatLabRockies/ROSCO .. [3] https://github.com/OpenFAST/python-toolbox diff --git a/docs/source/user/aerodyn-aeroacoustics/acronyms.rst b/docs/source/user/aerodyn-aeroacoustics/acronyms.rst index d444c40537..8a98c4dd62 100644 --- a/docs/source/user/aerodyn-aeroacoustics/acronyms.rst +++ b/docs/source/user/aerodyn-aeroacoustics/acronyms.rst @@ -3,47 +3,49 @@ List of Acronyms ---------------- -+-----------+--------------------------------------------------------------+ -+ BPM + Brooks-Pope-Marcolini airfoil noise model + -+-----------+--------------------------------------------------------------+ -+ dB + decibels + -+-----------+--------------------------------------------------------------+ -+ dBA + A-weighted decibels + -+-----------+--------------------------------------------------------------+ -+ deg + degrees + -+-----------+--------------------------------------------------------------+ -+ Hz + hertz + -+-----------+--------------------------------------------------------------+ -+ IEA + International Energy Agency + -+-----------+--------------------------------------------------------------+ -+ kg + kilograms + -+-----------+--------------------------------------------------------------+ -+ kHz + kilohertz + -+-----------+--------------------------------------------------------------+ -+ LFC + low-frequency correction + -+-----------+--------------------------------------------------------------+ -+ m + meters + -+-----------+--------------------------------------------------------------+ -+ N + newtons + -+-----------+--------------------------------------------------------------+ -+ NREL + National Renewable Energy Laboratory + -+-----------+--------------------------------------------------------------+ -+ rad + radians + -+-----------+--------------------------------------------------------------+ -+ s + seconds + -+-----------+--------------------------------------------------------------+ -+ SPL + sound pressure level + -+-----------+--------------------------------------------------------------+ -+ TBL + turbulent boundary layer + -+-----------+--------------------------------------------------------------+ -+ TBL-TE + turbulent boundary layer – trailing edge + -+-----------+--------------------------------------------------------------+ -+ TNO + a Netherlands organization for applied scientific research + -+-----------+--------------------------------------------------------------+ -+ TE + trailing edge + -+-----------+--------------------------------------------------------------+ -+ TI + turbulent inflow + -+-----------+--------------------------------------------------------------+ -+ TUM + Technical University of Munich + -+-----------+--------------------------------------------------------------+ ++-----------+----------------------------------------------------------------+ ++ BPM + Brooks-Pope-Marcolini airfoil noise model + ++-----------+----------------------------------------------------------------+ ++ dB + decibels + ++-----------+----------------------------------------------------------------+ ++ dBA + A-weighted decibels + ++-----------+----------------------------------------------------------------+ ++ deg + degrees + ++-----------+----------------------------------------------------------------+ ++ Hz + hertz + ++-----------+----------------------------------------------------------------+ ++ IEA + International Energy Agency + ++-----------+----------------------------------------------------------------+ ++ kg + kilograms + ++-----------+----------------------------------------------------------------+ ++ kHz + kilohertz + ++-----------+----------------------------------------------------------------+ ++ LFC + low-frequency correction + ++-----------+----------------------------------------------------------------+ ++ m + meters + ++-----------+----------------------------------------------------------------+ ++ N + newtons + ++-----------+----------------------------------------------------------------+ ++ NREL + National Renewable Energy Laboratory (changed to NLR in 2025) + ++-----------+----------------------------------------------------------------+ ++ NLR + National Laboratory of the Rockies + ++-----------+----------------------------------------------------------------+ ++ rad + radians + ++-----------+----------------------------------------------------------------+ ++ s + seconds + ++-----------+----------------------------------------------------------------+ ++ SPL + sound pressure level + ++-----------+----------------------------------------------------------------+ ++ TBL + turbulent boundary layer + ++-----------+----------------------------------------------------------------+ ++ TBL-TE + turbulent boundary layer – trailing edge + ++-----------+----------------------------------------------------------------+ ++ TNO + a Netherlands organization for applied scientific research + ++-----------+----------------------------------------------------------------+ ++ TE + trailing edge + ++-----------+----------------------------------------------------------------+ ++ TI + turbulent inflow + ++-----------+----------------------------------------------------------------+ ++ TUM + Technical University of Munich + ++-----------+----------------------------------------------------------------+ diff --git a/docs/source/user/aerodyn-aeroacoustics/references.bib b/docs/source/user/aerodyn-aeroacoustics/references.bib index 3250183685..23c90916c6 100644 --- a/docs/source/user/aerodyn-aeroacoustics/references.bib +++ b/docs/source/user/aerodyn-aeroacoustics/references.bib @@ -108,7 +108,7 @@ @techreport{aa-Moriarty:2005 title= {NAFNoise User's Guide}, address= {Golden, CO}, institution= {National Renewable Energy Laboratory}, - URL= {https://github.com/NREL/NAFNoise/blob/master/NAFNoise.pdf} + URL= {https://github.com/NatLabRockies/NAFNoise/blob/master/NAFNoise.pdf} } @misc{aa-xfoil:699, diff --git a/docs/source/user/beamdyn/index.rst b/docs/source/user/beamdyn/index.rst index ce14098d1c..616891821c 100644 --- a/docs/source/user/beamdyn/index.rst +++ b/docs/source/user/beamdyn/index.rst @@ -12,7 +12,7 @@ can be downladed from the list below. - :download:`BeamDyn inputs from sectional beam properties <../../../OtherSupporting/BeamDyn/beamdyn_inputs_sectional_props.pdf>` The authors are grateful to the U.S. Department of Energy Wind and Water -Power Program and the NREL Laboratory Directed Research and Development +Power Program and the NLR Laboratory Directed Research and Development (LDRD) program through the grant “High-Fidelity Computational Modeling of Wind-Turbine Structural Dynamics” for supporting the development of this software. diff --git a/docs/source/user/beamdyn/introduction.rst b/docs/source/user/beamdyn/introduction.rst index 9cee56289b..b6e6c724f8 100644 --- a/docs/source/user/beamdyn/introduction.rst +++ b/docs/source/user/beamdyn/introduction.rst @@ -4,9 +4,9 @@ Introduction ============ BeamDyn is a time-domain structural-dynamics module for slender -structures created by the National Renewable Energy Laboratory (NREL) +structures created by the National Laboratory of the Rockies (NLR) through support from the U.S. Department of Energy Wind and Water Power -Program and the NREL Laboratory Directed Research and Development (LDRD) +Program and the NLR Laboratory Directed Research and Development (LDRD) program through the grant “High-Fidelity Computational Modeling of Wind-Turbine Structural Dynamics”, see References :cite:`Wang:SFE2013,Wang:GEBT2013,Wang:GEBT2014,Wang:2015`. The module has been coupled into the FAST aero-hydro-servo-elastic wind diff --git a/docs/source/user/beamdyn/theory.rst b/docs/source/user/beamdyn/theory.rst index 3f5f4d5097..7257d395d9 100644 --- a/docs/source/user/beamdyn/theory.rst +++ b/docs/source/user/beamdyn/theory.rst @@ -27,7 +27,7 @@ Coordinate Systems :width: 100% :align: center - Global, blade reference, and internal coordinate systems in BeamDyn. Illustration by Al Hicks, NREL. + Global, blade reference, and internal coordinate systems in BeamDyn. Illustration by Al Hicks, NLR. Global Coordinate System diff --git a/docs/source/user/elastodyn/coordsys.rst b/docs/source/user/elastodyn/coordsys.rst index 614ab85535..7e4fda78e4 100644 --- a/docs/source/user/elastodyn/coordsys.rst +++ b/docs/source/user/elastodyn/coordsys.rst @@ -9,9 +9,9 @@ For the coordinates system not detailed in subsections below, please refer to th - :download:`OpenFAST_coords.pdf <../../../OtherSupporting/OpenFAST_coords.pdf>`: Presentation from 2024 overviewing some coordinate systems in OpenFAST. -- `FAST 7 Manual `_ +- `FAST 7 Manual `_ -- `Technical report `_ on FAST_AD and modeling of the UAE wind turbine (in section 3) +- `Technical report `_ on FAST_AD and modeling of the UAE wind turbine (in section 3) - :download:`FASTCoordinateSystems.doc <../../../OtherSupporting/ElastoDyn/FASTCoordinateSystems.doc>`: Documents the transformation matrices relating each coordinate system in OpenFAST. Unfortunately, there are no pictures in this document that diagram these coordinate systems. They can hopefully be visualized by means of the transformation matrices. diff --git a/docs/source/user/fast.farm/FFarmTheory.rst b/docs/source/user/fast.farm/FFarmTheory.rst index 3f58c3a53e..5b78a1064d 100644 --- a/docs/source/user/fast.farm/FFarmTheory.rst +++ b/docs/source/user/fast.farm/FFarmTheory.rst @@ -484,9 +484,9 @@ each rotor. The wake-dynamics calculations involve many user-specified parameters that may depend, e.g., on turbine operation or atmospheric conditions that can be calibrated to better match experimental data or HFM, e.g., -by running `SOWFA `__ (or equivalent) as a +by running `SOWFA `__ (or equivalent) as a benchmark. Default values have been derived for each calibrated -parameter based on `SOWFA `__ +parameter based on `SOWFA `__ simulations (:cite:`ff-Doubrawa18_1`), but these can be overwritten by the user of FAST.Farm. @@ -1474,13 +1474,13 @@ wind farms or a subset of wind turbines within a larger wind farm. FAST.Farm can also use ambient wind generated by a high-fidelity precursor LES simulation of the entire wind farm (without wind turbines present), such as the ABLSolver preprocessor of -`SOWFA `__. This atmospheric precursor +`SOWFA `__. This atmospheric precursor simulation captures more physics than synthetic turbulence -- as illustrated in :numref:`FF:ABLSolver` -- including atmospheric stability, wind-farm-wide turbulent length scales, and complex terrain effects. It is more computationally expensive than using the ambient wind modeling options of *InflowWind*, but it is much less -computationally expensive than a `SOWFA `__ +computationally expensive than a `SOWFA `__ simulation with multiple wind turbines present. FAST.Farm requires ambient wind to be available in two different @@ -1599,7 +1599,7 @@ In previous implementations of DWM, the wind turbine and wake dynamics were solved individually or serially, not considering two-way wake-merging interactions. Additionally, there was no method available to calculate the disturbed wind in zones of wake overlap. Wake merging -is illustrated by the `SOWFA `__ simulation +is illustrated by the `SOWFA `__ simulation of :numref:`FF:WakeMerg`. In FAST.Farm, the wake-merging submodel of the *AWAE* module identifies zones of wake overlap between all wakes across the wind farm by finding wake volumes that overlap in diff --git a/docs/source/user/fast.farm/FutureWork.rst b/docs/source/user/fast.farm/FutureWork.rst index 9d620cc1ec..34ecdc3179 100644 --- a/docs/source/user/fast.farm/FutureWork.rst +++ b/docs/source/user/fast.farm/FutureWork.rst @@ -93,7 +93,7 @@ releases: - Interface FAST.Farm to the Wind-Plant Integrated System Design & Engineering Model - (`WISDEM `__\ :math:`^\text{TM}`) for + (`WISDEM `__\ :math:`^\text{TM}`) for systems-engineering applications (multidisciplinary design, analysis, and optimization; uncertainty quantification; and so on). diff --git a/docs/source/user/fast.farm/Introduction.rst b/docs/source/user/fast.farm/Introduction.rst index cb1797347a..bbb173e8ef 100644 --- a/docs/source/user/fast.farm/Introduction.rst +++ b/docs/source/user/fast.farm/Introduction.rst @@ -133,7 +133,7 @@ many user-specified parameters that may depend, e.g., on turbine operation or atmospheric conditions and can be calibrated to better match experimental data or by using an HFM solution as a benchmark. Default values have been derived for each calibrated parameter based on -`SOWFA `__ simulations, but these can be +`SOWFA `__ simulations, but these can be overwritten by the user. The wake-deficit evolution is solved in discrete time on an axisymmetric @@ -289,7 +289,7 @@ wind farms or a subset of wind turbines within a larger wind farm. FAST.Farm can also use ambient wind generated by a high-fidelity precursor large-eddy simulation (LES) of the entire wind farm (without wind turbines present), such as the atmospheric boundary layer solver -(ABLSolver) preprocessor of `SOWFA `__. +(ABLSolver) preprocessor of `SOWFA `__. This atmospheric precursor simulation captures more physics than synthetic turbulence -- as illustrated in :numref:`FF:ABLSolver` -- including atmospheric stability, @@ -382,7 +382,7 @@ separately compiled routines for them. FAST.Farm defers to the OpenFAST model of individual turbine for the turbine controller. The controller is specified in the ServoDyn module of OpenFAST. OpenFAST allows for the use of bladed-style controllers in DLL format. -Tools like `Reference Open Source Controller` (`ROSCO `_) +Tools like `Reference Open Source Controller` (`ROSCO `_) can be used to design and integrate turbine controller in DLL format, if the user does not already have their own controller. Farm-level super controller can be designed and implemented using external tools. @@ -391,7 +391,7 @@ provides for rapid design of common farm-level controllers such as wake steering control, spatial filtering/consensus and active power control etc. Hycon includes examples demonstration the design of a wake steering controller and implementation on a small farm using FAST.Farm. -The `Reference Open Source Controller` (`ROSCO `_) +The `Reference Open Source Controller` (`ROSCO `_) also has wind farm control capability. It gives the user low-level access to various turbine measurements and offsets, and enables implementation of user-written, python-based controllers. diff --git a/docs/source/user/fast.farm/ModelGuidance.rst b/docs/source/user/fast.farm/ModelGuidance.rst index ce47a7c22f..6ac30dd503 100644 --- a/docs/source/user/fast.farm/ModelGuidance.rst +++ b/docs/source/user/fast.farm/ModelGuidance.rst @@ -194,7 +194,7 @@ High-Fidelity Precursor Ambient Inflow There are many different methods by which high-fidelity precursor ambient inflow can be generated. This section focuses on generating such inflow using -`SOWFA `__. +`SOWFA `__. When using SOWFA to generate FAST.Farm precursor inflow, the *ABLSolver* preprocessor is used. It is important to note the baseline high-fidelity diff --git a/docs/source/user/fast_to_openfast.rst b/docs/source/user/fast_to_openfast.rst index 9f84b18b32..4b33d532c9 100644 --- a/docs/source/user/fast_to_openfast.rst +++ b/docs/source/user/fast_to_openfast.rst @@ -3,7 +3,7 @@ FAST v8 and the transition to OpenFAST ====================================== -This page describes the transition from FAST v8, a computer-aided 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 (DOE-WETO). +This page describes the transition from FAST v8, a computer-aided 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 (DOE-WETO). In the fall of 2025 the laboratory name changed to National Laboratory of the Rockies (NLR). FAST v8 ------- @@ -32,7 +32,7 @@ OpenFAST includes the following organizational changes relative to FAST v8.16: * Version numbering has been updated for OpenFAST (starting from OpenFAST v1.0.0), e.g., OpenFAST-v1.0.0-123-gabcd1234-dirty, where: - * v1.0.0 is the major-minor-bugfix numbering system and corresponds to a tagged commit made by NREL on GitHub + * v1.0.0 is the major-minor-bugfix numbering system and corresponds to a tagged commit made by NREL (now NLR) on GitHub * 123-g is the number of additional commits after the most recent tag for a build [the ‘-g’ is for ‘git’] @@ -46,13 +46,13 @@ OpenFAST includes the following organizational changes relative to FAST v8.16: * 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 user-related documentation is still provided through the NWTC Information Portal, https://nwtc.nrel.gov +* An online documentation system has been established to replace existing documentation of FAST v8: http://openfast.readthedocs.io/; during the transition to OpenFAST, most user-related documentation is still provided through the NWTC Information Portal, https://nwtc.nrel.gov (now deprecated) * Cross platform compiling is accomplished with CMake on macOS, Linux, and Cygwin (Windows) systems * Visual Studio Projects (VS-Build) 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 user-related questions on OpenFAST theory and usage should still be handled through the forum at https://wind.nrel.gov/forum/wind +* `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 user-related questions on OpenFAST theory and usage should still be handled through the forum at https://forums.nlr.gov/ * 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) @@ -77,7 +77,7 @@ Algorithmically, OpenFAST v0.1.0 is the release most closely related to FAST v8. * 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 user-related questions on OpenFAST theory and usage should still be handled through the forum at https://wind.nrel.gov/forum/wind + * `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 user-related questions on OpenFAST theory and usage should still be handled through the forum at https://forums.nlr.gov/ * The AeroDyn v15 aerodynamics module has been significantly updated. The blade-element/momentum theory (BEMT) solution algorithm has been improved as follows: @@ -196,5 +196,4 @@ For unit testing, we will employ the pFUnit framework (https://sourceforge.net/p 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. +Please contact `Jason.Jonkman@nlr.gov `_ or `Andy.Platt@nlr.gov `_ with questions regarding the OpenFAST development plan. diff --git a/docs/source/user/hydrodyn/appendix.rst b/docs/source/user/hydrodyn/appendix.rst index 558914dbaf..824778bf12 100644 --- a/docs/source/user/hydrodyn/appendix.rst +++ b/docs/source/user/hydrodyn/appendix.rst @@ -8,7 +8,7 @@ The following is a HydroDyn primary input file for OC4 semi-submersible structure:: ------- HydroDyn Input File ---------------------------------------------------- - NREL 5.0 MW offshore baseline floating platform HydroDyn input properties for the OC4 Semi-submersible. + historic NREL 5.0 MW offshore baseline floating platform HydroDyn input properties for the OC4 Semi-submersible. False Echo - Echo the input file data (flag) ---------------------- FLOATING PLATFORM --------------------------------------- [unused with WaveMod=6] 1 PotMod - Potential-flow model {0: none=no potential flow, 1: frequency-to-time-domain transforms based on WAMIT output, 2: fluid-impulse theory (FIT)} (switch) diff --git a/docs/source/user/hydrodyn/index.rst b/docs/source/user/hydrodyn/index.rst index 2dd19deb89..309e63a72d 100644 --- a/docs/source/user/hydrodyn/index.rst +++ b/docs/source/user/hydrodyn/index.rst @@ -26,11 +26,11 @@ development plans, and publications are made available for reference. Note that some of these may be outdated and pertain to older versions of HydroDyn. -- :download:`Computation of Wave Loads Under Multidirectional Sea States for Floating Offshore Wind Turbines ` -- :download:`Effects of Second-Order Hydrodynamic Forces on Floating Offshore Wind Turbines ` -- :download:`State-Space Realization of the Wave-Radiation Force within FAST ` +- :download:`Computation of Wave Loads Under Multidirectional Sea States for Floating Offshore Wind Turbines ` +- :download:`Effects of Second-Order Hydrodynamic Forces on Floating Offshore Wind Turbines ` +- :download:`State-Space Realization of the Wave-Radiation Force within FAST ` - :download:`Dynamics of Offshore Floating Wind Turbines—Model Development and Verification ` -- :download:`Dynamics Modeling and Loads Analysis of an Offshore Floating Wind Turbine ` +- :download:`Dynamics Modeling and Loads Analysis of an Offshore Floating Wind Turbine ` - :download:`Draft Implementation Plan - Changes in HydroDyn to Support Time-Varying Buoyancy Loads on Morison Members <../../../OtherSupporting/HydroDyn/HydroDyn_Plan_TCF_Morison.docx>` - :download:`Implementation Plan - Modifications to State-Space Modules in HydroDyn to Support Multiple WAMIT Bodies <../../../OtherSupporting/HydroDyn/HydroDyn_Plan_TCF_NBodyStateSpace.docx>` - :download:`Implementation Plan (Revised) - Changes in HydroDyn to Support Multiple WAMIT Bodies <../../../OtherSupporting/HydroDyn/HydroDyn_Plan_TCF_NBody.docx>` @@ -77,7 +77,7 @@ a separate frequency-domain panel code (e.g., WAMIT) from a pre-computation step. The radiation memory effect can be calculated either through direct time-domain convolution or through a linear state-space approach, with a state-space model derived through the -`SS_Fitting `_ +`SS_Fitting `_ preprocessor. The second-order terms can be derived from the full difference- and sum-frequency quadratic transfer functions (QTFs) or the difference-frequency terms can be estimated via Standing et al.’s :cite:`Standing:1987` diff --git a/docs/source/user/hydrodyn/input_files.rst b/docs/source/user/hydrodyn/input_files.rst index 20b8d76c06..a02d847ee7 100644 --- a/docs/source/user/hydrodyn/input_files.rst +++ b/docs/source/user/hydrodyn/input_files.rst @@ -349,7 +349,7 @@ any file headers. When the linear state-space model is used in place of frequency-to-time domain transformation for wave excitation or in place of convolution for radiation, the *.ssexctn* file for wave excitation (more information to be provided in the future) and/or the *.ss* file -for radiation generated by `SS_Fitting `__ +for radiation generated by `SS_Fitting `__ must have the same root name as the other WAMIT-related files. When **NBodyMod** = 1, **PotFile** should only contain one entry irrespective of diff --git a/docs/source/user/index.rst b/docs/source/user/index.rst index eb331f8113..c74a99f6f4 100644 --- a/docs/source/user/index.rst +++ b/docs/source/user/index.rst @@ -41,7 +41,7 @@ Additional module documentation The following modules do not currently have formal documentation or are contributed to OpenFAST from organizations -external to NREL and the core OpenFAST team. As documentation is added, +external to NLR and the core OpenFAST team. As documentation is added, these resources will be moved to their appropriate location. If newer versions of the external resources are available, please open a `GitHub Issue `_ with the information for the new documentation. diff --git a/docs/source/user/subdyn/introduction.rst b/docs/source/user/subdyn/introduction.rst index c5b8e1bf23..707e81cbf4 100644 --- a/docs/source/user/subdyn/introduction.rst +++ b/docs/source/user/subdyn/introduction.rst @@ -5,7 +5,7 @@ Introduction `SubDyn `__ is a time-domain structural-dynamics module for multimember fixed-bottom substructures -created by the National Renewable Energy Laboratory (NREL) through U.S. +created by the National Laboratory of the Rockies (NLR) through U.S. Department of Energy Wind and Water Power Program support. The module has been coupled into the FAST aero-hydro-servo-elastic computer-aided engineering (CAE) tool. Substructure types supported by SubDyn include diff --git a/docs/source/user/subdyn/modeling.rst b/docs/source/user/subdyn/modeling.rst index 0afc9cad06..353b8d19ba 100644 --- a/docs/source/user/subdyn/modeling.rst +++ b/docs/source/user/subdyn/modeling.rst @@ -155,7 +155,7 @@ use of the SubDyn-derived 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 SubDyn-obtained matrices +For instance, using NLR’s BModes software, the SubDyn-obtained 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 (free-free), BModes will @@ -166,8 +166,7 @@ and no distributed rotational-inertia contribution to the eigenmodes), the tower-distributed 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 results. The rotational inertia of the undeflected tower about its centerline is not currently accounted for in ElastoDyn. Thus, when the nacelle-yaw DOF diff --git a/docs/source/working.rst b/docs/source/working.rst index 5860c41ddb..f15320aa39 100644 --- a/docs/source/working.rst +++ b/docs/source/working.rst @@ -106,7 +106,7 @@ The input file format specifications of OpenFAST input files are given in :ref:`input_file_overview`. We provide a minimal working example to get you started on your first OpenFAST run. -This example uses the `NREL 5-MW `__ wind turbine, which is a fictitious but representative multi-MW wind turbine, with rated power 5 MW, rated rotor speed +This example uses the `historic NREL 5-MW `__ wind turbine, which is a fictitious but representative multi-MW wind turbine, with rated power 5 MW, rated rotor speed 12.1 rpm, Hub Height 90 m, and rotor diameter 126 m. This example is for an "onshore" version of the turbine, with only the structure (no aerodynamics), where the tower is initially displaced by 3m at the tower top. The files are located in the following `github directory `__ . @@ -269,40 +269,50 @@ Guidelines for the different modules can be found throughout this documentation, -Scripting ---------- +Scripting and other support tools +--------------------------------- -NREL maintains several repositories of scripts to work with OpenFAST. +NLR maintains several repositories of scripts to work with OpenFAST. The scripts can for instance be used to read the input and outputs of OpenFAST, visualize them, and generate multiple simulation inputs, and postprocess them. Some of these applications will be detailed in the following sections. -The repositories maintained by NREL are the following: +NLR toolboxes +~~~~~~~~~~~~~ - `openfast_toolbox `__: collection of low-level Python tools to work with OpenFAST and perform simple operations, with granularity. - `matlab-toolbox `__: collection of low-level Matlab tools to work with OpenFAST. -- `WEIS `__ : high-level Python scripts, stands for Wind Energy with Integrated Servo-control. It can perform multifidelity co-design of wind turbines. WEIS is a framework that combines multiple NREL-developed tools to enable design optimization of floating offshore wind turbines. +- `WEIS `__ : high-level Python scripts, stands for Wind Energy with Integrated Servo-control. It can perform multifidelity co-design of wind turbines. WEIS is a framework that combines multiple NLR-developed tools to enable design optimization of floating offshore wind turbines. -The users are invited to consult the documentations of the individual repository, and discuss related issues on their individual github pages. Contribution by the community to the NREL repositories are welcome and encouraged. +Users are invited to consult the documentation of the individual repositories and discuss related issues on their individual GitHub pages. Contributions by the community to the NLR repositories are welcome and encouraged. -Additional repositories maintained by NREL are listed below: +Other related NLR tools +~~~~~~~~~~~~~~~~~~~~~~~ -- `WISDEM `__: models for assessing overall wind plant cost of energy (COE), also contains file IO, (DLC) case generation, polar manipulations, visualization, and much more! -- `ROSCO_toolbox `__: tools to work with the `ROSCO `__ controller that is supported by OpenFAST +Additional repositories maintained by NLR are listed below: +- `WISDEM `__: models for assessing overall wind plant cost of energy (COE), also contains file IO, (DLC) case generation, polar manipulations, visualization, and much more! +- `ROSCO_toolbox `__: tools to work with the `ROSCO `__ controller that is supported by OpenFAST -Repositories maintained by third-parties are listed below: +Third party tools +~~~~~~~~~~~~~~~~~ - `pyDatView `_ : tool to plot the input and output files of OpenFAST, CSV-files, and other files from other wind energy software (Hawc2, Flex, Bladed). Multiple files can be opened at once to compare results from different simulations. - `WindEnergyToolbox `_: library developed by DTU, providing some support for different file formats -- `FASTTool `_ : NREL FASTv8, MATLAB GUI and Simulink integration developed by TUDelft +- `FASTTool `_ : MATLAB GUI and Simulink integration developed by TUDelft for FASTv8 + +- `Continuous Section Field (CSF) `_: a small Python utility developed by Giovanni Boscu for calculating cross-sectional properties for towers. The tool focuses on: + + - Modeling non-prismatic members using ruled surfaces. + - Calculating sectional properties :math:`(A, I, Ip)` along the tower height. + - Providing a simplified estimation of torsional rigidity :math:`( J )`. @@ -317,7 +327,7 @@ Open-source OpenFAST wind turbine models can be found here: - `r-test `__: regression tests for OpenFAST, contains models for OpenFAST and its drivers (AeroDyn, SubDyn, HydroDyn, etc.). This repository is not intended to be used as a "database" of models, but it has the advantage that the input files are always up to date with the latest `format specifications `_ . OpenFAST input files for previous version can be accessed via the git tags of this repository. - `IEA Wind Task 37 repository `_ : contains OpenFAST models of the IEA Wind 3.4-MW, 10-MW, 15-MW, and up-and-coming 22-MW reference wind turbines. -- `openfast-turbine-models `_: open source wind turbine models (in development and out of date). +- `openfast-turbine-models `_: open source wind turbine models (in development and out of date). @@ -358,7 +368,7 @@ Parametric studies can be run by using the scripts to read and write OpenFAST in and the Python `openfast_toolbox `__ . The openfast_toolbox provides dedicated Python scripts and examples to automatize the process (see the README of the repository for more). -The `AeroelasticSE` module of `WEIS `__ can generate input files for the design load cases specified in the standards. +The `AeroelasticSE` module of `WEIS `__ can generate input files for the design load cases specified in the standards. Consult the WEIS repository for more information. @@ -384,7 +394,7 @@ It is necessary to linearize at different operating points over a period of revo An additional complication is that some of the states of OpenFAST are in the rotating frame of reference (e.g. the ElastoDyn blade states). To obtain a linear state space model of the system that is in a fixed (non-rotating) frame of reference the multiblade coordinate transformation (MBC) is applied. For a purely periodic system, the MBC can be applied to the linearized outputs at different azimuthal positions which can be combined to form a linearized system in a fixed frame of reference. We note that the MBC only applies to 3 or more blades. -Floquet theory would be needed 1 or 2 blades, although NREL does not currently have a post-processor that makes use of Floquet theory. +Floquet theory would be needed 1 or 2 blades, although NLR does not currently have a post-processor that makes use of Floquet theory. .. note::