openmdao / aviary

NASA's aircraft analysis, design, and optimization tool

OpenMDAO

OpenMDAO is an open-source high-performance computing platform for systems analysis and multidisciplinary optimization, written in Python. It enables you to decompose your models, making them easier to build and maintain, while still solving them in a tightly coupled manner with efficient parallel numerical methods.

The OpenMDAO project is primarily focused on supporting gradient-based optimization with analytic derivatives to allow you to explore large design spaces with hundreds or thousands of design variables, but the framework also has a number of parallel computing features that can work with gradient-free optimization, mixed-integer nonlinear programming, and traditional design space exploration.

If you are using OpenMDAO, please cite us!

Documentation

Documentation for the latest version can be found here.

Documentation archives for prior versions can be found here.

Important Notice

While the API is relatively stable, OpenMDAO remains in active development. There will be periodic changes to the API. User's are encouraged to pin their version of OpenMDAO to a recent release and update periodically.

Install OpenMDAO

You have two options for installing OpenMDAO, (1) from the Python Package Index (PyPI), and (2) from the GitHub repository.

OpenMDAO includes several optional sets of dependencies including: test for installing the developer tools (e.g., testing, coverage), docs for building the documentation and visualization for some extra visualization tools. Specifying all will include all of the optional dependencies.

Install from PyPI

This is the easiest way to install OpenMDAO. To install only the runtime dependencies:

pip install openmdao

To install all the optional dependencies:

pip install openmdao[all]

Install from a Cloned Repository

This allows you to install OpenMDAO from a local copy of the source code.

git clone http://github.com/OpenMDAO/OpenMDAO
cd OpenMDAO
pip install .

If you would like to make changes to OpenMDAO it is recommended you install it in editable mode (i.e., development mode) by adding the -e flag when calling pip, this way any changes you make to the source code will be included when you import OpenMDAO in Python. You will also want to install the packages necessary for running OpenMDAO's tests and documentation generator. You can install everything needed for development by running:

pip install -e OpenMDAO[all]

OpenMDAO Versions

OpenMDAO 3.x.y represents the current, supported version. It requires Python 3.8 or later and is maintained here. To upgrade to the latest release, run:

pip install --upgrade openmdao

OpenMDAO 2.10.x was the last version to support Python 2.x and is no longer supported. To install this older release, run:

pip install "openmdao<3"

OpenMDAO 1.7.4 was an earlier version of OpenMDAO and is also no longer supported. The code repository is now named OpenMDAO1, and has moved here. To install it, run:

pip install "openmdao<2"

The legacy OpenMDAO v0.x (versions 0.13.0 and older) of the OpenMDAO-Framework are here.

Test OpenMDAO

Users are encouraged to run the unit tests to ensure OpenMDAO is performing correctly. In order to do so, you must install the testing dependencies.

1. Install OpenMDAO and its testing dependencies:

   pip install openmdao[test]

   Alternatively, you can clone the repository, as explained here, and install the development dependencies as described here.

2. Run tests:

   testflo openmdao -n 1

3. If everything works correctly, you should see a message stating that there were zero failures. If the tests produce failures, you are encouraged to report them as an issue. If so, please make sure you include your system spec, and include the error message.

   If tests fail, please include your system information, you can obtain that by running the following commands in python and copying the results produced by the last line.

    import platform, sys
   
    info = platform.uname()
    (info.system, info.version), (info.machine, info.processor), sys.version
   

   Which should produce a result similar to:

    (('Windows', '10.0.17134'),
     ('AMD64', 'Intel64 Family 6 Model 94 Stepping 3, GenuineIntel'),
     '3.6.6 | packaged by conda-forge | (default, Jul 26 2018, 11:48:23) ...')
   

Build the Documentation for OpenMDAO

Documentation for the latest version can always be found here, but if you would like to build a local copy you can find instructions to do so here.

aviary's Issues

Improve variable list doc page

Desired capability or behavior.

Herb said: I noticed the tables on https://openmdao.github.io/Aviary/misc_resources/variable_list.html are getting chopped off on the right

John mentioned: Great point. I see this page exists and so does the variable metadata page, both of which seem to serve close to the same purpose.

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

No response

Associated Bug Report

No response

Allow L2 users to set constraints on the mission

Desired capability or behavior.

Jes wants to constrain throttle to be 1 during climb and 0 during descent.
We should expose this as a possibility in the L2 phase_info object.
Jason suggests doing this in a general way so we can accept names for general variables and constrain them as well.

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

No response

Associated Bug Report

No response

Add metadata to the Aviary Variables table in the dashboard

Desired capability or behavior.

Add the aviary metadata to the dashboard tab named Aviary Variables.

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

No response

Associated Bug Report

No response

Initial guessing for some setups should be better integrated

Desired capability or behavior.

After wrestling with GASP-based initial guessing, I'm putting it aside for a bit.
We should move the initial guessing that currently occurs in create_vehicle out to the correct method within methods_for_level2.py, set_initial_guesses. Unfortunately there are intermediary uses within the code for the initial guesses. I haven' been able to parse them apart or refactor them too easily.

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

No response

Associated Bug Report

No response

Allow users to provide a custom PhaseBuilder in the `phase_info` object

Desired capability or behavior.

Jes asked about this and it seems relatively doable. This way we could have a series of "regular" phases with a custom phase inside of phase_info. We'd need to work out the logic of how to connect states, etc, and that might get a bit hairy. For now the only way to do this is to replace add_phases with your own method, which might be a lot of work.

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

No response

Associated Bug Report

No response

Update mass report to use SAWE RP-8 standard

Desired capability or behavior.

Current mass report is a placeholder regurgitation of some relevant outputs. The report should be updated to use the mass categories in SAWE RP-8. Additional post-mission components or code in the reporting function might be needed to sum and re-organize the mass outputs for FLOPS and GASP into the categories used by the standard.

The updated report should be moved to the MassBuilderBase class instead of the CoreMassBuilder, so it is more easily accessible to non-core Aviary mass estimations.

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

No response

Associated Bug Report

No response

Matrix size error when setting up solved aero table with structured unique inputs.

Description

The new table lookup is only tested with fully broadcast arrays for inputs instead of the compact unique arrays. There is an exception raised now when using the latter.

Example

This is the MBSAE problem, and worked in earlier aviary.
works: mach =[0.1, 0.1, 0.6, 0.6]; altitude = [0, 1000, 0, 1000]
broken: mach = [0.1, 0.6]; altitude = [0, 1000]

Aviary Version

0.9.2-dev

Relevant environment information

No response

Improve sizing behavior of the N2 diagram in the dashboard

Desired capability or behavior.

It would be ideal if the N2 somehow knew the user's window size and would grow dynamically when increasing the window size

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

No response

Associated Bug Report

No response

TAS & TAS_rate -> VELOCITY & VELOCITY_RATE

Desired capability or behavior.

All references to TAS and TAS_rate should be changed to Mission.Dynamic.VELOCITY and Mission.Dynamic.VELOCITY_RATE`

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

GASP used TAS and TAS_rate as designations for velocity. Many of the equations supporting the GASP ODEs fall apart if TAS includes wind effects. e.g. calculation of ground speed based on TAS and gamma doesn't work if TAS includes any wind effects.

Associated Bug Report

No response

Standardize and document how `phase_info` defaults are set

Desired capability or behavior.

Now that all phases use the PhaseBuilderBase we can and should document how defaults are set. Currently they're at the bottoms of the different phase files.

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

No response

Associated Bug Report

No response

Pop-up windows during aviary installation

Description

I was following the instructions on Aviary installation. I tried to use testflo . & then during the run, i get all these pop-up windows that appear and disappear by themselves. I was not sure if it is a bug or something else or (hopefully not) some virus in my computer. I have attached the screenshot.

Example

testflo .

Aviary Version

0.9.0

Relevant environment information

Linkage report in dashboard has formatting issues

Description

The title is overlapped by the actual diagram

Example

run the run_simple_weight.py script to get reports generated and then run

aviary dashboard run_simple_weight

to see the dashbaord

Aviary Version

0.9.3-dev

Relevant environment information

NA

Refactor the dashboard tests so we don't need the reports and record files saved in the repo

Summary of Issue

Currently DashboardCommandTestCases uses saved reports and recorder files.
It'd be nice if we didn't have those in the repo for two main reasons; they're relatively large files and it might be confusing because we normally ignore reports folders in the repo.

Is it possible to have the dashboard tests instead run a simple Aviary case, then use those recorder and report files?
We could use an existing test and enforce the order of the tests.
We could use the built-in setUp method for unittests as well.

Issue Type

• Bug
• Enhancement
• Code Cleanup
• Docs
• Miscellaneous

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

No response

Associated Bug Report

No response

Allow Aviary to run without any passengers

Desired capability or behavior.

Jes pointed out that sometimes FLOPS users have no passengers and just use added cargo mass as the total contributed mass. Aviary currently doesn't support this as it assumes we have a non-zero amount of passengers. This isn't a major roadblock, but if it's relatively easy to change this, it would make it easier for people to keep their same workflow within Aviary.

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

No response

Associated Bug Report

No response

Users really want some basic examples in the examples folder

Desired capability or behavior.

Users understandably want to see examples in the examples folder.
We currently just have some specialized examples or external subsystem examples.
I'll drop a few examples in there and make sure they're tested.

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

No response

Associated Bug Report

No response

Add some documentation to each tab in the dashboard

Desired capability or behavior.

The current tabs in the dashboard don't provide much information about what the various tabs are about. Provide some way of giving that to the user. Options:

1. Button that brings up info. Maybe just a question mark button
2. Hover over to get info

Just a short sentence or two about each tab and why it's useful

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

No response

Associated Bug Report

No response

There is no checking on hierarchy variables read in from a csv file.

Description

If I typo one of the aircraft:* or mission:* hierarchy names, there is no warning or error that I have made a mistake.

Note: the aviary reader is going to see this as a non-hierarchy variable, since you can set any top-level variable in the csv. Maybe we should check the list of var names that get read in, and raise a warning or error for any that are found not to be in the aggregate hiearchy metadata and/or the model.

Example

"aircraft:wing:mass_scaler" which I could typo as "aircraft:wing:mass_scalar".
It is not a required variable, so I would never know without careful checking versus list_inputs.

Aviary Version

0.9.2-dev

Relevant environment information

No response

Add ability to use hot day (non standard atmosphere)

Desired capability or behavior.

Summary of Issue

GASP had the ability to include a temperature delta in its mission analysis for a hot day, which was especially useful for acoustic missions. We should add this ability to Aviary.

Issue Type

• Bug
• Enhancement
• Code Cleanup
• Docs
• Miscellaneous

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

No response

Associated Bug Report

No response

Aviary Dashboard needs cleaner handling when you give it a script-name that doesn't exist.

Description

Right now, if you give the dashboard a script_name that doesn't exist, the following happens:

1. Error is raised about not finding the "final" case. Need a more accurate message.
2. A new folder with the missing script name is created in reports. (This would be "zzz" in the example below). We shouldn't create new folders in this case.

Example

aviary dashboard zzz should do it, if you don't have a script named zzz.py.

Aviary Version

0.9.2-dev

Relevant environment information

No response

Make input decks handle blank lines correctly

Desired capability or behavior.

Users (like Jes! thanks Jes) sometimes will have blank lines in their .csv file for readability. We should be able to handle this. Shouldn't take a huge amount of time to change this in create_vehicle.

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

No response

Associated Bug Report

No response

Docs are potentially confusing for installation

Desired capability or behavior.

Both the readme and docs could be more clear about the installation process.
Tests are not explicitly required to run Aviary.
Make this clear in the docs.

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

No response

Associated Bug Report

No response

Aviary dashboard ought to still load even if an error prevents one of the reports from generating.

Description

I have a case that raised an exception during run_model, so it never wrote its final case, and never got to the post-driver hook reports. I get the following error in the dashboard:

I think it would be ideal if the dashboard loaded no matter what happens to any of its reports or panes. In this case, I want to inspect the n2 to see what is going on in my model.

Example

Just raise an exception in any component's execute, and you will see it.

Aviary Version

0.9.2-dev

Relevant environment information

No response

Unify phase builders for all phase types

Description

Summary of Issue

Currently FLOPS-originating phases use a phase builder object. GASP-originating phases do not use this same object but have a similar set of methods. We should unify these methods to use the same builder setup. This would make the level3.py logic much simpler and also remove potential confusion from users if they modify the phase setup.

Issue Type

• Bug
• Enhancement
• Code Cleanup
• Docs
• Miscellaneous

Example

See description

Aviary Version

0.9.3-dev

Relevant environment information

No response

Better error handling when giving invalid script name to dashboard script

Description

The dashboard script currently doesn't do any checking if the user supplied script name is valid

Example

Use any random name for the script name in the dashboard command

aviary dashboard rubbish

The script will create a dashboard of mostly nothing

Aviary Version

0.9.0

Relevant environment information

No response

People want to see plots of variables vs range instead of time

Desired capability or behavior.

traj_results_report.html is awesome. It's sick as heck.
People want to see results against range sometimes.
Do we want to provide this as an output from Aviary? Or Dymos, or something else?
How tough would this be?
At a minimum, maybe some postprocessing showing the y-axes with the states/controls/etc and the x-axes with distance.

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

No response

Associated Bug Report

No response

Fully implement new VERBOSITY settings

Desired capability or behavior.

With the introduction of the Settings category to the variable hierarchy, we now have a official way to control output volume via the VERBOSITY flag. This variable now needs to be propagated through the code. A few immediate fixes:

• Replace the debug_mode flag everywhere it appears, and replace with the appropriate VERBOSITY level. This includes modifying fortran_to_aviary to no longer hardcode adding in debug_mode to converted files, and removing all of the special handling needed to deal with that add-on variable
• Wrap all print statements in the code under checks for a minimum threshold VERBOSITY level

VERBOSITY enum values are ints, so greater than/less than comparators should be used for logic statements whenever possible (e.g. only print specific info if VERBOSITY is greater than 2, etc.)

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

No response

Associated Bug Report

No response

Standardize "mission_method" usage throughout

Desired capability or behavior.

Summary of Issue

Within Aviary, there is a notion of mission_method as well as mission_origin which means the same thing.
There might be others cases or words describing the same thing.
To resolve this issue, use the same name throughout.

Issue Type

• Bug
• Enhancement
• Code Cleanup
• Docs
• Miscellaneous

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

No response

Associated Bug Report

No response

Reduce the height of the headers and tabs on the dashboard

Desired capability or behavior.

Shorter header and tabs so there is more screen space for the actual content

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

No response

Associated Bug Report

No response

Non case-sensitive Enum value matching for AviaryValues

Desired capability or behavior.

Currently when matching strings to Enum values when using set_val(), AviaryValues requires matching case. This is not strictly necessary, and removing case sensitivity would allow for more natural variable definitions in csv input files (e.g. accepting 2DOF instead of forcing 2dof).

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

No response

Associated Bug Report

No response

Fix cause of unnecessary warning when using simple mission

Desired capability or behavior.

Summary of Issue

Because of the way we call set_time_options() for the simple mission right now, we get some warnings that do not impact the problem but may confuse users unnecessarily:

/mnt/c/users/jjasa/Documents/Dymos/dymos/phase/phase.py:2178: UserWarning: Phase time options have no effect because fix_initial=True or input_initial=True for phase 'traj.phases.descent_1': initial_bounds, initial_ref
  warnings.warn(f'Phase time options have no effect because fix_initial=True '

Issue Type

• Bug
• Enhancement
• Code Cleanup
• Docs
• Miscellaneous

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

No response

Associated Bug Report

No response

Replace legacy code names with EOM names

Desired capability or behavior.

Referring to equations of motion should use the method's name (e.g. "height-energy") instead of a codename (FLOPS, GASP). Use of an Enum is preferred to string for clarity of available options to developers.

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

No response

Associated Bug Report

No response

Using pull request merge queues

Desired capability or behavior.

Once we're public, GitHub has some pretty slick tools available to us.
One is pull request merge queues which could help smooth out our PR review and merge process.

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

No response

Associated Bug Report

No response

Enhancement

Add more permutations of settings in tests

Desired capability or behavior.

We don't currently have full coverage of all mission-related settings.
We should evaluate those that are missing and add tests for them.
Specifically, I'm thinking about connections, no_descent, add_initial_mass_constraint, other things in the phase_info object.

From Ken on #88: "Ultimately, we are going to have to add more tests/benchmarks for all of these options to have complete coverage. We might not need full optimizations, but we do need to build and inspect. Same is true with optimize_mass/altitude, etc. Because of interactions, we might need a full-factorial number of tests."

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

No response

Associated Bug Report

No response

Interpolation Check (Legacy 54)

Desired capability or behavior.

Many interpolants are used in Aviary. Check over all of them and make sure we use the fixed methods to improve speed.

Originally submitted by @jdgratz10

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

No response

Associated Bug Report

No response

Deepcopy of phase_info in AviaryProblem can cause problems.

Description

In the AviaryProblem init, we do a deepcopy of the phase_info object. This was done to address a problem during testflo execution, where a test fails because the default phase_info was modified in some previous test. It is not a safe solution though, because the phase_info can contain an object that wraps an external code., and it is possible (maybe likely) for that to contain an attribute that can't (or shouldn't) be copied.

The proper way to address the testing problem is, sadly, to copy the phase_info on a case-by-case basis in the tests or benchmarks where it is imported.

Example

See MBSA&E VSP aero wrappers.

Aviary Version

0.9.0-defv

Relevant environment information

No response

Name Duplication: Dynamic.Mission.DISTANCE & Dynamic.Mission.RANGE

Desired capability or behavior.

Dynamic.Mission.RANGE and Dynamic.Mission.DISTANCE have the same meaning in Aviary.
There are also rates associated with both values.
The difference is probably a holdover from the LEAPS2 and GASPy codes.
We only need one of them.
We should choose one and rename throughout Aviary.
The consolidated standard will be Dynamic.Mission.DISTANCE.

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

No response

Associated Bug Report

No response

Variable metadata list is not properly displayed in the docs

Description

The package itables is not installed when the docs are created.
This causes the bottom interactive table on this page to not get shown: https://openmdao.github.io/om-Aviary/user_guide/variable_metadata.html

Example

See description

Aviary Version

0.9.2-dev

Relevant environment information

No response

Multiple (unused) example aircraft models loaded every Aviary run

Desired capability or behavior.

Whenever the Aviary interface is used (at any level), the api is imported - this results in every single data-file based example case being loaded. This adds additional time (anecdotally ~1 sec extra on my laptop) and can generate warnings and errors that aren't actually related to the model being ran, as well as making debugging some files significantly more difficult.

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

No response

Associated Bug Report

No response

The logic for `optimize_mach` and `optimize_altitude` with different phases should be better

Description

Currently if a user has a multiphase mission and wants to optimize Mach or altitude across only some of the phases the logic isn't necessarily correct. Aviary will fail due to linkage issues.

We should make this work and document what it's doing clearly. Consult with John beforehand if you plan to tackle this issue.

Example

Jes encountered this

Aviary Version

0.9.2-dev

Relevant environment information

No response

Add units column to the Results->Aviary Variables page

Desired capability or behavior.

The Results->Aviary Variables page is missing information about the units of the variables

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

No response

Associated Bug Report

No response

Run benchmarks as part of CI

Desired capability or behavior.

We need to run benchmarks as part of CI.
To do all of them we'd have to install SNOPT.
I don't want to do this.
Let's make sure they run with IPOPT and add a workflow for it.

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

No response

Associated Bug Report

No response

Script aviary/examples/level2_shooting_traj.py fails

Description

The script,

python aviary/examples/level2_shooting_traj.py

fails with this error

  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/system.py", line 5137, in get_val
    raise KeyError('{}: Variable "{}" not found.'.format(self.msginfo, name))
KeyError: '\'traj\' <class FlexibleTraj>: Error calling compute(), \'<model> <class Group>: Variable "engine_deck.nox" not found.\''

Example

Run the script

python aviary/examples/level2_shooting_traj.py

The resulting stack trace is

Traceback (most recent call last):
  File "/Users/hschilli/Documents/OpenMDAO/dev/om-Aviary/aviary/examples/level2_shooting_traj.py", line 146, in <module>
    run_aviary(input_deck, phase_info,
  File "/Users/hschilli/Documents/OpenMDAO/dev/om-Aviary/aviary/examples/level2_shooting_traj.py", line 136, in run_aviary
    prob.failed = prob.run_aviary_problem(
                  ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/hschilli/Documents/OpenMDAO/dev/om-Aviary/aviary/interface/methods_for_level2.py", line 2266, in run_aviary_problem
    failed = self.run_model()
             ^^^^^^^^^^^^^^^^
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/problem.py", line 661, in run_model
    self.model.run_solve_nonlinear()
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/system.py", line 4558, in run_solve_nonlinear
    self._solve_nonlinear()
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/group.py", line 3669, in _solve_nonlinear
    self._nonlinear_solver._solve_with_cache_check()
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/solvers/nonlinear/nonlinear_runonce.py", line 26, in _solve_with_cache_check
    self.solve()  # don't use caching
    ^^^^^^^^^^^^
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/solvers/nonlinear/nonlinear_runonce.py", line 45, in solve
    self._gs_iter()
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/solvers/solver.py", line 803, in _gs_iter
    subsys._solve_nonlinear()
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/explicitcomponent.py", line 318, in _solve_nonlinear
    self._compute_wrapper()
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/explicitcomponent.py", line 272, in _compute_wrapper
    with self._call_user_function('compute'):
  File "/Users/hschilli/miniforge3/envs/openmdao/lib/python3.11/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/system.py", line 2680, in _call_user_function
    raise err_type(
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/system.py", line 2674, in _call_user_function
    yield
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/explicitcomponent.py", line 292, in _compute_wrapper
    self.compute(self._inputs, self._outputs)
  File "/Users/hschilli/Documents/OpenMDAO/dev/om-Aviary/aviary/mission/gasp_based/phases/time_integration_traj.py", line 94, in compute
    sim_gen.send(next_problem)
  File "/Users/hschilli/Documents/OpenMDAO/dev/om-Aviary/aviary/mission/gasp_based/ode/time_integration_base_classes.py", line 535, in compute_traj_loop
    [
  File "/Users/hschilli/Documents/OpenMDAO/dev/om-Aviary/aviary/mission/gasp_based/ode/time_integration_base_classes.py", line 536, in <listcomp>
    current_problem.prob.get_val(state_name, units=unit)
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/problem.py", line 529, in get_val
    val = self.model.get_val(name, units=units, indices=indices, get_remote=get_remote,
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/hschilli/Documents/OpenMDAO/dev/OpenMDAO/openmdao/core/system.py", line 5137, in get_val
    raise KeyError('{}: Variable "{}" not found.'.format(self.msginfo, name))
KeyError: '\'traj\' <class FlexibleTraj>: Error calling compute(), \'<model> <class Group>: Variable "engine_deck.nox" not found.\''

Aviary Version

0.9.0

Relevant environment information

No response

Control connections need to be different for height_energy

Desired capability or behavior.

Both takeoff and landing constraint connects have traj.climb.control_values:mach, but that could be polynomial_control_values if they set the option for those.

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

No response

Associated Bug Report

No response

Clean up takeoff/landing logic for height_energy mission

Desired capability or behavior.

kenneth_t_moore:
The constraints for takeoff are being added in the add flops landing systems method.
Should move those into the takeoff code, because you can independently turn on takeoff and landing.

johnjasa:
cool, good catch. I'll move it. It can't go directly in the takeoff code because that would create a cyclic loop because takeoff is before climb and we're connecting climb and takeoff with the resid calc. but it should be out of the landing group indeed. I'll make an issue

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

No response

Associated Bug Report

No response

Standardize required altitude rate naming

Desired capability or behavior.

Summary of Issue

In some places in Aviary, we have multiple names for effectively the same thing: required_altitude_rate and roc_at_toc.
Pick one name -- probably the former as verbosity is helpful -- and use it everywhere.

Issue Type

• Bug
• Enhancement
• Code Cleanup
• Docs
• Miscellaneous

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

Thinking more about this now, this is slightly more complex than just renaming.
I'll put my thoughts here.

GASP- and FLOPS-based missions handle rate of climb at top of climb differently. Aviary currently has no constraint on the GASP side but it exists in the input decks. FLOPS-based has required_altitude_rate come in at the phase_info level. This is valid for any phase and is enforced as a path constraint across the whole phase, not just climb.

We might as well rework this so that:

• the required altitude rate is available to be enforced anywhere, not just a phase called climb
• it's handled in the same way for all types of missions with a constraint at the add_design_variables() method level from methods_for_level2.py
• to do this, we'd need to compute ALTITUDE_RATE_MAX as part of the GASP equations of motion, which is not currently the case

Associated Bug Report

No response

Update workflows to use Node.js 20

Desired capability or behavior.

Node.js 16 is currently in use, but has been deprecated.

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

Associated Bug Report

No response

Modify the where reports go when running level1

Desired capability or behavior.

Currently the reports all go into ./reports/aviary no matter what the csv file is named. It would be better to name the directory after the csv file.

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

No response

Associated Bug Report

No response

N2 and linkage diagram visibility in the dashboard

Description

The N2 and linkage diagrams are not displayed optimally in their tabs on the dashboard:

can't show the entire diagram on the screen, even when i set the model height to 50%
The frame that contains the n2 has a large area of unused space at the bottom
Using set model height also has a weird interaction where it sizes the n2 larger than the dashboard frame that contains it, and there is no way to scroll right to see it. On the plus side, the "fit" button always brings it back to fit fully within the left and right boundaries (still requires scrolling down.)

Example

All the dashboards will have this problem. As an example of what is currently shown,

Aviary Version

0.9.0

Relevant environment information

NA

Improve top-level docs organization

Desired capability or behavior.

There is the table of contents widget in the upper right, which looks handy. But when you click on those links (eg, User Guide) , you go to a paragraph about the User Guide, not the links below for the user guide. And that paragraph doesn't even have a link to the section with the links.

We should add a table of contents to the top level pages for each section.

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

No response

Associated Bug Report

No response