log_to_console attribute not working

[Ethan-Russell]

When I run optimize! with a JuMP Model with the HiGHS optimizer, with the attribute "log_to_console" set to false, I am still seeing output to both the REPL and to the log file (though different outputs). I am under the impression that setting "log_to_console" to be false would mean the solver would still log to the output file (if specified), and not output anything in the console.

Log file output:

Presolving model
104 rows, 101 cols, 277 nonzeros
82 rows, 101 cols, 233 nonzeros
Presolve : Reductions: rows 82(-135); columns 101(-1); elements 233(-164)
Solving the presolved LP
IPX model has 82 rows, 123 columns and 255 nonzeros
Ipx: IPM       optimal
Ipx: Crossover optimal
Solving the original LP from the solution after postsolve
Model   status      : Optimal
IPM       iterations: 15
Objective value     :  1.2968100000e+05
HiGHS run time      :          0.08

Console output:

Input
    Number of variables:                                123
    Number of free variables:                           33
    Number of constraints:                              82
    Number of equality constraints:                     58
    Number of matrix entries:                           255
    Matrix range:                                       [5e-01, 2e+02]
    RHS range:                                          [0e+00, 0e+00]
    Objective range:                                    [1e+01, 2e+10]
    Bounds range:                                       [1e-01, 1e+01]
Preprocessing
    Dualized model:                                     no
    Number of dense columns:                            0
    Range of scaling factors:                           [1.25e-01, 4.00e+00]
IPX version 1.0
Interior Point Solve
 Iter     P.res    D.res            P.obj           D.obj        mu     Time
   0   1.91e+00 5.38e+10   0.00000000e+00 -1.29711082e+13  1.46e+11       0s
   1   3.67e-01 3.78e+08  -1.40132648e+11 -2.31551020e+12  2.29e+10       0s
   2   1.05e-01 7.38e+07  -1.79618080e+11 -5.42789812e+11  4.84e+09       0s
 Constructing starting basis...
   3   7.17e-03 7.81e+06  -2.43566767e+11 -3.35375751e+11  5.80e+08       0s
   4   3.88e-04 9.36e+05  -2.58532029e+11 -2.69905325e+11  6.55e+07       0s
   5   1.07e-05 9.36e+04  -2.62699144e+11 -2.63644843e+11  5.32e+06       0s
   6   1.07e-11 2.93e+03  -2.62799834e+11 -2.62826552e+11  1.48e+05       0s
   7   8.88e-16 9.05e+01  -2.62799838e+11 -2.62800669e+11  4.62e+03       0s
   8   8.88e-16 1.81e+01  -2.62799848e+11 -2.62800020e+11  9.59e+02       0s
   9   8.88e-16 3.13e+00  -2.62799860e+11 -2.62799904e+11  2.45e+02       0s
  10   8.88e-16 2.25e-01  -2.62799870e+11 -2.62799873e+11  1.69e+01       0s
  11*  8.88e-16 2.23e-02  -2.62799870e+11 -2.62799871e+11  2.25e+00       0s
  12*  8.88e-16 1.58e-03  -2.62799870e+11 -2.62799870e+11  2.61e-01       0s
  13*  8.88e-16 1.35e-04  -2.62799870e+11 -2.62799870e+11  2.23e-02       0s
  14*  8.88e-16 7.80e-06  -2.62799870e+11 -2.62799870e+11  6.31e-05       0s
  15*  8.88e-16 6.36e-06  -2.62799870e+11 -2.62799870e+11  2.92e-10       0s
Crossover
    Primal residual before push phase:                  2.15e-10
    Dual residual before push phase:                    6.36e-06
    Number of dual pushes required:                     7
    Number of primal pushes required:                   0
Summary
    Runtime:                                            0.04s
    Status interior point solve:                        optimal
    Status crossover:                                   optimal
    objective value:                                    -2.62799870e+11
    interior solution primal residual (abs/rel):        1.78e-15 / 1.61e-16
    interior solution dual residual (abs/rel):          1.59e-06 / 1.06e-16
    interior solution objective gap (abs/rel):          -6.10e-05 / -2.32e-16
    basic solution primal infeasibility:                0.00e+00
    basic solution dual infeasibility:                  0.00e+00

[odow]

Do you have a reproducible example?

julia> using JuMP, HiGHS

julia> model = Model(HiGHS.Optimizer)
A JuMP Model
Feasibility problem with:
Variables: 0
Model mode: AUTOMATIC
CachingOptimizer state: EMPTY_OPTIMIZER
Solver name: HiGHS

julia> set_optimizer_attribute(model, "log_to_console", false)

julia> @variable(model, x >= 0)
x

julia> optimize!(model)

julia> set_optimizer_attribute(model, "log_to_console", true)

julia> optimize!(model)
Solving LP without presolve or with basis
Solving an unconstrained LP with 1 columns
Model   status      : Optimal
Objective value     :  0.0000000000e+00
HiGHS run time      :          0.00

[Ethan-Russell]

Thanks for getting back to me so quickly. I believe the problem is only with IPM. Here is a minimum working example:

julia> model = Model(optimizer_with_attributes(HiGHS.Optimizer, "log_to_console"=>false, "solver"=>"ipm"))
A JuMP Model
Feasibility problem with:
Variables: 0
Model mode: AUTOMATIC
CachingOptimizer state: EMPTY_OPTIMIZER
Solver name: HiGHS

julia> @variable(model, x >= 0)
x

julia> @variable(model, 0 <= y <= 3)
y

julia> @objective(model, Min, 12x + 20y)
12 x + 20 y

julia> @constraint(model, c1, 6x + 8y >= 100)
c1 : 6 x + 8 y >= 100.0

julia> @constraint(model, c2, 7x + 12y >= 120)
c2 : 7 x + 12 y >= 120.0

julia> optimize!(model)
Input
    Number of variables:                                2
    Number of free variables:                           0
    Number of constraints:                              2
    Number of equality constraints:                     0
    Number of matrix entries:                           4
    Matrix range:                                       [6e+00, 1e+01]
    RHS range:                                          [1e+02, 1e+02]
    Objective range:                                    [1e+01, 2e+01]
    Bounds range:                                       [3e+00, 3e+00]
Preprocessing
    Dualized model:                                     no
    Number of dense columns:                            0
    Range of scaling factors:                           [5.00e-01, 1.00e+00]
IPX version 1.0
Interior Point Solve
 Iter     P.res    D.res            P.obj           D.obj        mu     Time
   0   8.85e+00 2.66e+00   2.03715741e+02  1.90309850e+02  3.67e+01       0s
   1   8.85e-06 2.66e-06   2.15808217e+02  1.93588563e+02  4.44e+00       0s
   2   7.84e-07 5.20e-07   2.05317615e+02  2.02113669e+02  6.41e-01       0s
   3   7.85e-13 4.53e-08   2.05209034e+02  2.04938729e+02  5.41e-02       0s
   4   6.58e-15 4.53e-14   2.05000287e+02  2.04999555e+02  1.46e-04       0s
   5*  6.49e-15 1.78e-15   2.05000000e+02  2.05000000e+02  5.76e-10       0s
 Constructing starting basis...
Crossover
    Primal residual before push phase:                  8.01e-10
    Dual residual before push phase:                    1.03e-10
    Number of dual pushes required:                     0
    Number of primal pushes required:                   0
Summary
    Runtime:                                            0.03s
    Status interior point solve:                        optimal
    Status crossover:                                   optimal
    objective value:                                    2.05000000e+02
    interior solution primal residual (abs/rel):        1.42e-14 / 1.17e-16
    interior solution dual residual (abs/rel):          1.78e-15 / 8.46e-17
    interior solution objective gap (abs/rel):          2.88e-09 / 1.40e-11
    basic solution primal infeasibility:                0.00e+00
    basic solution dual infeasibility:                  0.00e+00

[odow]

This is an upstream bug in HiGHS: https://github.com/ERGO-Code/HiGHS/issues/967

[Ethan-Russell]

Thanks for looking into this!

[odow]

Thanks for reporting it. Hopefully we can get this resolved upstream and a fix issued. I've started a patch here: https://github.com/ERGO-Code/HiGHS/pull/1052.

As an aside, do you really need to force ipm? Just let the solver choose.

[Ethan-Russell]

Awesome, I'll keep an eye out for the patch.

I don't need to force ipm, but I suspect that as my problem size grows, it may be faster. I know that Gurobi was unable to solve my problem with their simplex method in a reasonable amount of time, and switching to their Barrier method helped tremendously. Is there any overhead with letting the solver choose for me?

[odow]

Is there any overhead with letting the solver choose for me?

Yes. It may choose a slower method, like Gurobi did with simplex over barrier.

Did you force Gurobi to choose simplex? In most LPs, it should choose barrier as the first algorithm to try, and usually it will even run a concurrent solve with both barrier and primal/dual simplex.

[odow]

Closing since this isn't a bug in HiGHS.jl and Julian has confirmed the upstream issue.

If you run into any other bugs in HiGHS, please open an issue. If you have some general questions, e.g., comparisons with Gurobi, make a post on the forum, https://discourse.julialang.org/c/domain/opt/13, and we can discuss there.