Lidar bug fix + other minor changes

[bjonkman]

Feature or improvement description

• Bug fixes:

  • The RotorApexOffsetPos input in the InflowWind input file was reading only the first (x) component of the 3-dimensional array, so the other two were likely uninitialized when used in the Lidar module. This change also required an update to one of the r-test InflowWind input files that didn't have all 3 values.
  • The Visual Studio build was not able to create ServoDyn_Types.f90. This has been fixed.

• Other updates:

  • I updated some spacing and comments in the code.
  • I reorganized small bits of code for better compatibility with Envision code base.
  • I removed unused variables.
  • I fixed some issues with single-/double-precision types in some of the new HydroDyn code.
  • I removed some redundant error handling (e.g., errors in reading the Lidar input parameters from IfW would result in 2 messages instead of 1).
  • I reorganized a bit of the FAST Visual Studio project, creating folders for CompAero modules, CompInflow, and CompSub modules.

Related issue, if one exists
#2413

Impacted areas of the software
InflowWind, Lidar, HydroDyn, MAP++, glue code, NWTC_Library, ServoDyn

Additional supporting information

Test results, if applicable
This doesn't affect any results.

[andrew-platt]

My only concern is with the lidar connection to the OpenFAST_Library. Hopefully we don't break someones connection to another code with this change (I'm guessing we don't)

[bjonkman]

The change to that interface should be only (1) removing the definition of SensorType _None for the lidar and (2) modifying the FAST_ExternInitType data structure to remove the lidar variables. I'd be surprised if any of the other interfaces to OpenFAST (other than the Simulink one) would be affected. But, I guess we'll find out. :)

[andrew-platt]

That's what I was wondering about; does someone link it to SimuLink and I'm not aware of it. If we get a complaint about that, we can add it back in then (and maybe fix a few things at that point).

[bjonkman]

That's what I was wondering about; does someone link it to SimuLink and I'm not aware of it. If we get a complaint about that, we can add it back in then (and maybe fix a few things at that point).

Well, even if they were linking to Simulink another way, I didn't actually change any functionality that's been there since #1464 was merged in April 2023. The code was not doing anything with those variables that used to get passed from Simulink. They are read from the InflowWind input file. You can still pass them in that Simulink interface, they just now get ignored earlier than they used to.

[andrew-platt]

Thanks for the clarification! Given that the variables weren't getting passed all the way, this change shouldn't affect anyone.