OpenMDAO Logo

An open-source framework for efficient multidisciplinary optimization.

August 30, 2022
by Justin Gray
Comments Off on 2022 OpenMDAO Workshop — Now with more Mphys!

2022 OpenMDAO Workshop — Now with more Mphys!

With the OpenMDAO community converging (pun intended!) on NASA Glenn Research Center for the
OpenMDAO Workshop, the Mphys community will be using the opportunity to hold a one day workshop on Oct. 26th. That is ​immediately following the OpenMDAO Workshop on October 24th and 25th.
Mphys is a collaboratively developed OpenMDAO library which is tackling
one of the major barriers to wider adoption of high-fidelity MDAO:
modularity through standardized interfaces for the coupling of multiphysics problems.

The Mphys Workshop will be an opportunity to learn more about multiphysics optimization and see the types of problems people are applying it to.
It will also be a chance to participate in the planning for the next steps of Mphys development.

Whether you’ve been collaborating with us on Mphys for years or will be new to Mphys,
we’re looking forward to seeing you there! Register here.
If you are not able to join us in person, we are planning to have a virtual attendance option.
Stay tuned for more information on that

Agenda

Day 1 Morning:
8:00am – Refreshments
8:30am – Welcome (Eliot)
8:45am – State of OpenMDAO development – Visualization Tools / N2, Reporting System (Rob)
9:55am – State of OpenMDAO development – Improvements to Interpolators & Why not to use Piecewise Linear (Jasa)
10:15am – Break
10:30am – State of Dymos development – New Dymos Features including: Scaling Report (Rob)
11:15am – Model-Based Systems Analysis & Engineering (MBSA&E) Effort and vision / overview (Eric)
12:00pm to 12:15pm – Lunch Starts
1:15pm – Training resources being developed (Jasa)
1:45pm – Poems, critical ones being worked on (#69 + others) (Rob)
2:00pm – AFRL/QUAD Aero-Propulsion system optimization (John Gallman/speaker TBD)
2:30pm – AFRL Effectiveness-Based Design: Current Work and Future Challenges (Christopher Lupp)
3:00pm – AFRL – creating a PTMS tool in OpenMDAO (Christopher Lupp)
3:30pm – Break
3:45pm – ONERA – FAST-OAD and WhatsOpt (Nathalie Bartoli)
4:15pm – Community Needs Discussion (Rob / Eric / Justin)
5:00pm – End of Day 1
Day 1 Evening:
6:00pm – Top Golf

Day 2 Morning:
ay 2 Morning:
8:00am – Refreshments
8:30am – Welcome (Eliot)
8:45am – UMich Presentations – broad view of theory, applications, and future MDO Lab work (Quim)
9:15am – UMich Presentations – OpenConcept (Eytan)
9:45am – UMich Presentations – OpenMDAO Solver Development / aeropropulsive work for Thesis (Anil Yildirim only available to talk Tuesday)
10:15am – Break + Exchange Store for Swag
10:45am – UMich Presentations – aeroacoustic optimization of eVTOL vehicles (Bernardo Pacini)
11:15am – MPhys Overview that will include MDO Lab contributions (Kevin / Justin)
11:45am – Open Discussion
12:00pm to 12:15pm – Lunch Starts
1:15pm – Iowa State University  – OpenMDAO & GMAT Integration (Gage Harris & Ping He needs to present tuesday)
1:45pm – University of Memphis – Design of Floating Offshore Wind Turbines  (Yong Hoon Lee, Assistant Professor, Mechanical Engineering)
2:15pm – Georgia Institute of Technology – (Graeme Kennedy)
2:45pm – Cornell – Topic TBD (Kapil Khanal, PHD student at Cornell)
3:15pm – Break
3:30pm – Open Discussion (Rob / Eric / Justin)
5:00pm – End of Day 2

July 25, 2022
by Justin Gray
Comments Off on In-person OpenMDAO Workshop October 24/25

In-person OpenMDAO Workshop October 24/25

The OpenMDAO workshop is returning to the NASA Glenn Research Center in Cleveland Ohio on October 24-25th. Signup for a seat now! We have a few open slots for external presentations, and you can propose a topic when you sign up.

This is an opportunity for users and developers to meet and have conversations about the next steps for OpenMDAO development, the capabilities you’d like to see added to the toolbox, and the challenges you’re facing with your current implementations. In our first workshop we presented some of the new tools we were building and the POEM process for how the community could interact with the Dev team and propose upgrades. The world got in the way of holding follow up in-person annual workshops, but we did host a 2020 reverse hackathon to maintain links to the community and get a better sense of the kinds or problems that you were facing. These were great opportunities for you, our valued users, to give the Dev team feedback on areas we could work on improving.

For this next in-person workshop we’d like to present you with some of the new tools we’ve built in the last four years and new training resources we are creating for you. Additionally, we want to hear from you about what stumbling blocks exist in your organizations that are preventing OpenMDAO usage. We also want to hear from our users about the cool new things you’re building in OpenMDAO and what are your biggest challenges to adopting OpenMDAO internal to your organization.

We look forward to seeing you in Cleveland to be a part of the OM community!

July 13, 2022
by Justin Gray
Comments Off on A new FREE text book on MDO!

A new FREE text book on MDO!

Professors Martins and Ning have published a new text book on multidisciplinary design optimization, and they’ve generously decided to give the digital version away for free!

There are good lessons on Problem formulation (Section 1.2), comparisons of gradient-based and gradient-free algorithms (Sections 1.4.1-1.4.3), and overview of numerical solver algorithms (Section 3.6), and a great introduction to various MDO concepts (Section 13) — including an introduction to the MAUD equations that underpin OpenMDAO (Section 13.2.6). If you want to learn more about some of the various techniques for taking derivatives of your numerical models, I highly recommend Chapter 6.

They’ve provide code and examples from the textbook in a companion github repo. You can learn more about how AD works, test out surrogate modeling methods, or try out a 10 bar truss example.

They also have a set of lectures based on the content of the book free on youtube

It takes a lot of work to put a text book like this together, and its a true service to the community to offer the digital version for free. If you find it useful in your work, you can thank the authors by citing their book:

@book{mdobook,
author = {Martins, Joaquim R. R. A. and Ning, Andrew},
title = {Engineering Design Optimization},
isbn = {9781108833417},
publisher = {Cambridge University Press},
month = {Jan},
year = {2022}
}



March 22, 2022
by Justin Gray
Comments Off on You want reports? I’ll give you reports — V3.17

You want reports? I’ll give you reports — V3.17

OpenMDAO can produce a bunch of very useful report like the N2 diagram, and the scaling report. However, we noticed that a lot of users didn’t know they existed, or did know but didn’t think to generate them during development/debugging. So we’ve decided to automatically make as many reports as we can.

There are a bunch of user controllable settings you can configure to get the exact reports you want, set where they get stored, or turn them off completely.

There are now also some new ipython widets that you can use to build sort-of-gui like things, and to more quickly plot the results of your case databases.

Check out all the details in the release notes

November 19, 2021
by Justin Gray
Comments Off on OpenMDAO V3.14: I feel the need — the need for speed

OpenMDAO V3.14: I feel the need — the need for speed

OpenMDAO is used to design airplanes, so I think the Top Gun reference is appropriate.

OpenMDAO V3.14 is chocked full of speedy goodness. You can check out the full release notes for all the details, but I wanted to highlight two key developments that each give speed in their own special way

Faster Structured Interpolation

The in-house OpenMDAO Applications team had found that some of their Dymos applications were spending excessive amounts of time computing interpolations from data tables from the StructuredMetaModel component. We’ve known for a while that our interpolation code wasn’t super fast. In fact we specifically chose an implementation that we knew to be slower, because it offered N-dimensional capability.

However the bottlenecks in our own work got bad enough that we felt it was time to add some less flexible, but a lot faster option. The new interpolants only work for a fixed dimensionality (i.e. 1D or 3D), but they are about 100x faster. We have a new naming scheme, laid out in POEM 058. Any interpolation method that starts with its dimension (e.g. 3Dlagrange3) is one of the new fast ones. We started off with 1D and 3D interpolants because these were the ones we needed. We plan to add some 2D ones in the future though.

If you are using StrucuturedMetaModel, these new methods are worth a try for sure. If you are using cubic or scipy-cubic then I highly recommend that you give lagrange3 a try, or the 3D-lagrange3 if you are using 3D data. You’ll get a significant speed up either way.

Functional Component API

We’ve introduced a new component API, that can possibly help you code a bit faster. This feature is so big, it spans two whole POEMs: 056 and 057. If you’re going to use the new API, you should definitely read both poems.

Just to be clear, this new API is not going to replace the existing class based one but will live along side it. The new API, as the name suggests lets you build components using standard python functions. It works with both explicit functions and implicit ones

import openmdao.api as om
import openmdao.func_api as omf

def func(a=2.0, b=3.0):
    x = 2. * a
    y = b - 1.0 / 3.0
    return x, y

f = (omf.wrap(func)
        .defaults(method='cs')
        .declare_partials(of='x', wrt='a')
        .declare_partials(of='y', wrt='b'))

p = om.Problem()
p.model.add_subsystem('comp', om.ExplicitFuncComp(f))
p.setup()
p.run_model()
J = p.compute_totals(of=['comp.x', 'comp.y'], wrt=['comp.a', 'comp.b'])

If you don’t like the boiler plate of the class APIs, you may find this API to be a lot cleaner. If you happen to have a library of existing python functions, you’ll probably find this API to be a nice way to integrate that into OpenMDAO without having to write any class wrappers yourself.

The most fundamental motivation for this new API is that it more easily supports algorithmic differentiation (AD). AD relies on functional APIs, and OpenMDAO’s classed based API was always a tough fit. So if you’ve wanted to try out JAX or pyTorch then this new API is for you!

Adding analytic derivatives offers huge computational benefits, but is often a very slow development step. We’ve also found that when taking derivatives by hand, we tend toward smaller components to keep the derivations simpler.
Our goal with the functional API is to help alleviate the development bottleneck of derivatives, and offer a path for having larger chunks of engineering code in single components.

October 8, 2021
by Justin Gray
Comments Off on Announcing OpenMDAO V3.13

Announcing OpenMDAO V3.13

OpenMDAO V3.13.0 is live. You can read the release notes for complete details, but there are a few key changes worth highlighting:

There are some minor improvements to the way OpenMDAO computes relative step sizes. Full details in POEM 051, but in short you can now ask for step sizes for array variables on a per element basis or from an avg array value. The old method has been kept as well for backwards compatibility, though it is deprecated and will be removed in a later version.

POEMS 053 and 054 summarize a change to the way src_indices work. It’s a bit subtle, so I encourage you to read the POEMS. The key take away though is that src_indices behavior now matches what numpy does with array indexing. This is a backwards incompatible change, though you can can check for its impact by using OpenMDAO V3.12 which will give you a clear deprecation warning.

Another small tidibit: We’re starting to work on on speeding up the interpolation routines. We’re not done yet, but we have some early progress. Check out the akima1d and trilinear interpolation methods if you’re looking for speedier table lookups.

July 16, 2021
by Justin Gray
Comments Off on V3.10 – OpenMDAO on Google Collab!

V3.10 – OpenMDAO on Google Collab!

We revamped our docs based on jupyter notebooks, so you can run all our docs code on Google Collab. Just look for the rocket-ship icon in the upper right corner of a docs page!

That will take you to a live notebook of the same docs page so you can try things out in your browser without installing anything locally. Check out the paraboliod optimization example running in the cloud.

New features and APIs

V3.10 has a lot of new features, APIs, and some important deprecations. You can get all the details in the release notes, but here are the highlights.

  • Major redesign of the APIs for distributed components and variables. See POEM_046 for a lot of details. You now specify distributed independently on each variable.
  • We now use val everywhere (before there was a mix of val and value. The older keyword has been deprecated, which gives you a chance to update before the 4.0 release. See POEM_050.
  • An error is raised if you run check_partials and the same settings are used for both the approximated derivatives and the check.
    Note: We found a surprising number of cases where this was happening. The check is useless in this case. So You might get an new error, but you should be glad that you’re finding what is effectively a bug in your code.
  • You can now use “fancy” indices (i.e. multi-dimensional slices) for constraints
  • There is a new flag called under_finite_difference in components to tell you when you’re being finite-differenced (mirrors the existing under_complex_step flag)

New Logo

Have you noticed out new logo? Feel free to stamp it on any thing you like!

OpenMDAO Logo

June 21, 2021
by Justin Gray
Comments Off on value -> val

value -> val

OpenMDAO V3 is a little inconsistent with it use of val and value as keyword arguments to different API methods. We are going to fix this in V4 by standardizing on val for everything. This change is proposed in POEM 050.

Unfortunately, that is going to cause some “minor” backwards incompatibility for any user code that specifically called out the value keyword. So in V3.11 and higher, we’ll keep backwards compatibility with the old keyword and give you a deprecation warning. This should provide a smooth upgrade path, since you can try out the new code and work to remove the deprecations.

We recognize that these kind of API changes are modestly annoying, but we feel they are a net positive in the long run because don’t have to guess which keyword to use where. If you don’t agree with us, or have an alternate proposal then feel free to chime in with comments or PRs on POEM 050.

May 11, 2021
by Justin Gray
Comments Off on Have a look at POEMs 48 and 49

Have a look at POEMs 48 and 49

Introducing two new proposals for OpenMDAO enhancement (POEMs), for your consideration. Both are fairly low impact, though POEM 049 does propose removal of some unused APIs.

POEM 048: MetaModelSemiStructured Component

OpenMDAO Already has both structured and unstructured metamodel components. You might think that those two are the all you would ever need, but there is a semi-structured data format that is fairly common (at least in the aircraft design world). This kind of data is useful for things like performance tables where you can’t necessarily get valid data on a full structured grid. The data looks like this:

x = 1
    y = 1, 2, 3, 4, 5, 10, 11
    z = 10, 20, 30, 40, 50, 100, 110
x = 2 
    y = 1, 2, 3, 4, 5, 10, 11
    Z = 60, 80, 100, 200, 220
x = 3
    y = 1, 2, 3, 4, 5, 10, 11
    z = 300, 330, 120, 150, 300, 330

The independent values are always monotonic, but the dependent data does not necessarily have to be. Despite being non-structured, the monotonic inputs allow for the same kind of recursive interpolation that OpenMDAO’s MetaModelStructuredComp uses.

POEM 049: Removal of the matrix-matrix derivative APIs.

While this POEM does propose a backwards incompatible change, to the best of our knowledge no one is actually using these APIs. If you are using them and want to object to their removal, now is your chance! Please comment on the POEM PR and provide us an example use case where you really need to have it.

These APIs date back to early OpenMDAO V1 days when performance for serial components that provided a dense partial derivative Jacobian were very poor due to some slower internal data formats and the lack of a DirectSolver. At that time, our solution involved augmenting the matrix-vector product APIs with a matrix-matrix product API that would skip a particularly slow OpenMDAO for-loop. It worked to an extend, but was not a very general solution.

Today we have both sparse and dense assembled Jacobians that provide better overall performance in a wider range of use cases. We believe these older matrix-matrix features are not needed, and removing them will simplify several places in the code and make our linear solvers more easily understandable.

If you think otherwise, please speak up. We’d appreciate you providing a use case that shows how the matrix-matrix APIs are significantly faster than using the an Assembled Jacobian and LinearRunOnce or DirectSolver.

May 4, 2021
by Justin Gray
Comments Off on V3.9.1

V3.9.1

Version 3.9’s biggest change is the new serial/distributed api for variables. We now allow you to label individual variables as serial or distributed, which ultimately clears up a lot of confusion when working with distributed memory computations. All of the details are covered in POEM 046. There are lots of other changes in this release, including performance improvements and a few other new features. You can read the release notes for a full accounting, but here are the highlights.

ExecComp Improvements

A small but useful update was made to ExecComp. You can now call the add_expr method on that Component to create new outputs. This change makes the ExecComp API look more similar to the BalanceComp and EQConstraintComps. It also makes for slightly cleaner inputs when you’re using a lot of expressions in your model.

Quieter Warnings

Were you annoyed by the warnings about missing MPI4py or petsc4py? You were not alone! We’ve specifically quieted those two, and you’ll only see them if you try to use those features without the proper packages in stalled. More generally though, we reworked our whole warnings system.

OpenMDAO gives you a lot of freedom, and sometimes that lets you get into trouble. We’ve tried hard to add clear error/warning messages to cover these situations. However, the net result is that sometimes your runs can get kind of noisy. So we re-built our warning system to be more organized, and gave users the ability to limit which ones actually get reported. Check out the docs for the new warning system.

Try to remember, with great power comes great responsibility 🙂 When you suppress warnings you might be missing helpful information. We recommend you leave most warnings on during development and turn them off only for production runs.

Fork me on GitHub