search

OpenMDAO / Aviary

NASA's aircraft analysis, design, and optimization tool
https://openmdao.github.io/Aviary/
Other
134 stars 59 forks source link

Comprehensive Aviary atmospheric component #375

Closed jkirk5 closed 1 month ago

jkirk5 commented 3 months ago

Desired capability or behavior.

There are many calculations related purely to flight conditions that are vehicle-agnostic - currently these calculations are only added wherever needed (such as computing Mach from sos and velocity, computing EAS vs. TAS, etc.). A bundled atmosphere component that includes things like dymos' atmosphere component, the FlightConditions component, Mach number computation, and others is desired. This should then be added to the api and used throughout the code.

These values are broadly useful to have universally available for all components and should help streamline the code. For example, setting a constraint on EAS for a energy-height mission suddenly becomes really easy if EAS is always computed.

Is your feature request related to a problem? Please describe.

No response

Associated Bug Report

No response

xjjiang commented 3 months ago

In OAS_weight external subsystem, it uses another atmospheric component called ambiance. Is it necessary?

jkirk5 commented 3 months ago

In OAS_weight external subsystem, it uses another atmospheric component called ambiance. Is it necessary?

I don't think that should be part of this new component - ambiance is a python package not required for Aviary, as well as only being used for an external subsystem

jkirk5 commented 3 months ago

Preserving additional conversation on this topic here: DJ: If I'm not mistaken, GASP flight_conditions.py has a very nice and flexible definition for dynamic pressure. FLOPS based aero has two separate definitions, one each for computed aero and tabular aero.

John: Thanks DJ, you are indeed correct. Let me try to write out my logic here and you can let me know if it makes sense or not.

We had three ways of computing dynamic pressure in Aviary as you mentioned: 1.) flight_conditions.py in GASP 2.) computed_aero_group.py had its own version 3.) tabular_aero_group.py had its own which had different inputs

I needed the input/outputs from 2.) above for this new solved aero setup. I could've imported it from computed_aero_group.py, but it seemed slightly more smart to make a new file that could house any commonly used components or methods. So I moved the component to that new file and out of computed_aero_group.py.

Now, the more comprehensive change would be to indeed combine all of these ways of computing dynamic pressure into one component. But that sounds like a very nice add-on PR that's well contained later, when we're not introducing a different aero builder as well. I didn't use the flight_conditions.py implementation here because it has slightly different inputs/outputs than what I needed, and if I'm rewriting that to be more general, I might as well tackle all of them.

Does that make sense? Let me know if it's unclear or if you disagree and we can talk through it.

DJ: Your explanation makes sense. I can see in my mind a path forward that combines the best of all three, keeping the GASP flight_conditions.py interfaces, but also making the dynamic pressure calculations available as a separate and shared component or set of components. Minimal changes all around, but definitely a slightly different implementation, without actually changing the underlying calculations at all - just (I hope) quality reuse of common code.

IMHO, a follow on PR for that refactor sooner than later would be great.