Clean up range_constraint behavior in sizing. - #1327
Kenneth-T-Moore wants to merge 8 commits into
Conversation
| else: | ||
| target_range = aviary_inputs.get_val(Aircraft.Design.RANGE, units='NM') | ||
|
|
||
| aviary_inputs.set_val(Mission.RANGE, target_range, units='NM') |
There was a problem hiding this comment.
Do we want to set this value in aviary_inputs? Mission.RANGE is an output of the problem representing how far the aircraft has flown on the mission being analyzed. Having it present in aviary_inputs might be confusing?(if running an off design max range mission then there would be no target range, target range would be set to design range and then aviary_inputs Mission.RANGE would be set=target_range. After the problem solves the problem level Mission.RANGE (probably significantly longer than the design range) would mismatch with the aviary inputs version set here?
There was a problem hiding this comment.
Good catch. This is a holdover from the 2dof configurator, but since we are caching this value in self.target_range now, we don't need this backchannel.
|
|
||
| self.add_constraint(Mission.Constraints.RANGE_RESIDUAL, equals=0, ref=1000) | ||
| # If target_range is unspecified, then don't assume we want to fly a fixed range. | ||
| if 'target_range' in self.post_mission_info: |
There was a problem hiding this comment.
I don't understand why we check for presence of 'target_range' in post mission info only for this problem_type but not the other 2?
There was a problem hiding this comment.
Hey, Chris. I took a look at our problem_type definitions, and I think I got this mixed up. SIZING and OFF_DESIGN_MIN_FUEL require a target range, but OFF_DESIGN_MAX_RANGE is the one that maximizes distance, so it shouldn't even have a range constraint.
It makes me wonder though, whether we need to add a tru OFF_DESIGN, where we fly it however we want.
There was a problem hiding this comment.
This is a fair point! The off_design_min_fuel is helpful for evaluating the performance of an aircraft on an 'economy' mission or similar, and is a hangover from how people traditionally design for a 'design' mission but want to evaluate performance on shorter ranges or with different payloads.
The off_design_max_range is required for generating a payload-range diagram.
You're right though - an aircraft being flown as a communications relay, or as a disaster relief observation aircraft probably wants to maximise endurance with no constraints or care for the range or distance flown - this is not currently possible with Aviary. Maybe we need an OFF_DESIGN_MAX_TIME mission type.
A time to climb mission would require OFF_DESIGN_MIN_TIME. A supersonic aircraft might require a MIN_TIME mission that includes a range constraint...
Not sure if it's worth trying to build some of these in, or whether we wait until someone requests support for them first.
This branch has not been deployed
2 participants
Summary
target_rangeconsistent between Energy and 2DOF missions.Previously, the Energy method would allow you to run a Sizing mission with no range constraint, while the 2DOF method would use Aircraft.Design.RANGE from the aviary_inputs as the range constraint value if
target_rangewas not specified. This PR changes this behavior so that both Energy and 2DOF will pull the target range from Aircraft.Design.RANGE if it is not specified in post-mission. This only applies to the Sizing problem type.Related Issues
Backwards incompatibilities
This PR does remove the ability to do unconventional sizing where you don't care about the range. An example is the all-electric UAV work our interns did this summer, where they sized the weight and physical dimensions while flying a typical mission. Note that one of the off-design mission types is probably a better choice for this kind of work, but we may need to add some additional support.
AI Usage
Disclose any AI usage in this PR, including models used and files affected.