Decision Optimization

Decision Optimization

Delivers prescriptive analytics capabilities and decision intelligence to improve decision-making.

 View Only
  • 1.  doopl solve model twice useing main flow control. strange

    Posted Thu December 19, 2019 04:31 AM

    Originally posted by: qtbgo


    Dear IBM,

    1  I have a test.py as follows:

    DATADIR = join(dirname(abspath(__file__)))

    mod = join(DATADIR, 'main.mod')

    with create_opl_model(model=mod) as opl:    

        opl.run()

     

    2 Then, the main.mod is:

     

    string mipModel = "test.mod";

    subject to {

        

    }

    main{

       thisOplModel.generate();   

       var MIPSrc = new IloOplModelSource(thisOplModel.mipModel);

       var MIPDef = new IloOplModelDefinition(MIPSrc);

       var MIPData = thisOplModel.dataElements;      

       var MIPModel = new IloOplModel(MIPDef, cplex);

       MIPModel.addDataSource(MIPData);

       MIPModel.generate();

     

       cplex.solve();

       MIPModel.postProcess(); 

    }

    3 the test.mod is:

    dvar boolean x;

    minimize x;

    subject to {

      x>=1;

    }

    execute{

      writeln();

      writeln("good");

    }

     

    When I run test.py, in the log, I found it solves the model twice. Very strange, any idea?


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 2.  Re: doopl solve model twice useing main flow control. strange

    Posted Thu December 19, 2019 04:32 AM

    Originally posted by: qtbgo


    I have attached the three files above.


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 3.  Re: doopl solve model twice useing main flow control. strange

    Posted Thu December 19, 2019 06:26 AM

    Originally posted by: Viu-Long Kong


    The output of your main.mod looks like:

     

    Found incumbent of value 1.000000 after 0.00 sec. (0.00 ticks)
    Tried aggregator 1 time.
    MIP Presolve eliminated 1 rows and 1 columns.
    All rows and columns eliminated.
    Presolve time = 0.00 sec. (0.00 ticks)Root node processing (before b&c):
      Real time             =    0.00 sec. (0.00 ticks)
    Parallel b&c, 12 threads:
      Real time             =    0.00 sec. (0.00 ticks)
      Sync time (average)   =    0.00 sec.
      Wait time (average)   =    0.00 sec.
                              ------------
    Total (root+branch&cut) =    0.00 sec. (0.00 ticks)
    good
    Root node processing (before b&c):
      Real time             =    0.00 sec. (0.00 ticks)
    Parallel b&c, 12 threads:
      Real time             =    0.00 sec. (0.00 ticks)
      Sync time (average)   =    0.00 sec.
      Wait time (average)   =    0.00 sec.
                              ------------
    Total (root+branch&cut) =    0.00 sec. (0.00 ticks)
    

     

    The first log (before your 'good' print) is the execution log for your test.mod, while the second log is the execution log for your main.mod.

    You can try opl.mute() in test.py if you don't want those to be displayed.


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 4.  Re: doopl solve model twice useing main flow control. strange

    Posted Thu December 19, 2019 08:32 AM

    Originally posted by: qtbgo


    Thank you Viu-Long Kong. But according to my understanding, test.py call main.mod. And in main.mod, it solves the test.mod,  I think after calling MIPModel.postProcess(), there should be no solve again. But it'seems the engine solves the second time.  opl.mute() can only hide display, it cannot stop the second solve.

     

    In my real project, I have a larger model than the test.mod. So, the second solve would last a long time.


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 5.  Re: doopl solve model twice useing main flow control. strange

    Posted Thu December 19, 2019 09:08 AM

    Originally posted by: Viu-Long Kong


    I just tried substituing test.mod for something larger in main.mod.

    The run log says:

     

    Found incumbent of value 0.000000 after 0.00 sec. (0.01 ticks)
    Tried aggregator 1 time.
    Reduced MIP has 495 rows, 55 columns, and 1485 nonzeros.
    Reduced MIP has 55 binaries, 0 generals, 0 SOSs, and 0 indicators.
    Presolve time = 0.00 sec. (0.62 ticks)
    Probing time = 0.00 sec. (0.08 ticks)
    Tried aggregator 1 time.
    Reduced MIP has 495 rows, 55 columns, and 1485 nonzeros.
    Reduced MIP has 55 binaries, 0 generals, 0 SOSs, and 0 indicators.
    Presolve time = 0.00 sec. (0.98 ticks)
    Probing time = 0.00 sec. (0.08 ticks)
    MIP emphasis: balance optimality and feasibility.
    MIP search method: dynamic search.
    Parallel mode: deterministic, using up to 12 threads.
    Root relaxation solution time = 0.01 sec. (3.25 ticks)

            Nodes                                         Cuts/
       Node  Left     Objective  IInf  Best Integer    Best Bound    ItCnt     Gap

    *     0+    0                            0.0000       55.0000              --- 
    *     0+    0                           15.0000       55.0000           266.67%
    *     0+    0                           16.0000       55.0000           243.75%
    *     0+    0                           17.0000       55.0000           223.53%
    *     0+    0                           18.0000       55.0000           205.56%
          0     0       36.6667    55       18.0000       36.6667      124  103.70%
          0     0       36.0000    55       18.0000      Cuts: 22      183  100.00%
    [... snipped of log ...]
          0     0       34.0139    55       19.0000   ZeroHalf: 9      901   44.87%
          0     2       34.0139    55       19.0000       27.5256      901   44.87%
    Elapsed time = 0.22 sec. (140.90 ticks, tree = 0.02 MB, solutions = 6)
       4512  2883       33.5852    55       19.0000       24.5000    60247   28.95%
      11036  3208       21.0000    28       19.0000       23.5000   130582   23.68%
      21590  5404       21.0000    29       19.0000       21.6667   239351   14.04%
    * 24276  5164      integral     0       20.0000       21.3500   260596    6.75%

    Zero-half cuts applied:  39
    Gomory fractional cuts applied:  1

    Root node processing (before b&c):
      Real time             =    0.22 sec. (140.65 ticks)
    Parallel b&c, 12 threads:
      Real time             =    1.28 sec. (865.77 ticks)
      Sync time (average)   =    0.21 sec.
      Wait time (average)   =    0.00 sec.
                              ------------
    Total (root+branch&cut) =    1.50 sec. (1006.43 ticks)
    === MIPModel finished ===

    Root node processing (before b&c):
      Real time             =    0.00 sec. (0.00 ticks)
    Parallel b&c, 12 threads:
      Real time             =    0.00 sec. (0.00 ticks)
      Sync time (average)   =    0.21 sec.
      Wait time (average)   =    0.00 sec.
                              ------------
    Total (root+branch&cut) =    0.00 sec. (0.00 ticks)

     

     

    As you can see with the '=== MIPModel finished ===' log: all before that line are execution log for my model (loving_hearts.mod modified so that log is not too large).

    Everything after is the execution log for main.mod - if my model was run twice, I would have 2 identical logs, right ?

     

    If you experience that your main.mod runs test.mod twice, please send me your model at viulong.kong@fr.ibm.com (note: I'll be off from today and will be back in january, so it make take some time for an answer)

     

    Thanks


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 6.  Re: doopl solve model twice useing main flow control. strange

    Posted Mon January 27, 2020 01:43 AM

    Originally posted by: qtbgo


    I attach a test model, it seems clearly that the second solve continues the first solve.


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 7.  Re: doopl solve model twice useing main flow control. strange

    Posted Mon January 27, 2020 01:48 AM

    Originally posted by: qtbgo


    attached is the log:


    #DecisionOptimization
    #OPLusingCPLEXOptimizer


  • 8.  Re: doopl solve model twice useing main flow control. strange

    Posted Mon January 27, 2020 02:00 AM

    Originally posted by: qtbgo


    by the way. When will doopl support cplex 12.10?


    #DecisionOptimization
    #OPLusingCPLEXOptimizer