Multi-Rotor input file and glue-code changes#2838
Multi-Rotor input file and glue-code changes#2838deslaughter merged 46 commits intoOpenFAST:dev-tcfrom
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds multi‐rotor support to OpenFAST by introducing a new rotor-index parameter and updating the corresponding glue code, registry definitions, and I/O routines throughout the codebase. Key changes include:
- Insertion of the NRotors parameter and new rotor mapping fields (e.g. iRotor) in input file readers, writers, and registry files.
- Updates in module glue code and mapping functions to propagate rotor-specific indices for BeamDyn, ServoDyn, and other modules.
- Modifications in the NWTC library types and helper routines to accommodate the new multi-rotor indexing scheme.
Reviewed Changes
Copilot reviewed 20 out of 20 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| reg_tests/r-test, CTestList.cmake | Updated regression test and disabled multi-rotor test in CTestLists |
| openfast_io/FAST_writer.py, FAST_reader.py | Added new parameter NRotors for I/O of rotor count |
| modules/subdyn/* | Added new fields (qR0, IsFloating) and packed/unpacked routines for substructure |
| modules/openfast-library/* | A large number of mapping, solver, and API changes to support rotor indexing |
| modules/nwtc-library/* | Updated registry and type routines to include the rotor number (iRotor) |
| docs/source/user/api_change.rst | Documentation updates for multi-rotor input file changes |
Comments suppressed due to low confidence (2)
modules/openfast-library/src/FAST_Mapping.f90:449
- It may be helpful to add a brief comment clarifying that an iRotor value of 0 indicates a module that is not rotor-specific, ensuring the condition is clear to future maintainers.
if ((Mods(iModSrc)%iRotor /= 0) .and. (Mods(iModDst)%iRotor /= 0) .and. (Mods(iModSrc)%iRotor /= Mods(iModDst)%iRotor)) cycle
modules/openfast-library/src/FAST_AeroMap.f90:561
- Since the code now uses p_FAST%NumBD in related contexts, please verify that replacing nBeams with NumBD is consistent across the codebase.
do iter = 1, p_FAST%nBeams
| logical, intent(in) :: Linearize | ||
| integer(IntKi), intent(out) :: ErrStat | ||
| character(ErrMsgLen), intent(out) :: ErrMsg | ||
| subroutine MV_AddModule(ModDataAry, ModID, ModAbbr, Instance, ModDT, SolverDT, Vars, Linearize, ErrStat, ErrMsg, iRotor) |
There was a problem hiding this comment.
Please ensure that the optional iRotor parameter is clearly documented as defaulting to 0 (i.e. applicable for all rotors if not provided) to avoid ambiguity.
hkross
left a comment
hkross
left a comment
There was a problem hiding this comment.
These changes look good to me, although I don't have extensive experience working in many sections of the code that were changed here.
Do we want to add the MHK multi-rotor r-test to the pull request?
docs/source/user/api_change.rst
Outdated
|
|
||
| Changes to the OpenFAST input file support multiple rotors in one turbine. Line 16, NRotors, | ||
| is required to specify the number of rotors in the turbine. Lines 50-56 specify the | ||
| ElastoDyn, BeamDyn, and ServoDyn input files for the second rotor. The `MirrorRotor` line |
There was a problem hiding this comment.
We should specify in the documentation or in the example input file (or both) that the new section only needs to list the ElastoDyn, BeamDyn, and ServoDyn input files for the additional rotors and all other modules will use the input files listed in the first rotor section.
There was a problem hiding this comment.
I added a note about this in the paragraph, but I agree, we'll need a section in the documentation to describe how to set up a multi-rotor simulation
|
@hkross Adding the MHK multi-rotor would be great to this PR would be good, or we can go ahead and merge this and you could add it later. Whatever works for you. |
I'll work on putting those input files together, and if they are done in time, we can add them here. |
…nges' into multirotor-file-changes
…nges' into multirotor-file-changes
|
Hi @deslaughter, I added a new SD driver r-test here OpenFAST/r-test#156. This provides an example where we have multiple transition pieces and rigid-body DoF tracked by SD. We can update |
andrew-platt
left a comment
andrew-platt
left a comment
There was a problem hiding this comment.
Looks good!
Apologies for the delay in reviewing
This PR is ready to merge.
Feature or improvement description
This PR adds support for multiple rotors to the input files and the glue code for OpenFAST. A demo regression test was added for the multi-rotor capability in
5MW_OC4Semi_WSt_WavesWN_MR; however, this test is not run as part of the test suit as it is not fully working.Impacted areas of the software
This PR has changes throughout the OpenFAST glue code to handle indexing, allow multiple ServoDyn instances, and allow mapping of module instances within the same rotor or across rotors. The
5MW_OC4Semi_WSt_WavesWN_MRmulti-rotor regression test was added to ther-testrepository, but is not enabled inCTestLists.txt(the line is commented out).Test results, if applicable
Existing test results are unchanged.