OLAF FVW stability issue when simulating multiple rotors

[luwang00]

This PR is not ready to be merged.

Feature or improvement description
When simulating multiple rotors with the OLAF free vortex wake (FVW) method, it was observed that the wakes of Rotor 2 and beyond tend to be unstable. This is most obvious immediately after the start of the simulation or when the global time step is large. The stability issue also does not manifest when running the standalone AeroDyn driver.

This problem appears to be fixed by calling MV_AddModule for the AeroDyn rotors in FAST_InitializeAll in reverse order, i.e., starting from the last rotor and ending with the first rotor. It is not fully clear why this change yields the desired behavior.

In OpenFAST, a single AeroDyn module is used to simulate all rotors. However, this AeroDyn module is registered multiple times in the glue-code, resulting in multiple AeroDyn instances. The AeroDyn Jacobian subroutines are called multiple times as the glue-code iterates through all AeroDyn instances, with each call for a single rotor. The other subroutines that affect the whole module, such as AD_Input_ExtrapInterp, AD_UpdateStates, and AD_CalcOutput, are only called with the first AeroDyn instance that corresponds to Rotor 1 (see FAST_Funcs.f90) to prevent duplicated calls. By adding the AeroDyn instance for Rotor 1 last, the glue-code should call the module-level subroutines last after iterating through all the other rotors. It is likely that this change in the order of operations led to the correct behavior.

Example results
Example results based on the r-test MHK_RM1_Floating_MR:

The code change does not affect the fluid torque of Rotor 1 (R1) significantly; however, the erratic torque fluctuation of R2 immediately following the start of the simulation disappears with the proposed fix to OpenFAST.

For further verification, the results obtained with the full OpenFAST model with all ElastoDyn DOF set to false are compared with the results from an equivalent AeroDyn driver only model. For clarity, the speeds of the two rotors are made slightly different to obtain different thrust forces. The thrust of Rotor 1 obtained from the AeroDyn driver shows good agreement with the full OpenFAST model with and without the fix. On the other hand, the thrust of Rotor 2 obtained with OpenFAST without the fix shows large initial oscillations. In contrast, the OpenFAST result with the fix is in agreement with the AeroDyn driver result.

Impacted areas of the software
Glue-code

Test results, if applicable
This change affects r-tests with multiple rotors

• r-test branch merging required

[andrew-platt]

Good explanation of what is going on here. I think this is the correct solution.