fixing mode shapes again

[gbarter]

Purpose

Continuing to wrestle with ElastoDyn. Hopefully these are both more accurate and more robust.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (non-backwards-compatible fix or feature)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Documentation update
• Maintenance update
• Other (please describe)

Testing

• I have run existing tests which pass locally with my changes
• I have added new tests or examples that prove my fix is effective or that my feature works
• I have added necessary documentation

[ptrbortolotti]

The comparison looks quite good, with differences impacting second mode frequencies and damping (as expected)

What I maybe find a little more surprising is the actual shape of the second modes

[ptrbortolotti]

This comparison includes SubDyn

[jennirinker]

Out of curiosity, are you comparing with BeamDyn? Or should we be cross-comparing with HAWC2? I'm sure there's been a lot of internal discussion, but since I only have access to the comments on the PR it looks a bit hand-wavy. Just worried we're making changes without knowing what the target should be, you know?

[gbarter]

Just realizing now that @jennirinker commented on this and I didn't respond, given all of the bot activity from last week. @ptrbortolotti noted that this is still pending and a source of error for OpenFAST simulations in the main branch, so we need to push the update through.

@jennirinker - If there is a way to cross compare to HAWC2 that you can easily generate, that would be helpful. Otherwise, I think this is us trying to get an OpenFAST model that correctly captures the elastic model implied from the yaml-input geometry. It is hand-wavy in that it is very easy to make mistakes in the workflow.