About Start Values in JuMP - MOA

Hello to all!

I have a doubt about using start values in variables.

My hypothesis was that could speed up the execution time if I provide most of the values in variable vector already in optimum position.

In my problem I have a constraint that consumes a lot of processing time. When I run the model without this constrait, I got a very quick solutin output. So I Think I could use it to speed up processing considering that not all variables are suitable to changes when the restriction is applied

But my benchmark results show that it isnt affecting the processing time at all. Should I do something additional to achieve this time reduction? Or my hiphotesis doesnt make sense?

Here the benchmarks for the optimiztion without the constraint (t0); with constraint but no startup (t1) and with constraint initializated with (t10 ← t0)

BenchmarkTools.Trial: 100 samples with 1 evaluation.
Range (min … max): 12.752 ms … 38.410 ms ┊ GC (min … max): 0.00% … 57.62%
Time (median): 14.630 ms ┊ GC (median): 0.00%
Time (mean ± σ): 15.587 ms ± 3.695 ms ┊ GC (mean ± σ): 3.68% ± 9.27%

 ▂█▁   ▁                                                   

▃▆▄███▅▄▄█▇▄▃▁▁▃▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▃ ▃
12.8 ms Histogram: frequency by time 34 ms <

Memory estimate: 4.80 MiB, allocs estimate: 67712.

BenchmarkTools.Trial: 100 samples with 1 evaluation.
Range (min … max): 1.307 s … 1.647 s ┊ GC (min … max): 0.00% … 0.00%
Time (median): 1.333 s ┊ GC (median): 0.00%
Time (mean ± σ): 1.349 s ± 50.825 ms ┊ GC (mean ± σ): 0.23% ± 0.57%

▁█▁▃▁▁
▆██████▅▄▄▆▄▃▄▄▃▄▁▁▁▁▃▁▁▁▄▁▁▃▁▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃ ▃
1.31 s Histogram: frequency by time 1.6 s <

Memory estimate: 18.67 MiB, allocs estimate: 478216.

BenchmarkTools.Trial: 100 samples with 1 evaluation.
Range (min … max): 1.304 s … 1.599 s ┊ GC (min … max): 0.00% … 0.00%
Time (median): 1.334 s ┊ GC (median): 0.00%
Time (mean ± σ): 1.348 s ± 42.970 ms ┊ GC (mean ± σ): 0.22% ± 0.54%

  ▁▂ ▂█                                                  

▃▅▅███▇███▇▃▅▅▄▃▃▄▄█▃▁▃▃▁▁▃▃▁▁▃▁▁▃▁▁▃▁▁▃▃▁▁▁▁▁▁▁▁▃▁▁▁▁▁▁▃ ▃
1.3 s Histogram: frequency by time 1.5 s <

Memory estimate: 18.67 MiB, allocs estimate: 478216.

Code for result replication is in upload area. I’m using Julia 1.8.5.

Thanks in advance and best regards!!!
SHC_MOA.jl (24.2 KB)

What is the result of solution_summary(model) with and without the constraint?

Small changes to a MILP (like adding or removing a constraint) can have a large change on the output, so this result is not surprising.

I’m not sure why the start value doesn’t help, but it’s probably because we’re re-using the same HiGHS model with different scalar objectives, so it is already re-using the previous starting solution.

Here is a file with both outputs. I just have to change it to *,jl for upload
SSM.jl (13.5 KB)

To clarify, the output of solution_summary(model), not the full log:

Ah ok, sorry for the wrong answer. I Think this is the data you asking for:

#Solver without constraint

  • Solver : MOA[algorithm=MultiObjectiveAlgorithms.Hierarchical, optimizer=HiGHS]

  • Status
    Result count : 1
    Termination status : OPTIMAL
    Message from the solver:
    “Solve complete. Found 1 solution(s)”

  • Candidate solution (result #1)
    Primal status : FEASIBLE_POINT
    Dual status : NO_SOLUTION
    Objective value : [-1.06258e+01,9.29934e+00]
    Objective bound : [-1.04922e+01,1.10000e+01]
    Relative gap : 0.00000e+00

  • Work counters
    Solve time (sec) : 9.00002e-02
    Simplex iterations : 0
    Barrier iterations : -1
    Node count : 0

#Solver with Constraint but not initialized

  • Solver : MOA[algorithm=MultiObjectiveAlgorithms.Hierarchical, optimizer=HiGHS]

  • Status
    Result count : 1
    Termination status : OPTIMAL
    Message from the solver:
    “Solve complete. Found 1 solution(s)”

  • Candidate solution (result #1)
    Primal status : FEASIBLE_POINT
    Dual status : NO_SOLUTION
    Objective value : [-1.07207e+01,8.95209e+00]
    Objective bound : [-1.05872e+01,1.04591e+01]
    Relative gap : 0.00000e+00

  • Work counters
    Solve time (sec) : 1.06000e+00
    Simplex iterations : 302
    Barrier iterations : -1
    Node count : 1

#Solver with Constraint but initialized with first result

  • Solver : MOA[algorithm=MultiObjectiveAlgorithms.Hierarchical, optimizer=HiGHS]

  • Status
    Result count : 1
    Termination status : OPTIMAL
    Message from the solver:
    “Solve complete. Found 1 solution(s)”

  • Candidate solution (result #1)
    Primal status : FEASIBLE_POINT
    Dual status : NO_SOLUTION
    Objective value : [-1.07207e+01,8.95209e+00]
    Objective bound : [-1.05872e+01,1.04591e+01]
    Relative gap : 0.00000e+00

  • Work counters
    Solve time (sec) : 9.61000e-01
    Simplex iterations : 302
    Barrier iterations : -1
    Node count : 1

A small update in this thread.

I tried to increase the loads amount generating a random Vector, size 500 . The Goal here is to test if due to the small amount of data (only 11 loads, in study scenary) i’m not been able to se diference in benchmarks with and without start values.

When I Run the methods, JuMP + MOA is capable of solve the problem without the demand restriction with no problems (it runs for about 3 to 10s). But most of the times it is struggling to process the demand restriction. It keeps running for hours without find a solution. Only in cases that max peak demand is much lower than the demand restriciton the solver is able to delivery a solution, althou this case this constraint wasn’t used at all.

There is some inner propertie from HiGHs I should tune to get throgh this problems?

Any other solver could do HiGHs job is worth trying?

Thanks in advance!!!

Result count : 1

This is weird. You’re solving a multi-objective optimization problem, but there is only one solution. I think the problem with the demand restriction is just difficult to solve?

Did you try excluding the 0 >= 0 constraints, like I suggested in HiGHS Error: No invertible representation for getDualRay - #16 by odow?

Any other solver could do HiGHs job is worth trying?

You could try Gurobi