A feasible QP problem can not be solved after other QPs had been solved.

[mkatliar]

To reproduce, run the example code in the issue6 branch, `examples/test_issue_6.c'. The output is:

[qpDUNES] ←[91mERROR in ..\..\src\dual_qp.c:1760: ←[0m
          Backtracking line search: Deceeded minimum step size.
          Itertation 11
          alpha = 1.000e-012
          alphaMin = 0.000e+000
          normDeltaLambda = 5.941e-005
          minimumProgress = 6.207e-016
          last objVal = -3.985530886191e-002
          objValIncumbet = -3.985530886191e-002
[qpDUNES] ←[91mERROR in ..\..\src\dual_qp.c:264: ←[0m
          Search direction is not an ascent direction. QP could not be solved.

The same QP problem can be solved with MATLAB quadprog (see examples/issue6_test.m).

The appearance of this issue seems to depend on the pre-history of solver calls. If the same QP is the very first one after qpDUNES_setup(), it is solved successfully. To check it, uncomment #define SKIP on line 4 in examples/test_issue_6.c.

[mkatliar]

@dkouzoup wrote:

It is possible if you warm-start your solver (the warm-start includes both previous solution but also
factorizations) that given a big change in your problem data, the warm-start is so bad that the solver 
crashes. I have not experienced that myself but I have heard that this happens even with qpOASES 
which is a much more mature software. Unfortunately I have no solution for this issue at the moment. 
If it happens too often in your data you may consider always initializing your solver and check how 
good/bad the timings are. What would be interesting, is if you fall on a QP that cannot be solved with
 cold-started qpDUNES but with quadprog instead.

If I remove all calls to qpDUNES_shiftLambda() and qpDUNES_shiftIntervals() and replace the calls to qpDUNES_updateData() by qpDUNES_init(), does it count as a cold-start?

In this case, the same error occurs.

[jfrasch]

Hi,

I had a brief look at your example.

• I do not believe that warmstarting itself will crash the solver. As issue like the one mentioned by Dimitris should only appear for really ill-conditioned problems. Of course, the solver might very well need significantly more iterations as a result from the warmstart.
• It seems to me that you are trying to solve a QP with non-diagonal Hessian with the line search option "QPDUNES_LS_BACKTRACKING_LS". I'm am not following the current developments closely, but the status in January was that non-diagonal Hessians are only supported with line search option QPDUNES_LS_HOMOTOPY_GRID_SEARCH The first QP simply does not crash b/c no line search is triggered.
• Your example does not run, even with QPDUNES_LS_HOMOTOPY_GRID_SEARCH enabled. This could be another bug or simply a data quality problem. I would strongly recommend to only use the -dev branch of qpDUNES by starting out from a working example and modifying it only where you really understand what you are doing. qpDUNES-dev features many work-in-progress pitfalls and is only recommended for expert users (i.e., developers).

[mkatliar]

Hello @jfrasch ,

Thank you for your suggestions about the line search option. I think it would be a good idea to check that the linear search option is consistent with the Hessian type or to set this option automatically based on Hessian type.

I am trying to use qpDUNES in a real application. My example reproduces exactly the sequence of calls that happens in the application, therefore I cannot base it on a 'working example'. I tried to keep the call sequence consistent with the working examples though. If you think I am using the qpDUNES API in a wrong way, please tell me where.

[mvukov]

@mkotlyar Let me know if you need help. I have managed to use qpDUNES in a real application -- at least to hook it up to the app software.