Use pointers to couple InflowWind and AeroDyn #1596
Conversation
This commit contains a complete port of the openfast-registry to C++. The new registry doesn't support the dimspecs used in AD14 so they were replaced in the input file. This module will be removed soon and this feature is not used by other modules so it didn't seem necessary to keep this feature. AeroDyn_Registry.txt had a malformed line which was acceptable to the previous parser, but didn't work for the new one so the input file was updated. The registry implements specifying a target and a regular pointer pointer on the field name using & and * respectively. The registry treats TARGETs (&) the same as allocatable fields wrt pack/unpack/copy. Essentially, target's own their memory. POINTERS (*) do not own their memory and are not packed/unpacked. The pointer association is maintained by the copy function.
While this may duplicate the wind calculation, it avoids having code outside the module dealing with the wind calc.
There was a problem hiding this comment.
This looks great. I didn't review the changes to the registry.
I didn't find the GetVelAcc function but I guess it was part of a previous pull request. I wanted to check that this function has some speedup if a simple flow field is used (shear), but I think you indeed took care of it. I also wanted to see if we could easily add a flag to request OpenMP parallelization on the fly (likely harder). For even more speedup in OLAF we would need to pass the flowfield to FVW. That can be done at another stage.
I have my nerdy preference of having the "if failed" at the end of the line so that similar lines can easily be read on top of each other and I'm not sure I'm set on cutting lines with & (when they are medium size). Don't change that for me of course.
Tried to clean it up a little with an associate block
The functions called by AD_CalcWind had inconsistent starting node numbering. The functions were fixe so the starting node has the same meaning. The functions were also renamed
Renamed this function to the more descriptive InflowWind_GetRotorSpatialAverage. Also fixed routine name in InflowWind_GetHubValues
AD_SetExternalWindPositions was previously called here, but had been commented out.
Ideally this will allow for parallel evaluation of the wind velocity/acceleration
The new registry parses files and keeps quoted strings intact. There were a couple of instances where "default" appeared inside a quoted string which was then interpreted as separate fields. This can be avoided by escaping the double quote as \" so the parser won't end the string. There was also an extra dash on line 320 in AeroDyn_Registry.txt which caused the description to be printed as a unit.
|
@bjonkman , I've updated the registry input files to escape the double quotes and remove the extra dash. The double quote can be escaped by writing |
|
Thanks, @deslaughter! I'm actually surprised the old registry parsed that without the escape character. There are probably other registry input files that have the same issue, but I just happened to see the AA and AD ones. |
…ifwptr Regenerated all Types files using registry.
This is a draft pull request for review of the implementation.
Feature or improvement description
The goal of this PR is to allow AeroDyn to call InflowWind directly via a pointer to
FlowFieldTypederived data type and theIfW_FlowField_GetVelAccfunction. This code adds logic to copy the FlowField pointer from the InflowWind Parameters derived type into the AeroDyn Parameters derived type during initialization. From thereAD_CalcOutputsandAD_UpdateStatescan callIfW_FlowField_GetVelAccto get and update the wind velocities and acceleration.Impacted areas of the software
Additional supporting information
The calls to get the wind velocity from InflowWind and transfer them to AeroDyn within
FAST_Solverhave been removed as they are no longer needed. To avoid disrupting Linearization, the wind velocity variables have been left as inputs in AeroDyn but will be moved to MiscVars as part of Linearization work in a future PR.Test results, if applicable
Test results are unchanged as expected.