Clean up range_constraint behavior in sizing.

[Kenneth-T-Moore]

Summary

1. The "constrain_range" post_mission phase_info key was removed. It previously had no effect.
2. Made behavior for target_range consistent between Energy and 2DOF missions.
3. The range_residual constraint, the component that computed it, and its associated hierarchy variable have been removed in favor of a direct equality constraint on the Mission.RANGE variable.
4. We now use the specified range for the constraint ref.
5. The remaining 2dof phases have been updated to support 'constraints' specified in the phase_info user_options.

For all mission types, we now add a constraint on Mission.RANGE using the value specified in the "target_range" of the post-mission in the phase_info, except for OFF_DESIGN_MAX_RANGE, where we do not add a range constraint. Warnings are raised if 1.) the target_range does not match the Aircraft.Design.RANGE in sizing or 2.) the target_range is missing in sizing.

Related Issues

• Resolves Range constraint in a single-phase mission #673

Backwards incompatibilities

AI Usage

Disclose any AI usage in this PR, including models used and files affected.

[cmbenne3]

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?

[Kenneth-T-Moore]

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.

[cmbenne3]

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?

[Kenneth-T-Moore]

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.

[cmbenne3]

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.

[jkirk5]

Ken, I think that is the goal long-term for how off-design should work. Instead of having these pre-prescribed problem types it would be great for the user to just tell us what should be varied, and we assume everything else is fixed.

I think the only hard rule for off-design is when you run off-design from an existing sizing run is that all design variables must have fixed values taken from the sizing problem. If you create an off-design from scratch all we know is that gross mass can't be a design variable, since we assume it is always used in SIZING missions. It would be up to the user to make sure not to define other design variables that would be important for sizing their particular configuration.