Missing documentation about the `FAST_Library.f90` interface

[andrew-platt]

Bug description The FAST_ExtInfw_Init includes 4 variables in the interface. ~I am suspicious there may be some hidden requirements with these.~

Edit: there is an intermediate mesh that I forgot about. We need documentation on this so we don't trip on it later

• NumBlElem_c [OUT] number of aerodynamic nodes on blade 1 (This assumes that the same number of aerodynamic nodes on all blades — this is not actually a requirement in OpenFAST, but generally true). Output from AeroDyn/OpenFAST to CFD (edited)
• NumActForcePtsBlade [IN] number of blade actuator line node force points from CFD sent into OpenFAST. Used to tell OpenFAST how many tower inflow measurement points are passed from CFD measured inflow (needed for setting the wind for AeroDyn correctly). This is not checked to see if it matches NumBldElem_c ~(I’m not sure the code works if they are different).~
• NumTwrElem_c [OUT] number of aerodynamic nodes on the tower from AeroDyn. Assumes only one tower per OpenFAST turbine.
• NumActForcePtsTower [IN] number of actuator line node force points on the tower from CFD sent into OpenFAST. Used to tell OpenFAST how many tower inflow measurement points are passed from CFD measured inflow (needed for setting the wind for AeroDyn correctly). This is not checked to see if it matches NumTwrElem_c ~(I’m not sure the code works if they are different).~

From what I can tell in a quick check, NumActForcePtsBlade and NumActForcePtsTower are used to tell ExtInflow how to unpack the wind data passed in from CFD and place it into the FlowField data structure (part of InflowWind). AeroDyn then grabs the FlowField data and applies it to the blade/tower nodes, so the number of AD nodes and CFD wind data points should be expected to exactly match.

It is very possible that this setup is leftover from when the structural mesh was used for location information passed to CFD (the structural mesh usually has a different number of points than the aero meshes).

Remedy ~Review how this works and simplify if possible, or add error checking.~ Add documentation about how the mapping works, and diagrams.

OpenFAST Version ~This applies to OpenFAST 4.0.0 and 4.0.1~ Not a bug.

[andrew-platt]

@marchdf brought this to our attention.

[andrew-platt]

After reviewing, there is a mesh mapping that occurs inside the ExternalInflow module. So these numbers do not need to match.

Changing this to a documentation request.