Hack a fix to issue #91

[odow]

Closes #91

@joaquim, I only have the community edition, so I could trigger this bug for further investigation. Do you have time to take a look? I've done something which I think fixes the issue, but I don't know the underlying cause.

cc @zolanaj

[codecov]

Codecov Report

Merging #94 into master will increase coverage by 2.89%.
The diff coverage is 60.93%.

@@            Coverage Diff             @@
##           master      #94      +/-   ##
==========================================
+ Coverage   46.03%   48.93%   +2.89%     
==========================================
  Files           7        7              
  Lines        3306     3509     +203     
==========================================
+ Hits         1522     1717     +195     
- Misses       1784     1792       +8     

Impacted Files	Coverage Δ
src/MOI/MOI_wrapper.jl	87.70% <60.93%> (+0.75%)	⬆️
src/Xpress.jl	100.00% <0.00%> (ø)
src/utils.jl	79.06% <0.00%> (+2.14%)	⬆️
src/helper.jl	41.96% <0.00%> (+2.14%)	⬆️
src/license.jl	71.42% <0.00%> (+2.19%)	⬆️
src/lib.jl	7.69% <0.00%> (+2.39%)	⬆️
src/api.jl	18.80% <0.00%> (+3.54%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b241a85...ecfdda9. Read the comment docs.

[odow]

@zolanaj can you test this?

[zolanaj]

After applying this patch, I now get a different error:

ERROR: Result index of attribute MathOptInterface.ObjectiveValue(1) out of bounds. There are currently 0 solution(s) in the model. Stacktrace: [1] check_result_index_bounds at C:\Users\AZOLAN\.julia\packages\MathOptInterface\R1y80\src\attributes.jl:133 [inlined] [2] get(::Xpress.Optimizer, ::MathOptInterface.ObjectiveValue) at C:\Users\AZOLAN\.julia\packages\Xpress\kcAft\src\MOI\MOI_wrapper.jl:2447 [3] _moi_get_result(::Xpress.Optimizer, ::MathOptInterface.ObjectiveValue) at C:\Users\AZOLAN\.julia\packages\JuMP\e0Uc2\src\JuMP.jl:840 [4] get(::Model, ::MathOptInterface.ObjectiveValue) at C:\Users\AZOLAN\.julia\packages\JuMP\e0Uc2\src\JuMP.jl:861 [5] objective_value(::Model; result::Int64) at C:\Users\AZOLAN\.julia\packages\JuMP\e0Uc2\src\objective.jl:42 [6] objective_value at C:\Users\AZOLAN\.julia\packages\JuMP\e0Uc2\src\objective.jl:42 [inlined] [7] run_test_case(::Int64, ::Float64, ::String) at C:\Users\AZOLAN\Documents\GitHub\xpress-issue.jl:73 [8] top-level scope at REPL[5]:1

The function reference in MOI_wrapper.jl in this case is:
function MOI.get(model::Optimizer, attr::MOI.ObjectiveValue) _throw_if_optimize_in_progress(model, attr) MOI.check_result_index_bounds(model, attr) if Xpress.is_mixedinteger(model.inner) return Xpress.getdblattrib(model.inner, Xpress.Lib.XPRS_MIPOBJVAL) else return Xpress.getdblattrib(model.inner, Xpress.Lib.XPRS_LPOBJVAL) end end

[odow]

Do you call objective_value in your script? If so, you should only do this after checking termination_status(model) and/or primal_status(model) and verifying that the solver has a solution to return. This error seems reasonable, it is saying it can't query the objective value because there are 0 solutions.

[zolanaj]

The log file indicates that a solution (and upper bound) has been found for the same run though:

Reading Problem 
Problem Statistics
           0 (      0 spare) rows
           0 (      0 spare) structural columns
           0 (      0 spare) non-zero elements
Global Statistics
           0 entities        0 sets        0 set members
Minimizing MILP 
Original problem has:
     21000 rows        21010 cols        51000 elements     10010 globals
Presolved problem has:
     20922 rows        20932 cols        50142 elements     10010 globals
LP relaxation tightened
Will try to keep branch and bound tree memory usage below 11.1Gb
Starting concurrent solve with dual, primal and barrier (6 threads)

                           Concurrent-Solve,   1s
            Dual                      Primal                     Barrier      
                                                          objective   sum inf 
                         |                          |  P  6090.2971   .0000000
----- interrupted ------ | ----- interrupted ------ | ------- optimal --------
Concurrent statistics:
      Dual: 11476 simplex iterations, 0.35s
    Primal: 15327 simplex iterations, 0.35s
   Barrier: 17 barrier and 0 simplex iterations, 0.35s
            Barrier used 6 threads 4 cores, L1\L2 cache: 32K\8192K
            Barrier used AVX support
Optimal solution found

   Its         Obj Value      S   Ninf  Nneg        Sum Inf  Time
     0       6090.297146      P      0     0        .000000     1
Barrier solved problem
  17 barrier iterations in 1s

Final objective                         : 6.090297145641871e+03
  Max primal violation      (abs / rel) :       0.0 /       0.0
  Max dual violation        (abs / rel) :       0.0 /       0.0
  Max complementarity viol. (abs / rel) :       0.0 /       0.0
All values within tolerances

Starting root cutting & heuristics

 Its Type    BestSoln    BestBound   Sols    Add    Del     Gap     GInf   Time
k         8063.176781  6090.297146      1                 24.47%       0      1
c         6288.141561  6090.297146      2                  3.15%       0      1
STOPPING - MAXTIME limit reached.
 *** Search unfinished ***    Time:     2 Nodes:          0
Number of integer feasible solutions found is 2
Best integer solution found is  6288.141561
Best bound is  6090.297146

So, for some reason, one or more solutions are found, but aren't accessed at this point in post-processing. The model termination status in this setting is MOI.OTHER_ERROR when I think it should be MOI.TIME_LIMIT.

[odow]

Any ideas how I can't get a license to reproduce this? I hit the 5000 rows+cols limit on my trial.

[zolanaj]

Not a permanent solution, but I know they offer a 60-day trial license:
https://content.fico.com/l/517101/2019-03-05/6w6k7

[odow]

I don't know what was going on with the status reporting; the block containing the time limit block was unreachable. Try now. I applied for a license.

[zolanaj]

Looks great! Status is now MOI.TIME_LIMIT when the optimizer times out and a feasible solution has been found, and the upper bound is reported correctly. After including the updates from #93, the correct lower bound is reported as well. Thanks very much for these!

[joaquimg]

this is not 100%, when the original version fails we might be getting bad results.
I will open an issue.
I have a candidate fix.