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.