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.

Check it out at our Downloads page.
Release notes for 0.9.4 are here.
The support of the 0.9.0 major changes is starting to stabilize, but keep comments coming in the OpenMDAO Forums!