Blade resolved loads from CFD #1932
Conversation
Existing branch at https://github.com/gantech/OpenFAST/tree/f/br_fsi_2 This commit extends the C++ API
This library is needed by openfastcpplib
NOTE: OpenFAST.H and OpenFAST.cpp are not resolved!!!
Changes to help compile
This needed to be added because the C++ interface sets DTdriver, but simulink doesn't
Fix issues to get C++ API to run
andrew-platt
force-pushed
the
f/ExtLoads_rebase
branch
from
d0a035a to
095b3db
Compare
|
Simulation from NALU-Wind coupled to OpenFAST through the |
|
|
||
| ELSE IF (p_FAST%CompAero == Module_ExtLd ) THEN | ||
|
|
||
| DO K = 1,SIZE(u_ED%BladePtLoads,1) ! Loop through all blades (p_ED%NumBl) |
There was a problem hiding this comment.
This code to blend AD and ExtLd data is repeated in both BeamDyn and ElastoDyn routines, and actually called twice in ED because ExtLd_ConvertOpDataForOpenFAST is called for both tower and blade loads. Since the code is just adding AeroDyn output data to the ExtLd output mesh, it seems like that should have been done in a different routine so that these routines to set BeamDyn and ElastoDyn inputs don't actually change the ExtLd outputs. That would mean you don't need the extra p, u, and m variables from ExtLd, making it match the way the other modules are handled here. Otherwise, that blending should be stored someplace other than the ExtLd output type.
There was a problem hiding this comment.
@gantech, FYI.
| n_t_global_next = n_t_global+1 | ||
| t_global_next = t_initial + n_t_global_next*p_FAST%DT ! = m_FAST%t_global + p_FAST%dt | ||
|
|
||
| y_FAST%WriteThisStep = NeedWriteOutput(n_t_global_next, t_global_next, p_FAST) |
There was a problem hiding this comment.
I'm wondering why this line wasn't included in FAST_Prework.
y_FAST%WriteThisStep is used in FAST_UpdateStates. While it doesn't matter in this glue code, I assume the reason this routine was split into FAST_Prework, FAST_UpdateStates, etc, is that the individual routines would be called by a glue code instead of calling FAST_Solution, in which case, y_FAST%WriteThisStep would probably not be set properly.
Is there another reason for keeping it here?
There was a problem hiding this comment.
Good question. Since the AMR-Wind has the ability to reset OpenFAST back multiple timesteps, it may be that they didn't want to have the write outputs updated during intermediate steps that may be redone. @gantech, do you happen to remember?
There was a problem hiding this comment.
If they aren't directly setting y_FAST%WriteThisStep, then it is probably just using the initial value of true. If you don't need file output at every integration step, you will get performance improvements by setting this value.
There was a problem hiding this comment.
Good point. I suspect they aren't setting that at all. I'll move it into the FAST_PreWork routine.
There was a problem hiding this comment.
Corrected with #2076 (on the dev-unstable-pointers branch which will be merged to dev soonish).
This PR is ready to merge.
Feature or improvement description
A new module named
ExtLoadsinterfaces with CFD to transfer loads from a CFD solver into OpenFAST. This module is an alternative to AeroDyn.To stabilize the CFD solution, AeroDyn loads are used during initialization and then blended into the CFD solution after the transients die out. The time AD15 loads are used is user configurable (set in radians of rotation -- typically a few revolutions). This requires that AeroDyn is used in addition to the ExtLoads module.
During the simulation, the CFD code will call OpenFAST multiple times for each CFD timestep. This may require rewinding the OpenFAST simulation to the prior CFD timestep and recalculating all the intervening times using updated CFD information. To accomplish this, the size of the state variables (and other things) was increased from 2 to 4 so that a saved copy of the previous and current state information (3,4) at the CFD time step can be used. When rewinding OpenFAST back to the previous CFD time, this data will be copied over to the previous and current state information (1,2).
Other additional features include:
Related issue, if one exists
Impacted areas of the software
ExtLoadsmoduleFAST_ExtInfw_Solution0renamedFAST_CFD_Solution0FAST_ExtInfw_SteprenamedFAST_CFD_Stepand split into multiple routinesFAST_ExtInfw_Restartnew variablenumElementsTower_cFAST_ExtLoads_RestartFAST_CFD_Store_SSFAST_CFD_Reset_SSFAST_CFD_PreworkFAST_CFD_UpdateStatesFAST_CFD_AdvanceToNextTimeStepFAST_CFD_WriteOutputFAST_SolutionFAST_PreworkFAST_UpdateStatesFAST_AdvanceToNextTimeStepFAST_WriteOutputFAST_Store_SSFAST_Reset_SSFAST_InitIOarrays_SSAdditional supporting information
Test results
To do