Non-Smooth Actuator-Line Solution

[mchurchf]

Bug description
I am running AMR-Wind coupled with OpenFAST 4.2.1 to do actuator line simulations. I noticed that if I select actuator points that are not exactly coincident with the Aerodyn input points, the flow field develops "streaks" of velocity perturbation trailing from each blade. The streaks show up at the same spanwise location on all blades. If I write out and plot Aerodyn force/unit length along the blade, I see "blips" in the spanwise distribution of forces. As soon as I set the Aerodyn and actuator points to be exactly coincident (well, within like 4-6 decimal places), the problem disappears. The problem appears random as I change number of actuator points. Sometimes the problem shows only a couple of streaks, sometimes many of them. Because of mesh mapping, the Aerodyn points should not have to be coincident with the actuator points.

To Reproduce

Steps to reproduce the behavior:

1. Compile AMR-Wind-main and OpenFAST-4.2.1 using the kynema-manager
2. I have a simple uniform inflow actuator line case using the NREL 5 MW turbine that illustrates the problem. I can share the case. I only run it for about 1-2 s of simulated time to see the issue.
3. Take a rotor normal velocity slice right in the rotor plane and visualize velocity normal to the rotor and you'll see the issue.
4. Plot spanwise forces per unit length and you'll see the issue.

Expected behavior
The Aerodyn and actuator line points should not have to be coincident to obtain a smooth force distribution and velocity field. I do expect some jumps where airfoil changes, but the issue I am seeing is more abrupt than those airfoil change jumps.

Screenshots, if applicable

Expected behavior: this is what I get when Aerodyn and actuator points match. I have 64 points each.

Problematic behavior: This is when I have 64 Aerodyn points and 96 actuator points.

OpenFAST Version

Creating ExtSolver instance: OpenFAST

 **************************************************************************************************
 OpenFAST

 Copyright (C) 2026 National Renewable Energy Laboratory
 Copyright (C) 2026 Envision Energy USA LTD

 This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
 See the "LICENSE" file distributed with this software for details.
 **************************************************************************************************

 OpenFAST-v4.2.1-dirty
 Compile Info:
  - Compiler: Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.2.0
  Build 20230622
  - Architecture: 64 bit
  - Precision: double
  - OpenMP: Yes, number of threads: 1/1
  - Date: Sep 08 2026
  - Time: 08:29:07
 Execution Info:
  - Date: 09/09/2026
  - Time: 13:59:44-0600

 OpenFAST input file heading:
     FAST Certification Test #18: NREL 5.0 MW Baseline Wind Turbine (Onshore)

System Information (please complete the following information):

• OS: Red-Hat Linux
• Compiler: IntelLLVM 2023.2.0
• Compiler settings: Whatever spack does...
• System: Kestrel

Additional context
N/A

[andrew-platt]

A few details on the mesh mapping. A point mesh ActForceMotionsPoints of locations is passed from AMR-Wind. A sibling point load mesh ActForceLoadsPoints is created inside the ExternalInflow module. The line loads from AeroDyn are then mapped to this point load mesh for return to AMR-Wind.

When there are more points on the actuator line mesh from AMR-Wind, the AeroDyn distributed loads are mapped to the closest points, which results in some points getting the load and neighboring ones not receiving a load.

My suspicion is we can address this in one of two ways:

1. change AMR-Wind to expect a line load returned
2. modify the mesh mapping to more evenly apply the line loads to a finer mesh of points

I don't know if we'll be able to make an update on 4.2.1 or not, but we can likely update this going forward on the v5.x series