Originally posted by: TomaszGorski

I often use cplex to solve problems in iterative way, fixing some variable values in between solver runs. This gives good results, but there are numerical results related to it.

Example:
I solve the problem with integer variable x. CPLEX assigns value 1.0000001 to it, which is allowed given the integrality tolerance. I then want to fix the value of this variable such that it does not change in subsequent runs.

1. Fixing the bounds to be (1.0000001, 1.0000001) is risky/will not work because presolve might conclude that there are no integer values in the range.

2. Fixing the bounds to be (1, 1) will exclude currect value, potentially leading to infeasibility.

3.Fixing the bounds to be (1, 1.0000001) will leave some (very limited) range for the variable, decreasing numerical quality of the problem and decreasing performance. If presolve concludes that the bounds should be rounded to (1, 1) then it is the same as the case (2) above. This is what we do now as most safe.
What would you suggest as best practice in such a case?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I would try rounding the value to the nearest integer before fixing (case (2) in your list). If that renders the current solution infeasible then you could try to resolve with all integral variables fixed.
If you often run into feasibility problems after fixing the variables then you should probably tighten the integrality tolerance for CPLEX even further or work on the numerics of your problem.
I wonder what you are going to do with a solution that is feasible within integrality tolerance but rounding the integral values leads to an infeasible solution? Is that any useful in practice?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: TomaszGorski

Hi Daniel,

First of all, we use CPLEX to solve a variety of problems and would like to do that in a simple and robust way. In this case, simple means that we would like to decide what needs to happen if you fix a variable to its current value in reexecution, and that should work for most cases. Robust means that we would like to avoid dealing with infeasibility for problems that are actually not infeasible. If CPLEX provides a solution, we would like to be able to reuse it as start solution for another run (with user modifications that do not break feasibility).

Because of that using an approach that can result in infeasibility is not a good option for us I think. At least, I hope we can find an approach that is more robust.

Using solutions that are a little bit infeasible is often ok for us, if the violations are negligible (so 0.9999 integer or bound/constraint violation of 1e-4 range is often usable). In my experience it is CPLEX that tends to use extreme values that are creating violations and I am trying to find an approach that would make sure that whatever CPLEX outputs as tolerated solution, is accepted when fed back to it as start solution/fixed bounds.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

What I meant is the following:

• Rounding the integer variables in a feasible solution is expected to result in a feasible solution (maybe call solveFixed() to make sure the values of the continuous variables match the rounded values of integer variables).
• If rounding the solution values for integer variables and fixing the variables to these values results in an infeasible model then there is something wrong with your model or the way CPLEX handles it (for example tolerances). In that case you need to figure out what is wrong anyway, don't you? If rounding results in an infeasible solution then what good is the non-rounded solution? Its "feasibility" is definitely questionable, isn't it?

#CPLEXOptimizers
#DecisionOptimization