Multi mission opt #529
Multi mission opt #529
Conversation
…ti_mission_opt
…passed in problem
…o have 1 passenger
…d to sweep a design variable. added SNOPT option. Faster convergance with SLSQP but SNOPT returns the same answer
…tion method of user input suggested by jason
…o multi_mission_opt
…oved exit from multimission
…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.
| if show: | ||
| plt.show() | ||
|
|
||
| def create_payload_range_plot(self, show=True): |
There was a problem hiding this comment.
This isn't a payload-range diagram, that can only be built using off-design missions (with range as a fall-out). I say either remove this plot, or change it to points on the diagram and not lines, and remove the 0 range point.
The design missions are just points inside the viable area of the payload-range diagram and don't necessarily define its boundaries.
| for i, (aviary_values, phase_info) in enumerate(zip(aviary_values, phase_infos)): | ||
| prob = av.AviaryProblem() | ||
| prob.load_inputs(aviary_values, phase_info) | ||
| prob.check_and_preprocess_inputs() |
There was a problem hiding this comment.
group_1 (the deadhead mission) mission passenger counts are getting reset to design passenger counts by the preprocessor
There was a problem hiding this comment.
I'm surprised that is happening because I just checked and we are setting passenger count to 1 for the deadhead mission. Which should have side-stepped this issue. I'll test again.
Summary
The Goal was to create a large_single_aisle example of multi-mission 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
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, which is incorrect.Related Issues
Backwards incompatibilities
None
New Dependencies
None