Incorrect force mesh used with OpenFOAM module

[andrew-platt]

Bug description The OpenFOAM module is used to transfer the motion of the aerodynamic centers of blades to the AMR-Wind or SOWFA. The loads calculated through CFD are then returned through the OpenFOAM module for OpenFAST to apply to the structure. The motion mesh is taken from the input mesh to AeroDyn 15, which is located at the aerodynamic centers of the blades. However, the ~~loads~~ velocities calculated from CFD are then applied at the ElastoDyn blade mesh, which may be offset from the aerodynamic centers where the ~~loads~~ velocities are calculated. Since the CFD code does not know about the offset between the meshes, the resulting moments form AD15 may be incorrect. See the AMR-Wind bug report here: https://github.com/Exawind/amr-wind/issues/673.

Since the ED blade load mesh is used for the returned ~~loads~~ velocities, it has also been impossible to use BeamDyn with either AMR-Wind or SOWFA.

In a discussion with @jjonkman, @tonyinme, and @ebranlard, we concluded that the correct approach is to use the AeroDyn15 load mesh for loads returned from CFD.

Thanks to @tonyinme for discovering and reporting this bug

Corrections required Most of the modifications required to correct this problem are in the OpenFAST-Library:

• FAST_Subs.f90: FAST_Initialize_All, p_FAST%CompInflow == Module_OpFM section, line ~650
  • Allocate the StructBldRNodes based on the AD15%y%rotors(1)%BladeLoad mesh
  • also change the tower to use the AD15 tower
  • change blade length and other values to originate from AD15 instead of ED
• FAST_Solver.f90
  • Check the logic used on OpFM, and adjust as needed to have AD15 loads mapped to structural codes (ED/AD15) as appropriate
• OpenFOAM module:
  • ED%u and ED%y are passed. Why? Does OpenFOAM even need these after adjusting the mapping above?

EDIT: corrected description based on comments below

[andrew-platt]

@gantech -- there may be some reasons you are aware of for using the ElastoDyn mesh for the loads originally. Any thoughts on why that was?

[gantech]

I thought I had used the OpenFAST mechanism to transfer the loads correctly to the actuator line mesh here. Let me know if you still think that's an issue.

https://github.com/OpenFAST/openfast/blob/main/modules/openfoam/src/OpenFOAM.f90#L478

[andrew-platt]

From what I can tell, that is correct in OpenFOAM.f90. I think the issue is really in the OpenFAST glue code in FAST_Subs.f90. Do you remember any discussions of the glue code modifications?

[gantech]

So the mesh for the actuator line is the same the mesh for the structural module (Only ElastoDyn for now.. will include BeamDyn soon). As far as I understand the load transfer between the structural module and the aerodynamics module already happens. And the current implementation uses the exact same load transfer mechanism as already being used inside OpenFAST. May be I just don't see the issue.

[andrew-platt]

The problem is the actuator line mesh is not the same as the structural mesh.

So the sequence at the moment is:

• ED structural mesh motion is mapped to AD15 motion mesh (these are spatially slightly different)
• AD15 motion mesh is passed to OpenFOAM as the motion mesh (correct for actuator line)
• ~~OpenFOAM returns a force mesh under the assumption that it is at the actuator line~~
• ~~FAST_Subs.f90 applies the OpenFOAM force mesh directly to ED point load mesh, at a different spatial location than the motions given to OpenFOAM~~
• OpenFOAM passes the structural mesh with a refinement to the CFD codes. This mesh doesn't match the AD15 mesh for the actuator line

~~This can be corrected in FAST_Subs.f90 by mapping the OpenFOAM mesh directly to the AD15 force mesh. Then the glue code will handle the moment arm effects when mapping to whatever structural mesh is used (either ED or BD).~~

EDIT: revised based on discussion below and discussions with @gantech and @jjonkman (revisions in italics)

[gantech]

Ok.. I agree that the actuator line mesh is not exactly the structural model mesh. But it's based on the structural model mesh. The reason for this is because we want to have an arbitrary number of points along the actuator line.

Here's where the actuator line mesh is created.

1. A temporary mesh based on the structural model is created here https://github.com/OpenFAST/openfast/blob/main/modules/openfoam/src/OpenFOAM.f90#L900

2. Then the actuator line mesh is created from this here https://github.com/OpenFAST/openfast/blob/main/modules/openfoam/src/OpenFOAM.f90#L786

[gantech]

Also..I was a little surprised by this statement "FAST_Subs.f90 applies the OpenFOAM force mesh directly to ED point load mesh, at a different spatial location than the motions given to OpenFOAM"

OpenFOAM module doesn't calculate any forces as far as OpenFAST is concerned. It's designed to be a replacement to the Inflow module. OpenFOAM module just gives the inflow velocity to AeroDyn and Aerodyn continues to give loads to ED as usual.

[andrew-platt]

Thanks for the clarification. I'm not entirely sure what I was looking at that led me to think OpFM was returning forces to the ED mesh. I stand corrected on this point (I crossed this out in my prior comment now that it is clear that was incorrect).

What is unclear to me is why OpenFOAM needs any info from ElastoDyn at all. It only needs info on the motion mesh and load mesh from AeroDyn15.

[andrew-platt]

After discussions with @gantech and @jjonkman, the issue stems from the CFD codes using a refined structural mesh derived from ElastoDyn. This mesh doesn't align with the AD15 mesh. So both meshes are passed to the CFD with different resolutions and locations.

Long term the solution appears to be to remove the structural meshes from the OpenFOAM module, but include an easy way to do refinement of the AD15 mesh. Additional changes would need to be made on the CFD side (AMR-Wind, SOWFA, and NALU-Wind).

[bjonkman]

I'd request that when any restructuring of this interface occurs, that you also keep in mind that the locations where AeroDyn requests wind input are not necessarily limited to places where it is calculating loads (e.g., ideally we'd have wind speeds at hub and nacelle, even if the load is lumped to a single "hub" point). There are also plans to send a disk-averaged wind speed to AeroDyn so that the mean velocity it uses isn't dependent on the azimuth angle. It would be nice if CFD could also handle that AD input.

[mchurchf]

It seems like it would be a simple fix to just keep the current framework, but subtract the 1/4 chord offset from the force positions passed to CFD. The whole problem that Tony and I are seeing is that with an actuator line, a bound vortex forms along the line of force (i.e., the Elastodyn mesh points). Yet we feed sampled velocity from CFD to Aerodyn at points that are shifted by 1/4 chord. To do the freestream velocity sampling correctly, one wants to sample right in the center of the bound vortex, where the flow induced by the vortex is not felt. If you are 1/4 chord forward of that, you sample a lot of upwash, which is not part of the freestream that you want to sample.

[tonyinme]

We had an excellent discussion yesterday with @jjonkman @andrew-platt and @gantech . As a temporary fix, we have set the variables "BlCrvAC BlSwpAC" in the aerodyn input files to zero. This ensures that the point forces coincide with the aerodyn/velocity points. After running a few tests, I can confirm this change works in AMR-Wind.

A more permanent fix will have to be implemented later on. The permanent fix should only use aerodyn/velocity points within the CFD coupling. With the fix, OpenFAST should be able to interpolate the aerodyn lookup tables to the desired total number of actuator points / aerodyn nodes.

[andrew-platt]

We will need to modify AD15 to add the ability to interpolate appropriately so it is user friendly.

As far as OpenFAST updates go, we will do this in two steps:

1. Adjust the OpenFOAM module to use only the AeroDyn15 nodes for both velocity and force (change in OpenFOAM module and glue code)
2. Add a way to easily interpolate the airfoils to increase the number of nodes -- input file option for refinement (change in AD15 only)

[tonyinme]

Thanks @andrew-platt , I agree, those are the main updates needed. These updates will also require some changes on the CFD codes. Ideally, it will make the CFD coupling easier by only requiring one set of actuator points as opposed to two sets.

[psakievich]

I would request that whatever interface is implemented retains backwards compatibility with the current interface in terms of function calls and the API. I think adding a new, more refined interface is an excellent idea, but if the API changes then all the dependent codes will need to be updated and will become backwards incompatible. This will make it difficult to reproduce old results or bisect code changes.

Another option is to add in a macro that allows compile time detection of the change so the downstream codes can maintain backwards compatible interfaces and update based on the openfast version they link against. This is a fine long term solution.

[andrew-platt]

Hi @psakievich. The proposed changes are all within OpenFAST. At present, I don't think any changes to the API are required with them.

@tonyinme, can you clarify what changes this necessitates in the CFD?

[psakievich]

@andrew-platt that is what I was thinking. I think we might have had some information get lost in translation. AMR-Wind doesn't use the specified API unfortunately, but we can deal with that.

[andrew-platt]

More notes

• the AD%y%BldLoads are time lagged by one timestep
  • will require extrapolation to next timestep
• AD15 interpolate points to refine the mesh
  • use nearest neighbor polar
  • Will require passing to CFD the point locations.

[mchurchf]

Tony and I just had a conversation about interpolation of Cl/Cd polars between airfoils. There is a method implemented in this old NREL tool AirfoilPrep that does a Cl/Cd polar interpolation that makes most sense that you may want to consider. I use it when I prepare actuator line or Aerodyn input files to have more resolution than whatever I am given to start with. I will try to find a reference, but the main idea is that it transforms the alpha in these tables to what I'd call alpha'. In this transformed space, peak Cl occurs at the same alpha' no matter the airfoil (so, for each airfoil, you need to know alpha for Cl,max), then it does linear interpolation based on thickness of airfoil. Once the interpolation is complete, the inverse alpha transform is applied and all is done. The effect is that as you blend between two airfoils with different max Cl alphas, the peak in Cl will smoothly move left or right. If you don't do this, you get double Cl peaks for blended polars, which is completely undesirable. I'm happy to explain this process in more detail. It is a feature we've really wanted for a long time directly in OpenFAST, instead a preprocessing step.

[andrew-platt]

The first step has been completed with PR #1324. It will be in the 3.4.0 release.

The second step is now documented in more detail in #1344 (including some comments from above).

[chatianming]

hello, every one, I would like to know that if this solver ('pisoFoamTurbine.ALMAdvancedOpenFAST') can be used to solve floating wind turbines? Besides, is there any document for this solver? because I can not find the users guide for this solver? it really annoy me.