Diagnosing Infeasibilities in IMPL

258 views

Published on

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.

Published in: Engineering, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
258
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Diagnosing Infeasibilities in IMPL

  1. 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. 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. 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. 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. 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

×