A minimal conflict on a nontrivial model can take longer to refine than the associated optimization algorithm would have taken either to prove the infeasibility or to solve a similar model instance that was feasible. One reason that refining a minimal conflict may take longer is that multiple passes (that is, iterations) are performed; each iteration solves a submodel to decide its feasibility status. Another reason is that even if the full model is quickly detected to be infeasible, the infeasibility of the submodels may be less blatant and thus require more time to analyze. It can happen that a number of refinement iterations proceed quickly, and then suddenly no further progress is seen for quite a long time. This deceptive appearance of lack of progress may be especially noticeable in the case of mixed integer models, where a proof of infeasibility may become a quite difficult mathematical problem.

If the user sets a resource limit, such as a time limit, an iteration limit, or node limit, for example, or if a user interrupts the process interactively, the conflict that is available at that termination will be the best (that is, the most refined) that was achievable at that point. Even a nonminimal conflict may be more useful than the full model for discovering the cause of infeasibility. The status of a bound or constraint in such a nonminimal conflict may be proved, meaning that the conflict refiner had sufficient resources to prove participation of bound or constraint in the conflict, or the status may be possible, meaning that the conflict refiner has not yet proven whether the bound or constraint is necessarily part of a minimal conflict.

If a model contains more than one cause of infeasibility, then the conflict that is delivered may not be unique. As you saw in the example, you may repair one infeasibility only to find that there is another arising. An iterative approach may be necessary.

When the conflict refiner is allowed to run to completion, a conflict will be minimal in the sense that removal of any constraint or bound will result in a feasible subproblem. However, even if there is a single cause of infeasibility, it is worth realizing that conflicts can often be derived in more than one way, and one minimal conflict may be smaller (fewer in number of constraints or bounds) than another. For example, consider this small set of inconsistent constraints:

x + y + z >= 1
x         <= 0
    y     <= 0
        z <= 0
x + y + z <= 0

There are multiple minimal conflicts in that small set.

(1)
x + y + z >= 1
x         <= 0
    y     <= 0
        z <= 0

(2)
x + y + z >= 1
x + y + z <= 0

Removing any one of the constraints in conflict (1) results in feasibility. Likewise, removing either of the constraints in conflict (2) also results in feasibility. Either representation may guide you toward a correct analysis of the infeasibilities in the model.

Keep in mind also that a conflict may guide you toward multiple ways to repair a model, some more reasonable than others. For example, if the conflict in a model using continuous variables to represent percentages looked like this:

x1 + x2 + x3 >= 400
Bounds
0 <= x1 <= 100
0 <= x2 <= 100
0 <= x3 <= 100

the infeasibility could be repaired by one change, namely, by increasing the upper bound of x3 to be 200. However, with the way the variables are defined, this modification makes little sense. It is more likely that the model contains a subtle mistake in modeling (if the constraint should include more than three variables, for example).

When the model passed to the conflict refiner is actually feasible, the conflict refiner will return this message:

Problem is feasible; no conflict available

An attempt to display or access a conflict when none exists, whether because the conflict refiner has not yet been invoked or because an error occurred, results in this error message:

No conflict exists.