Closed robfalck closed 1 year ago
My thoughts on the names:
I prefer PseudospectralPhase
and ExplicitShootingPhase
over ControllablePhase
. There's nothing requiring the use of controls for those techniques, so some users may find the name confusing. In addition, there are a few minor differences in the two methods. Namely, ExplicitShooting
does not allow the option fix_final
, and solve_segments
is meaningless in that context.
Just to say that I like the technique perspective names over the use-case ones.
Issue Type
Description
As part of the upcoming development of allowing for analytic solutions to ODEs in dymos, the developers feel it would make sense to break phases into different classes.
For instance, when using an analytic solution to an ODE rather than numerically integrating, the state values in the phase are outputs of the system, not design variables as they are in pseudospectral or shooting methods. Notions of a
grid
for analytically solved ODEs also aren't really necessary.Controls are, to my knowledge, incompatible with the notion of an analytic solution. If anyone has a concrete example of an ODE with a dynamic input and an analytic solution, I'd love to see it. In lieu of that, it makes sense that we incorporate some new phase class that disallows the user from adding controls.
We're sold on the notion of AnalyticPhase, what about Phase?
Now that we have the notion of an
AnalyticPhase
, does it make sense to wrap everything else in the generic termPhase
?In this case, we've considered breaking existing transcriptions into different phase classes. There is still some debate as to which classes those should be.
On the one hand, we have a technique perspective:
PseudospectralPhase
to coverRadau
andGaussLobatto
transcriptionsExplicitShootingPhase
to cover theExplicitShooting
transcription.AnalyticPhase
to cover the analytic "transcription".On the other hand, there's a use-case perspective.
ControllablePhase
-Radau
,GaussLobatto
, andExplicitShooting
transcriptions.AnalyticPhase
- Analytic solutions, controls not applicable.Might there be other Phase types in the future?
Yes, absolutely! Two we're considering right now:
IntegrationPhase
- would be used to propagate an uncontrolled solution forward in time. Similar to our currentsimulate
capability, but with derivatives.TransitionPhase
- would take different states in representing the "start" and "end" condition and would pose defect constraints until those initial and final conditions are compatible. For instance, when transitioning from a state vector about the Earth to a state vector about the sun, you'd pose that as a transition phase. Simple linkage constraints combined with those transition defect constraints would provide physical continuity across the trajectory.Final thoughts
Whatever we decide to do here, we will deprecate the current
Phase
class with plenty of lead time so we don't break anyone's current use-case. We'd appreciate feedback to see what the community thinks of these potential name changes, or if anyone else has suggestions that they think are better.