Aeroelasticse

[ptrbortolotti]

Fix a bug in the fast reader and make all paths to openfast files relative

Purpose

Run aeroelasticse as standalone

Type of change

What types of change is it?
Select the appropriate type(s) that describe this PR

• 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

Explain the steps needed to test the new code to verify that it does indeed address the issue and produce the expected behavior.

Checklist

Put an x in the boxes that apply.

• 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

[johnjasa]

I'm not sure if the test failure is meaningful; I just queued up the jobs to run again. Let's see the results if we need to change anything.

[ptrbortolotti]

I'm a little puzzled. I'm creating a new weis env locally to try to reproduce the error and I've rerun GHA on develop. Stay tuned

[ptrbortolotti]

this will likely fix things, but I'm wondering whether anywhere in WEIS the absolute path to the Cp-Ct-Cq tables is needed, and maybe read directly from the DISCON? @dzalkind any tip?

[dzalkind]

I tend to use absolute paths in ROSCO because we don't handle relative ones that well. It's probably something we can address with some string processing or by borrowing subroutines from OpenFAST, but it's just never been at the top of our priority list.

If it's important for your work, we can get it figured out soon.