Off design payload

[cmbenne3]

Summary

This PR builds on PR #529 and corrects a bug where changes to payload for off design missions incorrectly impacts the design of the aircraft in pre-mission for GASP based missions.

This is in draft status because #529 must be merged first.

There was discussion as to whether Aircraft.CrewPayload.CARGO_MASS should be split into Aircraft.CrewPayload.Design.CARGO_MASS and an 'as-flown' cargo mass. I'd like to discuss this further with Carl to check if this functionality is available in GASP before we change how aviary treats it.
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).

Related Issues

N/A

Backwards incompatibilities

None

New Dependencies

None

[ehariton]

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.

[cmbenne3]

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

@crecine / @ehariton - what're your thoughts on this approach?

[crecine]

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).

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

• 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

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

[cmbenne3]

PR #623 created to replace this one. Comments copied to the description of that PR