robfalck
commented
2 years 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.
Kenneth-T-Moore
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
gridfor 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:
PseudospectralPhaseto coverRadauandGaussLobattotranscriptionsExplicitShootingPhaseto cover theExplicitShootingtranscription.AnalyticPhaseto cover the analytic "transcription".On the other hand, there's a use-case perspective.
ControllablePhase-Radau,GaussLobatto, andExplicitShootingtranscriptions.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 currentsimulatecapability, 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
Phaseclass 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.