You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a primal infeasible model where I want to find the dual objective value (following the Benders' tutorial on generating feasibility cuts). While solving the problem in HiGHS (v1.9.3) takes less than a second, the calculation for dual_objective_value takes around 2 minutes. It seems that this time is spent in MOI.Utilities.get_fallback which is triggered by the existence of a dual ray for the solution (MOI_wrapper.jl, line 2046):
if model.solution.has_dual_ray
return MOI.Utilities.get_fallback(model, attr, Float64)
Is this expected behavior? My problem is fairly large, but I did not expect such long running times. If needed, I can share the model.
A JuMP Model
├ solver: HiGHS
├ objective_sense: MIN_SENSE
│ └ objective_function_type: AffExpr
├ num_variables: 91171
├ num_constraints: 182159
│ ├ AffExpr in MOI.EqualTo{Float64}: 81350
│ ├ AffExpr in MOI.GreaterThan{Float64}: 1848
│ ├ AffExpr in MOI.LessThan{Float64}: 13524
│ ├ VariableRef in MOI.EqualTo{Float64}: 7473
│ ├ VariableRef in MOI.GreaterThan{Float64}: 77963
│ └ VariableRef in MOI.LessThan{Float64}: 1
└ Names registered in the model: none
Looking at the profiled results, almost all time is spent in Highs_getRowsByRange. So maybe this is related to #207.
The text was updated successfully, but these errors were encountered:
I have a primal infeasible model where I want to find the dual objective value (following the Benders' tutorial on generating feasibility cuts). While solving the problem in HiGHS (v1.9.3) takes less than a second, the calculation for
dual_objective_value
takes around 2 minutes. It seems that this time is spent inMOI.Utilities.get_fallback
which is triggered by the existence of a dual ray for the solution (MOI_wrapper.jl, line 2046):Is this expected behavior? My problem is fairly large, but I did not expect such long running times. If needed, I can share the model.
Looking at the profiled results, almost all time is spent in
Highs_getRowsByRange
. So maybe this is related to #207.The text was updated successfully, but these errors were encountered: