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.

V2.9.1 is a patch release that address a few small issues that coincidentally were all found on the very same day that we released V2.9.0 (darn you Murphy and your law!)

First, we found a small reversion in the line search. Through some refactoring, one of the default settings for the type of bounds enforcement in the ArmijoGoldstein line search accidentally changed, and we patched it back to the original default. So be warned, that if you updated to 2.9.0 and are using that line search you might see some weird behavior. If you go to 2.9.1 though, it should be all good.

The other issues are really minor and probably not stuff regular users will run into. You can see all the details in the release notes.

The V2.9 release is live now, and it is a fairly substantial release. Most of the stuff is subtle changes or under the hood improvements, but taken as a whole there is a lot in this release.

See the release notes for full details, but here are some highlights:

• Metamodel visualization via the openmdao mm_view command line tool (you really should check this one out!)
• A whole bunch of small solver improvements
• Modest improvements to the CaseRecorder functionality to make it work just like the problem interface (e.g. get_val and set_val methods)
• Efficiency improvements in reverse mode data transfers and derivatives solves with the DirectSolver
• Big efficiency improvements to StructuredMetaModel

There are also a few backwards incompatible api changes as well. We’ve deprecated things wherever we could to (hopefully) make it as painless as possible for you all.

NASA Glenn Research Center will be hosting a public OpenMDAO workshop on October 28 – 29th, 2019 in Cleveland Ohio. We will be meeting at the Ohio Aerospace Institute.

The primary goal for the workshop is for the broad user community get a chance to interact directly with the OpenMDAO development team in order to discuss the current and future development of the framework. We want to focus on topics surrounding current functionality and future development. In other words, we want to talk about what is working and what is not working right now, and hear about things the community would like to see for future development. Your input will help us figure out our long term development roadmap, so this is your chance to have a voice!

Click here to register for the workshop. There is no cost to attend the workshop, but we will be offering an optional catered lunch each day that will cost ~$30 (total for both days).

We are looking for community members who want to give 15 minute talks about their use of OpenMDAO. There is a space on the registration form to indicate if you would like to present. We have space for between 8-12 talks in the schedule, though if there is a lot of volunteers with good topics we will potentially devote more of day 2 to additional talks.

We need to have a head-count for the workshop, so registration is going to close on September 1st, 2019. Please register ASAP and if you are interested in giving a talk then REALLY register ASAP so we can start to figure out the presentation schedule.

Schedule:

October 28:

8:50 Opening Remarks (Justin Gray)

9:00 Overview of evolution of derivative computation, coupled adjoints, and OpenMDAO (Joaquim Martins)

9:30 Level-Set Topology Optimization in OpenMDAO with Cython (Carolina Jauregui)

10:00 Using OpenMDAO as a collaboration platform for a large design team (Eric Hendricks)

10:30 Exploration of active aeroelastic tailoring on the D8 aircraft in OpenMDAO (Tim Brooks)

11:00 Challenges and encountered when wrapping ParOpt and TACS in OpenMDAO (Graeme Kennedy)

11:30 Growing pains for building WISDEM on OM (Garett Barter)

— lunch —

1:00 Demo: Introduction to the openmdao command line tool (Bret Naylor)

1:30 Demo: Using the N2 diagram to inspect your model (Ken Moore)

2:00 Demo: Two new UI concepts for N2 diagram (Herb Schilling)

2:30 Demo: Using MMView to inspect a metamodel (Danny Kilkenny)

3:00 Building an automated install script for the OpenMDAO Dev Cluster local cluster (Tad Kollar)

3:30 OpenMDAO Development Roadmap (Justin Gray)

October 29:

9:00 Modeling Fluid Structure Interaction with CFD in OpenMDAO (Anil Yildirim)

9:30 How Supaero and Onera use OpenMDAO for MDAO Research (Joseph Morlier)

10:00 OpenMDAO Usage for Launch Vehicles (Mathieu Balesdent)

10:30 Orchestrating Model-Based Systems Engineering with OpenMDAO (Santiago Balestrini)

11:00 Large-scale wind farm optimization and integrating Julia with OpenMDAO (Andrew Ning)

11:30 Using OpenMDAO and OpenAeroStruct in the classroom (John Jasa)

— lunch —

1:00 Demo: How to setup and run a pyCycle model (Eric Hendricks)

1:30 Tutorial: Building Models with Analytic Derivatives (John Jasa)

2:30 Tutorial: Solving Multidisciplinary optimal control problems with Dymos (Rob Falck)

Any questions can be directed to justin.s.gray “at” nasa.gov

This is a modest release, with a few bug fixes and small list of relatively minor added features. See the release notes for all details.

The biggest change in 2.8 is actually a roll-back of a warning message that was added in 2.7. If you upgraded and started getting a lot of new warnings about promoted inputs that were connected in a funky way… well, we made that go away. It wasn’t helpful and we got a lot of user feedback that we shouldn’t show it by default — and we do occasionally listen to user feedback 🙂

The other change worth noting is not technically a new feature, but rather a new convention. We now recommend that users do the following to import the OpenMDAO API:

import openmdao.api as om

This is a much more compact and convenient way of handling the imports. In hindsight, this is the obvious way of doing this, but since we lack a time machine all we can do is use this better approach from now on. No need to change all your existing scripts if you don’t want to, the old way still works! We’ve updated all our docs to use it though, and we’ll use it for everything going forward.

We hope this new release is useful to you!

The NASA OpenMDAO development team would like to congratulate the 2019 AIAA Multidisciplinary Design Optimization Technical Committee student paper competition winners!

1) Anil Yildirim: Aeropropulsive Design Optimization of a Boundary Layer Ingestion System

2) Sicheng He: A Coupled Newton-Krylov Time Spectral Solver for Wing Flutter and LCO Prediction

3) Payam Ghassemi: Adaptive Model Refinement with Batch Bayesian Sampling for Optimization of Bio-inspired Flow Tailoring

See you next year!

For Aviation 2020, there will be another student paper competition. Again, first prize will be $2000, second prize will be $1000, and third prize will be $500. If you’re thinking of submitting your work to that, you should definitely have a look at these papers!

OpenMDAO 2.7.0 has been released.

Here are the release notes listing the new features, bug fixes and a couple of backwards-incompatible changes:

New Features:

• You can now define guess_nonlinear method at the group level
• New documentation added about the N2 diagram usage
• Significant improvement to documentation search functionality (by default, only searches the feature docs and user guide now)
• Improvements to support for complex-step across a full model (specifically when guess_nonlinear is implemented)
• Derivatives:
  • Improved support for full-model complex-step when models have guess_nonlinear methods defined
  • **Experimental** FD and CS based coloring methods for partial derivative approximation. Valuable for efficiently using FD/CS on vectorized (or very sparse) components
• Solvers:
  • `Solver failed to converge` message now includes solver path name to make it more clear what failed
  • Improved pathname information in the singular matrix error from DirectSolver
  • Directsolver has an improved error message when it detects identical rows or columns in Jacobian
  • NonlinearGaussSeidel solver now accounts for residual scaling in its convergence criterion
  • New naming scheme for solver debug print files (the old scheme was making names so long it caused OSErrors)
• Components:
  • ExecComp now allows unit=<something> and shape=<something> arguments that apply to all variables in the expression
  • New AkimaSpline component with derivatives with respect to training data inputs
• Visualization
  • Several improvements for the N2 diagram for large models
  • N2 diagram html files have been reduced in size significantly
  • `openmdao view_model` command line utility now supports case record database files
  • (Experimental) Automatic XDSM generator (using either Latex with pyXDSM or html with XDSMjs)
    • contributed by Peter Onodi
    • uses XDSMjs v0.6.0 by Rémi Lafage (https://github.com/OneraHub/XDSMjs)

Backwards Incompatible API Changes:

• New APIs for total derivative coloring that are more consistent with partial derivative coloring (previous APIs are deprecated and coloring files generated with the previous API will not work)
  
• The API for providing a guess function to the BalanceComp has changed. guess_function is now passed into BalanceComp as an init argument.
  
• Changed the N2 diagram json data formatting to make the file size smaller. You can’t use older case record databases to generate an N2 diagram with latest version.
  
• The problem level `record_iteration` method was not properly respecting the includes specification
  
• All component methods related to execution now include `discrete_inputs` and `discrete_outputs` arguments when a component is defined with discrete i/o. If no discrete i/o is defined, the API remains unchanged. (includes `solve_nonlinear`, `apply_nonlinear`, `linearize`, `apply_linear`, `compute`,
  `compute_jac_vec_product`, `guess_nonlinear`)
  
• The internal Driver API has changed, a driver should execute the model with `run_solve_nonlinear` to ensure that proper scaling operations occur .
  

Bug Fixes:

• CaseRecorder was reporting incorrect values of scaled variables (analysis was correct, only case record output was wrong)
• ExecComp problem when vectorize=True, but only shape was defined.
• Incorrect memory allocation in parallel components when local size of output went to 0
• Multidimensional `src_indices` were not working correctly with assembled Jacobians
• Fixed problem with genetic algorithm not working with vector design variables
  • contributed by jennirinker
• Fixed incompatibility with mpich mpi library causing “PMPI_Allgather(945).: Buffers must not be aliased” error
  • contributed by fzhale and nbons

OpenMDAO 2.6.0 is out!

Here are the release notes listing the new features, bug fixes and a couple of backwards-incompatible changes:

New Features:
-------------

Many users of the OpenMDAO framework have interacted with Keith Marsteller in one way or another over the last 11 years. Keith has decided to move on to other projects and interests and, though the development team is sad to see him go, we wish him all the best in his new endeavors.

If you’ve used OpenMDAO at all, you’ve very likely felt Keith’s influence even if you didn’t realize it. He has managed our development and release process, led the construction of our entire CI system, played a key role in defining the structure our docs, built our web-site, and generally pitched in to keep the overall development process running smoothly all the time.  For users he often helped solve installation issues and provided guidance on how to build plugins.

Those who know Keith, even a little bit, know of his fondness of running up hills — the bigger the better, but he’ll do repeats if he has to!  Gradient based optimization is sometimes referred to as “climbing the hill”, and so in honor of Keith’s time on the team we are pleased to announce that Keith has been awarded the first ever,  OpenMDAO Hill Climb Award. This award is given to those who display stubborn determination in the face of huge hills (literal or metaphorical) that block their path, and climb to the top no matter what obstacles lie in their way. Keith earned this award by sticking with the project through over 10 years of development, three re-writes, 17000 different CI systems, 28 docs re-factors, an unexpected white-board marker battle, and far too many really bad inside jokes.

Keith, we’ll miss you, but we look forward to hearing about your new hill climb adventures in the future.

There are several new papers, published for Scitech 2019, that used OpenMDAO as a tool to reach their conclusions, that we wanted to share.  Here are seven OpenMDAO-related works that you may find interesting:

“Battery performance modeling on sceptor x-57 subject to thermal and transient considerations,” by authors J. Chin, S. L. Schnulo, T. Miller, K. Prokopius, and J. S. Gray

“Gradient-based propeller optimization with acoustic constraints,” by authors D. J. Ingraham, J. S. Gray, and L. V. Lopes.

“Multi-point design and optimization of a turboshaft engine for tiltwing turboelectric vtol air taxi,”  by author J. W. Chapman.

“Optimal control within the context of multidisciplinary design, analysis, and optimization,” by authors R. D. Falck and J. S. Gray.

“Load flow analysis with analytic derivatives for electric aircraft design optimization,” by authors E. S. Hendricks, J. W. Chapman, and E. Artskin-Hariton.

“Multipoint variable cycle engine design using gradient-based optimization,” by authorsJ. P. Jasa, J. S. Gray, J. A. Seidel, C. A. Mader, and J. R. R. A. Martins.

“A Mixed Integer Efficient Global Optimization Algorithm with Multiple Infill Strategy – Applied to a Wing Topology Optimization Problem,” by authors S. Roy, Willam A. Crossley, B. K. Stanford, K. T. Moore, and J. S. Gray.

If you liked these, and want to see all publications related to OpenMDAO, check out our publications page.