Closed dumpram closed 4 years ago
You would have to supply a reproducible example, as it is not generic. Could it be that a sub-solver stalls? (bmibnb does not terminate the sub-solver if it exceeds bmibnbs timelimit, although it is a good feature to add, works like that in bnb)
`>> optimize([-1 <= x <= 1],x'Qx,sdpsettings('solver','bmibnb','bmibnb.maxtime',1))
ans =
struct with fields:
yalmipversion: '20190425'
yalmiptime: 0.2370
solvertime: 2.0910
info: 'Maximum iterations or time limit exceeded (BMIBNB)'
problem: 3
`
If understand correctly, I should add time limit to every solver which BMIBNB uses:
* Starting YALMIP global branch & bound.
* Branch-variables : 168
* Upper solver : fmincon
* Lower solver : MOSEK
* LP solver : MOSEK
Node Upper Gap(%) Lower Open
in this case MOSEK and fmincon?
At the moment you will have to do that, but I will update the code so that it is handled automatically
fmincon does not support time limit so a bit tricky...
btw, are you sure that is where it stalls? (set verbose to 2 and you will see local solver iterations)
In this particular case, it spends only 1 % of the time in fmincon. After I added time limit to MOSEK, BMIBNB stopped as expected.
Care to share the example? Sounds weird that it would stall in the lower solver which should take no time. Send privately by mail if you wish
Here is an output from example:
* Starting YALMIP global branch & bound.
* Branch-variables : 168
* Upper solver : fmincon
* Lower solver : MOSEK
* LP solver : MOSEK
Node Upper Gap(%) Lower Open
1 : 2.146E-01 1.10 2.013E-01 2 Improved solution
* Finished. Cost: 0.21459 Gap: 1.1034
* Termination due to time limit
* Timing: 1% spent in upper solver (2 problems solved)
* 43% spent in lower solver (337 problems solved)
* 33% spent in LP-based domain reduction (656 problems solved)
Is this enough? When I turn on verbose, output from MOSEK solver can be seen. I could provide an example but not at this moment.
To act I would have to have a reproducible example
Or do you mean perhaps that it spends a lot of time in Mosek in general (as it solves around 1000 problems for bound propagation etc), and not necessarily in a single call to mosek
There are definitely multiple MOSEK calls. I'll try to prepare an example.
I guess what you mean then is simply that YALMIP should check for time limit also during the bound propagation routines, and not just in the end of every node iteration. With as many branching variables as you have here, most of the time might easily be spent in bound propagation, in particular with the default settings which assumes a low number of branching variables. (With 168 variables, it requires pure luck for bmibnb to work)
If time limit is exceeded with BMIBNB sovler, YALMIP hangs until Ctrl + C is pressed.