GEKKO solution not converging to sufficiently small number

Question

The accepted answer on my question regarding NaN in objective function helped a lot. I now somehow run into the problem where the convergence value reported does not go below a certain value as depicted below:

Iter    Objective  Convergence
  20 -1.55305E+04  1.78101E+00
  21 -1.54846E+04  1.78101E+00
  22 -1.55665E+04  1.42371E+00
  23 -1.55675E+04  1.42371E+00
  24 -1.55209E+04  1.78101E+00
  25 -1.54972E+04  2.00348E+00
  26 -1.54750E+04  1.78101E+00
  27 -1.54835E+04  1.78101E+00
  28 -1.55488E+04  1.78101E+00
  29 -1.55047E+04  1.78101E+00
  
Iter    Objective  Convergence
  30 -1.55043E+04  1.78101E+00
  31 -1.55043E+04  1.78101E+00
  32 -1.55054E+04  1.78101E+00
  33 -1.55058E+04  1.78101E+00
  34 -1.55517E+04  1.78101E+00

The context of the problem might be appropriate. I am optimising a complex make-store-use system. The inventory limits of the store subsystem are represented as CV's that have obvious integrator models to the inventory balance around the storage system. At times it might be useful to the evaluate the decoupling of the make and use sub--systems , i.e. prevent limitations on the use subsystem to turn down the make sub-system. This can be done by 'dropping' the inventory CV's by setting cv.STATUS=0. When I do that the convergence gets stuck at 1.78 and after maximum iteration an unsuccessful solution is reported. When the inventory are controlled within bounds, the solution converge within a few iterations with convergence reported as 0.00004. (OTOL=0.1, RTOL=0.01).

The inventories is part of the objective function via cv.COST=-0.01 to incentivise building inventory when possible.

I am suspecting that because of the integrating model of the inventories and the fact that it is not controlled but still form part of the objective function, non-convergence might be inferred. If so, how should I treat such problems?

score 1 · Answer 1 · answered Apr 02 '23 at 04:24

Without specific code for testing, it is difficult to diagnose the problem. Here are a few ideas:

If using m.options.CV_TYPE=1 (l1-norm objective), try setting a small WSPHI and WSPLO value such as 1e-5 instead of turning off the CV with STATUS=0. This effectively de-prioritizes the inventory CV, but still tries to minimize e_hi and e_lo from the l1-norm objective. With no minimization, e_hi and e_lo can be any value and make it more difficult to converge.
Set a lower bound on the make and use rates of 0 and a reasonable upper bound. There is often a failure to converge if a quantity, such as inventory, is unbounded towards infinity.
Check the scaling on the equations. Unit conversions can help to avoid very large or very small gradient values that are difficult to converge. For example, if there is a population balance for the world:

population = m.Var(7.9e9)
m.Equation(population.dt() == birth_rate - death_rate)

because the population is very large, I would divide by a scaling factor such as 1e9 to scale the units to billons of people.

s = 1e9; population = m.Var(7.9)
m.Equation(population.dt() == (birth_rate - death_rate)/s)

I'm not sure why scaling would make a difference if the STATUS is off or on, but it is something I check when the solver has trouble converging.

GEKKO solution not converging to sufficiently small number

1 Answers1