The case i can think of where it makes sense to tighten up the integer feasibility tolerance is Big M modeling applied to an intrinsically poorly scaled problem having large magnitude variable bounds. This can result in a Big M "logic" error if the integer feasibility tolerance is not small enough to accommodate the magnitude of the bounds, meaning that the Big M logic needs to work correctly, even accounting for worst case departure from integrality given the integer feasibility tolerance. I have seen several cases where people used the default integer feasibility tolerance, and the solution from the solver violated the intended logical constraint, even though the solution was within numerical tolerance of the Big M constraints as written.
In light of this, I don’t understand why Mixed Integer Programming vendors usually choose 1e-5 or 1e-6 as the default integer feasibility tolerance. Would it kill you to make the default value 1e-8, and at least buy “protection” for variable bound magnitudes well into the millions (many naive users choose one million as their big M value)? That being said, I follow Johan Lofberg’s maxim of just big enough M, which I specify per constraint, and then I make sure integer feasibility tolerance is small enough so that the logic works correctly when departure from integrality is the maximum allowable per the integer feasibility tolerance.
Also,@Erling don’t tell anyone at Mosek , but I have found that changing
MSK_DPAR_INTPNT_CO_TOL_PFEAS from its default value of 1e-8 to as low as 1e-12 (I’ve even experimented with smaller values) can be effective, at least on the problems I was solving, in getting the minimum eigenvalue of an SDP constraint closer to zero (or multiple eigenvalues closer to zero, as the case may be) when the true solution has minimum eigenvalue of exactly zero. Whether or not this parameter is changed, the eigenvalues below threshold can be adjusted to exactly zero. However, if the solver solution’s eigenvalue is not sufficiently close to zero, this adjustment can cause significant consequences elsewhere. For instance, when calling Mosek to solve SDP sub-problems, the achievable solution accuracy of the outer algorithm spawning the SDP sub-problems might be orders of magnitude worse than the size of the eigenvalue adjustment, which can be eliminated or substantially reduced by tightening the tolerance. Perhaps this comes at some increase in run time, or increases the chance that optimality can not be achieved, but I have found that on problems I did this on, the optimizer worked just fine and declared optimality. And those minimum eigenvalues were much closer to zero : . Perhaps if my model were very poorly-conditioned, or not as well-scaled and formulated, this parameter change would not work out as well. That being said, on many problems, there is no crucial need for"zero" eigenvalues to be less than 1e-8 in magnitude. So unlike integer feasibility tolerance, I am not advocating for changing the default value of this parameter.