Passing guesses to solver

41 views
Skip to first unread message

Andrea Zignoli

unread,
Aug 18, 2021, 8:10:41 AM8/18/21
to apmonitor
Hi all, 

I've been struggling with this a lot lately. I'm using Gekko for one of our project, where we computed the optimal manoeuvre for a bike-rider system along a course (dynamic optimisation problem, solved with optimal control solver). The problem is solved in an MPC fashion, meaning that it's solved multiple times and has a moving horizon.

However, the main problem is that it looks I can only provide initial conditions to the solver, not guesses. What I mean here is that I would like to use the solution computed in the previous iteration step, to reduce the computational time during the next step. 

There are references to "guess" in the main Gekko documentation, but I cannot find valuable example about how provide a guess for a state variable. 

Can anyone direct/help me in these regards with an example, code snippet or a hint? 

Thank you so much

Andrea

John Hedengren

unread,
Aug 18, 2021, 8:20:10 AM8/18/21
to APM Google Groups
Andrea,

Gekko automatically uses the prior time step solution to "warm-start" the next solution. The solution is shifted by the number of steps given with m.options.TIME_SHIFT (default 1). When the solution is time-shifted, the last "TIME_SHIFT" steps are equal to the last prior value. You can also give an initial guess for any variable "x" with x.value = [0.1,0.2,0.3,0.5,0.8] with a length equal to m.time. Internally, Gekko changes x.value.value and sets x.value.change=True to override the default values in the gk0_model.csv file as shown in m.path when m=GEKKO(remote=False).

If the problem is that you need a faster solution then I recommend that you use a non-uniform m.time such as [0,0.1,0.2,0.5,1.0,2.0,4.0,10]. The first step is the cycle time of the controller. The additional steps are used to maintain solution accuracy and approach an infinite horizon approximation. You can also try a different solver such as m.options.SOLVER = 1 after the first solution. IPOPT (m.options.SOLVER=3) is often better at initialization but APOPT (1) is often better from warm-start solutions.

This is a great question. If you need further assistance, please consider posting to StackOverflow with tag [gekko] with an illustrative example of the problem.

-John Hedengren



--
--
APMonitor user's group e-mail list.
- To post a message, send email to apmo...@googlegroups.com
- To unsubscribe, send email to apmonitor+...@googlegroups.com
- Visit this group at http://groups.google.com/group/apmonitor
---
You received this message because you are subscribed to the Google Groups "apmonitor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apmonitor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/apmonitor/c121810e-51a2-4f16-9a24-b3c35bc20f90n%40googlegroups.com.


--
Best regards,

John Hedengren
GEKKO Optimization Suite

Andrea Zignoli

unread,
Aug 18, 2021, 8:40:07 AM8/18/21
to apmonitor
Oh wow... can't believe it. Honestly, now that you tell me, sounds reasonable! I will be defining an array of equal length of the time. I didn't think about that. Did not now it was possibile.
This is great and I'm going to try that asap. Thank you for your advice on the non-uniform distribution, the IPOPT vs APOPT warm-start computation speed and accuracy. 

Thank you so much Sir for your great answer and overall work. 

Andrea 
Reply all
Reply to author
Forward
0 new messages