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.

1. The GUI won’t work in v0.12.0 and greater
2. All array variables must now be fully initialized before running your model
3. Running a DOE or CaseIteratorDriver in parallel is going to change in a big way
4. A single instance of a component can no longer exist in multiple workflows
5. 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!

http://www.youtube.com/watch?v=PDovutmuME4&feature=youtu.be

During low speed maneuvers associated with approach and landing, typical transport-class aircraft deploy high lift devices to improve stall and lift characteristics. Unfortunately, this also results in increased airframe noise, of which the leading-edge slat is a significant component. A proposed solution to mitigate slat noise is the development of a slat-cove filler (SCF). The SCF design considered in a current study incorporates shape memory alloys (SMAs), which are a class of active material that undergoes a solid-to-solid phase transformation allowing for large recoverable deformations. SMAs are considered in the current work in order to satisfy three conflicting design requirements: 1) stiffness under aerodynamic loads, 2) compliance to accommodate slat movement, and 3) low overall weight. The researcher is being done by W. Scholten and D. Hartl from the Texas Institute for Intelligent Materials and Structures associated with the Texas A&M University Department of Aerospace Engineering in close collaboration with T. Turner at NASA Langley. They are using OpenMDAO to perform a structural design optimization of the SMA-based SCF. The goal of the optimization is to minimize the actuation torque needed to retract the slat and attached SCF. The optimization process considered the highly nonlinear SCF structural response associated with aerodynamic loads and slat retraction/deployment. Structural analysis of SCF design configurations is performed using the Abaqus Unifed FEA suite in combination with custom material models.

OpenMDAO managed the integration of the material and FEA modeling and performed the optimization. The animation, above, is showing three of the hundreds of designs iteratively considered during optimization, including both feasible and infeasible solutions. But lest you think this is meerely a very interesting optimization problem, it turns out they have built and tested a number demonstration prototypes too!

0.10.2, which is considered a minor, bugfix release, is up for download. Check out the release notes for further details.

OpenMDAO has a new release out, 0.10.1. It’s a minor release. You can grab the new code here, and read about it here.

Version 0.10.0 is out, and there are a lot of changes! Grab the go-file, or check out the release notes!

A team of researchers from the Technical University of Denmark, F. Zahle, D. Verelst, F. Bertagnolio, and C. Bak,  are using OpenMDAO to perform an aero-structural optimization of wind turbine blades. Their goal is to design airfoils that are more effective over the varied wind conditions seen by wind turbines in real-world conditions. They performed an airfoil optimization that considered aerodynamics at multiple wind conditions with clean and rough blade surfaces. They also considered the structural needs of the blades in order to retain structural integrity. Aerodynamics computations are handled by XFOIL or their in-house CFD code, EllipSys2D, and the structural calculations are handled by BECAS. OpenMDAO is managing the interdisciplinary coupling between the aerodynamics and the structures and is facilitating the switching between XFOIL and EllipSys2D. The researchers have made a nice animation of the optimization process.

OpenMDAO version 0.9.6 is available for download today.  This new version has many bug fixes as well as some new capabilities, most of which are detailed  in the release notes.  As always, head to the OpenMDAO Forums with any questions or comments!  Of minor note is that starting with this release (and altered retroactively through all old release downloads), the “go-openmdao.py” files that install OpenMDAO will have version numbers incorporated in their names (e.g., “go-openmdao-0.9.6.py”) which should help our users who install multiple versions simultaneously to keep track of which script will install what.

When we designed case recording, we tried to give users ultimate flexibility and control. Case recording responsibilities were given to the drivers, which allowed users to have very fine-grained control over how/when they were recorded by putting different recorders into different drivers. We also allowed users to specify multiple simultaneous case recorders. But the result has never been fully satisfying to us. The current recording API is a little ad hoc and not fully consistent, even across the drivers in our standard library. So we’ve been thinking about improving the case recording behavior of OpenMDAO for a while now. We want to make it more automatic, easier to use, and save more information. The new method would record anything that is relevant (indicated by the data dependency graph) in your entire model. This would make sure you never had to re-run a model to get a value you didn’t think to save before. It would also provide a single consistent API for generating plots of your data.

The most significant change is that we want to move the place where you specify recorders out of the Driver and up into the Assembly. You will still be able to write your own recorders and specify as many of them as you like. But you will no longer have the ability to have separate recorders for each driver. Although we thought allowing separate recorders was a neat idea when we did it, in practice we’ve always just assigned the same recorder to all drivers (or sometimes just added a recorder to the top driver only).We’ve never seen any of our users do it either. But this will be a major backward incompatible change, and we wanted to give everyone the opportunity to weigh in. In case anyone feels strongly about this issue, we’re going to open up a discussion on our forum.

It boils down to this. This will affect anyone who has written their own case recorders but also anyone who has written their own drivers that used the case recording API. More importantly, it will also break any models where you used case recorders. It won’t be a serious challenge to fix these models. You’ll simply move the specification of case recorders up from the Driver to the Assembly. But you’ll still have to do it (or stay with an older version) to user your old models. We’ll be starting this update in the pretty near future, so if anyone has any suggestions or can relate experiences from their use of case recording, we’d love to hear ’em! We’re working on the design of the new interface now, and we’ll post some details about it in the near future.

Since 0.9.0 OpenMDAO has had a new derivatives system that can handle really large design spaces. What does really large mean? We’ve tested the capability (in fact, we developed the capability around) a 25,000-design-variable problem. You can read all about the details in the online docs, which include some interactive data visualization with Google Earth. The docs tell you how to install and run the this test problem for yourself.

We worked closely with the University of Michigan MDO lab to implement their problem for a small satellite design. This problem achieves its large design space because the optimizer is being given control over the attitude and power distribution to subsystems for the entire mission. So this is a big optimal control problem, with some traditional design optimization thrown into the mix.

When John Hwang did the original work, he was able to converge this problem in about 100 hours. However, about 90% of that time was used calculating derivatives. The huge derivative cost was a function of the way he got derivatives – by solving a linear system that included all the variables in the whole system each time. When we implemented this problem in OpenMDAO, we were able to get the computational cost down to about 6 hours. This pickup was due to our using the data dependency graph to figure out which variables were needed for a given derivative calculation (almost always much less then the full set of variables for the whole problem). Since we shrank the size of the linear system for the derivatives solved by quite a bit, we became a lot more efficient.

OpenMDAO v. 0.9.5 has been released. Download the go-script here. Release notes are available here. This release is another maintenance release to address issues reported by our user base. But this release also has a couple small backwards non-compatible changes as well.

The first one is a small update to the derivatives api. You can read about the new api in the docs. But here’s the short version. You now declare the variables you’re providing derivatives for explicitly in a separate function. This change streamlined things a bit and lets us add a bit more error checking.

The other change also needs some further discussion. Previously, allowing Slots to have an iotype created two unintended consequences: it allowed for issuing connections to a Slot object, and it caused Slot objects to appear in the Input/Output tabs of the GUI. Neither of these behaviors is desired.

We’ve taken several steps to address this issue.

1. Starting with this release, OpenMDAO no longer supports iotype metadata for Slots. The instantiation of any Slot containing “iotype” as metadata will generate a FutureWarning.
2. If a user needs to use “iotype”, we’ve created a new datatype, called Instance. Outside of the GUI, it has the same behavior as a Slot but supports having an iotype. In the GUI, Instance variables should appear in the Input/Output tabs of a component (but won’t show up in the slots tab).
3. We know that some of our components and drivers previously had Slot objects with iotype. To address this, we’ve created “connectable” versions of these, located in the same packages/modules as their Slot-based counterparts. For example, ConnectableDOEdriver and DOEdriver can both be imported from openmdao.lib.drivers.doedriver. A non-exhaustive list of other examples include:

• ConnectableNeighborDOEdriver
• ConnectableCaseIteratorDriver
• ConnectableParetoFilter
• ConnectableMetaModel

If you relied on any of the Slot-based versions for connections, you can easily swap them for the connectable version. Please let us know in the forums if there are any questions or problems with this change.