[BUG] Fix aeroelasticity units

[JonahJ27]

Description

Fixes the unit changes suggested in the branch bug/aeroelastic logic. Could use some feedback based on the feedback in the other branch

Motivation

See aeroelastic logic thread in #190 for background.

Relevant Issues

None.

Changes

• Correct angular units in aeroelastic logic.

Dependency Updates

None

Change Magnitude

Minor: Small change such as a bug fix, small enhancement, or documentation update.

Checklist (check each item when completed or not applicable)

• I am familiar with the current contribution guidelines.
• PR description links all relevant issues and follows this template.
• My branch is based on main and is up to date with the upstream main branch.
• All calculations use S.I. units.
• Code is formatted with black (line length = 88).
• Code is well documented with block comments where appropriate.
• Any external code, algorithms, or equations used have been cited in comments or docstrings.
• All new modules, classes, functions, and methods have docstrings in reStructuredText format, and are formatted using docformatter (--in-place --black). See the style guide for type hints and docstrings for more details.
• All new classes, functions, and methods in the pterasoftware package use type hints. See the style guide for type hints and docstrings for more details.
• If any major functionality was added or significantly changed, I have added or updated tests in the tests package.
• Code locally passes all tests in the tests package.
• This PR passes the ReadTheDocs build check (this runs automatically with the other workflows).
• This PR passes the ascii-only, black, codespell, docformatter, isort, and pre-commit-hooks GitHub actions.
• This PR passes the mypy GitHub action.
• This PR passes all the tests GitHub actions.

[camUrban]

Hey @JonahJ27! Thanks for the unit conversion fixes. I read through them and they look correct to me! Regarding the inertial vs. aerodynamic scaling, I suspect that what we are seeing now is actually correct (within the limitations of the model of course), and that the problem is that the default spring constant and wing areal density (or their relative magnitudes) may not be physically realistic. I agree that papering over the problem by messing with the scaling parameters isn't a good idea. In fact, we may want to remove those from the API if there is no physically-motivated reason to touch them. We could leave them as private module-level global constants (set to 1.0 by default) for debugging.

Our best bet is to validate by reproducing analytical results. I did some digging and found Moore (2014), "Analytical results on the role of flexibility in flapping propulsion," which analytically solves a problem we can replicate in simulation. The system is a rigid flat plate (negligible thickness, high AR) immersed in a freestream (high Re, low Mach). The plate is mounted at its leading edge to a torsional spring. It is also mounted to a system that prescribes a sinusoidal heaving. Any pitching motion is entirely passive, and affected by the spring. The heaving amplitude/St number are chosen to prevent flow separation.

The one caveat is that the paper seems to neglect any structural damping, so we'd need to zero that parameter when setting up the simulation, or re-solve the ODE from the paper with an additional $c\dot{\theta}$ term.