Paramport refactor part 1: Remove need for VariablesIn for height-energy mission.
Summary
This PR removes the VariablesIn component from the height-energy mission. This component was formerly needed because we were adding parameters from a curated list. The new approach moves the responsibility for declaring those parameters into the aerodynamics builder, because those variables are introduced by components in the default aero subsystem.
- Aero builder now declares all parameters it uses in height-energy.
-
VariablesIncomponent has been removed.
This caused some challenges in models that use the level 3 interface, and existing models will need to be updated. Anyone running level 3 may need to manually set_input_defaults on some variables in their top level script. A new helper function is introduced to aid in this.
- New method
set_aviary_input_defaultsfor level 3. Requires a list of aviary variables as input. Replaces the oldset_aviary_initial_valuesand the "input_sink"VariablesIn, which are no longer needed. - New method
set_aviary_initial_values(repurposing the old name, which is more accurate), which is called after setup and loops over the aviary_inputs, setting all the values. This is needed because we don't loop over the dummy "input_sink" anymore. - Docs updated to show these.
TODO: Next up, need to apply this to the gasp counterpart ParamPort.
Related Issues
- Resolves # 294
Backwards incompatibilities
None
New Dependencies
None
In Issue #294, John pointed out the desire of replacing ParamPort with VariableIn. Is it still a desire?
In Issue #294, John pointed out the desire of replacing
ParamPortwithVariableIn. Is it still a desire?
I think it is even more desirable to remove the paramport entirely, but we weren't sure it was possible then. GIven that it works on the FLOPS side, I think it should also work on the gasp side. Given how complexly it is integrated though, we might need to do some incremental refactors on the way towards removing it entirely.