- 5MW_Land_BD_Linear_Aero: BD + AD15 (based on 5MW_Land_BD_Linear, but with aero)
- 5MW_Land_Linear_Aero: ED + AD15 (based on 5MW_Land_BD_Linear_Aero, but with ED)
- 5MW_OC4Semi_MD_Linear: MD equivalent of 5MW_OC4Semi_Linear

Upgrade to setup-python@v4 and cache@v4 for GH actions

Specify using np.float32 where possible in reading the linearization file. Also use np.float64 instead of float for matrices. Read matrices with genfromtxt instead of line by line

Previously the number of parallel threads in CTest was set via the -j flag. This changes it to use an environment variable set at the top of the file. The number of parallel tests was reduced from 4 to 2 as the linearization tests were failing from lack of memory. This may need to be adjusted.

…sion tests.

The previous method looped over each element and checked to see if it was within tolerance of the reference. This does the compare for the full matrices and then iterates over the element indices which were not within tolerance. This should significantly reduce the time to do the comparison for large matrices.

Also prints out the row/column variables which correspond to that element.

This will prevent warnings about node 16 deprecation

…SS_Rdtn%numStates

This also moves to a simpler scheme that just checks if the perturbation index 'n' is equal to the current value index 'k'

Add linearization regression tests

…kwards compatibility

Backport of PR #2013 and #2016

The motions in dUdy from BD were starting at the incorrect index.  Instead of starting at the motion, the index started at the root load output.  This resulted in a shift of all the dUdy terms coupling y_BD motion to u_AD blade motion.

This error has existed since at least commit 315bb29 on April 13, 2018

Co-authored-by: Derek Slaughter <deslaughter@gmail.com>

Lin tests: increase out precision, error printing full filename, add SD linearization test

…h documentation)

This results in some differences in the dUdy, A, and C matrices, but basically the same frequencies

Co-authored-by: Derek Slaughter <deslaughter@gmail.com>

Fix BD + AD linearization indexing (negative damping results)

When the change in reference rotation was implemented in v3.5.0, it effectively changed the states to be in the rotating frame. The existing method for putting the state Jacobians into the rotating frame involved calculating the difference in rotation between the root mesh reference orientation and the root mesh current orientation. Originally, the reference orientation always aligned with the blade root reference orientation inside BeamDyn. However, this is not a valid assumption when ChangeRefFrame = .true. as the blade root reference is updated by UpdateStates at every step.

This commit changes two things: first, if ChangeRefFrame is true, then p%RotStates is also set to true because the states are in the rotating frame; second, the Jacobian is now rotated by the difference between the root mesh current orientation and BeamDyn's root reference orientation. These orientations will be the same after UpdateStates, but the correction is still applied in case the Jacobian routines are called with a different root mesh orientation.

…_BD_Linear_Aero due to fixing this bug

…t 1 second

Fix bug in BD linearization resulting from reference rotation change

@rdamiani pointed out in issue #2059 that the existing method for handling file paths with `UserSubs` is difficult as it requires putting all the user input files in the same location as the ServoDyn file.  This commit is from recomendations from @rdamiani for a method he has had good success with.

Co-authored-by:rdamiani <r.damiani@RRDengineering.com>

Handling of Paths for SrvD UserSubs Input Files

This reverts commit ab42564.

The previous initial strain fix caused bad linearization results (and likely didn't fix the issue in the correct way). The new one replaces RR0 with R*x0' which is what OpenTurbine is using to avoid the mismatch that caused initial strain.

This fix was unintentionally removed when reverting the initial strain fix.

Bug: BeamDyn Initial Strain and Linearization

All code in FAST_Subs.f90 and other modules assumes Fortran style indexing (index start at 1) to the Turbine data structure.

This more accurately reflects what it is used for.

- `iTurb_c` is the new variable name for the turbine index passed into a FAST_Library.f90 routine.  This is assumed to start at 0 for the first turbine.
- `iTurb = iTurb_c + 1` shifts this index to the indexing used internally in OpenFAST.

…Turbines.

On some systems, the filepath may take the filename beyond 200 characters.

Consistent use of turbine indexing when coupled to c/c++

Automatically build OpenFAST docker images

Also updated some VS solution versions to 16 from older versions.

…odule

These members of the InflowWind initialization input DDT weren't being initialized and could potentially cause issues in the code when using FAST.Farm. Fixed by initializing values.

The array p_AD%FVW%Bld2Wings was indexed with iRot even if the array hadn't been allocated. This is not valid code, which was fixed by adding an if statement to only use the array if WakeMod is FVW

VSbuild: always build Registry as release x64

Fix use of uninitialized variables in FAST.Farm and increase stack size in Visual Studio