Phase info revamp: part 1: Height Energy

[Kenneth-T-Moore]

Summary

This is a major overhaul of the phase_info dictionaries with the following goals:
1. Provide a set of keys that is more consistent across the different phase types.
2. Remove redundancies, particularly cases where we can replace 2 keys with 1.
3. Rename keys to be more understandable to the user.
4. Add missing options such as certain missing scaling parameters.

Before Merging:
1. Evaluate the new phase_info keys and make changes.
2. Finish modifying the documentation, and create a transition document.
3. Add a few tests that use some of the new keys.

Summary of Changes:
1. Created AviaryOptionsDictionary methods to add all options associated with a state, control, or time. Most phase builders now use these, but some of the GASP extra states/controls don't use them yet .
- This provides a uniform interface for states or controls.
- Missing keys were added, such as bounds and ref/ref0 for states. Formerly, these were hardcoded values.
2. Created PhaseBuilderBase methods to add a state or control to a phase. FlightPhaseBuilder now uses these.
3. Many options renamed to make them more uniform and consistent. This includes some options in 2DOF, because a global search and place was convenient. (e.g, "initial_mach" -> "mach_initial")
4. Some methods were renamed to make them clearer.
5. Some logic was simplified in the configurators and in methods for level 2.
6. The phase_info graphical tool was modified to output the phase_info in a pretty format.
7. Some checks for an old version of dymos were removed, since we are reliant on a more recent version.

Follow-on work:
1. Apply changes to 2DOF
2. Modify MBSAE to use new phase-info
3. Get detailed takeoff working better.

Related Issues

• Resolves #

Backwards incompatibilities

All user phase-info files will need to be modified.

New Dependencies

None

[ehariton]

considering we have distance_solve_segments wouldn't it make sense to update target_distance to distance_target ?

[Kenneth-T-Moore]

This is actually an oddball one because the state is called distance, but target_distance is really more like target_delta_distance. If we wanted to generalize this to other states like mass, mass_target wouldn't imply end_mass - start_mass. I think we could come up with better name though.

[ehariton]

I thought distance was always relative to the start of the phase your in vs. range which is relative to the absolute start of the mission.

[ehariton]

most serious issues I found were the checks and definitions for the new test_aviary_options_dict.py