Wind io2p1

[ptrbortolotti]

Purpose

Update to windIO v2.1, which fixes a few bugs and updates the controller section thanks to work from @dzalkind and staff at DTU

Tests should be passing, although PR #691 has slowed them down excessively and we will need to go back and do something about it

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (non-backwards-compatible fix or feature)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Documentation update
• Maintenance update
• Other (please describe)

Testing

Checklist

• I have run existing tests which pass locally with my changes
• I have added new tests or examples that prove my fix is effective or that my feature works
• I have added necessary documentation

[ptrbortolotti]

Also, I've used the discon_to_windio function from ROSCO https://github.com/dzalkind/ROSCO/blob/0f159ae7a52e072743433621b8185a2cb4392cd8/Examples/34_discon_windio.py#L69
That misses the optimal_tsr field, which is needed by WISDEM
It also populates many more fields than the ones strictly needed by WISDEM. However for the sake of supporting WEIS and minimizing the amount of yaml files going around, I've left many of the yaml files fully populated
@dzalkind let me know what you think

[dzalkind]

Before this PR, there were a couple of inputs where there are multiple inputs defining the same thing. Peak shaving and optimal TSR are examples that WISDEM defines, but also ROSCO defines within WEIS.

I started de-conflicting and making a hierarchy of these options here:

WISDEM/wisdem/glue_code/gc_WT_InitModel.py

Line 1363 in 42cdb7d

if 'ROSCO' in modeling_options: # Will only be there if called by WEIS

I'm not sure we need to address these right now with this PR, but it's a heads-up that more of these conflicts (mainly between ROSCO and the windIO control schema) now exist, but that might be more of a WEIS issue. A few inputs are doubly defined in the geometry inputs now, so we may need to make a few updates to WISDEM once we start on the WEIS updates for this schema.

I'll mark them in this PR for (mainly my own) future reference.

[dzalkind]

One thing that's always tripped me up when using WISDEM is how rated_rotor_speed, max_rotor_speed, and max_allowable_blade_tip_speed is reconciled within the code.

[ptrbortolotti]

rated_rotor_speed is not an input to WISDEM, rather an output

the more stringent between max_rotor_speed and max_allowable_blade_tip_speed is enforced here

WISDEM/wisdem/rotorse/rotor_power.py

Line 396 in 0e109de

if inputs["max_allowable_blade_tip_speed"][0] > 0.0:

and now that I think about it there is a problem is the user does not define max_rotor_speed. I'll push a fix now

[dzalkind]

min_pitch_table, peak_thrust_shaving, and ps_percent (ROSCO) now all define the same thing. I can reconcile this.

[ptrbortolotti]

WISDEM takes min_pitch_table only to extract cut in and cut out...

WISDEM/wisdem/glue_code/gc_WT_InitModel.py

Line 1432 in 0e109de

wt_opt["control.V_in"] = min(control["min_pitch_table"]["wind_speed"])

[dzalkind]

Will WISDEM find and use fine_pitch and optimal_tsr from RotorSE or use these values?

[ptrbortolotti]

it uses these two values. TSR could be set as a design variable, although it rarely is because optimization problems are rarely well posed