Phase linking overhaul.

[Kenneth-T-Moore]

Summary

Prior to this refactor, all of the phase linkages were added by custom code written independently for each problem origin (gasp, flops, solved twodof) and encapsulated in the configurators. This PR implements a general phase-linking that replaces all of these, and paves the way for a future capability of selecting the ODE individually in each phase.

1. General phase linking capability implemented in aviary_group.
2. The get_linked_variables method has been added to the phase builder base class. This method allows phases to define which variables should be linked.
3. For analytic phases that need an initial parameter connected upstream, the phase linking supports this. For a variable like "mass"

• The input should be called "initial_mass"
• The get_linked_variables should contain "initial_mass" instead of "mass".

4. The phase_info has been updated to provide a new key for time/states/controls that gives the user control over whether the link is via a direct connection or a constraint. For a variable like mass, this key is called mass_direct_link.

• Default values for these are specified in the default keys for each phase. Some linkages were handled differently between the problem types, and that custom code has been replaced by these default values.

5. The former link_phases method on the problem configurators has been renamed to link_trajectory. This method now just performs any problem-specific linkage with components external to the trajectory.
6. When linkage constraints are created, the ref and ref0 now come from the ref/ref0 defined in the upstream or downstream phase. Formerly, they came from initial conditions or hardcoded values.
7. The new phase linking no longer creates a constraint between two ends that are already constrained by initial_ and final_.

Related Issues

• Resolves #

Backwards incompatibilities

There is a possibility that your model may run a bit differently due to some scaling changes and some small differences in the resulting linkages (particularly downstream of a Breguet range phase). The new phase keys should restore some of this.

New Dependencies

None

[jkirk5]

Should we just iterate over all subsystems (I believe that should be self.subsystems), just in case in the future we have a core subsystem use linked variables? Just a future-proofing idea while we're here

[Kenneth-T-Moore]

I don't think there's any reason not to do that.

[jkirk5]

The subsystem designer will often have no knowledge of whether their subsystem will be used with an analytic phase or not, so I'm not sure how this can be used in practice

[Kenneth-T-Moore]

This part of the docstring should only be in the phase builder. It doesn't apply to external subsystems. I will remove it.

[jkirk5]

The name change confuses me - link_trajectory makes me think there are trajectories being linked together? While link_phases made more sense to me, as it is the individual phases that are being linked together

[Kenneth-T-Moore]

The configurator method doesn't actually create links between phases anymore. It just adds components and manually connects to things that are upstream or downstream of the trajectory -- stuff that isn't so generalizable. We could go with something like configure_trajectory.