Simplify how mission range is specified
Maintainers usually reply within 3 days
@ehariton is already working on this.
Since Oct 27, 2026.
Assessment
This issue has not been assessed yet.
Description
Desired capability or behavior.
- Decouple phase info range and Aircraft.Design.RANGE
- These should not interact so we should update the variable descriptions in metadata (maybe a reference range?). Phase info controls the actual mission flown, and Aircraft.Design.Range is a mass equation input that must be specified separately.
- Simplify how we specify 'target_range' in phase info.
- We believe that the current interface already is capable of doing whatever kind of mission we can think of
- Some parameters like distance can be constrained by just adding 'distance_final'.
- Other parameters might need to be added to the 'constraints' key added to the phase.
e.g.
'constraints': {
'normal_force': {
'equals': 0.0,
'loc': 'final',
'units': 'lbf',
'type': 'boundary',
'ref': 1.0e5,
},
}
There might be valid reasons to have a sizing mission where range is not constrained (e.g. might want to constrain time or altitude or speed or something instead), so we don't want to enforce a requirement that there is a range constrain for SIZING missions.
target_range in phase_info post_mission is not necessary (as could get added to the final phase as described in 2 above), but we think it might be helpful for users. We should add a translation section that checks if target_range is set, and then adds the distance_final constraint to the final phase. If a user sets both then we should throw a warning.
If we handle target range in this way we can remove the range constraint component.
Suggested implementation.
No response
- Dominant language
- Python
- Stars
- 294
- Forks
- 144
- Avg merge
- 11d 18h
- Merged PRs (30d)
- 8
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenMDAO/Aviary
-
Consolidate Aircraft.Nacelle.WETTED_AREA & Aircraft.Nacelle.SURFACE_AREAPossibly taken @xjjiang claimed this 1 day ago. Openrequest
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
OpenMDAO/Aviary#1346 · 1 comment · 1 assignee ·
Maintainers usually reply within 3 days
-
request
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 3 days
-
Move mass_per_flight_crew to Aviary variablePossibly taken @xjjiang claimed this 22 days ago. Openrequest
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
OpenMDAO/Aviary#1190 · 1 assignee ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 3 days
-
request
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 3 days
Similar issues
-
infrastructure
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
NatLabRockies/H2Integrate#977 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
topoteretes/cognee#6470 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
area:docs priority:p2 type:docs wave:9
Difficulty 1/5 Under an hour Newbie friendliness 84/100
jejjohnson/radtrax#293 ·
Maintainers usually reply within 1 day
-
bug core plugins
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
bunkerity/bunkerweb#4121 · 1 comment ·
Maintainers usually reply within 1 day