In October 2017, we released OpenMDAO 2.0 alpha. The 2.0 release of OpenMDAO has two important improvements to the code base:
- Cleaner, more self-consistent API
- 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.
