Recommended module time step

Dear OpenFAST team,

I’m running different simulations in OpenFAST in order to understand how the global time step (DT) influences in terms of stability.

My simulation runs stably with DT=0.005 s. Since my goal was to achieve a smoother controller response, I increased it:

  • With DT=0.006 s, the simulation still runs fine. From that value upwards, the simulation stops: it doesn’t crash with an explicit error but simply stops progressing.

When this happened to me, I searched the forum for a similar problem, which led me to this thread: PTDM implementation - #15 by Emanuel.Rergis . After reading it, I understood two things;

  1. The standard rule for an optimal DT is DT<1/(10*f_max)
  2. Increasing NumCrctn to 1 or more may allow the use of larger time steps. However, even when I set NumCrctn=1 (keeping DT>0.006), the simulation still stops (the 0.005 and 0.006 DT simulations were run dith NumCrctn=0 successfully).

In parallel, I noticed that the log prints this warning when the DT is higher than 0.006:

BEMT_UpdateStates: UA_UpdateStates: Divergent states in UA HGM model

So, I would like to ask:

  1. When you refer to f_max, do you mean the highest frequency of the entire system, regardless of the component?

  2. Could you please clarify how DT and NumCrctn interact numerically? Are there recommended or practical ranges for NumCrctn when increasing DT?

  3. Could this warning message be linked to an inadequate DT - NumCrctn combination?

Any recommendation would be appreciated.

Kind regards,

Kepa

Dear @Kepa.Cueto,

I agree with your summary of the structural time step rule-of-thumb. Here are my responses to your questions:

  1. Yes; f_max should be the highest frequency you’d see when performing a linearization analysis, followed by eigenanalysis, for a structural only model.
  2. If the time step requirement is dictated by module-to-module coupling (such as coupling between BeamDyn and ElastoDyn or between ElastoDyn and SubDyn), then increasing NumCrctn often allows for larger DT. However, if the time step requirement is more intrinsic to a specific module, increasing NumCrctn may not help.
  3. This warning implies that DTAero in AeroDyn is too large causing a numerical instability in the unsteady airfoil aerodynamics model. This issue has been reported in the OpenFAST GitHub repository: BeamDyn + UA_Mod=4 in dev-tc requires DT <= 0.001s · Issue #2813 · OpenFAST/openfast · GitHub. Increasing NumCrctn will not solve this specific issue. This issue applies to the continuous-time state aerodynamic modules (UA_Mod = 4, 5, or 6), which currently require smaller than desired time steps.

FYI: In the upcoming release of OpenFAST v5, a new tight coupling algorithm has been introduced that allows for larger structural time steps that avoid the DT = 1/( 10 * f_max ) rule-of-thumb.

Best regards,

2 Likes