Add offshore linearization capability #350
Conversation
- tau_V was reset at n+1 before setting other states that required values at n. - also removed some comments
this commit should affect spacing and comments only
factor = (alpha_filt_cur - alpha0) * Kalpha_f
if (xd%tau_V(i,j) > T_VL .AND. (factor > 0)) then
! The assertion is the T_V will always equal T_V0/2 when this condition is satisfied
becomes [note sign change and comment regarding value of sigma3, BUT: Code still needs a fix which is incomplete regarding the 2nd comment. If you fall into that if block, then we must continue to eliminate the vortex feed until we begin tracking another vortex, i.e., tau_V is reset to 0.0, this may mean the addition of a new flag.]
if (xd%tau_V(i,j) > T_VL .AND. (Kalpha_f*dalpha0 < 0)) then ! .AND. (.not. LESF)
! We no longer require that T_V will always equal T_V0/2 when this condition is satisfied as was the case in AD v13 GJH 7/20/2017
! If we fall into this condition, we need to require we stay here until the current vortex is shed (i.e., tauV is reset to zero)
Cn_v = xd%Cn_v_minus1(i,j)*exp(-ds/T_V) ! Eqn 1.52
else
Cn_v = Get_ExpEqn( ds, T_V, xd%Cn_v_minus1(i,j), C_V, xd%C_V_minus1(i,j) ) ! Eqn 1.47
Email dated July 28, 2017: From Greg Hayman/Rick Damiani to Envision Energy:
We changed the definition of VRTX:
was:
VRTX = (xd%tau_V(i,j) <= 2.0_ReKi*T_VL) .and. (xd%tau_V(i,j) > 0.0_ReKi)
now:
! Is the vortex over the chord?
VRTX = (xd%tau_V(i,j) > 0.0_ReKi) .and. (xd%tau_V(i,j) <= T_VL)
Because of this change in the definition of VRTX all if tests related to VRTX have been changed:
if ( VRTX .and. (xd%tau_V(i,j) <= T_VL) ) then ! Still shedding a vortex?
becomes
if ( VRTX ) then ! Still shedding a vortex, i.e., the current vortex is still over the chord?
and
if ( VRTX .and. (xd%tau_V(i,j) <= T_VL) ) then
becomes [ NOTE This is part of a logic change in the sigma3 section, see below]
else if ( VRTX ) then
The glue-code implementation is incomplete, and MAP still needs to be linearized
1. fprimeprime_m wasn't initialized in UAMod 2, but was still used to compue cm_FS. I initialized to 0 until Alvaro can comment as to what it should be. 2. Df_c was changed to use T_fc instead of T_f, but T_fc was static when UAMod/=2 (it is based on a new state variable for UAMod==2). I modified the OtherState%sigma1c variable to be equal to the old %sigma1 to get the same results here.
- added ds to KC parameters so that we don't recalculate it in the update states routine. -
His fix changes the calculation of DF_c.
Added MAP and more glue-code implementation
Added MAP_JacobianPInput, and bug fixes
Added DerivOrder information for output files. Various bug fixes. Finished glue code implementation.
Needed to avoid problems due to MAP load mesh not having moments
This code came from GHayman in Feb 2018; I fixed some merge conflicts and some minor details. It compiles (with the exception of UA driver) and gives same results as before. I did not add the AFI driver or move the AFI code into a separate source-code directory,
Any airfoils that use "default" interpolation will see different results.
BEMTU_Wind was calculating Re based on dynamic viscosity instead of kinematic viscosity as reported here: OpenFAST#71 Fixed the calculation and cleaned up calling routines that don't need the airDens variable anymore.
The SSS_Excitation states were being misrepresented in the LinNames_x array due to an error when computing the number of states for a given DOF. The HydroDyn continuous state names were not being set in the glue code.
The floating linearization feature includes Fortran-specific MAP++ datatypes which need to be including in the cmake build system.
added references to SS_Excitation module
- Remove override of default C++ include paths. Source-file directories are included by default, so they don't need to be explicitly specified - Remove link to (non-existent) WinSock2.h file in the vs-build directory; this should be found in the Windows SDK instead
Merge previous PRs into this one
|
@rafmudaf and @ghaymanNREL: I've already updated the HydroDyn input files in the regression tests with the additional line required for this pull request. You can cherrypick those files from this commit bjonkman/r-test@411e037 |
|
These merge conflicts are resolved in HaymanConsulting#13 |
Merged NREL dev into the branch and addressed merge conflicts
| call SetErrStat( ErrID_Fatal,'RdtnDT must be equal to the glue-code DT if PotMod = 1 and using RdtnMod > 0 or ExctnMod > 1.',ErrStat,ErrMsg,RoutineName) | ||
| return | ||
| end if | ||
|
|
There was a problem hiding this comment.
@ghaymanNREL, @jjonkman : This new check prevents the ITIBarge regression test from running. Is this the correct logic? Or were the old input files set up improperly?
RdtnDT must be equal to the glue-code DT if PotMod = 1 and using RdtnMod > 0 or ExctnMod > 1
There was a problem hiding this comment.
Has this been resolved?
There was a problem hiding this comment.
@ghaymanNREL sent me some email chains about this issue in February. After reading them, I inferred that the previous implementation of the RdtnDT time step was incorrect if it wasn't the same as the glue code, so they added this check. I changed the input file that was causing issues in the regression tests for PR #373 (see bjonkman/r-test@c2fe16a). Greg probably modified it in his r-test branch, too.
Actually, it looks like @jjonkman wanted the comment for RdtnDT to be updated to read
Time step for wave radiation kernel calculations (sec) [only used when PotMod=1 and RdtnMod=1; DT<=RdtnDT<=0.1 recommended; determines RdtnOmegaMax=Pi/RdtnDT in the cosine transform]
Guess we should update that in the HD input files, too.
There was a problem hiding this comment.
I think @rafmudaf created a new r-test branch for this PR from a commit on the r-test/bjonkman-linear branch.
There was a problem hiding this comment.
I noticed that @ghaymanNREL already had a branch with these changes, too (last October/November), so I made a pull request for @rafmudaf to merge that into his new branch.
|
Dear all, I am trying to use the latest commit of this branch to try the linearization tool for floating case, and I am executing the test 5MW_OC4Semi_Linear.
How could I solve the problem? Thank you in advance, Jon |
|
Hi, I ran the simulation again and left for a long time, and thakfully it finished. Nevertheless it took 24 minutes to perform the linearization.
Is it usual to need so much time? Besides, there are small differences in the .lin file comparing to the windows-intel results. Here I should point that I have performed the simulation with cygwin64+CMake compilation, so that could be the cause.
I would appreciate feedback! Best regards, Jon |
|
Well, I would normally suggest compiling OpenFAST in single precision; double precision is generally not necessary for accuracy (the variables that need double precision are defined in double even for single precision compiling) and compiling in single will run a lot faster. Also, the speed will depend on which compiler you are using and the optimization settings defined. |
|
Forgot to answer @jjonkman, I compiled for single precision as you said and the linearization works faster (even if still a bit slow). Thank you! |
| if (p%CompSub /= MODULE_None) call SetErrStat(ErrID_Fatal,'Linearization is not implemented for any of the substructure modules.',ErrStat, ErrMsg, RoutineName) | ||
| if (p%CompMooring /= MODULE_None) call SetErrStat(ErrID_Fatal,'Linearization is not implemented for any of the mooring modules.',ErrStat, ErrMsg, RoutineName) | ||
| !if (p%CompMooring /= MODULE_None) call SetErrStat(ErrID_Fatal,'Linearization is not implemented for any of the mooring modules.',ErrStat, ErrMsg, RoutineName) |
There was a problem hiding this comment.
@bjonkman shouldn't this be
if (p%CompMooring == MODULE_MD) call SetErrStat(ErrID_Fatal,'Linearization is not implemented MoorDyn.',ErrStat, ErrMsg, RoutineName)
if (p%CompMooring == MODULE_FEAM) call SetErrStat(ErrID_Fatal,'Linearization is not implemented FEAMooring.',ErrStat, ErrMsg, RoutineName)
There was a problem hiding this comment.
Yes, I agree that should be changed in case someone tries to linearize with a mooring module other than MAP.
There was a problem hiding this comment.
Actually, it looks like I fixed this problem in #373.
There was a problem hiding this comment.
We can leave it as is in this PR.
|
5MW_ITIBarge_DLL_WTurb_WavesIrr and all similar cases should have this input changed to 0.0125 to match the glue-code time step. Does this have any unintended impact? Here's the error with the input unchanged: |
|
@rafmudaf see this comment on the code: https://github.com/OpenFAST/openfast/pull/350/files#r374860824 |
# Conflicts: # modules/openfast-library/src/FAST_Subs.f90
# Conflicts: # modules/openfast-library/src/FAST_Lin.f90 # modules/openfast-library/src/FAST_Subs.f90
Adds the new ExtnMod parameter to the inputs. Baselines not changed.
Complete this sentence
THIS PULL REQUEST IS READY TO MERGE
Feature or improvement description
This pull request adds new linearization functionality to OpenFAST for floating offshore wind turbines. Specifically, linearization capability has been added for HydroDyn (and associated sub-modules) and MAP++. A new state-space wave excitation module has been developed. Additionally the glue-code has been modified to support these additional linearization features. The HydroDyn input file now includes options (ExctnMod) related to the new state-space wave excitation module.
Related issue, if one exists
None
Impacted areas of the software
OpenFAST glue-code
ElastoDyn
HydroDyn
WAMIT
SS_Excitation
SS_Radiation
MAP++
Additional supporting information
https://www.nrel.gov/docs/fy19osti/71865.pdf
https://www.sintef.no/globalassets/project/eera-deepwind-2019/presentations/h_jonkman_nrel.pdf
Automated test results