OpenMDAO Logo

An open-source framework for efficient multidisciplinary optimization.

October 2, 2020
by Justin Gray
Comments Off on OpenMDAO V3.4.0

OpenMDAO V3.4.0

OpenMDAO V3.4.0 has been released. Check out the full list of changes in the release notes. One change nice new feature is “noisy warnings” if AnalysisError is raised inside an optimization loop. Many optimizers can catch these errors and recover by backtracking on the line search, but previously this all happened silently. Now you’ll see some feedback on what went wrong in standard output. You can use that information to find the problem and potentially alleviate it for future runs.

I also want to highlight the new experimental feature that lets you size inputs based on their connection. The docs are a little bare at the moment, but we’re working on updating them. The gist of this though is that you can now have variables in components that are sized by the thing they are connected to!

As you can imagine, this is a pretty powerful new feature but it also has a lot of potential to cause confusion. So we’re marking it as experimental and we’re going to see how the user community likes it! We welcome all feedback here.

The credit for this feature goes to Josh Anibal from the University of Michigan MDO Lab. He submitted POEM 22 to propose the idea. Then he (unexpectedly) provided us with a prototype implementation in OpenMDAO. Josh’s prototype was absolutely critical in making this feature happen. The dev team didn’t see the same vision that he did, and we couldn’t get past some implementation challenges that he saw through clearly. We were about to reject the POEM, till we saw his solution.

One of the fundamental goals of the OpenMDAO project is to help spread innovations from MDO researchers to the user community more quickly. For me personally, Josh’s contributions are a major milestone towards achieving that goal. He’s definitely not the first person to make code contributions to OpenMDAO, but he’s the first to provide a fundamental change to the setup stack which allows users to build models differently.

Anyone who uses this feature has Josh to thank, and I look forward future contributions by him and others. One day, I hope we’ll have a huge list of people to thank!

September 4, 2020
by Justin Gray
Comments Off on OpenMDAO V3.3.0 released

OpenMDAO V3.3.0 released

OpenMDAO V3.3.0 is live. You can read the release notes for full details, but the major new feature in this release is the ability to query for input/output metadata from within the configure method. This introspection feature allows you to build much more reactive groups that can update themselves based on data from their children. For example, you can look at the size of an output in one component, then create tell some other component to create an input of the same size.

With this update, you now have a lot of flexibility in the way you build models. Groups now have two key methods that are used in model building setup and configure. setup is a top-down recursion where you can construct your model hierarchy. configure is a bottom-up recursion where you can inspect your children and then make changes to the I/O of other children accordingly.

We’ll be making good use of this new feature in a new version of Dymos in the very near future! We hope you find the feature useful too.

September 1, 2020
by Justin Gray
Comments Off on New Lecture: Sparse Derivatives for Vectorized Outputs

New Lecture: Sparse Derivatives for Vectorized Outputs

I’ve posted a new lecture that provides an introduction to sparse partial derivatives. This lecture uses a simple beam moment calculation, with vector inputs and outputs with fairly sparse partial derivatives.

The derivatives are a little tricky to get right, and I walk through how the code structure should look and ways to debug as you go.

September 1, 2020
by Justin Gray
Comments Off on 2020 OpenMDAO Reverse Hackathon

2020 OpenMDAO Reverse Hackathon

The 2020 OpenMDAO workshop will be a reverse hackathon, that will be held October 19 – 30. This will be a virtual, asynchronous event, with no cost to anyone who wants to participate.

Check out the github repo for the event, to submit your ideas

Our goal for this event is to spur the adoption of the most advanced features in OpenMDAO by the broader user community, so we are explicitly offering to help you upgrade your models!

What is a reverse hackathon?

In a normal hackathon, the organizers pose the problems and the participants solve them. We’re flipping that around.

You pose challenge problems to the OpenMDAO dev team. We’ll solve as many of them as we can for you! On top of that, we’ll give a write-up on our solution with important details about what we did and why.

While we’re in the middle of solving your problems, we’ll likely have lots of questions. So we expect there to be lots of discussion back and forth.

Critical Dates:

  • Initial Project Submissions Due: October 1st, 2020
  • Final Project Submissions Due: October 19th, 2020
  • RevHack 2020 Presentations: October 30th, 2020

Besides the due dates for project submissions, the other date to note is the 30th. That’s when we’ll be posting some talks on important topics for the community, including a summary of the most important new features developed in 2020 and the 2021 development roadmap.

How will the devs pick which ones to work on?

It is critical that your problem is scoped so it can be tackled within the two week window. It can certainly be shorter than 2 weeks (we’re totally fine solving smaller problems!) but it can’t be longer than that. That’s not a lot of time, so we’re stipulating that we won’t add any new features to OpenMDAO. You must submit a problem that can be solved with current features!

We’re also asking for a well defined request such as:

  • Convert the provided code to an OpenMDAO component/model
  • Differentiate the given component
  • Profile and speed up a given model
  • Stabilize an optimization problem so it finds a solution more robustly
  • Generate a data-post processing script (e.g. plots Y vs X over the entire iteration history) for a model that is being executed in a strange way

If you have an interesting problem that you would like to work on, but you’re not totally sure what the best request to make would be, that’s ok! You can submit a less well defined idea and we’ll try to work with you to narrow it down a bit.

Here are some suggestions to get you started here are a few broad ideas:

  • Pushing the boundaries: a problem where the solution will extend the capabilities of OpenMDAO by creating a new technique for using the framework
  • Software design: finding the best way to integrate a modular analysis into OpenMDAO or convert a non OpenMDAO analysis into an OpenMDAO component
  • Derivatives: Differentiating a tricky component, or speeding up the performance of your existing derivatives implementation with advanced coloring features.
  • Performance: Identifying bottlenecks and speeding up code that is already implemented in OpenMDAO
  • Numerical Stability: Improving the robustness of a nonlinear solve or optimization so that it gets a converged answer more frequently

Problem Requirements:

Open Source: The number one most important requirement is that all the code associated with the problem needs to be open source. That includes any and all dependencies that your code has. It’s ok if you need a few external libraries as long as they are open source!

Concise: Please keep your code as short as possible. We suggest a soft limit of 1500 lines of code (excluding external dependencies). We won’t automatically reject the problem if there is too many lines, but we’ll be hesitant. We’re asking you to put some effort into crafting a concise chunk of code for us to work with and others can relatively easily digest.

Tests: Your submission should include some tests that show us how to run your code and what the expected answer should be (even if its not currently getting the right answer).

How do you submit a problem?

You submit a pull request to the RevHack2020 repository. Add a new folder, and in it include whatever code is needed along with a readme file that describes the code and the specific, well defined request you have.

It’s ok if your initial pull request isn’t fully baked. The code doesn’t need to be there at first. You could have only a readme that spells out what you’re thinking. The devs will review your PR and respond, asking questions or making suggestions.

We’ll we’re likely to pick your project to work on, or if we think your proposal is too narrowly focused and won’t offer enough value to the broad community. Preparing a good problem that is concise, but has the details necessary will takes time. We’re happy to give you a strong indication of whether your time will be well spent or not.

Want to do some of the hacking yourself?

Think you have what it takes to tackle one of the submitted problems yourself? You’re more than welcome to! You can comment on the PRs with the proposed problems just like the devs will. The more the merrier!

August 25, 2020
by Justin Gray
Comments Off on New OpenMDAO Mailing List

New OpenMDAO Mailing List


We’re starting a mailing list for announcements by the dev team. It will not be too noisy, but you can expect to hear from us whenever we make a new release, post a new POEM, or want to invite you to an event. If you want to stay up to date with the latest OpenMDAO news, go here to subscribe.

We’ll be making an announcement about a virtual OpenMDAO community event in the near future, so subscribe to the mailing list to make sure you don’t miss out!


July 22, 2020
by Justin Gray
Comments Off on OpenMDAO V3.2 is live and it’s a big deal!

OpenMDAO V3.2 is live and it’s a big deal!

OpenMDAO 3.2 is live. You can read the details in the release notes, but I want to specifically highlight something that all current users will notice. You no longer need to manually create any IndepVarComps.

Following POEM 015, we’ve implemented an automatic IndepVarComp feature that means in the vast majority of use cases you do not need to manually create them.

The IndepVarComp was always a bit awkward from a user perspective, but due to some of the details in the math that powers OpenMDAO it is necessary that every single variable have an ultimate source associated with it. The IndepVarComps served as that source for the independent variables in your models.

Since they were necessary, we grew to accept this idiosyncrasy of OpenMDAO syntax. However, recently a series of other updates to setup stack (POEM 003 and POEM 009) made it possible to create I/O in components much later in the setup process. These improvements were not made for the purposes of eliminating manually created IndepVarComps, but they were crucial to being able to add this new functionality.

We’ve made the new feature highly backwards compatible, so your old models should still work with the manually created IndepVarComps in place. For that matter, if you so choose you are still free to create them wherever you like. There are a few corner cases where backwards compatibility was not possible, and if you run into anything that the devs haven’t foreseen please don’t hesitate to reach out!

Upgrade Guide

To help you adopt the new coding style, we’ve put together an upgrade guide for you. This covers all the common cases that we could think of. We’ve also updated all of the docs to use the new auto-ivc capability in all the examples.

There is one use case for the new functionality that I am most excited about. You can leverage the new apis to create pass-through style variables in your groups. The variable name can either be used directly as a design variable or be connected into from some other source.

Here is a contrived example that demonstrates the basic concept. In the first use case, “g0.x” is used directly as a design variable. In the second use case we connect “upstream.x” to “g0.x”. Note that there is no IndepVarComp anywhere in these examples.

import openmdao.api as om

class FancyPassthroughGroup(om.Group): 

    def setup(self): 

        self.add_subsystem('comp0', om.ExecComp('y0 = 3*x', 
        self.add_subsystem('comp1', om.ExecComp('y1 = x**2', 

        self.set_input_defaults('x', units='cm', val=3.0)

# First usage of the fancy group is to set up a direct 
# optimization of the group: minimize y1 w.r.t x
prob0 = om.Problem()
prob0.model.add_subsystem('g0', FancyPassthroughGroup())
# note: this design variable will be in 
#       units of `cm` following the input default
prob0.model.add_design_var('g0.x', lower=-10, upper=10) 

prob0.driver = om.ScipyOptimizeDriver()


# this will find x=0 to minimize y1=x**2
print('x: ', prob0.get_val('g0.x')) 
print('y1: ', prob0.get_val('g0.y1')) 

# Second usage of the fancy group is connect add a modifier 
# upstream and connect that into x, then optimize the w.r.t 
# the new variable
prob1 = om.Problem()
prob1.model.add_subsystem('upstream', om.ExecComp('x = x_prime + 3',
prob1.model.add_subsystem('g0', FancyPassthroughGroup())
prob1.model.connect('upstream.x', 'g0.x')
# note: this design variable will be in 
#       units of `inch` following units on the upstream input
prob1.model.add_design_var('upstream.x_prime', lower=-10, upper=10) 

prob1.driver = om.ScipyOptimizeDriver()
prob1.driver.options['tol'] = 1e-6


# this will find x=0 to minimize y1=x**3
print('x_prime: ', prob1.get_val('upstream.x_prime'))
print('y1: ', prob1.get_val('g0.y1'))

June 12, 2020
by Justin Gray
Comments Off on Come to a discussion about MDO Community Test Problems

Come to a discussion about MDO Community Test Problems

Despite AIAA Aviation 2020 moving to a virtual format, there is still a chance for some “in person” discussion via video conferencing software.

On Monday June 15th, at 2:00 Eastern Time, I’ll be leading a discussion about development of a new MDO test problem suite. There have been two versions of previous test suites, but they haven’t gained wide adoption. In my opinion that was due, in large part, to a lack of reference implementations provided with the test suite.

In recent years many new open source disciplinary analysis tools and MDO algorithms have been releases. These can provide the basis for reference implementations of test suite problems. Along with social coding tools like GitHub we have the necessary ingredients to provide a test suite that has realistic, challenging problems with ready-to-run reference implementations.

If you’re registered for the conference, I hope you’ll attend and participate in the discussion. One nice thing about the virtual format is that all of the presentations are pre-recorded and posted early. So they are already up. I’ve linked to each presentation here, but you’ll only be able to see them if your registered for the conference.

We have 4 different proposals for new problems:

  1. MDO Problem Suite V3: We have the technology, we can rebuild it
  2. Design of a high-bypass turbofan engine using OpenMDAO + PyCycle
  3. An Aeropropulsive Test Problem: Coupling CFD Simulations with a Propulsion Model
  4. Wind Farm Optimization Benchmark Problems
  5. Multi-fidelity aero-strutural shape optimization test problem

May 1, 2020
by Justin Gray
Comments Off on OpenMDAO V3.1.0 Released

OpenMDAO V3.1.0 Released

V3.1.0 has quite a few new features and a few small tweaks to the API (we’ve deprecated the old APIs). You can read all the details in the release notes, but here are a few highlights:

  • we tweaked the definition of light year in our units lib to match the international standard (it was a little off before).
  • We added the ability to set units when you add design variables, objectives, or constraints to a driver
  • We cleaned up the options and details in the case recording, and made some significant improvements to the docs for case recording. There two new tutorials (basic and advanced) and a reorganized feature guide too
  • The N2 viewer has gotten a bunch of updates.

We made this release on May 1 2020. Our intention is to keep to a monthly release schedule from now on, in order to get the updates from the development branch released more regularly. So you can expect another release around June 1, 2020.

April 22, 2020
by Justin Gray
Comments Off on YouTube lectures on various optimization topics

YouTube lectures on various optimization topics

When working in the office, I rely heavily on white boards for technical problem solving. Thanks to the the pandemic I’m working from home and deprived of my critical white boards. So I’ve been forced to “innovate” and learn to use a tablet and stylus instead… oh poor me, right?

Im not complaining at all, just looking for the solver lining here. Tablets are actually pretty easy to record on, and thanks to some tips from colleagues who are doing a lot of remote teaching these days I managed to cobble together a reasonable set up. So now, I can record lectures on optimization related topics and post them on the internet for all to comment on — be gentle, I’m delicate!

Practical Optimization Topics

I don’t have a detailed plan for a complete course yet, so for now I am recording topics that I end up having to explain to others anyway. These will mostly be practical topics that come up often with new users, though occasionally they might cover something more advanced about the guts of OpenMDAO. Im not going to duplicate the existing OpenMDAO documentation, but rather try to supplement it.

The first two lectures are already posted to the youtube channel! You can subscribe to the channel so you get notified when I post new lectures. I hope to do one a week.

Comparing the chain-rule to the unified derivative equations

Specifying sparse partials for vectorized components

April 1, 2020
by Justin Gray
Comments Off on Stay healthy, keep calm and optimize

Stay healthy, keep calm and optimize

TL;DR We built an optimization problem using OpenMDAO, Dymos, and the basic SIR model. The code is on github here.

The corona virus pandemic is being tracked with a set of mathematical models, that are tuned to match the data on the virus. They predict the number of deaths we’ll see and health officials are relying on them to track the “curve”, and to figure out when it will be safe for us to stop social distancing.

However, we’ve read a number of articles that clearly indicate that the modeling isn’t simple, or even widely agreed upon. One of the models being used is the Susceptible-Infected-Recovered (SIR) model. The SIR model is actually just an ODE with a few key parameters that can be tuned to match the data.

When we saw that, we thought that perhaps some of our optimization tools could be used to attack this problem. Dymos is a library we’ve written specifically to deal with time-integration and optimal-control problems. So Tristan Hearn, a member of the OpenMDAO Application team, has built a basic implementation and showed that it could be used to do optimization on defining the counter measures.

Now for a disclaimer

We are by no means infectious disease experts, but rather pracitioners of numerical optimization and multidisciplinary systems analysis. These models have not been tuned to match the data, and are by no means an accurate representation of the current situation anywhere in the world!

The Model

You can check out all the details on his pandemic repository. The code is set up to produce results like this:

The blue line, represents the number of infected people. This is the “curve” that we’re all trying to flatten through social distancing. The goal is to lower the height of that hump, in order to not overwhelm our health care system.

By doing that, we can hopefully minimize the height of the red line. The red line represents the number of deaths from the pandemic. This is the scary one.

We don’t know if this model is useful to any actual infectious disease experts. Most probably, it won’t. But to be frank… it just feels good to be applying our skill sets to this world problem. If anyone out there wants to mess with the model, feel free!

Here are some things that need to be done:

  • Parameter Identification: The model needs to be matched to real data. This isn’t easy. The data is different from state-to-state and county-to-county… this is part of what makes this so hard. See this fivethirtyeight article that talks about all of the uncertainty there is.
  • Uncertainty quantification: The OpenMDAO team doesn’t have a lot of UQ experience, but we do have some of the most flexible and most scalable ODE optimization tools around. We suspect there are some good ways that UQ could be brought to bear here. If anyone wants to work on that, feel free to reach out.
  • Model extension: Again, we’re not infectious disease experts. Those who are may be using more advanced models than this … or perhaps using a more complex version of this where different regions are modeled independently and interact with each other. We just don’t have the experience to know what to do here!

So if you’re looking for some interesting optimization problems to keep your busy during these strange times, check out Tristan’s pandemic repository.

Fork me on GitHub