Add_bridges

What is the default value of add_bridges when a JuMP model is created? Can this be checked via a JuMP call? For a JuMP model m, get_optimizer_attribute(m, MOI.add_bridges()) doesn’t work.

What is the default value of add_bridges when a JuMP model is created?

The default is true.

Can this be checked via a JuMP call?

No. Why do you need this?

As a side note:

I’ve just seen that the docs don’t include the actual docstring:

I’ll get this fixed.

How do we know what the default value is, without checking the code, if we can’t check it using a JuMP call?

How do we know what the default value is, without checking the code, if we can’t check it using a JuMP call?

Read the documentation. But my question was more, “why do you need to know the default?”

julia> using JuMP

help?> Model
search: Model ModelMode model_string copy_model owner_model direct_model AbstractModel INVALID_MODEL nonlinear_model

  Model()

  Return a new JuMP model without any optimizer; the model is stored in a cache.

  Use set_optimizer to set the optimizer before calling optimize!.

  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  Model(optimizer_factory; add_bridges::Bool = true)

  Return a new JuMP model with the provided optimizer and bridge settings.

  See set_optimizer for the description of the optimizer_factory and add_bridges arguments.

  Examples
  ==========

  Create a model with the optimizer set to Ipopt:

  model = Model(Ipopt.Optimizer)

  Pass an anonymous function which creates a Gurobi.Optimizer, and disable bridges:

  env = Gurobi.Env()
  model = Model(() -> Gurobi.Optimizer(env); add_bridges = false)

There is a bug in Documenter that is preventing the docstrings from appearing in the online documentation.

That’ll be fixed shortly: Fix docstring of Model not appearing in docs by odow · Pull Request #3198 · jump-dev/JuMP.jl · GitHub

Maybe I don’t want to specify every parameter and attribute and use the default values when creating a model, for efficient looking code. In this case, it would be useful for the documentation to state the default values.

Using HiGHS, add_bridges=false degrades performance for a particular model. I had thought add_bridges=false might improve performance based on this documentation: Models · JuMP.

add_bridges = true:

Solving report
Status Optimal
Primal bound -128
Dual bound -128
Gap 0% (tolerance: 0.01%)
Solution status feasible
-128 (objective)
0 (bound viol.)
4.88498130835e-15 (int. viol.)
0 (row viol.)
Timing 1460.68 (total)
821.37 (presolve)
0.00 (postsolve)
Nodes 404
LP iterations 542675 (total)
0 (strong br.)
32998 (separation)
36029 (heuristics)
1465.169666 seconds (11.94 M allocations: 781.290 MiB, 0.03% gc time, 0.28% compilation time)

add_bridges = false:

Solving report
Status Optimal
Primal bound -128
Dual bound -128
Gap 0% (tolerance: 0.01%)
Solution status feasible
-128 (objective)
0 (bound viol.)
1.33226762955e-13 (int. viol.)
0 (row viol.)
Timing 2115.38 (total)
815.70 (presolve)
0.00 (postsolve)
Nodes 825
LP iterations 1085261 (total)
0 (strong br.)
58459 (separation)
122888 (heuristics)
2118.386670 seconds (5.68 M allocations: 348.871 MiB, 0.02% gc time, 0.13% compilation time)

The performance difference is just randomness, and it is a side-effect of the bridges, not as a direct result of them. Going via bridges or not can change the order of constraints that are present in the model. Different row orders can give wildly different performance characteristics. You could have another model where the performance is reversed. Alternatively, you might be able to play with the order of constraints in your formulation and achieve the same result.

The documentation issue is fixed: Fix docstring of Model not appearing in docs by odow · Pull Request #3198 · jump-dev/JuMP.jl · GitHub, and will shortly show in the dev version of the docs, and the stable in the next release of JuMP.

Instead of https://jump.dev/JuMP.jl/stable/reference/models/#Constructors

it will show

Just to close the loop: this is now fixed.