Multimission v2

[ehariton]

Summary

Multi-mission enables a user to input one or more aircraft definitions (aviary_inputs) and a matching number of mission definitions (phase_info) to create a composite objective function who's weighting is specified by the user. In this PR we completely revamp the multi-mission capabilities of Aviary which were previously broken by an OpenMDAO release. As part of this PR, a number of examples were cleaned up / shortened for decrease verbosity and to make use of some of the new methods created in the PR.

General Changes that could affect all users:

1. There is not interface change for regular users. Their models are now instantiated in prob.AviaryGroup. Most all of the original functions contained in methods_for_level2 have been forwarded down into AviaryGroup(). This allows us to set values, link phases, and create subsystems in individually on each group without interfering with the other groups.
2. A new build_model() method combines calls to add_pre_mission_systems(), add_phases(), add_post_mission_systems(), link_phases() that are often used by the user without modification. The individual supporting methods can still be accessed at level 2 if the user needs to add more detail to those inputs.
3. setup() will now automatically call set_initial_guesses() This will allow users to remove set_initial_guesses() from their code making things less verbose.
4. There are some new methods for objective declaration: add_composite_objective() and add_composite_objective_adv(). These methods can be used with any mission type.
5. Mission.Summary.FINAL_MASS and Mission.Summary.FINAL_TIME were added to the variable meta data to enable users to reference the last point in the mission phase without using loc=-1 calls. This allows users easy access to information from the last mission phase run in dymos. If you are adding custom ExecComp() at the end of your mission i.e. to do taxi-to-gate without a dymos phase, these values will not reflect that and you will need to update them for your specific implementation.
6. AviaryProblem can now accept meta_data as an input. This allows the user to first combine all different meta data they have using av.merge_hierarchies and then to input that into the AviaryProblem.

Multi-mission specific changes

1. When setting ProbelmType = MultiMission separate aviary problems will now be instantiated in prob.model.AviaryGroup0, prob.model.AviaryGroup1 etc.
2. Setting problem_type = multimission supersedes and ignores problem_type information written in the .csv . We did not want these problem types conflicting with eachother.
3. It is not possible to run range-based optimizations with multi-mission at the moment (follow-on work).
4. Some new methods will help with setup multimission problems including: add_aviary_group(), promote_inputs(), add_design_var_default(), and set_design_range().
5. Use add_composite_objective() and add_composite_objective_adv() to quickly specify composite objectives such as fuel from mission 1 + payload capacity from mission 2.
6. The reports were updated to accommodate creating one report per aircraft + mission definition pair.
7. add_aviary_group() will not accept .csv files. If the user needs to start from an aircraft defined by a .csv, we recommend examining large_single_aisle_2_FLOPS_data.py for an example of how the .csv needs to be converted. An automated converter will be supplied in the future. You may be able to use parse_inputs() to achieve this before an official converter is supplied by the dev team.

Related Issues

• Resolves #

Backwards incompatibilities

None

New Dependencies

None

[kanekosh]

Could you add engine_builders and meta_data arguments here and pass them to load_inputs so we can bring in custom meta data and engine builders?

[ehariton]

engine_builders has been added. meta_data can be loaded with add AviaryProblem.

[kanekosh]

This will clean-up our multimission code quite a bit, thank you! I'm trying to adopt this change in our code, still getting some errors but will let you know how it works.

This is not directly relevant, but I think mission:summary:gross_mass and mission:design:gross_mass are a bit confusing and might benefit from renaming. In my understanding mission:summary:gross_mass is the actual takeoff weight for a mission, and mission:design:gross_mass is the design MTOW. In my opinion MTOW would belong toaircraft: variables rather than mission:. So I was wondering if the renamings like mission:summary:gross_mass -> mission:takeoff_gross_mass and mission:design:gross_mass -> aircraft:design:max_takeoff_gross_mass would make more sense.