Unify subsystem addition and solver control across all of our ODEs.

[Kenneth-T-Moore]

Summary

This PR unifies subsystem addition and solver control across all of Aviary's ODEs. Previously, only the Energy method allowed the subsystem to specify that it needed to be in a solver loop.

1. Renamed the ODE base class method add_subsystems to add_subsystems_and_solver. This method is now also responsible for adding all subsystems to either the top ODE or a solver sub group.
2. Each ODE is aware of the kind of coupling is implemented, so add_subsystems_and_solver now has arguments to control whether the propulsion (throttle) or aerodynamics (angle of attack) are coupled to the EOM.
3. In the subsystem base class, needs_mission_solver now returns False. This should be set to True by the user if any additional subsystem coupling is introduced.
4. The solved-2DOF ODE has two separate solver subsystems, so add_subsystems_and_solver supports passing in two premade subsystems, and it assigns them to the appropriate solver group.
5. The setting of predetermined aero subsystem_options in the 2dof phases has been removed. Those options have been moved into the phase_info files instead.
6. Tightened up some solver tolerances, which seems to help some cases that had trouble hitting optimality.
7. Similarly, fixed a few spots where we were performing complex steps with a large stepsize (1e-8 vs 1e-40). This should also help with optimality.
8. Removed the flight_path_ode, which seemed to be an early unfinished experiment in unifying the 2dof ODEs.

Note: the solver setup is still not perfect. OpenMDAO 4 promises a complete decoupling of solver specification from the group, and this will streamline most of the difficulties.

Related Issues

• Resolves 2DOF ODE's do not use solver group flag #1198

Backwards incompatibilities

None

AI Usage

Disclose any AI usage in this PR, including models used and files affected.

[jkirk5]

This update is a good demonstration of how OM4 could be valuable for Aviary and a point in favor of updating

[jkirk5]

This argument seems hyper-specialized for a specific ODE, which I think disqualifies it as useful to include in BaseODE. Is a better approach to have these ODEs have their own definitions for the method? I don't want to keep having to add to BaseODE as we add additional equations of motion that also have special rules for how they want things set up.

[Kenneth-T-Moore]

The solved 2dof is the only ODE that creates two different solver groups.

[jkirk5]

Is returning the group useful? I feel like it will cause confusion, because an easy mistaken interpretation of this function is that it returns the correctly configured group of subsystems and solvers they then need to add to the ODE.

If users need the group object for some reason it already got added to the ODE so they should probably use OM interface to access that info in their ODE.

[jkirk5]

My suggestion is simply no return statement at all here

[Kenneth-T-Moore]

After we return it, some of the ODEs will add the ode or a balance comp to the solver group. I could modify it back so that each ODE is responsible for creating the Group and passing it into the add_subsystems, which is what it was doing originally. It is just some duplicated code.

[jkirk5]

Oh ok that makes sense! I guess it is better how you have it here

[jkirk5]

I wonder what causes the circular import?? If it is due to imports required for type hints in some other file, I found a way around that (see subsystem_builder.py imports)

[Kenneth-T-Moore]

Looks like I'm not seeing any interaction now, so I think I can safely move these back to the top.