OpenMDAO Logo

An open-source framework for efficient multidisciplinary optimization.

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

SUBSCRIBE HERE

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!

SUBSCRIBE HERE

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', 
                                                 x={'units':'ft'}, 
                                                 y0={'units':'ft'}), 
                           promotes=['*'])        
        self.add_subsystem('comp1', om.ExecComp('y1 = x**2', 
                                                x={'units':'m'}, 
                                                y1={'units':'m'}), 
                           promotes=['*'])

        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.model.add_objective('g0.y1')

prob0.driver = om.ScipyOptimizeDriver()

prob0.setup()

# this will find x=0 to minimize y1=x**2
prob0.run_driver()
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',
                                                  x_prime={'units':'inch'}, 
                                                  x={'units':'inch'}))
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.model.add_objective('g0.y1')

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

prob1.setup()

# this will find x=0 to minimize y1=x**3
prob1.run_driver()
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 admin
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 admin
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.

March 14, 2020
by admin
Comments Off on Say goodbye to IndepVarComp… POEM_015

Say goodbye to IndepVarComp… POEM_015

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.

March 10, 2020
by admin
Comments Off on OpenMDAO V3.0 is out

OpenMDAO V3.0 is out

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!

February 27, 2020
by admin
Comments Off on OpenMDAO V2.10, now get ready for V3.0

OpenMDAO V2.10, now get ready for V3.0

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.

Fork me on GitHub