Version 0.12? Where did v 0.11 go? Well, we were talking to our good friends at Microsoft and they suggested that we should skip a number in our versioning to help distinguish the newer product more. So, Windows 8.1 -> Windows 10 and OpenMDAO 0.10.3.x -> OpenMDAO 0.12. Expect this to be released in late November or early December of 2014.
All kidding aside though, the next release of OpenMDAO is a really big one. It’s the culmination of 10 months of work to make OpenMDAO more efficient, more scalable, and to prepare us for some really cool MPI-based capability in the future. On a small satellite design problem with 25000 design variables, the new version of OpenMDAO is 20% faster. Most of these changes are under-the-hood things that users won’t have to ever look at. But there are some major impacts to this upgrade that need to be discussed.
- The GUI won’t work in v0.12.0 and greater
- All array variables must now be fully initialized before running your model
- Running a DOE or CaseIteratorDriver in parallel is going to change in a big way
- A single instance of a component can no longer exist in multiple workflows
- The geometry interface is changing
Before getting into the details, let’s start with this: If any of these issues is a show stopper for you, then you DON’T upgrade to the new version yet. At least not for your current models. We do suggest you build any new models with the newer version, since we’re not going to be providing any serious support for the older versions going forward. Ok, now onto the more detailed discussion of each point.
The GUI is going away
It’s not going away forever, but just for now. The way the GUI worked added a significant amount of complexity and overhead to the framework, so we needed to remove the GUI’s plumbing to get things working better. We’ve figured out how to put the GUI back in, without hurting our performance. In fact, the end result is going to be a lot better. But we wanted to get the new framework out there for users to start working with and didn’t want you to have to wait for us to re-build the GUI. So for now, no more GUI. If anyone wants to try V0.12 with a model that was previously in the GUI, then get in touch with us. We’ll help you port the model out of the GUI so you can try things out!
All Array variables need to be initialized
Some of you might have made models with array inputs or outputs, where you didn’t set a default size or provide an initial value for the arrays. You were relying on the connections you made to propagate the array values down stream to other components. However, in order to make things work properly in the new version, the framework needs to know the shape of all arrays before execution starts. We’ve run into a few of our own models where we didn’t bother setting initial values up for arrays before. So its expected that you’ll run into this as well. This is something we’re looking for a way to work around, but for now, it is a requirement.
CaseIterDriver and Parallel Execution
We’re not actually sure how many folks have actually tried out the “sequential=False” option for DOEDriver and CaseIteratorDriver. However, if you have tried it, expect major changes here. In v 0.10.3 and older, this used something called a ResourceAllocationManager (RAM) to shell out jobs to workers. This could be set up to work locally without you doing much, or with some work, you could set up a RAM to point to a remote cluster. However, in V 0.12 and up, this is all going to work really differently. The RAM is going away, in favor of a more direct approach using an MPI-based implementation. Those are all the details I wish to share on this subject at the moment, but just know that you can look forward to a lot of MPI-based awesomeness in the near future from us. For now, if you need “sequential=False”, stick with 0.10.3 or older.
One Component in Multiple Workflows
This was a neat idea that we had early on in OpenMDAO. It sounded great at the time, and we did find an occasional application for it. The two cases of note were our implementation for Efficient Global Optimization (EGO) and our implementation of the BLISS architecture. In 0.10.0 we changed the whole MetaModel interface, and EGO no longer required a single component in multiple workflow. So that only left BLISS. For a number of reasons, we didn’t feel that this use case warranted the complexity that came with supporting this idea. So we removed the feature and simplified the code base a bunch. If this feature was something you were actually using a lot, please get in touch with us. We really want to talk to you about it and see how best to port your models to the latest version.
The Geometry Interface is Changing
Given that the GUI is going away, this should not be a huge surprise. But the change is a bit more fundamental than just not having a native viewer anymore. We wanted to take a clean look at how geometry interfaces with the framework and especially with the derivatives system. Plus, truth be told, our old geometry API was really clunky. So we’ve cleaned it up a good bit and simplified it a lot. If you happen to have written something to our old geometry api and would like some help moving it to the new one, just let us know!
