Preliminary support for multiple rotors in AeroDyn

[ebranlard]

This pull request is ready to merge

Feature or improvement description
Provide support for multiple rotors in AeroDyn.
This feature is not yet supported by the glue-code, nor the current aerodyn-driver, but it has been tested using a new aerodyn driver that will be shipped in a future pull request. This is an example of VTK outputs with the new driver, both rotors are handled by BEM:

Actions:

• Merge Add ability to turn unsteady aero back on during a simulation #647 first
• Make sure the r-test are unchanged. (Yes now that Add ability to turn unsteady aero back on during a simulation #647 was merged)
• Review

Impacted areas of the software
AeroDyn, OpenFAST library, Openfoam coupling

Additional supporting information

General info:

• Only AeroDyn supports multiple rotors, so only 1 rotor is used in the OpenFAST library and Openfoam. For loops were not added there.
• Most of the changes involve introducing %rotors(1) in the glue code and other caller of AeroDyn.
• Support for multiple rotors with OLAF is not part of this pull request and will come through another pull request (either WEIS, or the new aerodyn driver)
• Each rotor has a nacelle, tower, hub.
• For BEM, the tower influences only the rotor to which it is attached to (simpler for now). For OLAF, all the towers will influence the wake.

Some points to review/comment on:

• Most of the AeroDyn data is now stored per rotor, even things like AirDensity, BEM Options, this offer the most flexibility, but might be overkill (say one rotor in the water and one in the air, one with UA the other without). I can easily change this, most AeroDyn functions now have two set of parameters coming in, p (the rotor parameters), and p_AD` the AeroDyn parameters (very few for now, but we can shift AirDensity there for instance).
• The WriteOuputs are stored per rotor, leaving it to the glue code to decide whether these should be written to different files. This means AeroDyn does not have WriteOutputs directly, and I had to add an if statement in the glue code at the point where the write outputs from each modules are packed.
• The linearization of AeroDyn is currently dedicated to BEM, and one rotor. To try to keep the changes minimal, I've made Jacobian routines that deal with one rotor at a time. The downside is that the Jacobian routine have then to call a 'CalcOutput' and 'CalcResidual' that are per rotor as well. In general, I've kept the convention AD_RoutineName -> RotRoutineName for routines that are rotor specific. The code will return an error if linearization is done for multiple rotors.
• I'm happy replacing %rotors with %rot for shorter notations

[ebranlard]

@bjonkman if you have time, can you have a look at these code changes? Thanks a lot!

[andrew-platt]

I looked through quickly and didn't see anything problematic.

The glue code changes look ok.