What is the best approach to obtain initial values for a GEKKO optimisation problem?

Question

I have a dynamic control problem with about 35 independent variables, many intermediate variables and a few equations, mainly to enforce a sensible mass balance by limiting certain dependent variables (representing stream flows) to be positive.

Initially the variables were declared using the m.Var() constructor but I consequently upgraded them to MV an CV variables to capitalize on flexibility of tuning attributes such as COST , DCOST , etc. that these classes add.

I noticed that IPOPT (3.12) does not produce a solution (Error reported: EXIT: Converged to a point of local infeasibility. Problem may be infeasible ) when a set of variables are configured as MV 's, yet when one is instantiated as a Var a successful solution is returned. I re-instantiated the variable as MV and systematically removed constraints to try and pinpoint the constraining equation. I discovered that the set of initial conditions I provided for the independent variables constituted an infeasibility (it resulted in value of -0.02 on a stream that have a positive constraint on it). Although RTOL can probably be used to solve the problem for this case, I do not think it is correct general approach. I have tried COLDSTART=2 but do not know how to interpret the presolve.txt file generated.

Firstly, is there some standard functionality to assist with this situation or should one make sure the initial guesses represent a feasible solution.

Secondly, why would the inability to produce a successful solution only manifest when the variable is declared as an MV as opposed to the less decorated Var ?

Answer 1

The m.Var() creates an additional degree of freedom for the optimizer while m.Param() creates a quantity that is determined by the user. The m.Var() types can be upgraded to m.SV() as state variables or m.CV() as controlled variables. The m.Param() type is upgraded to m.FV() for fixed values or m.MV() for manipulated variables. If the STATUS parameter is turned on for those types then they also become degrees of freedom. More information on FV , MV , SV , and CV types is given in the APMonitor documentation and Gekko Documentation . The problem likely becomes feasible because of the additional degree of freedom. Try setting the m.MV() to an m.SV() to retain the degree of freedom from the m.Var() declaration.

Initial solutions are often easiest to obtain from a steady-state simulation. There are additional details in this paper:

Here is a flowchart that I typically use:

There are additional details in the paper on how COLDSTART options work. If the solver reports a successful solution, then there should be no constraint violations.