QCQP model doomed infeasible in presolve, however it is not

Hi Tristan,

Thank you very much for a comprehensive answer and possible solutions.

I have looked into rounding when preparing the problem, however I cannot find any number that causes this error directly.

I agree that changing the FeasTol to 10^-4, which indeed is perfectly fine for our model, the QCQP solver finds a solution. That is really good, and is the solution I will go with!

However, if the issue is that the original model with integralities is too complex and a bit more wiggle-room is allowed, I guess there must be a tolerance/precision setting to control this wiggle-room?

Also, even when using the lp-file created using WriteProb (which should then have full precision?) the IIS still finds the model feasible. What am I missing here?

Cheers,

Jonas

Hi Jonas,

when you say that you looked into rounding but couldn't find any number causing this error directly, you mean that the - 330.8786 is coming out of whatever data source directly as is, without it having been rounded before (either on your side or by whoever you got the data from)? It is of course totally clear that you cannot get data of arbitrary precision in all cases, but it seemed like there were some differences in the accuracy of different coefficients, and in any case, if the model has constraints that can lead to infeasibility in case of mismatches, I think it is important to make sure that the tolerances are coarser than the data accuracy, so that they can absorb those errors.

With regards to the original solve, if you solve the MILP with a tighter feasibility tolerance to ensure that the solution is not just within tolerances but actually feasible, and then slightly relax those for the second solve, then this should help with the problem (although there are still things like scaling and presolve happening in between, which you could also disable, but then you might have issues with still being able to solve the problems quickly). Although if this is indeed an issue with data accuracy, then this means that you would just cut off solutions with unfortunate rounding errors earlier. But that is something you have to answer from an application point of view, whether you are looking for solutions that could have been feasible before rounding/measurement errors/data uncertainty or whether you want solutions that are actually still feasible for the specific data you received, even it it means cutting off solutions due to previous roundings.

In general IIS will make some control changes (including disabling presolve) both for performance and reproduceability reasons, so in general IIS is a much better tool for actual clear-cut infeasibility than for borderline numerical cases which are about finding or not finding solutions that are slightly violated but within tolerance.

Best,

Tristan