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.

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

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.

TL;DR — Check out the proposed POEM_015 for details on how we think we can get rid of the need to manually specify an IndepVarComp in your models.

The IndepVarComp has been a part of OpenMDAO since the start of the version 1 era. In V2.0 its API changed a little bit, but it stayed mostly the same. Its job is to provide the variables the very start of any analysis. We will call these the “model inputs”. Despite providing something that is conceptually an input, the way it works in OpenMDAO is that these variables are the outputs of the IndepVarComp.

No doubt, many users have found this confusing at first though most seem to quickly accept it as wart on the API. A number have asked me why IndepVarComp outputs needed exist at all. It is admittedly confusing, since these model inputs end up being defined by calls to the add_output() method on the IndepVarComp component.

So why can’t you just work directly with the input variables? There is a mathematical reason anchored in the MAUD formulation that OpenMDAO is based on. There is also a practical reason. There is an ambiguity when multiple inputs are promoted to the same name at the group level, but each input has different units. If that promoted variable happens to be a model input, then the IndepVarComp output is used to resolve that ambiguity.

We’ve always thought it would be nice to get rid of the need for the IndepVarComp, but saw no way around it. As of OpenMDAO V2.10, a new addition to the API (which is specified in great detail in POEM_003) has provided us a a way forward. So now we’re proposing POEM_015 to accomplish this. POEM_0015 would let you go from this:

PRE POEM_015

import openmdao.api as om

class AGroup(om.Group): 

    def intialize(self): 
        self.options.declare('owns_dvs', default=True)
    
    def setup(self): 
        if self.options['owns_dvs']: 
            dvs = self.add_subsystem('dvs', IndepVarComp(), promotes=['*'])
            dvs.add_output('X', value=10, units='furlongs/fortnight')

        **do other stuff**
        . 
        . 
        . 

if __name__ == "__main__": 

    # To use G0 stand alond
    p = om.Problem()
    p.model.add_subsystem('G0', AGroup(owns_dvs=True))
    p.model.add_design_var('G0.X', lower=-1, upper=1)

    # To use G0 with some other component
    p = om.Problem()
    
    dvs = p.model.add_subsystem('dvs', IndepVarComp(), promotes=['*'])
    dvs.add_output('speed', -4, units='furlongs/fortnight')
    p.model.connect('speed', 'some_comp.speed')
    p.model.add_subsystem('some_comp', 
                          om.ExecComp('X=speed+3', units='furlongs/fortnight'))
    p.model.add_subsystem('G0', AGroup(owns_dvs=False))
    p.model.connect('some_comp.X', 'G0.X')

    p.model.add_design_var('speed', lower=-4, upper=-2)

POST POEM_015

import openmdao.api as om

class AGroup(om.Group): 
    
    def setup(self): 

        self.add_input('X', units='furlongs/fortnight')
       
        **do stuff**
        . 
        . 
        . 

if __name__ == "__main__": 

    # To use G0 stand alond
    p = om.Problem()
    p.model.add_subsystem('G0', AGroup())
    p.model.add_design_var('G0.X', lower=-1, upper=1)

    # To use G0 with some other component
    p = om.Problem()
    p.model.add_subsystem('some_comp', 
                          om.ExecComp('X=speed+3', units='furlongs/fortnight'))
    p.model.add_subsystem('G0', AGroup())
    p.model.connect('some_comp.X', 'G0.X')

    p.model.add_design_var('some_comp.speed', lower=-4, upper=-2)

Notice the lack of any IndepVarComp instances and the new add_input() method on group… looks better right? We think so!

Minor Backwards Incompatibility

There are some very mild backwards incompatible changes in POEM_015, and we’ve specifically called them out as well as proposed an release plan that would provide you with some deprecation warnings as a means of facilitating the upgrade.

So is this going to happen?

The leadership team (Rob, Eric, and Justin) think it’s a good idea… so it’s probably going to happen. We’ve pinged several users who’ve all expressed strong support. But we’re expressly asking for your opinions (positive or negative). Feel free to post comments or just thumbs up/down on the PR for the poem. We’ll keep an open mind, and if anyone raises any issues we’ll try to address them in the POEM before accepting it.

Version 3.0 is a major release, but not because of any massive new functionality. It’s primarily because we removed all the deprecated APIs from V2.10. So that means that this upgrade is definitely going to break some user code out there. But fear not, we’ve provided a handy-dandy upgrade guide for you! It gives side-by-side comparisons of any code you would need to change.

We’ve tried to make the upgrade path as easy as possible for you. So v2.10 and v3.0 are identical in terms of functionality, except for the deprecations. So the best way manage the upgrade is as follows:

1. Upgrade to V2.10
2. Run your models and make sure the answers are still correct
3. Modify your modes to remove all the deprecation warnings you see
4. Upgrade to V3.0 and re-check that your answers are still correct!

OpenMDAO V2.10 is out in the wild now. You can see the docs here. This will be the last major release of OpenMDAO V2.X. In other words, there will be no V2.11.

This is an important release for two reasons:

1. Lots of good new stuff is in there. Check out the release notes for full details, but here are some highlights:
   • Refactor of the AkimaSplineComp and BsplineComp into a single SplineComp
   • Improvements/slight tweaks to reverse-mode derivatives for distributed components
   • There is a plugin system now (a simple one, but you gotta start somewhere)
   • The N2 viewer now works for models that run in parallel
2. This release is intended to be a bridge to V3.0. That means that all or the things that are currently deprecated will be actually removed in V3.0. So to get ready for that update, what you need to do is first upgrade to V2.10, then modify your models to get rid of all the deprecation warnings. Then you should be ready to change to V3.0.

In 2019 the user base of OpenMDAO grew quite substantially. In order to better support the growing users base, we’re excited to announce a new leadership team for the OpenMDAO project:

• Rob Falck, Development Team Lead: overseeing the execution of development tasks including feature addition, bug fixes, and technology development for both OpenMDAO and the Dymos library.
• Eric Hendricks, Application Team Lead: supporting internal NASA users of OpenMDAO and overseeing execution of applications of OpenMDAO at NASA Glenn.
• Justin Gray, Project Lead: supporting external users of OpenMDAO, designing training materials, and overseeing the overall project.

Most of you have interacted with Justin Gray in the past and you’re more than welcome to continue to do so! However, please also feel free to reach out to Rob or Eric. The three of us will be working in close coordination to manage development, support users, and integrate user feedback into our development pipeline.

Here are some presentations from Eric, Justin, and Rob at the 2019 OpenMDAO workshop:

https://youtu.be/ivLfFGMK9d0
https://youtu.be/tTMftNL-02c
https://youtu.be/e52KczetQX0

Thank you to all who attended the workshop in person. The dev team got a lot out of your feedback and insights. We really enjoyed getting to know all of you in person and we’re looking forward to hosting the 2020 workshop and real-life optimal-control experiment (i.e. go-karting)

We’re very sorry for the delay, but due to some paperwork issues it took us until now to get final approval to post these online. So, with no further ado here are all the talks from the 2019 OpenMDAO workshop.

If you didn’t attend the workshop, you might consider watching all of the talks in sequence because a few of the later ones do reference earlier talks a bit. This is especially true for some of the demo talks, but most of the presentations from users do stand alone.

One more note. For 2019 workshop presenters were explicitly asked by the Dev Team to come and present any and all criticism they had about any aspect of the project. The specific goal was to gather the feedback for the Dev team and to open up a channel of communication between the devs and the community. So a number of talks were very frank about things they didn’t like, and the dev team greatly appreciated their candor!

We are proud to announce that OpenMDAO has won a 2019 R&D 100 Award in the Software and Services category. The development team honored to be given this recognition, but we can’t take all the credit. It is really thanks to the great support of our broad user community that we were able to show the impact and value of our work to the judging panel. So thank you to all of the OpenMDAO users who helped to make the framework into what it is today! We could not have gotten this far without you, and we look forward to working with you all moving forward.

Since the launch of OpenMDAO V2, we’ve seen a significant increase in the size and breath of the framework’s user base. To date, OpenMDAO’s development has been guided almost exclusively by the needs of the NASA projects that are using it and paying for its ongoing development. Fundamentally, that is going to change, however we recognize that our user based adds a significant amount of value to the project and that we need to address your needs as well. Therefore, we are going to be more formal and open about our development plans for your benefit.

What does that mean exactly? For starters, we are going to publish an annual development roadmap. This document, while not all encompassing or strictly binding, is intended to give the community a clear view of what the development team will focus on in the short and mid-term.

The initial version of the OpenMDAO 2020 Development Roadmap has been developed, and is currently the topic of a pull request to the main repo. It has been left as an open PR, to give you a chance to comment on it (via GitHub’s discussion threads and comment board in the PR itself). We will gladly consider any and all feedback from minor edits, to suggestions, and questions about adding or removing topics from the roadmap. The roadmap will be discussed in person during the 2019 OpenMDAO workshop on October 28 and 29, and we will finalize it by the end of November 2019.

We can not promise to accept everyone’s suggestions. The roadmap is not intended to be a document developed by the committee. However, we sincerely do want to hear your thoughts on our plans and are open to considering other topics if you can make a good case for why they deserve higher focus.

We want to highlight one particular part of the 2020 roadmap: Establishing A Community Contribution Process. A key part of letting the community contribute to OpenMDAO will be establishing formal rules that will govern all API and functionality changes to OpenMDAO (including our own changes!). This process will revolve around documents called POEMs. The current POEM rules are our first cut at this and we know they will need to evolve as we actually start to use it. If you think you might write your own POEMs in the future, we encourage you to take a look at what we have so far.