Discussion: openfast 4.0 update?

[marchdf]

OpenFAST updated it's main branch to 4.0.

Two things to consider, one easy, one not:

• Easy issue: update amr-wind code to use the new openfast. I have a branch that does this.
• Hard issue: this will require users update their openfast input files. The changes are documented but not insignificant: https://openfast.readthedocs.io/en/main/source/user/api_change.html#api-change

The holy grail would be to support both 3.x and 4.x. But... we've had this discussion before and it is not easy.

Users: thoughts?

[rybchuk]

Talking to some of the devs, it seems like 4.0 will be a short term release, and 5.0 is right around the corner and that will be a long-term version. I can't pin a specific timeline to that, but it might be worthwhile saving the coding effort for 5.0

[lawrenceccheung]

I think we might need to be supporting OpenFAST v3.5 turbine models for a while too. Not all turbines have been upgraded to 4.0, and there isn't an automatic upgrade utility/path for turbine models. Which means updating models by hand could be an error-prone, frustrating process.

However, I also see that we might need OpenFAST 4.0 and AMR-Wind for some of the benchmarking work, so maybe we need both? This holy grail could turn into a necessary, everyday grail soon.

Lawrence

[marchdf]

Just for my education. What are the features in 4.0 that we "need" (in the vaguest sense) ?

[lawrenceccheung]

My understanding was that we needed the latest beamdyn in OF 4.0, and also to get a consistent, stable build for the blade resolved cases. @ndevelder, do I have that right?

[marchdf]

In the dev meeting, we talked of having a compile definition for the openfast version. The user would compile amr-wind against the openfast version they wanted and would need to specify that version as a cmake option. Would users be ok with this option?

[lawrenceccheung]

yes, that would work. In spack-manager we also might need to put in safeguards so that nobody tries to build exawind-manager with OF 3.5 or below.

[andrew-platt]

For clarification from the OpenFAST side:

• we intend to support 3.5.x for another year or two with bug fixes (no new features)
• there were some BeamDyn improvements made in 3.5.5, but not in 4.0.0 (BD is identical between these versions). There were some slight performance improvements with 3.5.5 (up to 30% speed increase), and a little improvement in stability (marginal compared to what is coming with 5.0)
• Version 5.0.0 will include tight coupling which will improve stability and speed with BeamDyn
• Once 5.0.0 is released, we will likely reduce support of 4.0.0
  • Module input files will not change much from 4.0 to 5.0, but the main input file will change significantly.

[marchdf]

Thanks for that @andrew-platt! Do you anticipate any changes to the fast library API between 4.0 and 5.0?

[andrew-platt]

I don't currently expect there will be any changes in that API from 4.0 to 5.0 -- most of the changes will be internal in the solver. If there are any changes, they would be relatively minor compared to what happened between 3.5.x and 4.0

[hgopalan]

For our project, we would prefer that we have an option to use OpenFAST 4.0 with AMR-Wind. We had deployed the version 3.5 in our December deployment and would like to use the newer version since OpenFAST 4.0 is also used with the other NREL tools used in the project.