1

I'm pretty new to OpenMDAO. If would like to setup my problem such that there is a subdiscipline that is driven by its own optimizer, and it hands off the results to the top level problem, where a separate optimizer will use those results.

For a bit more context, the sub-problem is trajectory optimization of a vehicle. I successfully got that problem to converge in a few iterations, without varying the vehicle parameters (mass, thrust, fuel etc.). So far so good. However, if I let the optimizer also vary some vehicle parameters, it can't seem to get it to go to the global optimum.

So my thought was to let trajectory optimization subproblem do what it does succesfully, and incorporate that as subproblem to the overall problem, and see if that works better.

So my question is:

  1. Can an OpenMDAO problem have multiple drivers?
  2. What's the right way to set that up? Do I wrap my subproblem into its own ExplicitComponent?
Mark Garnett
  • 197
  • 7

1 Answers1

0

While this is possible, solving a problem in this way will not pass accurate analytic derivatives between the system design and the trajectory design.

We've developed another tool specifically for the purpose of doing multidisciplinary optimization which involves trajectory optimization. Dymos It supports pseudospectral methods (like those in GPOPS, PSOPT, and OTIS) as well as shooting methods, and it allows a trajectory to be optimized as part of a larger system optimization problem.

Take a look at some of the example problems and see if it might work for you.

Rob Falck
  • 2,324
  • 16
  • 14
  • Thank you Rob. I am checking out Dymos and it looks pretty interesting. I actually am working on launch vehicle optimization and I see there are a few examples there on that subject. I am using a compiled program (not written by me) to the trajectory shooting, while letting SLSQP optimize for payload while meeting constraints (final orbit, max Qalpha). In the interest of making progress I am going to wrap the trajectory optimization in a component as explained here (https://stackoverflow.com/questions/35287786/how-to-use-nested-problems-in-openmdao-1-x/35295627#35295627) and see where I get. – Mark Garnett Aug 10 '20 at 16:54
  • Dymos looks interesting but I'll have to do quite a bit of work to replicate the full functionality of the trajectory program I am using now -- 3 DOF and all that – Mark Garnett Aug 10 '20 at 17:00
  • It's understandably a large undertaking. If you need to rely on that external tool, you could try OpenMDAO's ExternalCodeComp to wrap that external executable. The downside is that it likely doesn't provide analytic sensitivities of its outputs w.r.t. its inputs, so you'll lose that, and finite differencing across the "black box" will be a bit slower. – Rob Falck Aug 11 '20 at 12:56