How do I warm start a dymos optimization problem?

0
votes

My problem: I have a system with 4 states and 4 parameters (static) that I would like to optimize. The parameters are initialized to some known values that would result in trajectories that respect constraints. The states are initialized to a constant value. To verify the model, I run the problem where the parameters setting opt=False. Once verified, I rebuild the OpenMDAO problem with opt=True and run the optimizer.

I'm running a study to evaluate how each parameter affects the system, cost function, etc. and how the initial guess impacts the optimization (ideally, it doesn't). The problem I encounter is that some initial guesses for a parameter result in a failed optimization (iteration limit or positive line search) while others don't and it's not immediately clear why. Note: I always provide an initial guess for the problem that results in feasible trajectories. I check this by setting opt=False for the parameters when I build the problem. My assumption is that although my initial guess for the parameters are okay, my initial guess for the states is not and the problem gets stuck trying to get feasible trajectories.

My solution/idea: Is it possible to warm start an optimization problem in Dymos? To warm start, I would like to provide a feasible solution to the states and state rates of the optimizer. As a general flow I would like to first (1) run the optimization with the opt setting in controls and parameters set to False to get a state trajectory, then (2) set the opt setting for controls and parameters to True, and finally (3) re-run the optimization. It seems like there should be an easy way to do this, but I can't determine how without creating 2 problems (with different opt settings) and setting all the initial state guesses of the opt=True problem.

Note: I did read this post: Dymos how to use previous trajectory solution as initial guess? and I can rerun a problem. I just don't know how to change the opt setting between runs.

If there is an alternate or better solution to my problem, I'd be interested in that as well.

1
openmdao
Using the previously cited post, you'd build the problem and set opt=False on your design variables, and use dymos.run_problem to generate output files from a simulated trajectory. The next time running your code (or using a different run script), set those flags to opt=True and load the previous solution as defined. It should start with that trajectory as a solution and iterate from there. - Rob Falck
This worked! Thanks for the information. I think I misunderstood that previous post when I saw that it wasn't running the driver on the the first 'run_problem()' execution. If I understand correctly, the simulated and optimized trajectories should be the same so they are equivalent ways to setup the optimization. I've provided my version of the code below that uses the optimized trajectory instead of the simulated trajectory. - Chris
First, run the problem with all settings opt=False and save the output as 'Baseline.db'. # Run the problem without optimizing controls and parameters: dm.run_problem(p,solution_record_file='Baseline.db') Second, set the desired settings opt=True and rebuild the problem. Third, run the new problem using the previous solution as a guess. dm.run_problem(p, run_driver=True, simulate=False, restart='Baseline.db') - Chris
The collocation/pseudospectral techniques used in dymos enforce the physical validity of the trajectory by constraints on the transcribed optimization problem. When you start with run_driver=False, simulate=True options to run_problem, you're skipping the initial optimization and telling dymos "just simulate the trajectory from the initial conditions using the initial guesses for the controls and parameters". This provides a physically valid trajectory so those defect constraints will be close to zero (we're making the optimizer's job easier). - Rob Falck
The downside is that, for some problems, it's very difficult to provide a valid initial control guess. The minimum time climb problem is notorious for this. A bad guess of the alpha control history will send the flight path vertical, where the equations of motion are singular. Sometimes it's useful to shorten the t_duration guess so that you get physically valid simulation even if the guess doesn't get close to your desired final boundary constraints. - Rob Falck

1 Answers

1
votes

If you are using IPOPT, using a previous solution as your initial guess doesn't really help. This is due to the nature of interior point optimizers. On start, the barrier parameter mu is large. This will push the "optimum" solution, for that value of the barrier parameter mu, from doing Newton's method, AWAY from the initial guess. Then mu is decreased, Newton's method gets you closer to the true optimum. This process gets repeated as mu as decreased, until finally mu is small and you get back to the point, which was the optimum that you guessed initially.

Also, because we are using a Quasi-Newton method with a limited-memory Hessian approximation (L-BFGS) when going through Dymos/pyoptsparse, all the information about the Hessian is not there when you start again even if your initial guess is the optimum. So that information has to be filled in again as the algorithm iterates.

I am not an IPOPT expert but this seems to explain why I had no luck trying to use an "improved" initial guess. One thing that did help a lot with convergence was increasing the "limited_memory_max_history" parameter to 100 or so.

IPOPT does have the warm-start option but getting it the initial information it needs regarding the Hessian and initial multipliers might be something you have to go into pyoptsparse to figure out how to do.