OpenMDAO Logo

An open-source MDAO framework written in Python.

December 8, 2017
by admin
Comments Off on Release of OpenMDAO 2.1.0

Release of OpenMDAO 2.1.0

OpenMDAO 2.1.0 was released today. Documentation for this version can be found here. If you have any trouble with the release, feel free to contact us for support via our Stack Overflow tag, “openmdao.”

Here are the release notes for 2.1.0:

New Features:
– Configure setup hook allowing changing of solver settings after hierarchy tree is instantiated.
– Component metadata system for specifying init_args with error checking.
– Parallel Groups were added.
– Units Reference added to the docs.
– Case recording now records all variables by default.
– `openmdao` console script that can activate useful debugging features
(e.g. view_model) without editing the run script.
– Scipy COBYLA optimizer converts des var bounds to constraints (the algorithm doesn’t natively handle bounds)
– StructuredMetaModel component offers a simple spline interpolation routine for structured data.

Backwards-Compatible API Changes:
– `NonlinearRunOnce` changed `NonLinearRunOnce` for consistency (old class deprecated).
– `types_` argument to `self.metadata.declare` changed to `types`. (old argument deprecated).
– `types` and `values` arguments to `self.metadata.declare`
– `BalanceComp` has a `use_mult` argument to control if it has a `mult` input, defaulting to false
(the mult input isn’t used most of the time)
– Renamed `MetaModel` to `UnstructuredMetaModel` and `MultiFiMetaModel` to `UnStructuredMultiFiMetaModel`

Backwards-Incompatible API Changes:
– Case Recording options API updated with `.recording_options` attribute on Driver, Solver, and System classes
– `get_subsystem` changed to a private method, removed from public API of System.
– `check_partials` now has a `method` argument that controls which type of check.

Bug Fixes:
– Improved error msg on a corner case for when user doesn’t declare a partial derivative.
– Fixed docs embedding bug when `<>` included in the output text.

November 23, 2017
by admin
Comments Off on Should I Use OpenMDAO 1 or 2?

Should I Use OpenMDAO 1 or 2?

OpenMDAO 2 represents a total re-write and significant update of the framework with much cleaner APIs and performance improvements. It is also a backwards-incompatible release, and does not yet (as of November 2017) include all of the features that were in version 1. Given that, when and how should you go about updating your code? While each group will have to make this choice for itself, we want to give our perspective on the issue in the hope that it will help make the decision easier for you.

Why a total rewrite?

OpenMDAO 1.0 offered two key features that made it unique:

  1. Tight integration with high-fidelity, parallel-analysis tools.
  2. Automatic analytic derivatives.

The high fidelity HPC capability was achieved by integrating a novel computational architecture that supported distributed memory parallelism via MPI. The analytic derivatives features were enabled by the development of a sparse, matrix-free linear solver sub-system. The first feature worked extremely well, but the second was only partially successful because it suffered some performance limitations.

The challenge we faced was that we had designed a system that was efficient for large sparse analyses (e.g. problems including CFD models), but that had come at the cost of performance for smaller more dense analyses (e.g. low fidelity serial propulsion models).

Once we identified the performance issue, the fix was clear. We needed to use a dense linear solver system for smaller problems. The challenge was that 1.0 was designed around the sparse, matrix-free assumption, and it wasn’t clear that we could easily refactor the code around that. So we decided that a re-write was necessary.

So version 2 includes a hybrid linear solver architecture that supports a mixture of sparse and dense operations. Our testing on our own internal applications has shown an 10x reduction in compute cost for smaller problems while maintaining efficiency for larger scale problems.

These massive performance gains make a compelling reason to upgrade to  v2.0, and we do expect that the user base will all make the switch eventually! The time may not be quite right for everyone to upgrade, because we haven’t just re-written the underlying code. We’ve also made several backwards-incompatible changes to the user-facing APIs.

Why make it backwards incompatible?

In making the transition to the hybrid linear solver architecture, it became clear that some new component level APIs were going to be needed, and that it would not be easy to make them backwards incompatible. Also, in a number of spots we felt that the version 1 APIs were both a little inconsistent and somewhat confusing. So we decided to free ourselves to make backwards-incompatible changes to the API. We feel that these updates are for the best in the long term.

However, writing a clean and fully self-consistent API is easier said than done. As we’ve developed version 2, we’ve had to repeatedly re-evaluate our API choices as we implement new features and build new applications that stress the framework. As such, we’re still making tweaks to the APIs and likely will be for through summer 2018. At this point (November 2017), the API changes are fairly small and mostly consist of “find and replace” type operations, or represent expansions via new API methods, but changes are still being made.

This API-changing issue was the primary reason we decided to release version 2 when we did. We decided that it was important to let the community know about the new APIs and start getting some outside feedback. It also gave users the ability to fix their work to a specific version and guarantee a stable API for themselves. To that end, our version numbering system uses a three-digit convention: 2.x.y. The ‘x’ is for releases that include API changes. All new APIs will be listed in the release notes, and any backwards incompatible changes will be called out.  The ‘y’ is for minor releases (e.g. bug fixes and docs updates) and won’t represent new APIs. In other words: changing from 2.1 vs 2.2 will mean an API change, changing from 2.2.0 to 2.2.1 will not.

So which version should you use?

If you’re starting a new project from scratch, you should start from version 2! The only exception would be if you immediately need some of the features we have not yet implemented. As of November 2017, the most significant things on the list of missing features are the DOEDriver and Pass-By-Object variables. If you need either of those features, you’ll have to wait at least a few more months.

If you have a significant code base already implemented in 1.0, the decision is a little harder. Although the APIs are different, they are dauntingly so. As a point of reference to the difficulty of translating from 1 to 2:  an internal application built on OpenMDAO that included over 100 files and 10000 lines of code was updated from version 1 to version 2 by one person in less than 3 days. However, if your application is currently working fine in version 1 and you’d rather wait a few more months till we’ve finished porting all the major features and settled down on backwards incompatible API changes, thats a reasonable choice.

By August 2018, things will have settled down considerably, and at that point we’ll start recommending that everyone make the update. Again, new codes should definitely start out in version 2! For the time being, though, good arguments can be made for using either version 1 or version 2 with existing codes, and the choice is yours.

October 23, 2017
by admin
Comments Off on What’s New in 2.0

What’s New in 2.0

In October 2017, we released OpenMDAO 2.0 alpha. The 2.0 release of OpenMDAO has two important improvements to the code base:

  1. Cleaner, more self-consistent API
  2. Improved performance for models with lots of components and scalar variables

A new API?

The decision to make backwards incompatible changes to the OpenMDAO API isn’t one that we take lightly. We know it causes a lot of inconvenience to users, and presents a huge barrier to updating. However, the 1.7.3 API was built incrementally as we developed new applications, and we never had the chance to develop a self-consistent API design.

Many of the API changes that we wanted to make were superficial (e.g. changing `add_parameter` to `add_input`). However, there were some more significant API changes that were made for the sake of enabling improved performance (e.g. the new derivatives APIs). When we stood back and looked at all the changes as a whole, we decided that it was better to make them all at once in one big 2.0 release rather than make small changes as we iterated from 1.7 to 1.8 to 1.9 …

In the end, we feel that the new 2.0 API is much cleaner and more clear. Its also really not that big of a departure from the 1.7. We developed a translation guide that shows you how to update your models. It’s not long, which shows that the API changes are not massive.

We still have a few parts of the API that we’re not totally done with yet. Specifically the CaseRecording API is going to get a further update in the very near future. But the vast majority of the APIs are now in place and we wanted to get the new code out there for users to play with as a soon as possible.

“Simplify, then add lightness”

In 1.7.3, the derivatives system was designed primarily around use-cases that included high-fidelity analyses (e.g. CFD, FEA) in the model. It needed to scale well to distributed-memory computing environments. We succeeded in designing a system that worked on that scale, but we soon realized that our design was not very efficient on smaller-scale serial analyses. Things got especially inefficient when we tried to build models with hundreds or thousands of components in them.

We needed to re-work the guts of OpenMDAO to support both problem scales simultaneously. In the process, we’ve been able to get computational cost reductions of up to 10x on some of our trajectory analysis work, and 5x on some of our propulsion analysis work. We’re still working on getting more performance out of 2.0, but improvements like those have shown that we’re on the right track.

Why should I upgrade?

You shouldn’t feel the need to update right away. If 1.7.3 is working for you, and meets your needs, then by all means stay working with that code for now. Not all the 1.7.3 features have been implemented in 2.0 yet (for a current list, check out the README in the repository)

However, if you were having performance issues with 1.7.3 (memory or cpu performance), then 2.0 is definitely worth a look. If you’re developing new engineering applications natively in OpenMDAO (this is what the OpenMDAO development team does) then you’ll benefit greatly from the new speed improvements and the cleaner APIs.

October 20, 2017
by admin
Comments Off on OpenMDAO 2.0.x

OpenMDAO 2.0.x

We here at OpenMDAO have been hard at work writing a completely new version of OpenMDAO. After 1.7.3, we started from a clean slate, and OpenMDAO 2.0.0 is now an all new alpha. OpenMDAO 2.0 is all about performance, especially for smaller scale problems. On our in-house applications we’re seen up to a 10x speed up in performance.

Still Alpha?

We’re still tweaking the APIs a bit and we want you all to be aware of that. One of the reasons we’ve decided to make an official release of 2.0 is so that we could make it it clear when the APIs are changing. Any change in the version number at the second decimal (i.e. a change in the `x` from 2.x.0) will indicate an api change. The API change could be a modification to an existing API, or the addition of new APIs to extended functionality. Once we’re happy with the APIs, the alpha tag will come off.

And now for a bit of housekeeping:

The OpenMDAO 1.7.3 codebase repo has been renamed to OpenMDAO1, and it resides at If you have a clone of this repo, you’ll need to update the URL on your remotes.

The OpenMDAO 2.0.x code has taken the name OpenMDAO,
and it resides at

Installation of 2.0.x code will now work with `pip install openmdao`.

Installation of 1.7.3 code will now only work with a version specifier: `pip install openmdao==1.7.3`

The release notes detail what is in 2.0.0, here’s an excerpt:























To get started, read our documentation at

July 18, 2016
by admin
Comments Off on OpenMDAO 1.7.1

OpenMDAO 1.7.1

OpenMDAO v1.7.1 is now available!

Feel free to ask questions on our Stack Overflow tag if you experience any difficulties.

Here are the release notes for 1.7.1:
OpenMDAO Version 1.7.1 Alpha Release Notes
July 18, 2016

* Newton and NLGS solvers now also check for convergence by monitoring the unknown vectors for when it falls below a tolerance `utol`.
* The print_all_convergence function in Problem now has an argument level that lets you choose between:
0 — only display failures
1 — display iteration counts
2 — display residuals each iteration (this is the default)
* Added a SAND example from our users into our Examples section in our documentation.
* Implemented better error handling when user gives too many args to connect.
* Modified linear_system so that its derivatives are solved with an additional LU back-substitution solve_linear.

Bug fixes:
* Fixed bug in relevance checking related to pass_by_obj vars.
* Fixed doc problem where multiple requirements sections listed under Examples on docs main page.
* Fix for keyerror when you have an array scaler on a design variable or constraint and are using SLSQP
(so the return_type for jacobian is array) under full_model fd.
* Non-python files are no longer missing from our distribution.
* Fixed a bug where residual scaling/unscaling was applied to a finite-differenced Jacobian when it shouldn’t be.
* Fixed bug in Newton derivative calculation when containing system is set to ‘fd’ or ‘cs’.
* Fix for Newton when solving a system that has been set to ‘fd’ (or ‘cs’)

June 30, 2016
by admin
Comments Off on OpenMDAO v1.7.0

OpenMDAO v1.7.0

OpenMDAO v1.7.0 is now available!

Feel free to ask questions on our Stack Overflow tag if you experience any difficulties.

Here are the release notes for 1.7.0:
OpenMDAO Version 1.7.0 Alpha Release Notes
June 30, 2016

Backwards-Incompatible Change:
1. ‘fd_options’ is now ‘deriv_options’ in systems.
2. New ‘type’ option allows the user to select between analytic, finite difference, or complex step.
3. The ‘force_fd’ option is no longer needed because of type.
4. The ‘complex_step’ choice has been removed from the ‘form’ option.
5. The ‘step_type’ option is now ‘step_calc’.
6. New explicit options ‘check_type’, ‘check_form’, ‘check_step_calc’, and ‘check_step_size’
allow you to control the fd check during check_partial_derivatives.
7. Old code will still work, but will raise deprecation warnings.

* NAS access component
* The output of check_partial_derivatives has been modified so that absolute or
relative errors that exceed a tolerance are flagged with a ‘*’.
The tolerances can be specified via call arguments.
* User can now specify a scaler on any residual by specifying a resid_scaler during add_state.
OpenMDAO see the residual divided by this number.
* A new Model Structure Viewer has been added for viewing the data dependency of your model.
* Updated our Kriging surrogate model based on Sci-kit learn’s Kriging module.
* Added support for parallel DOEs using multiprocessing.
* Converted NREL Tutorial from OpenMDAO 0.1x to OpenMDAO 1.x
* The default Line Search for the Newton solver is now None.
The Backtracking Line Search has been overhauled to use the Armijo-Goldstein for termination.

Bugs fixes:
* Fixed a bug in the lower limiting for state variables.
* Fixed a bug in the KSP solver related to relevance reduction.
* Fixed a bug in fd partials checking.
* Fixed a bug in Radians to Degrees unit conversion.
* Fixed a bug in Newton Backtracking to ignore pass_by_obj variables.
* Fixed where using `abs` in ExecComp expression gave bad derivatives.

May 10, 2016
by admin
Comments Off on OpenMDAO v1.6.4

OpenMDAO v1.6.4

OpenMDAO v1.6.4 is now available!

Feel free to ask questions on our Stack Overflow tag if you experience any difficulties.

Here are the release notes for 1.6.4:

OpenMDAO Version 1.6.4 Alpha Release Notes
May 10, 2016

* User can get more compact output from check_partial_derivatives via `compact_print=True` argument
* User can call alloc_jacobian() to pre-allocate jacobian with correct sizes for everything when jacobian structure is fully dense
* Setup messages, warnings, and errors are now all delayed and given all that the same time, at the end of setup.
* Components can now raise AnalysisError when a component fails to have solver or driver handle the situation cleanly. Note: solvers and drivers need to be written to handle this correctly
* Systems (Groups & Components) will set a _jacobian_changed flag, so that solver can know if they need to do some extra work.
* Pyoptsparse Driver will catch AnalysisError and pass fail-flag to pyopt-sparse.
* Added error msg to top of run and run_once in case force_fd is changed from its setting pre-setup.
* User can call list_params method on a group to get a list of all the parameters that don’t have any src at that level of the hierarchy.
* Add a test support utility function to check for the presence of fd_options[‘force_fd’]=True in a group.
* Added option to DirectSolver to improve performance by manually assembling the Jacobian.
* Added support for caching the LU factorization to the DirectSolver. This is the default option.
* We now raise an error if more than one objective is added to a driver that does not support multiple objectives.
* User can specify a scaler when adding an output or state. That number is internally used to scale the variable in the unknowns vector.
* User can specify a resid_scaler when adding a state. That number is internally used to scale the resids vector.
* Many documentation fixes and improvements.
* Coming in next release, a model structure viewer.
* Coming in next release, a basic profiler.

Bug fixes:
* Fixed a sign inconsistency in the derivatives systems with Residuals.
* Fixed error-checking for solver maxiter when there are cycles or states.
* Fixed error message for things that shouldn’t be changed after setup to be more user-friendly.
* Fixed bug when distrib comp used with parallel DOE.

March 1, 2016
by admin
Comments Off on OpenMDAO 1.6.0 Released

OpenMDAO 1.6.0 Released

OpenMDAO v1.6.0 is now available!
And remember, we are now pip-installable, as we are now indexed on pypi:

Feel free to ask questions on our Stack Overflow tag if you experience any difficulties.

Here are the release notes for 1.6.0:

Backwards-Incompatible Change
*System names must be valid Python names:
Because we add subsystems as attributes of their parent system, the name of each system must be a valid Python name. Otherwise we will raise an exception.

*User now has the ability to call check_total_derivs and have it just do the driver-relevant params/cons/objs instead of every param/unknown in the model.
*Multiple local components are now allowable in a parallel system.
*User can choose to complex step a full model for total derivatives.
*We now account for Jacobian sparsity patern that arises from src_indices connections. This is available for the pyoptsparse driver.
*Documented more of our MPI functionality.
*Added support for File variables.
*Case recorders now save derivative information by default. You can turn this off in the recorder options.
*Pass-by-object connections will now convert units if the object is numeric.
*Now raise an error if a user tries to add the same constraint/param twice.
*Made Brent solver work for when state variable is an element of an array variable.
*Sped up setup of model
*Test nsga2 with pyoptsparse wrapper.
*Added dynamic load balancing option for PredeterminedRunsDriver.
*Removed getitem() function from System class.
*Added complex step example to the FD tutorial.
*Edited paraboloid tutorial and sellar tutorial to include lines where we set initial guesses.

*Components without outputs now allow linearize to return an empty dict ({}).
*User can now specify units for ExecComp values.
*Two_sided_constraints are now supported in ScipyOptimizer.
*Unit conversions were being reported for pass-by-object variables.
*Fixed bug in check_setup when connecting array_src to scalar target.
*Cleared up problems that ExternalComp had with timeout and Windows process termination.
*check_total_derivatives did not work under single_voi_relevance_reduction because the vectors were setup for only fwd or rev.
*DOE des-vars with array variables didn’t work.
*optlatinhypercube was missing the load_balance arg.
*Fixed bug where RBF interpolator returned NaN when a Jacobian is requested at a point in the training set.
*Fixed a bug where finite difference of a group would error out if there was a pass-by-object param or unknown in any sub-component.
*All metamodel training data is now params.
*Bogus unit conversion msg when inputs that share a source have different units.
*Fixed bug where the size of src_indices could exceed the size of the source.

January 19, 2016
by admin
Comments Off on OpenMDAO 1.5.0 Released!

OpenMDAO 1.5.0 Released!

OpenMDAO v1.5.0 is now available!
And remember, we are now pip-installable, as we are now indexed on pypi:

Feel free to ask questions on our Stack Overflow tag if you experience any difficulties.

Here are the release notes for 1.5.0:

OpenMDAO Version 1.5.0 Alpha Release Notes
* Proper MPI/PETSC installation/testing/usage now documented in User Guide.
* User can run a DOE in parallel.
* Removed pyoptsparse output from our test output to declutter things.
* User can run a model in parallel using pass_by_obj data transfer under MPI.
* Pyoptdriver now supports saving its history file.
* User can call cleanup method on problem that closes all recorders.
* Converted Brent driver from OpenMDAO Classic to OpenMDAO 1.x
* Case recorder will (optionally) save gradient information from driver cases that requested a gradient in that run.
* OpenMDAO now makes suggestions to user how to improve efficiency when the layout of systems in the model is not optimal.
* OpenMDAO now uses feature of pyOptSparse that allows a single Jacobian element to be sparse.

* User now gets an error if they pass `promotes` keyword arg into any System.
* Dealt with the duplicate executions of explicit comps when using a solver.
* Fixed bug in accessing prob.unknowns and prob.resids.
* Fixed bug where pyOptSparse/SLSQP failed with Pointer.
* Fixed a bug in pass_by_obj_check_derivatives.
* Fixed MPI hangs that were related to use of Python 3.
* Fixed a bug in ExecComp expressions that didn’t allow the use of ‘:’ notation.
* Added missing documentation of ‘.keys()’ in recorder documentation.
* Fixed a bug in the pass_by_obj params.
* Fixed a problem in recent CADRE runs.

December 16, 2015
by admin
Comments Off on Server Migration Will Cause (Hopefully) Brief Website Outage Server Migration Will Cause (Hopefully) Brief Website Outage

UPDATE: The migration went pretty well, and should be back at full strength. Please report any problems to our support email. is being migrated to newer, faster servers on Thursday evening – Friday morning, December 17-18, 2015.
We expect the website to be down for some of that time, or longer, if there are complications.
While is down, our code is still available on Github, our docs at ReadTheDocs, and support available at Stack Overflow .

Fork me on GitHub