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.
Check out the cool stuff we did:
- Wrapped OpenVSP in OpenMDAO and integrated it with OpenAerostruct.
- Got OpenMDAO + OpenVSP working in google collab (run OpenMDAO in the cloud!)
- Sped up the optimization of an eVTOL take-off trajectory optimization by an order of magnitude.
- Wrote a driver for the CMA-ES optimization library (serial and parallel versions)
- Updated an unsteady aerodynamic simulation from V0 to V3, and experimented with a sub-problem based solution structure
- Played with nested optimizations, trying out sub-problems and solver-based alternatives.
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.
2) We need to better job of making OpenMDAO easier to use. That means making bigger components, supporting algorithmic differentiation, and giving clear examples of how to leverage sub-problems when you want to do things like for-loops, use derivatives as outputs in a model, and sub-optimizations.
Maybe we don’t need drivers at all
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.
