Rename Mission.Design.XXX and Mission.Summary.XXX variables for clarity

[cmbenne3]

Summary

• Changes the names of Mission.Design.XXX to Aircraft.Design.XXX, and Mission.Summary.XXX to Mission.XXX.
• Removes some unnecessary variables.
• Removes the duplicate variable Mission.Landing.TOUCHDOWN_MASS and replaces references to it with Mission.FINAL_MASS

Mission.Design.XXX

class Mission.Design:	New Variable Name	Notes
Mission.Design.CRUISE_ALTITUDE = 'mission:design:cruise_altitude'	Aircraft.Design.CRUISE_ALTITUDE = 'aircraft:design:cruise_altitude'	This variable is only used to calculate max mach for GASP-based Mass in design_load.py It has hardcoded atmospheric constants and should be updated to use Aviary's atmospheric subsystem Issue #1039 .
Mission.Design.CRUISE_RANGE = 'mission:design:cruise_range'	N/A	Removed as not used anywhere in codebase
Mission.Design.GROSS_MASS = 'mission:design:gross_mass'	Aircraft.Design.GROSS_MASS = 'aircraft:design:gross_mass'	We update this to Aircraft since it makes no sense to track the design mission gross mass under mission.
Mission.Design.LIFT_COEFFICIENT = 'mission:design:lift_coefficient'	Aircraft.Design.LIFT_COEFFICIENT = 'aircraft:design:lift_coefficient'	This is not actively set by any of our models, but can be used to overwrite the value clculated by EDET if desired
Mission.Design.LIFT_COEFFICIENT_MAX_FLAPS_UP = 'mission:design:lift_coefficient_max_flaps_up'	Aircraft.Design.LIFT_COEFFICIENT_MAX_FLAPS_UP = 'aircraft:design:lift_coefficient_max_flaps_up'	Currently only specified in GwFm... but seems to be an input to gasp aero...?
Mission.Design.MACH = 'mission:design:mach'	Aircraft.Design.MACH = 'aircraft:design:mach'	This is an aircraft Design Variable, mission mach can be updated in phase info
Mission.Design.RANGE = 'mission:design:range'	Aircraft.Design.RANGE = 'aircraft.design.range'	This is really an aircraft design variable used to size flops subsystems. It is used as an initial guess for target range when not set in phase info
RATE_OF_CLIMB_AT_TOP_OF_CLIMB = 'mission:design:rate_of_climb_at_top_of_climb'	N/A	Variable removed as not used anywhere in Aviary. We should add an example or document how a user would apply a minimum top of climb climb rate constraint as this is a common constraint to have in aircraft design. Issue #1037 tracks this
Mission.Design.RESERVE_FUEL = 'mission:design:reserve_fuel'	Mission.RESERVE_FUEL = 'mission:reserve_fuel'	This is moved under Mission directly as it is not a design variable. As the sum of Mission.RESERVE_FUEL_BURNED + Aircraft.Design.RESERVE_FUEL_ADDITIONAL + Aircraft.Design.RESERVE_FUEL_MARGIN it must be allowed to vary depending on the reserve mission being modelled. Fuel additional and fuel margin are design variables assigned at the aircraft level
Mission.Design.THRUST_TAKEOFF_PER_ENG = 'mission:design:thrust_takeoff_per_eng'	Aircraft.Design.THRUST_TAKEOFF_PER_ENG = 'aircraft:design:thrust_takeoff_per_eng'	This is only used for height energy simple takeoff. By default it should probably be calculated by the propulsion subsystem (e.g. take SLS thrust condition from engine deck), and only overridden intentionally by experienced users. Issue #1038 Not moved to Mission.Takeoff. group so as not to confuse with detailed takeoff parameters. This parameter is also independent of the mission to be flown

Mission.Summary.XXX

class Summary:	New Variable Name	Notes
Mission.Summary.CRUISE_MACH = 'mission:summary:cruise_mach'	Aircraft.Design.CRUISE_MACH = 'aircraft:design:cruise_mach	This variable is actually only used to calculate the landing_to_takeoff_mass_ratio, as a result moved to aircraft.design as it is not mission specific. The actual mach in cruise is specified in phase info dictionary, and might be optimized so having a single value under mission is confusing. Note Aircraft.Design.CRUISE_MACH is distinct from Aircraft.Design.MACH which is an aerodynamic design override or computed internally by EDET. There is also Mission.Constraints.MAX_MACH which is used in Aviary premission for sizing systems (equivalent to FLOPS VMMO). This is incredibly misleading and changing it is tracked in issue #1046
Mission.Summary.CRUISE_MASS_FINAL = 'mission:summary:cruise_mass_final'	N/A	This is removed as it is only used to set initial guesses for two_dof_problem_configurator. If the user wants this functionality they should set it within the .csv file using 'initialization_guesses:cruise_mass_final' or set ['cruise'][initial_guesses]['mass'] in phase info?
Mission.Summary.FINAL_MASS = 'mission:summary:final_mass'	Mission.FINAL_MASS = 'mission:final_mass'	This variable is the mass of the aircraft at the end of the final regular phase 'traj.{final_phase}.states:mass' where final_phase = self.regular_phases[-1] It is not really used anywhere in Aviary, but is potentially useful to the user. It is clearly documented in variable MetaData.
Mission.Summary.FINAL_TIME = 'mission:summary:final_time'	Mission.FINAL_TIME = 'mission:final_time'	This variable is the duration of the dymos phases of the mission. We should instead calculate more useful time variables such as bock_time, and flight_time. These will depend on what phases are modelled and included. Issue #1045 tracks this.
Mission.Summary.FUEL_BURNED = 'mission:summary:fuel_burned'	Mission.FUEL_BURNED	Summary is unnecessary
Mission.Summary.FUEL_FLOW_SCALER = 'mission:summary:fuel_flow_scaler'	Mission.FUEL_FLOW_SCALER = 'mission.fuel_flow_scaler	This PR just renames this variable, but Aviary is inconsistent with translation of FLOPS MISSIN variables since FCDO, FCDI, FCDSUB and FCDSUP are technically all mission variables in FLOPS, but are Aircraft.Design variables in Aviary. If we like this change then this variable could just be removed completely since the Aviary equivalents of Aircraft.Engine.SUBSONIC_FUEL_FLOW_SCALER and Aircraft.Engine.SUPERSONIC_FUEL_FLOW_SCALER can be used to replace the per-mission additional scaler here. Issue #1048 tracks this.
Mission.Summary.GROSS_MASS = 'mission:summary:gross_mass'	Mission.GROSS_MASS = 'mission:gross_mass'	Summary is unnecessary.
Mission.Summary.OPERATING_MASS = 'mission:summary:operating_mass'	Mission.OPERATING_MASS = 'mission:operating_mass'	Summary is unnecessary.
Mission.Summary.RANGE = 'mission:summary:range'	Mission.RANGE = 'mission:range'	Summary is unnecessary.
Mission.Summary.RESERVE_FUEL_BURNED = 'mission:summary:reserve_fuel_burned'	Mission.RESERVE_FUEL_BURNED = 'mission:reserve_fuel_burned'	Summary is unnecessary.
Mission.Summary.TOTAL_FUEL_MASS = 'mission:summary:total_fuel_mass'	Mission.TOTAL_FUEL_MASS = 'mission:total_fuel_mass'	Summary is unnecessary.
Mission.Summary.USEFUL_LOAD = 'mission:summary:useful_load'	Mission.USEFUL_LOAD = 'mission:useful_load'	This PR only modifies the name of this variable. This variable is poorly named. In aviation the useful load is Gross mass - Empty mass. Issue #1049 tracks changing this.
Mission.Summary.ZERO_FUEL_MASS = 'mission:summary:zero_fuel_mass'	Mission.ZERO_FUEL_MASS = 'mission:zero_fuel_mass'	Summary is unnecessary

Related Issues

• Resolves Renaming of design vs summary mission variables #772
• Resolves Consolidate the idea of target_range in phase_info and Mission.Design.RANGE #238
• Resolves Variable name change request: Aircraft.Design.TOUCHDOWN_MASS #991

Backwards incompatibilities

None

New Dependencies

None

[Kenneth-T-Moore]

Removing this connection breaks mass continuity between the end of the last flight phase, and the start of the landing. I think you want to connect it to Mission.FINAL_MASS instead, based on the change in line 643.

[cmbenne3]

What about this in aviary_group: does it not do the same thing?

I was confused as to why we have extraction of mass from the final regular phase in multiple places in the code?

[Kenneth-T-Moore]

Oh, I see what is happening. There is already an output that produces FINAL_MASS, so when Touchdown mass goes away, the landing component just hooks up there.

[Kenneth-T-Moore]

Yeah, we specify this in the phase_info now with required_available_climb_rate (at least in energy method).

[cmbenne3]

Does this mean that issue #1037 is not really necessary since we can do that by setting a phase_info parameter?

[Kenneth-T-Moore]

Well, we may still need the capability in 2dof, so the issue could still serve that purpose.