Presented in this document is a short description of a straightforward and effective technique to help diagnose infeasibilities in IMPL (Industrial Modeling and Programming Language). IMPL is mathematical programming based where many previous and useful studies on infeasibility diagnosis have been published (Greenberg, 1993; Chinneck, 1993; Chinneck, 2008). It is generally accepted that the “Irreducible Infeasibility Sets (IIS)” developed by Chinneck (1993) is a useful approach to diagnosing infeasibilities and can be found in all commercial LP-based solvers such as CPLEX, GUROBI and XPRESS. Unfortunately IIS performed on industrial optimization problems (IOP) is both slow and difficult to interpret especially for the end-user given that a plethora of IIS’s can be generated with little perceived connection between the variables or constraints contained in them. Another useful and extensively implemented approach that can also be helpful in diagnosing infeasibilities in the linear part of either the MILP or NLP is the presolving or preprocessing techniques found in for example Fourer and Gay (1993) and Andersen and Andersen (1995). These are extremely powerful to reduce the size and in some cases the complexity of the matrix that is ultimately transferred to the LP, QP, MILP or SLP. Unfortunately, although they can quickly and accurately detect LP infeasibilities, they provide little information to aid in the infeasibility diagnosis (Chinneck, 2008) as well shall see later. Instead, IMPL uses a well-known “tightening” technique to analyze the problem by focusing on the quantity phenomenon first given that it is our experience that in IOP’s, a great majority or percentage of the infeasibilities occur in this dimension. This is fortunate given that the constraints are linear in the variables and we can solve many LP’s rapidly as specialized network-flow problems where the dual simplex LP method is particularly efficient and if required we can solve several LP’s in-parallel. Essentially, we have two types of infeasibilities in IOP’s i.e., “incomplete” and “inconsistent” models. Incomplete models are problems where we expect to solve the problem when the problem is ill-defined or insufficiently specified. Inconsistent models are problems where some parts of the problem are incongruent, misaligned or contradictory with other parts.

1. Diagnosing Infeasibilities in IMPL
(IMPL-InfeasibilityDiagnosis)
i n d u s t r IAL g o r i t h m s LLC. (IAL)
www.industrialgorithms.com
May 2014
Introduction
Presented in this document is a short description of a straightforward and effective technique to
help diagnose infeasibilities in IMPL (Industrial Modeling and Programming Language). IMPL is
mathematical programming based where many previous and useful studies on infeasibility
diagnosis have been published (Greenberg, 1993; Chinneck, 1993; Chinneck, 2008). It is
generally accepted that the “Irreducible Infeasibility Sets (IIS)” developed by Chinneck (1993) is
a useful approach to diagnosing infeasibilities and can be found in all commercial LP-based
solvers such as CPLEX, GUROBI and XPRESS. Unfortunately IIS performed on industrial
optimization problems (IOP) is both slow and difficult to interpret especially for the end-user
given that a plethora of IIS’s can be generated with little perceived connection between the
variables or constraints contained in them.
Another useful and extensively implemented approach that can also be helpful in diagnosing
infeasibilities in the linear part of either the MILP or NLP is the presolving or preprocessing
techniques found in for example Fourer and Gay (1993) and Andersen and Andersen (1995).
These are extremely powerful to reduce the size and in some cases the complexity of the matrix
that is ultimately transferred to the LP, QP, MILP or SLP. Unfortunately, although they can
quickly and accurately detect LP infeasibilities, they provide little information to aid in the
infeasibility diagnosis (Chinneck, 2008) as well shall see later.
Instead, IMPL uses a well-known “tightening” technique to analyze the problem by focusing on
the quantity phenomenon first given that it is our experience that in IOP’s, a great majority or
percentage of the infeasibilities occur in this dimension. This is fortunate given that the
constraints are linear in the variables and we can solve many LP’s rapidly as specialized
network-flow problems where the dual simplex LP method is particularly efficient and if required
we can solve several LP’s in-parallel.
Essentially, we have two types of infeasibilities in IOP’s i.e., “incomplete” and “inconsistent”
models. Incomplete models are problems where we expect to solve the problem when the
problem is ill-defined or insufficiently specified. Inconsistent models are problems where some
parts of the problem are incongruent, misaligned or contradictory with other parts.
Infeasible Quantity Problem
Figure 1 displays a simple flowsheet with a supply perimeter, one input and one output
continuous-process and a demand perimeter where x1 and x2 are the flow or quantity variables.

2. Figure 1. Flowsheet of Infeasible Quantity Problem (X’s = Flow Variables).
The process obeys the law of conservation of matter which is modeled as a simple equality
constraint and we have lower and upper bounds on x1 and x2 where we simply maximize the
flow into the demand perimeter as shown algebraically below (see Appendix A for the IMPL
configuration of this problem in IML):
Maximize: x2
Subject to: x1 – x2 = 0
0.9 <= x1 <= 1.0
0.7 <= x2 <= 0.80
Obviously by inspection this problem is infeasible given the inconsistencies in the variable
domains specified. If we solve this using LPSOLVE for example we get the following message
from its presolve:
Upper bound infeasibility in EQ row (0.1 >> -0)
This type of presolve calculation is made by substituting a variable’s lower bound if the
coefficient is positive and substituting a variable’s upper bound if the coefficient is negative and
the constraint residual is greater than zero (0) then this is declared infeasible. The presolve
calculation for the lower bound is its converse.
Though the problem was detected to be infeasible quickly and precisely, there is no particular
insight as to what could be the inconsistency issue i.e., no bounds were isolated. And, if this
were a much larger IOP, then with just one constraint (or variable ) violation message, this
would be very difficult to diagnose the problem further. It should also be mentioned that most
presolvers will preempt the solving process once the first infeasibility is detected where tracing
options can be specified, it is still a daunting task to review the trace for infeasibility diagnostic
purposes.
Another popular approach is to add artificial, error, elastic, excursion, safety-valves, infeasibility-
breakers or penalties variables to each of the variable bound constraints and if we minimize
these artificial variables with an arbitrary weight of 1000.0, we get a solution of 0.9 – 1000.0 *
0.1 = -99.1 where 0.1 is the upper bound excursion for variable x2 i.e., x2 <= 0.80 + 0.1 = 0.9.
Yet the augmented or modified problem is now feasible, the presence of non-zero activities for
the error variables requires analysis to understand why it chose x2’s upper bound to relax and if
we had many active elastic variables then the analysis becomes even more challenging. In fact,
this is the notion behind IIS which strives to find canonical sets of excursion variables in order to
maximize the possibility of isolating a localized region of the problem from which to investigate
the root cause, defect or fault of the infeasibility more effectively.
Infeasibility Diagnosis for Quantities

3. Our straightforward approach in IMPL is not only to dispatch the presolving infeasibility
messages from the solvers and to allow the user to augment excursion variables to all variables
in the model but also to provide an analysis routine to assist in the diagnosis of infeasible
problems.
As mentioned, the technique is actually a tightening method we use as essentially a “testing”
method to try to contract the size of an upper bound or to try to expand the size of a lower
bound. It does this by maximizing or minimizing each quantity variable one at a time (which can
easily be run in-parallel) and comparing its lower and upper bound respectively. For this simple
infeasible quantity problem, we explicitly show each testing problem’s formulation below:
Test for x1’s Lower Bound:
Maximize: x1
Subject to: x1 – x2 = 0
0.0 <= x1 <= INF
0.7 <= x2 <= 0.80
If x1* (0.8) is less than (<) x1’s lower bound (0.9) then infeasible. This is true, therefore x1’s
lower bound is inconsistent with the rest of the problem.
Test for x1’s Upper Bound:
Minimize: x1
Subject to: x1 – x2 = 0
0.0 <= x1 <= INF
0.7 <= x2 <= 0.80
If x1* (0.7) is greater than (>) x1’s upper bound (1.0) then inconsistent. This is false, therefore
x1’s upper bound is consistent with the rest of the problem.
Test for x2’s Lower Bound:
Maximize: x2
Subject to: x1 – x2 = 0
0.9 <= x1 <= 1.0
0.0 <= x2 <= INF
If x2* (1.0) is less than (<) x2’s lower bound (0.7) then infeasible. This is false, therefore x2’s
lower bound is consistent with the rest of the problem.
Test for x2’s Upper Bound:
Minimize: x2
Subject to: x1 – x2 = 0
0.9 <= x1 <= 1.0
0.0 <= x2 <= INF

4. If x2* (0.9) is greater than (>) x2’s upper bound (0.8) then inconsistent. This is true, therefore
x2’s upper bound is inconsistent with the rest of the problem.
As can be seen, for the specific variable in question, its lower and upper bounds are reset to be
“free” instead of their usual “finite” bounds. If there is a contraction between the optimized value
and its bound, then we can declare the variable to be inconsistent. For this example, the lower
bound of x1 and the upper bound of x2 are both flagged or tagged as inconsistent. Though
there is no way of knowing if x1’s lower bound is too high or if x2’s upper bound is too low but it
does provide a relatively basic and clear way of isolating or locating potentially inconsistent
variable bounds in the quantity dimension, which as previously stated, experience shows that
this is where a bulk of the “dirty” data can be vetted in a straightforward manner.
From a computational perspective, the analysis can be performed for one time-period or all
time-periods if a significant amount of the data is time-varying. In addition, we do not need to
re-configure the model for each testing optimization given that we can easily modify the
variable’s objective function weight and bounds and hence we only need to change the matrix
and re-solve the LP dual simplex.
References
Fourer, R., Gay, D.M., “Experience with primal presolve algorithm”, AT&T Bell Laboratories,
Numerical Analysis Manuscript, 93-106, April, (1993).
Greenberg, H.J., “How to analyze the results of linear programs. 3. infeasibility diagnosis”,
Interfaces, 23, 120-139, (1993).
Chinneck, J.W., “Finding a useful subset of constraints for analysis in an infeasible linear
program”, INFORMS Journal of Computing, 9, 164-174, (1993).
Andersen, E.D., Andersen, K.D., “Presolving in linear programming”, Mathematical
Programming, 71, 221-245, (1995).
Chinneck, J.W., “Feasibility and infeasibility in optimization: algorithms and computational
methods, Springer Science, New York, (2008).
Appendix A – Infeasibility.IML File
i M P l (c)
Copyright and Property of i n d u s t r I A L g o r i t h m s LLC.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Calculation Data (Parameters)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sCalc,@sValue
START,-1.0
BEGIN,0.0
END,1.0
PERIOD,1.0
&sCalc,@sValue
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Chronological Data (Periods)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
@rPastTHD,@rFutureTHD,@rTPD
START,END,PERIOD
@rPastTHD,@rFutureTHD,@rTPD
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

5. ! Construction Data (Pointers)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sUnit,&sOperation,@sType,@sSubtype,@sUse
S,,perimeter,,
P,,processc,blackbox%,
D,,perimeter,,
&sUnit,&sOperation,@sType,@sSubtype,@sUse
&sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype
S,,o,,out,
P,,i,,in,
P,,o,,out,
D,,i,,in,
&sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype
&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState
S,,o,,P,,i,
P,,o,,D,,i,
&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Capacity Data (Prototypes)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sUnit,&sOperation,@rRate_Lower,@rRate_Upper
P,,-999.0,999.0
&sUnit,&sOperation,@rRate_Lower,@rRate_Upper
&sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper
S,,o,,0.9,1.0
P,,i,,-999.0,999.0
P,,o,,-999.0,999.0
D,,i,,0.7,0.8
&sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper
&sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper
S,,o,,-999.0,999.0
P,,i,,-999.0,999.0
P,,o,,-999.0,999.0
D,,i,,-999.0,999.0
&sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper
&sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed
P,,i,,-999.0,999.0
P,,o,,-999.0,999.0
&sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Cost Data (Pricing)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sUnit,&sOperation,&sPort,&sState,@rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight
D,,i,,1.0,,,
&sUnit,&sOperation,&sPort,&sState,@rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Command Data (Future Provisos)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time
S,,1,1,BEGIN,END
P,,1,1,BEGIN,END
D,,1,1,BEGIN,END
&sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time
&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time
S,,o,,P,,i,,1,1,BEGIN,END
P,,o,,D,,i,,1,1,BEGIN,END
&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time