# Infeasibility and inconsistency¶

When submitting a model to LocalSolver (calling method `solve`

), the expected
result is to obtain a feasible solution, and even sometimes an optimal solution.
However in some cases the returned solution can be infeasible in the sense that
the current assignement of values to variables violates some of the constraints
of the problem. Two solution statuses (see
getSolutionStatus) are defined for these
infeasibilty cases:

`infeasible`

means that no feasible solution was found to the submitted problem but it could not be proven that no such solution exists. Maybe running a longer search would have produced a feasible solution.`inconsistent`

means that the solver was able to prove that no feasible solution exists. In this case, LocalSolver offers a functionality for analyzing the causes of this inconsistency.

Note

Note that both statuses `infeasible`

and `inconsistent`

can also be
encountered on problems where no constraint was defined. Indeed some
LocalSolver expressions induce an *implicit* constraint on their operands.
For instance `sqrt(x)`

implicitly requires that x takes a non-negative
value.

## Analyzing inconsistencies¶

Analyzing an inconsistent model amounts to identifying a relatively small
inconsistent subproblem. Such a subproblem or *inconsistency core* is said to
be *irreductible* if it contains no smaller inconsistent subproblem.

The function `computeInconsistency`

computes such a core that is to say a set
of expressions (named causes) such that the problem restricted to these
expressions and their descendents is inconsistent. Calling this function
requires the model to be closed and the solver to be stopped. This
inconsistency core is returned as an `LSInconsistency`

object. This object
can be printed in a readable form so that the user can easily spot the origin
of the inconsistency. It also allows scanning the set of identified causes.

For example, the following model is inconsistent because limiting the cube of
`y`

to 250 prevents `y`

from taking values larger than 6, what make the constraint
`3*x + y >= 20`

impossible to satisfy:

```
function model() {
x <- bool();
y <- int(0,100);
z <- bool();
t <- int(0,100);
constraint 3*x + y >= 20;
constraint pow(y,3) <= 250;
constraint 4*z + t <= 18;
maximize x*t + 8*z*y;
}
```

The computation of the inconsistency core can be launched in the output function as follows:

```
function output() {
iis = computeInconsistency();
println(iis);
}
```

The resulting output on the standard console is the following:

```
...
Run output...
Computing inconsistency core...
Inconsistency core found with 2 causes.
Irreductible inconsistency core found with 2 causes.
2 causes in inconsistency core:
pow(int(0, 100)#1, 3) <= 250
3 * bool()#0 + int(0, 100)#1 >= 20
```

The two constraints responsible for the inconsistency are identified and displayed. Note that expressions are identified by their type and index. It is also possible to assign names to variables in the model function:

```
x.name = "x";
y.name = "y";
z.name = "z";
t.name = "t";
```

Having defined these names the inconsistency core reads as follows:

```
2 causes in inconsistency core:
pow(y, 3) <= 250
3 * x + y >= 20
```

Note

In version 6.0, this functionality is offered in beta version: only
explicit constraints are considered as potential causes of the
inconsistency unless a single non-constraint expression is sufficient to
cause the inconsistency. If the inconsistency core is empty it can mean
that the problem is consistent or that its inconsistency derives of the
combination of several *implicit* constraints.