HiGHS OTHER_ERROR

Specific Domains Optimization (Mathematical)
,
1

What does this mean? Is it infeasible, is it solved? Thx

Running HiGHS 1.12.0 (git hash: 755a8e027a): Copyright (c) 2025 HiGHS under MIT licence terms
LP has 4246 rows; 3330 cols; 15361 nonzeros
Coefficient ranges:
  Matrix  [1e-01, 2e+03]
  Cost    [9e-04, 4e+07]
  Bound   [1e-01, 4e+02]
  RHS     [1e+00, 1e+01]
WARNING: Problem has some excessively large costs
WARNING:    Consider scaling the objective by 1e-2, or setting the user_objective_scale option to -6
Solving LP with useful basis so presolve not used
Using EKK dual simplex solver - serial
  Iteration        Objective     Infeasibilities num(sum)
          0    -8.5248019006e+03 Ph1: 333(469037); Du: 74(8.5267) 0s
       2914     2.1700895546e+14 Pr: 751(3.00469e+17) 5s
Model status        : Not Set
HiGHS run time      :          5.05
2

Maybe it gave up because of the reason explained in the warnings ?

WARNING: Problem has some excessively large costs
WARNING:    Consider scaling the objective by 1e-2, or setting the user_objective_scale option to -6
3

Applied the option it suggested. Now it complains that the cost is very small, but it solves it.

4

Can you share a reproducible example or the MPS file?

1 Like
5

Sure

6

What’s the output of solution_summary? Something weird happened with the status not set. Looks like a bug we can fix

7 
solution_summary(; result = 1, verbose = false)
├ solver_name          : HiGHS
├ Termination
│ ├ termination_status : OTHER_ERROR
│ ├ result_count       : 0
│ ├ raw_status         : There was an error calling optimize!
│ └ objective_bound    : 0.00000e+00
├ Solution (result = 1)
│ ├ primal_status        : NO_SOLUTION
│ ├ dual_status          : NO_SOLUTION
│ └ relative_gap         : 0.00000e+00
└ Work counters
  ├ solve_time (sec)   : 1.36276e+00
  ├ simplex_iterations : 0
  ├ barrier_iterations : 0
  └ node_count         : 0
8

I created an issue here: OTHER_ERROR for model · Issue #316 · jump-dev/HiGHS.jl · GitHub
Thx for looking into it.

9

This looks weird as well.
How can it be OPTIMAL when it is an INFEASIBLE_POINT?

solution_summary(; result = 1, verbose = false)
├ solver_name          : HiGHS
├ Termination
│ ├ termination_status : OPTIMAL
│ ├ result_count       : 1
│ ├ raw_status         : kHighsModelStatusOptimal
│ └ objective_bound    : 1.70224e-04
├ Solution (result = 1)
│ ├ primal_status        : INFEASIBLE_POINT
│ ├ dual_status          : NO_SOLUTION
│ ├ objective_value      : 1.08943e-02
│ ├ dual_objective_value : NaN
│ └ relative_gap         : 0.00000e+00
└ Work counters
  ├ solve_time (sec)   : 7.68070e-02
  ├ simplex_iterations : 564
  ├ barrier_iterations : -1
  └ node_count         : 1
10

This can happen when a solver solves the presolved model to optimality, but when it unscales the solution to the original user-space, the point is (slightly) infeasible. This is not specific to HiGHS (e.g., it also happens with CPLEX) .

Maybe I need to write some proper documentation for this in the JuMP docs.

I’ll also discuss it with the HiGHS folks.

1 Like
11

JuMP’s solution_summary has its own design such that it does not perfectly correspond to each solver. It this true?

12

Maybe I need to write some proper documentation for this in the JuMP docs

solution_summary is just a helper function to print out different attributes.

I have a question: what is the dual_objective_value below

Please start new questions instead of posting at the bottom of someone else’s thread.

13

I have another one do not quite get. This time it is even an LP:

Running HiGHS 1.12.0 (git hash: 755a8e027): Copyright (c) 2025 HiGHS under MIT licence terms
LP has 34868 rows; 20424 cols; 76248 nonzeros
Coefficient ranges:
  Matrix  [2e-05, 1e+04]
  Cost    [3e-02, 8e+01]
  Bound   [1e+00, 1e+04]
  RHS     [1e-04, 2e+03]
Presolving model
10532 rows, 10640 cols, 35504 nonzeros  0s
7908 rows, 8016 cols, 33259 nonzeros  0s
Dependent equations search running on 1790 equations with time limit of 6.00s
Dependent equations search removed 0 rows and 0 nonzeros in 0.00s (limit = 6.00s)
7718 rows, 7918 cols, 31688 nonzeros  0s
Presolve reductions: rows 7718(-27150); columns 7918(-12506); nonzeros 31688(-44560)
Solving the presolved LP
Using EKK dual simplex solver - serial
  Iteration        Objective     Infeasibilities num(sum)
          0     0.0000000000e+00 Ph1: 0(0) 0s
       7216     9.8156324683e+03 Pr: 0(0); Du: 0(1.34825e-12) 1s

Performed postsolve
Solving the original LP from the solution after postsolve

Model status        : Optimal
Simplex   iterations: 7216
Objective value     :  9.8156324683e+03
P-D objective error :  7.4771018698e-14
HiGHS run time      :          1.21
Running HiGHS 1.12.0 (git hash: 755a8e027): Copyright (c) 2025 HiGHS under MIT licence terms
LP has 34868 rows; 20424 cols; 76248 nonzeros
Coefficient ranges:
  Matrix  [2e-05, 1e+04]
  Cost    [3e-02, 8e+01]
  Bound   [1e+00, 1e+04]
  RHS     [1e-04, 2e+03]
Solving LP with useful basis so presolve not used
Using EKK dual simplex solver - serial
  Iteration        Objective     Infeasibilities num(sum)
          0    -1.5149276219e+09 Pr: 6560(2.11687e+13); Du: 0(3.14271e-07) 0s
Model status        : Not Set
HiGHS run time      :          0.24

│ solution_summary(; result = 1, verbose = false)
│ ├ solver_name          : HiGHS
│ ├ Termination
│ │ ├ termination_status : OTHER_ERROR
│ │ ├ result_count       : 0
│ │ ├ raw_status         : There was an error calling optimize!
│ │ └ objective_bound    : 0.00000e+00
│ ├ Solution (result = 1)
│ │ ├ primal_status        : NO_SOLUTION
│ │ ├ dual_status          : NO_SOLUTION
│ │ └ relative_gap         : 0.00000e+00
│ └ Work counters
│   ├ solve_time (sec)   : 2.42043e-01
│   ├ simplex_iterations : 0
│   ├ barrier_iterations : 0
│   └ node_count         : 0
14

Can you do

HiGHS.Highs_writeModel(unsafe_backend(model), "model.mps")

and then send me the MPS?

Why are there two solves? Can you post a reproducible example?

15

It’s an MPC test case, where I use the old solution as a starting value. Is that a hint?

Unfortunately I cannot supply a reproducible example. But maybe I get the error again and can provide an MPS - it is very sporadic. There are other things happening that influence the problem data, but I got this a few times earlier, so I am not sure.
Is the JuMP MPS way also fine?

16

I use the old solution as a starting value. Is that a hint?

Hmm. This is probably why we couldn’t reproduce it in OTHER_ERROR for model · Issue #316 · jump-dev/HiGHS.jl · GitHub

17

It doesn’t need to be 100% reproducible. Even a script that sometimes triggers it is fine