OpenMDAO Already has both structured and unstructured metamodel components. You might think that those two are the all you would ever need, but there is a semi-structured data format that is fairly common (at least in the aircraft design world). This kind of data is useful for things like performance tables where you can’t necessarily get valid data on a full structured grid. The data looks like this:
x = 1
y = 1, 2, 3, 4, 5, 10, 11
z = 10, 20, 30, 40, 50, 100, 110
x = 2
y = 1, 2, 3, 4, 5, 10, 11
Z = 60, 80, 100, 200, 220
x = 3
y = 1, 2, 3, 4, 5, 10, 11
z = 300, 330, 120, 150, 300, 330
The independent values are always monotonic, but the dependent data does not necessarily have to be. Despite being non-structured, the monotonic inputs allow for the same kind of recursive interpolation that OpenMDAO’s MetaModelStructuredComp uses.
While this POEM does propose a backwards incompatible change, to the best of our knowledge no one is actually using these APIs. If you are using them and want to object to their removal, now is your chance! Please comment on the POEM PR and provide us an example use case where you really need to have it.
These APIs date back to early OpenMDAO V1 days when performance for serial components that provided a dense partial derivative Jacobian were very poor due to some slower internal data formats and the lack of a DirectSolver. At that time, our solution involved augmenting the matrix-vector product APIs with a matrix-matrix product API that would skip a particularly slow OpenMDAO for-loop. It worked to an extend, but was not a very general solution.
Today we have both sparse and dense assembled Jacobians that provide better overall performance in a wider range of use cases. We believe these older matrix-matrix features are not needed, and removing them will simplify several places in the code and make our linear solvers more easily understandable.
If you think otherwise, please speak up. We’d appreciate you providing a use case that shows how the matrix-matrix APIs are significantly faster than using the an Assembled Jacobian and LinearRunOnce or DirectSolver.
Version 3.9’s biggest change is the new serial/distributed api for variables. We now allow you to label individual variables as serial or distributed, which ultimately clears up a lot of confusion when working with distributed memory computations. All of the details are covered in POEM 046. There are lots of other changes in this release, including performance improvements and a few other new features. You can read the release notes for a full accounting, but here are the highlights.
A small but useful update was made to ExecComp. You can now call the add_expr method on that Component to create new outputs. This change makes the ExecComp API look more similar to the BalanceComp and EQConstraintComps. It also makes for slightly cleaner inputs when you’re using a lot of expressions in your model.
Were you annoyed by the warnings about missing MPI4py or petsc4py? You were not alone! We’ve specifically quieted those two, and you’ll only see them if you try to use those features without the proper packages in stalled. More generally though, we reworked our whole warnings system.
OpenMDAO gives you a lot of freedom, and sometimes that lets you get into trouble. We’ve tried hard to add clear error/warning messages to cover these situations. However, the net result is that sometimes your runs can get kind of noisy. So we re-built our warning system to be more organized, and gave users the ability to limit which ones actually get reported. Check out the docs for the new warning system.
Try to remember, with great power comes great responsibility 🙂 When you suppress warnings you might be missing helpful information. We recommend you leave most warnings on during development and turn them off only for production runs.
April 14, 2021
by Justin Gray Comments Off on V3.8.0 and an upcoming 100x speedup!
Ability to save/load views of an N2, so you can keep that specific view you spent a few minutes setting up 🙂
added some preliminary support for ipython notebooks to some of the visualization and variable listing methods.
Bug fixes for exec-comp has_diag_partials argument
Bug fix for the residual based filtering of list_outputs
Bug fix for Nan values breaking the N2
If you do any work with OpenMDAO distributed components, you should check out POEM_046. Ongoing collaborative work between University of Michigan, NASA Glenn, NASA Langley, and Georgia Tech exposed some weaknesses in the current (i.e. as of V3.8.0) apis. So we did a very deep dive to figure out the “right” way. POEM_046 is currently just a proposal, but it should be accepted and implemented in time for V3.10.0 in late May or early June 2021. We put a lot of detail into this POEM, so it could serve as a reference for anyone who wants to understand how OpenMDAO does its stuff. The final APIs are pretty simple, but the majority of the POEM deals with why we decided to go this way. Feedback is more than welcome from anyone!
So what about this 99% speedup? Sounds pretty great right? A few weeks ago we noticed this in one of our internal benchmarks:
On April 1st something pretty spiffy happened there right? Please excuse the obtuse benchmark test names. We have a lot of internal benchmarks (we run nightly tests on OpenMDAO core, pyCycle, and Dymos) and we use rather verbose names for them to help make it easy to figure out whats going on. In this case, the benchmarks were from Dymos, and (as the long names suggest) they delt with partial derivative coloring algorithms.
We recently completed a major overhaul of the internal FD/CS partial derivative approximations and the associated partial derivative coloring. Things are now fully sparse internally and work on a column by column basis that is a lot more memory efficient. That massive drop in benchmark times came from this upgrade. If you haven’t tried out the partial derivative coloring, you should give it a look. That goes triple if you’re a dymos user. It lets you use complex-step derivatives and still get a lot of the benefits of sparse partials!
These benchmarks literally got 99% faster, or 100x speedup. Props go to Bret Naylor on the dev team for doing the hard implementation work and to Sandy Mader — the user who suggested the improvement. Bret is pretty humble about the speed up though. He says that the secret was to make the initial code as slow as possible, so there was lots of room for improvement. The new, faster coloring will be released with Version 3.9.0.
February 11, 2021
by admin Comments Off on OpenMDAO V3.7.0
debugging methods give nicely formatted output in Jupyter notebooks
ExecComp now shows the equations in the info panel for the N2
Bug fixes for parallel solvers
User Defined ExecComp Functions
You can now add register own functions to be used in ExecComp. They can be complex-stepped for derivatives just like normal (or you can mark them as requiring finite-difference instead of you prefer). One of the nice things this will let you do is quickly compose a component that chains several methods together. You can read our thinking on details in POEM 39. Here are the docs for user function registration. If you try this out and have any feedback, don’t hesitate to let the dev team know!
N2 viewer Improvements
If you haven’t looked closely at the N2 for a while you might have missed a number of small improvements over the last few releases. The info tool can be used on components and variables to see values, units, and other metadata. New in V3.7, if you get the info for an exec-comp, you can see the equations that were used to define it.
You can also show/hide the solver hierarchy and highlight the design variables/constraints/objective as well.
January 17, 2021
by Justin Gray Comments Off on New Release: OpenMDAO 3.6.0
Version 3.6.0 marks a huge milestone for OpenMDAO. This is the second release in a row where there are no backwards incompatible API changes! Hurray! To celebrate we released our new logo!
Lest you think we just made a release without changing anything … check out the release notes. Here are the highlights
In our internal use cases, particularly with Dymos based problems, we’ve been struggling with optimization scaling. We’re starting to look into some more advanced methods for scaling, but the first step to improving things is understanding what you have in the first place. We built a scaling report tool that helps you get that information in one place. To run it, you can call the OpenMDAO command line openmdao scaling <your run script
Include data about which surrogate is used in metamodels
Can now hide the solver hierarchy in the N2 (useful if you want to make slightly lower-aspect ratio movies of the N2)
Included a button to show/hide the design variables, objective, and constraints
December 3, 2020
by admin Comments Off on POEM 039: User Functions in ExecComp
There is a new POEM (Proposal for OpenMDAO EnhanceMent) on the street. POEMS are the way that any new feature is vetted before being implemented. Developers and users are all welcome to propose POEMS! Also, we value any user input on POEMS before they are implemented. So please hop over to the proposal for POEM 039 and feel free to leave any comments you like (or submit suggested modifications as a PR of your own).
POEM 039 would enable users to register their own functions to the ExecComp, so they can use them in a simplified and streamlined manner without the boilerplate of writing their own component wrapper.
While the Dev team is putting the finishing touches on OpenMDAO RevHack2020, I wanted give a wrap-up summary.
First, let say thank you to everyone who submitted problems for us to work on. Thanks to Remi Lafage, Adam Chase, John Jasa, Anil Yildirim. Extra special thanks for Shamsheer Chauhan for submitting 4 different problems! Our goal for RevHack 2020 was to develop a better understanding of your perspective and we simply couldn’t have done that without your help.
A new perspective on the “right way” to use OpenMDAO
We used RevHack2020 as a chance to step outside the normal development process and examine things from a new perspective. That started with trying to really understand what was the core of a particular user struggle, but we took that further, asking the following:
Is there a better way to do this? What is the value of OpenMDAO for this problem? Are we really making this easier than it would be without OpenMDAO?
Here are some of the semi-philosophical answers that I came up with.
If you don’t want to use analytic derivatives, is OpenMDAO worth it?
As the leader of the OpenMDAO project, it is a little scary to ask myself this question. I know that it is extremely powerful and effective for our work at NASA. We couldn’t write tools like pyCycle or Dymos without it but we leverage the derivatives capabilities heavily.
OpenMDAO enforces some specific coding structures on you, and those are derived from the goals of modularity and support for analytic derivatives. Sometimes those are getting users way and if you are not getting the benefits of the derivatives, I can see how frustrating that would be.
So I have come to two conclusions:
1) If you are not planning to ever use analytic derivatives, then the case for OpenMDAO is much weaker. If you do want to have a path to using them, OpenMDAO is worth the effort.
I was personally shocked when thinking about CMA-ES problem brought me to the conclusion that the whole Driver interface in OpenMDAO is non critical. I still think it has a lot of value, but its non-critical because you could get all of the value from OpenMDAO without it just using the apis on the problem itself.
There is a lot of code in our Driver interfaces, and I can see that users find it intimidating to figure out how to navigate that. That code is there because it allows the developers to switch between the multiple optimization libraries that we use. If you want to use a single specific library though, you don’t need any of that.
I am not going to rip the Driver interface out of OpenMDAO, because its useful to the development team and I don’t want to break models of anyone who uses it. However, I am explicitly saying that you should feel free to disregard it and roll your own interface to the optimizer. Here is a more in depth discussion of this topic
If you build a massively complex optimization, expect it to be hard to solve!
One thing that OpenMDAO has done is make it easier to build bigger, more complex optimization problems. I can see that a lot of users are still struggling, and I acknowledge that we have more work to do. However, I have also seen users build models that are intensely complex, and set up massive optimization problems that are fundamentally hard to solve.
So even if it’s hard to do, I argue that there are definitely classes of problems that you would struggle to solve without OpenMDAO. Ironically, since OpenMDAO is making it easier to build these hard problems, more users seem to be running into the fact that hard problems are … hard to solve (shocking, I know!)
In the end, this is a good problem to have. If we really are to the point where you can build a problem that is so complex you can’t figure out how to optimize it then OpenMDAO has contributed something to the collective community. Now one of our next challenges is to give you some tools that make these hard problems a little less hard.
October 27, 2020
by admin Comments Off on What to do when OpenMDAO Deprecates A Component?
Working on the RevHack2020 effort, I wanted to run the eVTOL trajectory optimization provided by Shamsheer Chauhan. This code was written for OpenMDAO V2, and I had V3 installed on my machine. While there were no API backwards incompatibilities in V3 that I ran into, the code did use the BSplineComp from the V2.10 standard library which doesn’t exist in V3.
So I couldn’t run the model in my V3 install. I could have installed V2.10 as a separate conda environment, but that seems like overkill. Instead, here are two better options. Both take less than 5 minutes total time:
Fix 1: Update to the latest APIS
We provide an upgrade guide from 2.10 to 3.0, in which there is an example of how to update to SplineComp (V2.10 is in red, V3 is in green).
You can see that it wouldn’t take major changes to get it updated, and the results should be identical but if you would rather not hack on the code at all… maybe you just want to run it exactly as is.
Fix 2: Pull the old component into your model
We deprecated the older BsplineComp, in favor of the newer SplineComp because the newer one has a more consistent API and offers more features. Still, you might be totally happy with the BsplineComp, or perhaps in some other situation there is some missing functionality in the new component thats a problem for you. You just want to use the old component!
One of the best things about using an open source project is that … you have access to the source! You can go back to the last V2 release (V2.10.1) and grab the component code there, then pull it into your own repo.
Then you can navigate the repo, go get the code you want and pull it into your own project. The upside is that you now don’t have to change your code (except to change where you imported the component from). The downside is that you now how to maintain this component yourself if you need any changes in the future.
October 25, 2020
by Justin Gray Comments Off on RevHack 2020 — Halfway there
I will be adding more detailed write ups of these topics into the repository for RevHack 2020, but I want to cover one over-arching idea that is common across all of them: OpenMDAO does not have to be in charge, nor does it have to be the interface you present to your users
Though the dev team tends to let OpenMDAO be in charge, that doesn’t mean that you have to. In fact, it’s possible that for some applications adding a different layer on top that provides a simpler and more standardized interface for your users is the better solution. You’ll see a lot of our answers to the problems posed for RevHack2020 are going to be posed this way — not all, but many.
Moving forward, I think we’ll try to emphasize this use-case more. The native OpenMDAO way isn’t the solution to every single problem. More importantly I am trying to see the world through your (the users) perspective, and would like to find ways to map OpenMDAO use the common — some might argue more natural — types of coding patterns.
What to expect for the second week of RevHack2020
We have started work on solutions for every problem. Most of our effort in the first week went into figuring out what needed to be done and how best to do it. Now that we have had a chance to make some progress, we’ll be posting actual solutions to the repo soon, along with some detailed explanation of why we did things that way. (there are some solutions up already for the CMA-ES problem).
I am putting a lot of effort into seeing the world from your perspective, and the solutions we post will reflect that. As we see them, please feel free to post your own PR’s to modify/question our solutions. The more feedback we get, the better we can tailor things to be useful to you.
October 14, 2020
by Justin Gray Comments Off on 3 Tools for MDAO Success
Multidisciplinary Design Analysis and Optimization … MDAO
Practitioners of MDAO must develop skills in three separate, but closely related, areas: nonlinear optimization, model construction, and model differentiation. An undergraduate STEM education will likely have given given you a brief introduction to all three, and this is enough to get most people started with MDAO.
As your models grow more complex you start to hit walls because your model won’t converge, the optimizer can’t find a “good” answer, the compute cost grows to high, etc. We’ve built OpenMDAO to help alleviate many of these common problems, but it has become a bit of an arms race between the development team and the users. As we add features to solve existing common challenges, our users tend to add model complexity till they run into new ones. I don’t (yet) have a solution to end the arms race but I want to draw a clearer picture of the battle field.
So let’s take a closer look at the three areas I have deemed the keys to success in MDAO. I obviously can’t cover everything, but even just understanding the classification can help you narrow down your problem area and and enable a more focused search for solutions.
Do you know what “optimization” is? Some have joked that it’s an automatic process to find all the bugs, holes, and weaknesses in your model… if you found yourself wincing at that jab, it’s because you know there is more than a little truth to that 🙁
A more mathematical perspective on “optimization” is as a means of converting a underdefined problem with an infinite number of solutions (more degrees of freedom than equations to constrain them) into a well defined one with a single solution (equal number of degrees of freedom and equations). This conversion is done by using the objective function (usually represented by “f”) to say which solution you prefer. Sometimes there are also constraints (represented by “g” and “h”) as well, which help to further constrain the solution space.
There are lots of different kinds of optimizers, some that use derivatives and some that don’t. Optimizers see your model as a black box that maps design variables to objective and constraint values (and sometimes the associated derivatives). The optimizer doesn’t care how you accomplish that mapping, as long as you give it the data it needs.
A lot of optimization challenges occur because you have picked a bad objective function, a bad constraint, or had too many constraints. I find it useful to think of the black-box picture when trying to diagnose these kind of problem-formulation issues. You can ignore all of the internal workings of your model; assume/pretend/wish/fantasize) that it will work perfectly for any given inputs. Then think about how you expect the outputs to react to the inputs, and look for holes there.
OpenMDAO, despite the “O” in the name, doesn’t actually address the optimization area that much. We have a driver interface that provides access to a few of optimizers. Our interface is a useful abstraction that makes it easier to swap between optimizers, but it does not provide the optimization algorithms itself. If you already have a code that provides function evaluations (and derivatives) of everything you care about, then you might actually be better off interfacing directly with some of the optimizer libraries themselves.
The black box perspective says f=F(x). Model construction is everything that has to go into making those six characters actually compute f, for any reasonable value of x. There are two fundamental things you have to deal with when doing model construction: data passing and convergence.
Data passing is usually fairly strait forward. If you’re writing code, it can be as simple as passing the return values of one function as the arguments to the next. Some models use file i/o to pass complex data formats around. Generally speaking data passing is something you probably don’t think about a lot, but depending on what you’re doing it can be pretty important. Thats especially true in any kind of parallel memory situation, or if you have to work on geographically distributed computing and across firewalls. OpenMDAO uses a pretty fancy scheme based on the MAUD architecture that works well both in serial and distributed situations.
With regard to convergence, there is a whole spectrum from trivial to insanely hard challenges that you may encounter. Some models are composed of explicit functions arranged in a purely feed forward sequence. If your model looks like this, I’m jealous! Most of the time though, you end up with some implicit functions in the model. Maybe one of the boxes is implicit (i.e. there is a nonlinear solver inside it), or you have a cycle in the data flow between boxes that requires a top level solver. Often you have both implicit boxes and cyclic data flows… thats when things really start to get interesting. Making models sufficiently stable, so that for any value of “x” you can converge on a value of “f” is critically important. I promise you that if there is some area where your solvers don’t converge, an optimizer is going to find it!
I used the term “nonlinear solver” which you may or may not be familiar with. I am quite certain you’ve used one before. Perhaps you’ve written a while loop to iterate till some error term gets below a tolerance? Thats called a fixed-point solver, or alternatively a nonlinear Gauss-Seidel solver. There is the classic Newton’s method, and a bunch of variations that are very similar — scipy has a nice collection to check out. Of course, OpenMDAO has a good selection too.
Not every MDAO application demands derivatives, but they are usually needed whenever you have expensive function evaluations, large numbers of design variables, or require very tight convergence. Many MDAO practitioners avoid this topic area. It’s understandable, since it’s both challenging and potentially time consuming. But derivatives offer many orders of magnitude computational speedup and greatly improved numerical stability, so they are well worth considering!
This picture looks a lot like he one for model construction. That is intentional. One way to think of this whole process is that you could replace every single box in the model with its local linearized representation then finite-difference over the whole model to compute the total derivatives. Thats not a particularly efficient or simple implementation, but its a nice conceptual context to understand whats needed.
There are lots of ways to compute derivatives. There are numerical approaches such as finite-difference and complex-step methods. You likely learned about manual differentiation techniques based on the chain-rule. You may have also used symbolic differentiation (e.g. sympy) when you found it tedious to manually work through all the equations. Some modern scientific computing languages have an advanced form of symbolic differentiation called algorithmic differentiation which works on computer code directly (rather than having to type it in to the symbolic engine and convert back to code). These computational tools have their roots in the 1960’s when particle physicists were struggling with massive volumes of equations. The 1999 Nobel Prize in physics went to two scientists who pioneered the computer algebra techniques for their work!
All of these techniques work fairly well when you you have feed-forward models of explicit functions. Whenever you have implicit functions, or any kind of cycles in your data passing then the chain rule (and the blunt application of symbolic or algorithmic differentiation) start to break down. More complex techniques like adjoint derivatives, direct derivatives, or the unified derivative equations become valuable. These topics are some of the least widely known amongst MDAO practitioners, and they are also where OpenMDAO offers the most advanced and unique features. OpenMDAO lets you take advantage of the unified derivative equations without actually having to understand them at all!