Off Design Payload

[cmbenne3]

Summary

This PR has 2 parts:

1. Fixes the bug with GASP-based off design missions where variations in payload affect the design of the aircraft.

2. Enables GASP based missions to carry cargo whilst keeping backwards compatibility with the current Aviary functionality.

New cargo variables are created:
Aircraft.CrewPayload.Design.CARGO_MASS - this is similar to the design passenger number variables and refers to the cargo carried on the aircraft for the design mission.
Aircraft.CrewPayload.MAX_CARGO_MASS - this is the maximum cargo the aircraft is designed to be capable of carrying. It is used in sizing the fuselage fuel body tank.

Aircraft.CrewPayload.CARGO_MASS - this is the current variable and is now repurposed as the 'as-flown' cargo mass for GASP-Based missions. This variable is used as a summary variable for FLOPS-Based missions as the sum of wing_cargo + misc_cargo.

preprocessors.py has been updated with logic to detect which of the above variables has been input by the user. If only CARGO_MASS is specified by the user then the analysis is assumed to be legacy Aviary and for backwards compatibility it is assumed that the user intends to set MAX_CARGO_MASS with zero cargo flown on as-flown or design missions.

The cargo variables for FLOPS-based missions remain unchanged.

Comments from previous PR moved to here:

Chris:
Currently aviary only treats Aircraft.CrewPayload.CARGO_MASS as part of the design of the aircraft, and does not apply any of this mass to the gross mass of the aircraft when the mission is actually flown. If this is desired functionality then renaming this to 'Aircraft.CrewPayload.Design.CARGO_MASS' would seem sensible, but because this mass is not added to the aircraft for flight it would be different to the design passenger numbers (where that number of passengers is actually flown on the aircraft for that mission).

Eliot:
It looks like Aircraft.CrewPayload.CARGO_MASS has an effect on calculations for:
Aircraft.CrewPayload.CARGO_CONTAINER_MASS and payload_mass_max

Aircraft.CrewPayload.CARGO_CONTAINER_MASS goes into OperatingMass() to calculate Aircraft.Design.OPERATING_MASS. payload_mass_max is input to FuelMass() which outputs fuel_mass_min, which is then input to BodyTankCalculations() along with Aircraft.Design.OPERATING_MASS to calculatewingfuel_mass_min which is then input to FuelSysAndFullFuselageMass() to calculate fus_mass_full() which is input to FuselageAndStructureMass() to calculate Aircraft.Fuselage.MASS.

This large string of connections, and the resulting impact on Aircraft.Fuselage.MASS indicate that CARGO_MASS does have an impact on fuselage mass (at least in cases where fuel.py is used which I believe are GASP cases of mass-sizing). This would indicate that separating a design.CARGO_MASS and an as-flow cargo mass would be the correct approach.

Caution would need to be taken when importing GASP and FLOPS files if this change were implemented as the historical names which can be viewed in variable_meta_data.py for these values (i.e. INGASP.WCARGO) should be considered both the design values, with the as-flown values left blank. We could then assume that if as-flown is left blank, it indicates design is the same as as-flown. This is similar to how back-wards compatibility for design.passengers is handled as neither GASP nor FLOPS had concepts in their output files for the differentiation between as-flown and design passengers.

Chris:
I confirmed with @crecine that the current variable: Aircraft.CrewPayload.CARGO_MASS is implemented as a maximum cargo parameter, and this mass is NOT added to the aircraft gross mass for mission analysis. This copies one type of GASP analysis.
GASP does have the ability to fly missions with cargo, but this is not currently implemented in Aviary.
I plan to:

• Create a new "Aircraft.CrewPayload.Design.CARGO_MASS" parameter, which will exactly replace the current CARGO_MASS variable. Other option would be to name this "MAX_CARGO_MASS"
• Re-purpose "Aircraft.CrewPayload.CARGO_MASS" as an 'as-flown' cargo variable.
• If the user wants to replicate the current GASP implementation they would set Design.CARGO_MASS as they do currently for CARGO_MASS, and set re-purposed CARGO_MASS = 0 (i.e. don't fly the mission with any cargo).
• If they want to add cargo to a mission (design or off-design) then they would update the value of CARGO_MASS (and I will make some modifications to link this through to the mission analysis in the correct way).
• I will add some checks to ensure CARGO_MASS < design.CARGO_MASS

Carl:
Make sure that you have historical_name={"GASP": 'INGASP.WCARGO'} for the new design variable and historical_name={"GASP": None,} for the new as flown variable

I don't think you need to check that CARGO_MASS is less than Design.CARGO_MASS, I think it would be better to check that CARGO_MASS + PASSENGER_MASS is less than Design.CARGO_MASS + Design.PASSENGER_MASS, since it is possible to offload passengers in order to load more cargo