QCQP model doomed infeasible in presolve, however it is not

Hi Jonas,

first of all about the difference between exportProb and writeProb, by default exportProb will use a relatively low precision to make the file more readable (see https://www.fico.com/fico-xpress-optimization/docs/latest/bcl/bcl.net/HTML/html/4ccfa469-ec31-cf8f-8f0e-9ebe302a9c91.htm ), while writeProb will by default write with full precision to make things reproduceable, and in this case I can see that some of the coefficients in the problem created by exportprob have been cut off compared to the numbers I get after restoring the save-file, which for an infeasibility in the 10^-5 range can of course make a difference.

In fact looking at the infeasibility, I think it might have a similar reason. When I look at AVVAVV2Mode6FCRNGenericUpDownCondensing1_18, which on my side is the row we blame for infeasibility in the end, we start by fixing AVVAVV2Mode6Condensing_18 to -330.87860827049457, which is strikingly similar to the - 330.8786 coefficient in front of AVVAVV2Mode6FCRNGenericUpDownPPRPoint3Alpha_18, and after fixing two more variables, including the latter, that row ends up with a violation in the 10^-6 range, which very much matches the difference between those two numbers. And if I replace - 330.8786 by the full number in the original model, then this infeasibility seems to go away (even though the problem is still declared infeasible due to another row, but given that there are a number of rows with almost identical structure, that doesn't seem too surprising). Without knowing about your application, it looks to me very much like that - 330.8786 would be the result of a rounding operation, while other rows might still implicitly enforce the more accurate number?

If that is indeed the case, I would suggest either avoiding these roundings when preparing the problem, or otherwise to relax the feasibility tolerance to a value that doesn't require higher precision than the input data provides, as the 10^-4 with which the model still solves nicely even with presolve enabled seems to match the roundoff error in those numbers. Given these differences, I assume what happens is that the original model with integralities is still too complex for us to figure out these infeasibilities and then in the LP solver we leave a little bit more wiggle-room and end up with a solution that is not quite as accurate as we would want. But after fixing those integers, the problem simplifies and we can figure out these discrepancies in presolve and then apply the tolerances with a bit more force and therefore end up declaring the problem infeasible.