AeroDyn v5.0.0 propagation-direction Jacobian uses stale wind rotations

[Mohammad-Salik]

Title: AeroDyn v5.0.0 propagation-direction Jacobian uses stale wind rotations

Bug description

During linearization, AeroDyn perturbs PropagationDir without refreshing the dependent wind rotation matrices and rotation-enable state before evaluating the perturbed velocity.

At the validated operating point, the original implementation produces a zero propagation-direction column in B and zero direction feedthrough to turbine outputs in D across all 36 azimuths. InflowWind’s velocity-output Jacobian nevertheless correctly gives:

$$ \frac{\partial V_y}{\partial \psi} = -U $$

To Reproduce

Steps to reproduce the behavior:

1. Compile OpenFAST v5.0.0 in double precision.
2. Linearize an aeroelastic case using uniform wind with vertical shear, zero mean propagation direction and upflow angle, and extended wind inputs enabled. Collect 36 azimuth snapshots.
3. Open the resulting .lin files and locate the propagation-direction input columns in B and D.
4. In the validated case, the state-input and turbine-output direction derivatives are zero, while the InflowWind lateral-velocity derivative is correctly −U.

These observations were validated at one operating point; equivalent behavior has not been established for arbitrary configurations.

Expected behavior

A propagation-direction perturbation should update the wind velocity evaluated by AeroDyn, allowing the corresponding aeroelastic derivatives to be calculated consistently with InflowWind.

Screenshots, if applicable

Not applicable; evidence comes from numerical comparisons of the .lin matrices.

OpenFAST Version

• Base version: OpenFAST v5.0.0
• Base commit: 2895884d2be01862173c88d70f86b358d2f1a50a
• Local validation build: v5.0.0-psi-validation
• Architecture: 64 bit
• Precision: double

The validation build supports comparison of the original perturbation behavior, the repaired implementation, and an independent finite-difference implementation.

System Information (please complete the following information):

• OS: Windows, 64 bit
• Compiler: Intel Fortran ifx 2026.0, build 20260331
• Build system: CMake with Ninja
• Relevant settings:

  -DDOUBLE_PRECISION=ON
  -DOPENMP=OFF
  -DBLA_VENDOR=Intel10_64lp_seq
  -DCMAKE_BUILD_TYPE=Release
  

Additional context

The affected code is AD_JacobianPInput → PerturbFlowField in modules/aerodyn/src/AeroDyn.f90. Updating PropagationDir alone leaves RotToWind, RotFromWind, and RotateWindBox stale.

The repair refreshes these quantities when direction is perturbed and restores the base rotation before subsequent perturbations.

At one operating point, the repaired implementation restores a nonzero direction response and agrees with an independent uniform-wind-angle finite-difference perturbation across all 36 azimuths at the same step size. Saved operating states, A, C, and non-direction columns of B and D remain unchanged at saved precision.

Finite-difference step-size accuracy is a separate numerical issue. Agreement at a common step validates the rotation repair; it does not establish that the default step is sufficiently accurate.

[jjonkman]

Dear @Mohammad-Salik.

I haven't confirmed whether the bug you are reporting is true, but it sounds like you have a solution that you've already implemented. Do you plan to share a Pull Request (PR) that fixes the issue?

Can you share your OpenFAST input files and associated linearization (.lin) output files that include the bug and its fix so that we can further understand the issue you are reporting?

Best regards,

[Mohammad-Salik]

Dear Jason,

thank you for your response.

I have attached a reproducing OpenFAST input case together with the corresponding 36-azimuth .lin outputs from the original and repaired implementations. The reproducer is a uniform-wind, vertically sheared case at 18 m/s, $\alpha=0.14$, zero mean propagation/upflow angle. I also included a small Python comparison script that checks the propagation-direction columns and confirms that the non-direction matrices remain unchanged at the saved precision. The validated source patch is included as well.

The two output sets use identical OpenFAST inputs. The only intended difference is the propagation-direction perturbation behavior in AeroDyn.

I can also prepare a PR with the fix against the current development branch.

Best regards,

[jjonkman]

Dear @Mohammad-Salik,

Thanks for clarifying. I now understand what is missing from the B and D matrices for the extended input of AeroDyn, PropagationDir. I agree this is a bug, although I haven't confirmed your fix yet.

I recall this extended input did work on older versions of OpenFAST, but the bug was probably introduced when the linearization code was reworked when tight coupling was introduced in OpenFAST v5.0.0.

Thanks for tracking down and suggesting a solution. If you could submit a PR, that would be useful.

Best regards,

[andrew-platt]

Instead of putting this on the current dev branch, could you base your fix on the rc-5.0.1 branch? We can include it in upcoming bugfix release v5.0.1.

[andrew-platt]

Thanks @Mohammad-Salik!