The GASPy-based code currently uses a somewhat ad hoc mechanism for statically declaring the variables that need to be passed either from the user or from static analysis into the "phases" (referring to actual dymos phases and the analytic flight segments). It then functions as an input-only component in each ODE for other components to connect to via promotion and provides methods to resolve conflicting defaults and add them as parameters to the dymos trajectories.
Talked this through a bit with @crecine and @ehariton; we like the idea of naming the VariablesIn components when they're in the model to something like _dummy_component_for_inputs or something equally obvious what's going on.
Additionally, these components should move as far down in the model as possible to not create unnecessary backwards coupling from appearing in the n2.
Is your feature request related to a problem? Please describe.
Desired capability or behavior.
The GASPy-based code currently uses a somewhat ad hoc mechanism for statically declaring the variables that need to be passed either from the user or from static analysis into the "phases" (referring to actual dymos phases and the analytic flight segments). It then functions as an input-only component in each ODE for other components to connect to via promotion and provides methods to resolve conflicting defaults and add them as parameters to the dymos trajectories.
Talked this through a bit with @crecine and @ehariton; we like the idea of naming the VariablesIn components when they're in the model to something like _dummy_component_for_inputs or something equally obvious what's going on.
Additionally, these components should move as far down in the model as possible to not create unnecessary backwards coupling from appearing in the n2.
Is your feature request related to a problem? Please describe.
No response
Associated Bug Report
No response