Multi mission opt #529
Merged
Multi mission opt #529
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ti_mission_opt
…passed in problem
…ss from multi_mission example because not useful outputs.
… for multimission docs
… default, updated warning messages.
…tests do not successfully set these
| Optimizer = 'SLSQP' # SLSQP or SNOPT | ||
|
|
||
|
|
||
| class MultiMissionProblem(om.Problem): |
There was a problem hiding this comment.
class MultiMissionProblem could live in aviary/interface eventually.
There was a problem hiding this comment.
I agree with you, but it would probably need more polish like exposing all the design variables so the user can set those without modifying MultiMissionProblem()
| @@ -381,14 +391,16 @@ def load_inputs(self, aviary_inputs, phase_info=None, engine_builders=None, meta | |||
| aviary_inputs.set_val(Mission.Summary.GROSS_MASS, | |||
| val=self.initialization_guesses['actual_takeoff_mass'], units='lbm') | |||
| if 'target_range' in self.post_mission_info: | |||
| aviary_inputs.set_val(Mission.Design.RANGE, wrapped_convert_units( | |||
| aviary_inputs.set_val(Mission.Summary.RANGE, wrapped_convert_units( | |||
There was a problem hiding this comment.
I think this is the fix for the multiengine tests regressions!
There was a problem hiding this comment.
Yeah you must set this to target_range because that is how far we are actually flying. Whereas design.Range is really just for sizing subsystems, weights, and max mission range.
| @@ -473,16 +486,20 @@ def check_and_preprocess_inputs(self): | |||
| if (self.analysis_scheme is AnalysisScheme.COLLOCATION) and (self.mission_method is EquationsOfMotion.TWO_DEGREES_OF_FREEDOM): | |||
| try: | |||
| # if the user provided an option, use it | |||
| analytic = self.phase_info[phase_name]["user_options"]['analytic'] | |||
| analytic = self.phase_info[phase_name]["user_options"][ | |||
There was a problem hiding this comment.
auto-pep sure makes some weird choices.
Kenneth-T-Moore
approved these changes
Nov 5, 2024
Closed
jkirk5
requested changes
Nov 18, 2024
aviary/examples/multi_mission/run_multimission_example_large_single_aisle.py
Outdated
Show resolved
Hide resolved
aviary/examples/multi_mission/run_multimission_example_large_single_aisle.py
Show resolved
Hide resolved
…tting passengers to zero. Removed payload-range plot from example b/c not useful. Reordered output printing for example.
…TOTAL_PAYLOAD_MASS to zero as a suggestion on how the user can set zero passengers
jkirk5
approved these changes
Dec 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The Goal was to create a large_single_aisle example of a multi-mission monolithic optimization to allow an aircraft to be optimized for two missions, a mission where the aircraft was full of passengers, and one where the aircraft had no passengers. The implementation contains two pre-mission, missions, and post-mission analysis followed by summing the objective functions from both analysis into a single objective.
A number of updates to the way that aircraft are described were needed to make this PR work because there was previously no notion of "Design" passenger quantities vs. "As-flown" passenger quantities. In order to make a mission that could simulate both full and empty passenger seats, a clear division was created between these two values:
New Design Terms Added:
Design.NUM_PASSENGERS
Design.NUM_BUSINESS_CLASS
Design.NUM_TOURIST_CLASS
Design.NUM_FIRST_CLASS
Mission.Design.RANGE vs. target_range
Weights for all subsystems in pre-mission are sized based on the Design.pax values. This required a number of updates throughout different subsystems. For example, the weight of the air conditioning system should not be affected by the number of passengers on the plane. Rather it is affected by how many passengers the plane was designed for. That is because we don't remove the air conditioning if there are fewer people on the plane!
A number of checks had to be added to help users if they never specified Design.pax values. Those tests, run in preprocessor.py, will assist the user in filling out Design.pax values if they are not included in the csv files, enabling backwards compatibility.
Tested with FLOPS weights and mission models.
The
N3CC_data.pyconfiguration file has been revised. This file previously calledpreprocess_options(). This would trigger wheneverimport get_flops_inputswas called causing aviary to be unable to detect what aviary_values had been set by the user and what had been left blank.preprocess_options()fills in those blank areas. Removing this call fromN3CC_data.pyexposed that in many of the N3CC related tests,preprocess_options()was never called so it had to be added.All the aircraft .csv definitions were changed from specifying the as-flow passenger values to Design.pax values. This was required to make checks for the FLOPS and GASP converters work successfully. Those converters translate
INGASP.PAXand'aircraft.outputs.L0_crew_and_payload.passenger_count'toAircraft.CrewPayload.Design.NUM_PASSENGERS, reflecting GASP and FLOPS intent to set design passengers not as-flown passengers. There are no equivalents for historical_names for as-flown passengers so those are left blank.Related Issues
Backwards incompatibilities
None
New Dependencies
None