Wall time is much longer than userlimits

[jac0320]

Was trying to connect Juniper with POD for some large scale runs.

Juniper solver is configed as:

solver = JuniperSolver(IpoptSolver(print_level=0), time_limit=60)

Here is a sample output of problem chp_shorttermplan2a. The "wall time" (getsolvetime(m)=283.986s) is much longer then 60s.

[sitew@node1465 juniper]$ julia juniper.jl chp_shorttermplan2a
Loading model took 16.106777906417847...
time_limit        : 60.0
feasibility_pump  : false
log_levels        : Symbol[:Options, :Table, :Info]

#Variables: 1585
#IntBinVar: 240
#Constraints: 3897
#Linear Constraints: 3129
#NonLinear Constraints: 768
Obj Sense: Min

******************************************************************************
This program contains Ipopt, a library for large-scale nonlinear optimization.
 Ipopt is released as open source code under the Eclipse Public License (EPL).
         For more information visit http://projects.coin-or.org/Ipopt
******************************************************************************

WARNING: Not solved to optimality, status: Infeasible
WARNING: Not solved to optimality, status: Infeasible
WARNING: Not solved to optimality, status: Infeasible
WARNING: Not solved to optimality, status: Infeasible
Status of relaxation: Infeasible
WARNING: Not solved to optimality, status: Infeasible
DATA, chp_shorttermplan2a, 1585, 240, 0, 3897, Min, 0, NaN, Infeasible, 283.98688793182373

Is the solver configured wrongly? Some other cases suggested excessive long running time.

DATA, crudeoil_lee1_09, 964, 72, 0, 2353, Max, NaN, NaN, UserLimit, 2707.551236152649
DATA, crudeoil_lee1_10, 1071, 80, 0, 2656, Max, NaN, NaN, UserLimit, 3646.7778339385986
DATA, crudeoil_lee2_05, 1156, 70, 0, 2582, Max, NaN, NaN, UserLimit, 3792.00230884552
DATA, crudeoil_lee2_06, 1387, 84, 0, 3118, Max, NaN, NaN, UserLimit, 6318.2111921310425
DATA, crudeoil_lee2_07, 1618, 98, 0, 3671, Max, NaN, NaN, UserLimit, 8959.210350036621
DATA, crudeoil_lee2_08, 1849, 112, 0, 4241, Max, NaN, NaN, UserLimit, 11915.433699846268
DATA, crudeoil_lee2_09, 2080, 126, 0, 4828, Max, NaN, NaN, UserLimit, 14354.766273021698

[Wikunia]

Did you run the crudeoil_lee1_09,...,crudeoil_lee2_09 instances all with a 60s time limit? The time limit at the moment checks only inside the tree search (not for relaxation) :/ I'll add this but this can't be the reason for your other test cases, I suppose. Or are these extremely big instances where Ipopt takes that long?

[Wikunia]

At the moment I would also set the time limit inside of Ipopt as well. Have to think about how to implement this inside Juniper in the best way for all kinds of different NLP solvers.

[jac0320]

Yes. All were fed with 60s limit. They are large instances but not necessarily super large. For example, crudeoil_lee1_09 is with 2065 linear cons, 288 nonlinear cons, 964 variables, 72 binaries. No super long equations among all constraints.

@Wikunia just did a Ipopt test with crudeoil_lee1_09, the root relaxation with Ipopt took 591s on a single core node.

I guess the question is where time is spent outside the BnB search.

BTW, thanks @Wikunia

[ccoffrin]

I think there are two keys points,

1. 60s is a pretty aggressive limit, for a large problem
2. Juniper probably is not entering search, which prevents the time limit from engaging

This is a pretty common problem among non-commercial solvers (incl. bonmin). If a sub-solver is spinning the master solver will not check it's time limit.

@Wikunia, the only robust solution I can think of is to run the complete solver algorithm in it's own separate process (incl. pre solve, FP, and search). The master thread monitors the current best solution and bound, and time limit. It then kills the solver alg. process when the limit is reached.

[ccoffrin]

Until JuMP v0.19, we should not try to have Juniper set the NLP solver runtime limit. The parameters differ by solver, so the user should specify this.

[Wikunia]

This still needs to set the time limit for the nlp solver if you want to be safe.

[Wikunia]

At the moment I use https://github.com/lanl-ansi/Juniper.jl/blob/master/src/fpump.jl#L152-L157 to limit the time inside the feasibility pump. This might be an option (maybe this changes in JuMP v0.19)