Phase info corrections

[cmbenne3]

Summary

This PR removes the example_phase_info since it is duplicated by the default_height_energy phase info, and adds a small correction to the cruise phase throttle constraint to enforce a path constraint rather than a boundary constraint which makes no sense for the throttle parameter.

Related Issues

• Resolves Throttle enforcement for default Height-Energy 'cruise' phase #751

Backwards incompatibilities

None

New Dependencies

None

[Kenneth-T-Moore]

Just a note that 'boundary_constraint' isn't necessarily wrong. The thought process was that the most demanding point for the engine would be the top of climb, since the weight and drag should decrease over cruise, so constraining the upper bound on throttle at the first point in cruise is equivalent to constraining all points because the later points will never hit the boundary.

[cmbenne3]

I think you're absolutely right Ken and I'm sure this will be the case most of the time. I was thinking about the optimizer 'flying' the aircraft and didn't want it to be able to do something that's not physically possible (in this case push the throttle past 100 % or below 0 %). I don't believe the boundary constraints do this, and it would be possible (although not optimal) for the optimizer to choose an invalid throttle setting in the middle of the cruise phase.
In my opinion switching to a path constraint, which matches the climb and descent phases makes more sense to me. If we would like to keep the boundary constraints in there as an example of an option the user has, then I'm happy to do that, but perhaps we could add a comment explaining why using boundary constraints is 'safe' in this case.

[ehariton]

default_height_energy phase info is kept in a totally different location than the example_phase_info, which was kept in the examples folder. I think there is value in keeping the example phase info where it is and removing the default_height_energy instead.

[cmbenne3]

default_height_energy phase info is kept in a totally different location than the example_phase_info, which was kept in the examples folder. I think there is value in keeping the example phase info where it is and removing the default_height_energy instead.

From a repo organization point of view I would prefer that all default phase infos be kept in the same place (that makes more sense to me than having the height_energy_default in aviary/examples/ and the two_dof_default in aviary/models/missions/), however I do understand wanting to have everything we need to run examples in the examples folder. I guess none of our examples are gasp based...?
Other location for default_phase_infos could be aviary/mission/flops_based (or gasp_based). Perhaps that naming should be changed to height_energy/2dof rather than flops/gasp. Are those equivalent or is it possible to run flops 2dof and gasp height energy?