Fix 0 pax bug for multi-mission

[jkirk5]

Summary

Fixes a bug in the crew & payload preprocessor where providing a passenger count of 0 for a single mission was confused with not providing that particular passenger count variable at all, leading to overwriting mission pax count with design pax count.

Related Issues

• Related to Default values have broken the pre-processor for FLOPS crew/galley processing. #738

Backwards incompatibilities

None

New Dependencies

None

[ehariton]

test_ben_FwFm.py fails on this PR.

File "/mnt/c/OMDAO/om-Aviary/aviary/validation_cases/benchmark_tests/test_bench_FwFm.py", line 397, in test_bench_FwFm_SNOPT
    compare_against_expected_values(prob, self.expected_dict)
  File "/mnt/c/OMDAO/om-Aviary/aviary/validation_cases/benchmark_utils.py", line 48, in compare_against_expected_values
    assert_near_equal(masses[-1], expected_masses[-1], tolerance=rtol)
  File "/mnt/c/OMDAO/openmdao/openmdao/utils/assert_utils.py", line 583, in assert_near_equal
    raise ValueError('actual %s, desired %s, %s error %s, tolerance %s'
ValueError: actual [43067.40134181], desired [62697.71513264], rel error 0.3130945641208417, tolerance 0.02

This code detects:
pax_provided True
design_pax_provided True

even though only Design information is provided in aircraft_for_bench_FwFm.csv

Examining aviary_options what we find is that 'aircraft:crew_and_payload:num_business_class': (0, 'unitless'), has been set before getting to the following code lines in preprocessor.py:

    for key in pax_keys:
        if key in aviary_options:
            # mark that the user provided any information on mission passenger count
            pax_provided = True
        else:
            # default all non-provided passenger info to 0
            aviary_options.set_val(key, 0)

[jkirk5]

I will need to update docs once I have tests working

[jkirk5]

Examining aviary_options what we find is that 'aircraft:crew_and_payload:num_business_class': (0, 'unitless'), has been set before getting to the following code lines in preprocessor.py:

It appears it is an issue stemming from the way load_vehicle() works, which is to grab every single variable from the metadata with a default and apply it to the aviary inputs. I think this is really bad because it has the potential to accidentally set default values as overrides which 100% isn't intended behavior. It also is really overkill, we only need to set values for inputs the user wants - every other default should come directly from the metadata when adding component inputs/outputs.

This PR may need to stay on hold until we clean up how defaults work in the rest of Aviary, this approach should work with the new paradigm (all defaults come from metadata rather than using user inputs as a vehicle to get those values into the problem)

[ehariton]

I thought this was called "max fuel" point not "max economic range" ? The wording here doesn't make me feel great and I mis interpreted it the first time I read it. I might go for something like:
The range the aircraft can fly at where the fuel tanks are completely full and payload mass is added until the aircraft reaches it's maximum gross mass.

[jkirk5]

This change is actually already in main from the off-design overhaul, but I'll comment here.

I'm not sure I follow, the point is still directly named "Maximum Fuel Point" here. Each point has a name, and mentions the particular range that point corresponds to (e.g. flying the max payload point falls out design range) as additional information. The only other name I've ever heard to describe this range is "harmonic range", which to me is super unhelpful. I chose "Max Economic Range" based on the fact off-design missions that describe actual operating cases are often referred to as "economic missions". "Max Economic Range" is meant to refer to the maximum range of the aircraft at full utilization (and therefore maximizing profitability at that range). I'm open to a better name for this specific range since there doesn't seem to be a good official one.

And the sentence I have seems to me to say the exact thing you suggested? "fuel tanks completely full" == "at maximum fuel capacity", "payload mass added until reaches maximum gross mass" == "payload mass up to maximum gross mass"

[ehariton]

@Kenneth-T-Moore, considering the simplification here we may want to push all the below into the EOM builder.