Feature request - Eliminate the Requirement that Some OpenFAST Models Have Correction Steps

[jjonkman]

Is your feature request related to a problem? Please describe.
The OpenFAST glue code makes use of an implicit loose coupling scheme based on a predictor-corrector solution algorithm, with the number of correction steps defined by the user (NumCrctn). When NumCrctn = 0, the coupling is explicit (with no correction step). There is typically a tradeoff between using a smaller time step (DT) and adding a correction step (NumCrctn > 0), and in most cases, we find it easier to set NumCrctn = 0 and use a small enough DT to ensure numerical stability. However, there are a few situations where setting NumCrctn >0 is required to ensure numerical stability; i.e., reducing DT does not resolve an instability (no matter how small DT is set), but setting NumCrctn >0 resolves the instability (setting NumCrctn = 1 is typically sufficient). The two known situations where this problem exists are:

• When modeling floating substructure flexibility (hydro-elastic effects) with SubDyn and HydroDyn enabled, e.g., as discussed here: FeaCoupling of an External floater (platform+mooring) with Openfast #791 #801.
• When modeling some tuned-mass dampers (TMDs) through the structural control (StC) submodel of ServoDyn, e.g., as discussed here: https://wind.nrel.gov/forum/wind/viewtopic.php?f=30&t=2230&start=15.

This behavior is unexpected, and suggests that some reordering of the module calls in the calculate output step of the OpenFAST glue code could be rearranged to eliminate the need for the correction step.

Describe the solution you'd like
We'd like for all OpenFAST models to achieve numerically stability by reducing DT alone, without requiring NumCrctn >0.

Describe alternatives you've considered
The current workaround in these situations is to set NumCrctn >0.

[andrew-platt]

See also #983.

[dzalkind]

Hey Andy and Jason,

I'm working with a floating model with structural controllers requiring 3 correction steps. With fewer, it fails after the same number of timesteps, regardless of the time step length. In this model, the structural controllers' mass is slightly more than the mass of the platform in ElastoDyn. SubDyn is not used.

I figured I would note it here. I probably shouldn't share the model publicly, but I can make it available internally for testing if needed.

Best, Dan