Improvements to the InflowWind disk averaged velocity calculations

[andrew-platt]

This PR is ready for merging.

Feature or improvement description
The disk average velocity calculation is now based on multiple points instead of simply the hub center. This provides a more realistic average velocity when there is wind shear. There are also a few updates to the InflowWind outputs and driver.

• InflowWind has a new initialization input, RadAvg, the radius (from the hub). InflowWind will use 70% of this value to calculate positions to average for the wind speed (using 144 points)
• InflowWind driver has a feature to convert a wind file to a uniform wind format.
• InflowWind has new inputs for the hub position and orientation (the center from which to compute the position of the points that are averaged)
• InflowWind has new outputs:
  • HubVel is the instantaneous velocity at the hub position (whereas the hub velocity sent to ServoDyn is at the reference [fixed] position of the hub)
  • DiskVel has the same name as the value that was always sent to AD14, but is now computed in a different way. Importantly, it is NOT tied to the wind file type. This does change the results of AD14 simulations rather dramatically, but AD14 will be deprecated soon.
  • InflowWind has several new WriteOutput channels to query values of HubVel and DiskVel

Limitations:

• InflowWind calls in AD14/DWM have not been updated so it would probably seg fault if you called DWM. We expect to deprecate AD14 shortly after this PR.
• The linearization doesn't take into account ElastoDyn's hub position/orientation influence on InflowWind's DiskVel or Hub, but the matrices have been changed (hub orientation not added, but hub position is included)

Related issue, if one exists
N/A

Impacted areas of the software
This changes the disk average velocity used in AeroDyn 14. It will also impact future modules including AeroDisk.

Additional supporting information
The methods for extracting a disk average velocity for AD14 have been used since AD12 and are rather suspect. The calculation was different for each wind type and did not account for searh. For example, the disk average velocity from Uniform Wind files is simply the hub height wind speed, and full field files were simply the advection speed. This was resulting in very different loads from AD14 for the same wind profile stored in different wind file formats.

Test results, if applicable
Four regression tests using AD14 fail as a result of this change and must be updated.

casename	WindType	Wind name
AWT_YFix_WSt	1	Steady with PlExp
WP_VSP_WTurb_PitchFail	4	Bladed full-field
5MW_ITIBarge_DLL_WTurb_WavesIrr_py	3	TurbSim full-field
AWT_YFree_WTurb	4	Bladed full-field

[jjonkman]

I haven't reviewed the source code changes in great detail (and don't intend to), but overall this looks good to me. My only real comment is that the conversation focuses on how the calculation of DiskVel is improved, but the PR appears to contain much more than that, including new write outputs and functionality to convert from full-field to uniform wind formats.

[bjonkman]

Here are some comments about what is in this PR from when I sent you guys this code in July:

Some new features:

• InflowWind has a new initialization input, RadAvg, the radius (from the hub). InflowWind will use 70% of this value to calculate positions to average for the wind speed (using 144 points, but you can change that)
• InflowWind driver has a feature to convert a wind file to a uniform wind format.
• InflowWind has new inputs for the hub position and orientation (the center from which to compute the position of the points that are averaged)
• InflowWind has new outputs:
  • HubVel is the instantaneous velocity at the hub position (whereas the hub velocity sent to ServoDyn is at the reference [fixed] position of the hub)
  • DiskVel has the same name as the value that was always sent to AD14, but is now computed in a different way. Importantly, it is NOT tied to the wind file type. I would imagine all of the AD14 regression tests will give different results unless they use constant wind (with no shear).... as I recall, some of those cases changed significantly when I attempted to compute DiskVel differently way back when I made AD13 (and then reverted those changes).
• InflowWind has several new WriteOutput channels to query values of HubVel and DiskVel

Cautions:

• I didn't update where InflowWind is called in AD14/DWM (AD14 is already deprecated?) so it would probably seg fault if you called DWM.
• The linearization doesn't take into account ElastoDyn's hub position/orientation influence on InflowWind's DiskVel or Hub, but the matrices have been changed (I don't think I added the hub orientation, but I did add the hub position)

[andrew-platt]

Thanks @bjonkman! I'll incorporate your comments into the notes.

Given the caution on DWM, I'm inclined to add a fatal error if it is chosen. I think this PR will get merged in shortly before the removal of AD14.

[ebranlard]

Just a random comment,
I'm wondering why we have both .out and .outb in these cases. (probably a lot more other cases have them). This affects the size of the r-test repository.
I would be in favor of having only .outb (since anyway git cannot keep track of differences of channels because .out files are column by column, not line by line (the transpose of it), and let the python script try to open the .outb file if it exists, otherwise the .out file.
The summary files are also a bit unnecessary.

[bjonkman]

@ebranlard : I've deleted the .out files in the f/SeaState_ConstrWave branch and changed the output file types so they aren't generated. We don't use them, so it's just wasting space. I think all of the r-test files are that way... probably an artifact of the way generating the uncompressed binary files was first implemented.

[andrew-platt]

I'll remove them from here as well.