help with pwa-controller

33 views
Skip to first unread message

Radek Horalek

unread,
Jan 7, 2014, 11:44:55 AM1/7/14
to yal...@googlegroups.com
Hello,
I have problem to solve my online pwa-mpc controller. Controller gives good results for all initial states except of states, which are "border" between 2 dynamics
(e.g. dyn1: 50<=x24<=52, dyn2: 52<=x24<=54 and current value of x24=52). In that case solver keeps running failing to terminate. When I change "manually" value of x24 for example to 52.0001 (and all other states remain unchanged) it works good again. This problem appears for all 9 borders (I have currently 10 dynamics). Controller was created in MPT and converted to YALMIP. I used "solvesdp" function to get output you can see bellow. Any idea what is the problem?

Best regards,
Radek

 ----------
Optimize a model with 49348 rows, 2905 columns and 912542 nonzeros
Model has 80 quadratic objective terms
Presolve removed 41660 rows and 899 columns
Presolve time: 2.87s
Presolved: 7688 rows, 2006 columns, 170624 nonzeros
Presolved model has 79 quadratic objective terms
Variable types: 1926 continuous, 80 integer (80 binary)

Root relaxation: objective 1.206249e-04, 829 iterations, 0.04 seconds

    Nodes    |    Current Node    |     Objective Bounds      |     Work
 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | It/Node Time

     0     0    0.00012    0   79          -    0.00012     -      -    3s
     0     0    0.00012    0   79          -    0.00012     -      -    5s
     0     0    0.00012    0   80          -    0.00012     -      -    6s
     0     3    0.00012    0   80          -    0.00012     -      -   14s
     9    13    0.00012    6   74          -    0.00012     -    852   15s
    18    24    0.00012    8   72          -    0.00012     -   4065   24s
    24    30    0.00012    9   71          -    0.00012     -   6320   31s
    31    37    0.00012   10   70          -    0.00012     -   8138   37s
    39    44    0.00012   11   69          -    0.00012     -   8982   44s
    47    49    0.00012   11   69          -    0.00012     -   9841   51s
    55    58    0.00012   12   68          -    0.00012     -  10343   56s
    63    65    0.00012   12   68          -    0.00012     -  10534   62s
    71    73    0.00012   13   67          -    0.00012     -  10598   68s
    79    82    0.00012   13   67          -    0.00012     -  11101   75s
    87    88    0.00012   14   66          -    0.00012     -  11395   80s
    95    96    0.00012   15   65          -    0.00012     -  11530   87s
   103   105    0.00012   16   64          -    0.00012     -  12047  264s
   162   166    0.00012   23   57          -    0.00012     -  16917  328s
   235   236    0.00012   32   48          -    0.00012     -  17763  450s
   308   306    0.00012   34   46          -    0.00012     -  20076  600s

Cutting planes:
  Gomory: 5
  Implied bound: 1176
  MIR: 1144

Explored 360 nodes (8640057 simplex iterations) in 600.04 seconds
Thread count was 8 (of 8 available processors)

Time limit reached
Best objective -, best bound 1.206248998642e-04, gap -

info =
    yalmiptime: 11.0230
    solvertime: 600.1090
    info: 'Maximum iterations or time limit exceeded (GUROBI-GUROBI)'
    problem: 3


Johan Löfberg

unread,
Jan 7, 2014, 11:50:22 AM1/7/14
to yal...@googlegroups.com
I suspect MPT has a bug in the way it sets up the model. Something along the lines of this in the case when we have to regions

if in region 1 turn on binary 1
if in region 2 turn on binary 2
binary1 + binary2 == 1

clearly this will be infeasible if we are in both regions at the initial state

A better model is

if binary 1 we must be in region 1
if binary 2 we must be in region 2
binary1 + binary2 == 1

This is feasible even though we are in both regions in the initial state

Michal will probably tell me if I am wrong

Michal Kvasnica

unread,
Jan 7, 2014, 1:32:18 PM1/7/14
to yal...@googlegroups.com
In MPT3 we use the implies(binary, region) syntax with the additional xor condition on all binaries. That's the correct approach, isn't it? Radek's problem, however, is not infeasible. It's Gurobi which runs into some sort of numerical problems (I have seen that a lot recently with Gurobi 5.6 on multiple LPs).

Radek, to further debug the issue please send the complete problem formulation to my personal email.

-michal
Reply all
Reply to author
Forward
0 new messages