OpenMDAO
Cargo container mass bookeeping
Cargo container mass (used by FLOPS) is causing a lot of headaches. The actual number of required cargo containers (and therefore their mass) is calculated during premission based on how much non-passenger payload is added, and is not known ahead of time. This is currently bookept under operating empty mass - this makes sense, but causes problems. OEW now changes based on mission flown, and this breaks payload-range diagram missions. When figuring how how much fuel or payload is required to fill the aircraft to max takeoff gross mass, we have to rely on OEW's that contain cargo containers, but the number of cargo containers may actually change after running pre-mission, affecting the amount of payload we can actually carry.
A change in bookeeping is probably needed, and possibly smarter off-design mission setup that is aware of this issue and can maybe recalculate the cargo container mass on the fly using that individual component? I'm looking for a cleaner solution to this.
Perhaps we should change the breakdown so that operating empty weight excludes the mass of cargo containers. You then add cargo (and cargo container) weight on top of the operating empty weight to get your zero fuel weight (which already changes with mission). This implementation would then also require some smarter logic so that when a user attempts to load a certain amount of passengers and cargo onto an aircraft the max zero fuel weight is not exceeded by cargo containers. (perhaps we can automatically reduce the cargo by the calculated value of cargo_container_mass and print a warning to the user to let them know we have done this). In my opinion this is considerable complexity to capture a relatively small effect that in practice is often completely ignored anyway by FLOPS users setting WCON = 0.0 (cargo_container_mass = zero) to avoid OEW from recalculating between missions.
Current plan is to have cargo container mass in FLOPS methodology not change during off-design (basically always use design cargo mass). This matches how that code actually behaves, and sidesteps this issue