-
Notifications
You must be signed in to change notification settings - Fork 91
Description
When running an OpenFAST connected FSI case, all BeamDyn nodes (other than anything at exactly 0.0 span) must be within the blade mesh, or Nalu-Wind crashes, giving a somewhat useless message about negative volumes. This happens when using the NREL 5MW (split blade and tower) mesh and the official repo version of the NREL 5MW openfast model.
I created a split blade mesh wherein the blade roots were closer together, and this did fix the problem with OpenFAST integration, but caused too much speed-up near the root and the simulation diverged.
Removing the first "key point" in the BeamDyn model "fixed" the issue in that we didn't see a difference in OpenFAST-alone comparisons, and the second BeamDyn node was well within the blade mesh.
I see a few pathways forward on this one:
- We do nothing with the current implementation and remember we need to check this for all cases/modify BeamDyn if necessary
- Same as above, but looking forward, we write some combination of checks into the OpenTurbine/Nalu-Wind integration
- We code a check on the Nalu-Wind side that stops initializing the simulation if a BeamDyn node is outside the mesh
- We code something that ignores BeamDyn nodes that are outside the mesh? This one might have weird implications...
- Write an external script to check the mesh/BeamDyn setup prior to running
I think a secondary issue here is that we don't usually have structural model experts running these codes, so even if we have a check, we don't often know the full ramifications of removing or moving BeamDyn key points.