Representing knowledge about linear programming formulation

Annals of Operations Research, 21 (1989) 149-172 149

REPRESENTING KNOWLEDGE ABOUT LINEAR PROGRAMMING FORMULATION

Pai-chun MA 1, Frederic H. M U R P H Y 2 and Edward A. STOHR 3

i College of Business & Economics, University of Delaware, Newark, DE, U.S.A. 2 School of Business, Temple University, Philadelphia, PA 19112, U.S.A. 3 Graduate School of Business Administration, New York University, New York, NY, U.S.A.

Abstract

This paper describes a system, LPFORM, that enables users to design linear programming models interactively, using graphics. An output of the system is an algebraic statement of the model and data references that are subsequently used to generate the input for a solver in the standard MPS format. The emphasis of this paper is on the types of knowledge one has on the submodels that make up larger models and how this knowledge can be organized.

I. Introduction

Experience in applications of large mathematical programming models shows that the state of the art in optimization algorithms far outstrips our ability to construct the models and to interpret the results. As alluded in Gass [13], Greenberg [15] and Murphy et al [26], the human and computer resources expended in generating, analyzing and maintaining correct models can exceed the cost of computing an optimal solution by, perhaps, an order of magnitude. While human modeling skills are important, success in modeling large applications is also very dependent on the model management facilities provided by the software that is being used. The PLANET system at General Motors [5] provides an example of the usefulness of good user interface and model management characteristics.

Over the years, continuous improvements were made in the codes used to solve LP's. To help address the model construction problem, Matrix Generators have been developed to automate partially the generation of the input data for the Solvers (examples are OMNI [27] and D A T A F O R M [6]). These systems are a major Step forward but require skilled users since they are essentially programming languages. Another disadvantage is that they provide very few checks on the structures of the model. As a result, problems in the formulation, such as infeasibility or unboundedness of the solution cannot be discovered until after the model has been generated and run. Welch [30] has developed a system called PAM that simplifies the process of developing inputs to D A T A F O R M . Some more recent Matrix Generators allow users to state their problems in algebraic

© J.C. Baltzer A.G. Scientifio Publishing Company

150 Pai-chun Ma et al. / Representing knowledge about LP formulation

form (GAMS [18] and AMPL [12]). Algebraic languages are non-procedural and produce compact statements that provide good documentation. Despite their advantages, algebraic languages are difficult for anyone other than an expert to understand and there is room for improvement in the consistency checking performed by these systems.

Much current research is aimed at improving the modeling process. Geoffrion [14] has developed the technique of Structured Modeling which provides a representation scheme for a broad class of operations research models including LP's. Dolk [9], Krishnan [19] and Fourer et al. [12] have developed new modeling languages. See also Fourer [11], Lucas and Mitra [20], Bradley and Clemence [3], and Greenberg [16] for further work on the subject.

Our research is also concerned with the model construction phase of the modeling life cycle. This paper describes some of the results from our research. Our ideas have been implemented in a prototype system, LPFORM, to help modelers correctly formulate linear programming (LP) models (Murphy and Stohr [24] and Ma [22]). LPFORM allows users to define their problems in a graphical form using icons to represent real world objects such as warehouses, transportation flows, production facilities, inventories and so on. It also supports a number of model building strategies such as hierarchical decomposition and the composition of larger models from submodels. An algebraic representation is generated as a byproduct of the formulation process. This can be used to validate and document the model. The interface is described in Ma et al. [21] and is being developed further and tested by Asthana [1]. Section 2 of the paper illustrates the interface using an example.

The remainder of the paper describes the knowledge base used by LPFORM to translate from the pictorial representation to an algebraic representation, to combine submodels into larger models, and to provide consistency checks on the resulting formulation. Section 3 describes the inference process and section 4 the structure of the knowledge base. In section 5, we focus on how models can be composed from more basic sub-structures and provide a systematic view of the semantic relationships that hold both within models and between different models. Some basic problem templates are described. Section 6 uses the information on substructures, showing how a larger model evolves from the simple models.

A major idea in the paper is to create a separation between logical models as viewed by users and their physical embodiment as collections of physical components in the model base of the system.

2. A graphical representation for model specification

The LPFORM system uses a graphics interface to facilitate the design of a model. LPFORM translates from an iconic problem representation to an alge-

Pai-chun Ma et aL / Representing knowledge about LP formulation 151

Model --> I LPFORM I --> LPSPEC --> I LPFORM I --> MPS Statement

builder I Interface I Statement I Analyzer [ to Optimizer

Fig. 2-l. The LPFORMsys t em.

braic statement of the model and finally produces the input needed by solvers such as LINDO [28] or IBM's MPSX [17]. Figure 2-1 shows the structure of the prototype system.

The LPFORM Interface works on an IBM P C / A T class machine, using a set of graphics tools written in the C programming language [10]. A prototype of the LPFORM analyzer has been implemented in PROLOG [22]. The two subsystems are loosely coupled. The Interface sends the results of the user specification to the Analyzer in the form of statements in the LPSPEC language [21]. Each LPSPEC statement captures a single action made by the user in the graphics interface.

One can build a model by first representing the model in a systems diagram. Here one constructs blocks that represent black boxes and links that represent interconnections between blocks. The links represent flows and the blocks may be empty or contain activities. An empty block with inputs and outputs is a material balance constraint. A block that contains activities can be any type of submodel. It may stand for a collection of general rows and columns to be specified at a later stage in building the model or it may be a place holder for a pre-specified template.

Hierarchical layers are supported by allowing blocks to represent collections of blocks (or sub-blocks) plus their linkages. For example, a refinery model may be a single block in an initial LP and subsequently decomposed into blocks representing individual refinery units and links representing pipe connections. Finally, blocks can be replicated in either space or time.

The graphics interface is explained in detail in Ma et al. [21]. Figure 2-2 shows a sample screen.

The screen contains a central work area, where graphs can be drawn, and three areas for collections of commands. The commands in the top border are used for model management operations such as loading and saving the problem statement, accessing the database, moving up and down a hierarchical level in the model, and formulating the model to produce the algebraic statement and then, op- tionally, the full matrix, objective function and right hand side.

The commands in the bottom border, manipulate the graphical images under construction in the center of the screen. These allow the user to step backwards and forwards through prior model building steps, to delete and restore model components, to show the detail underlying a part of the problem representation, and to erase the screen.

The area on the right of the screen contains the commands used for modeling. The data commands are separated from commands used to define the model

152 Pai-chun Ma et aL / Representing knowledge about LP formulation

PROBLEM: p a r t s VERSION: $ LAST UPDATE: 03/31/88 [

LOAD SAVE PROS-DATA DATABASE DICTIONARY UP DOWN SOLVE QUITI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LEVEL: I GB~tPH: 1 CURRENT OP: LIHE_BLOCI

FACTORIES

2

~ g K E T S

I I

T I ==========> I

I I I . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REP:

SAC[ [ ] FOKWD [ ] DELETE [ ] UI~DELETE [ ] SHOW-DET [ ] ERASE [ ] OPT: LlUl TYPE: SPACE[] TIRE[] FLOW VAE: T . . . .

DATA :

I, IODE: DATA P.EL : x" TAB : ¢

PAR : p

SET : •

STEUCTUB.E

C-B: []

L-B: -';> L - O - t : : - -> S-lO: =[]=

D - I : . : . D - O : I_1 D-R: 0=0 D-T: D-A: =1- C-M: <

] ] ] " / v

Fig. 2-2. Graphic screen for LPFORM.

structure and are located in the upper part of the right border. They allow the user to link the symbolic model to the data either interactively during the terminal session or by specifying links to existing data in a database. A relational database query language, which is part of the interface system, performs queries and manipulates the data.

The commands for defining model structure are in the lower part of the right-hand border and are associated with icons. To place an object on the screen, users point to the command with a mouse and then to a position on the screen. They are then led through a series of questions associated with the command or asked to fill in an electronic form to supply necessary textual information. The model building commands include Create-Block (C-B), Link-Block (L-B), Def- Activity (D-A) and Call-Model (C-M). The commands respectively create a block that can be filled with an activity or a template, link blocks for which the output of one is an input to another, define a linear programming activity in terms of its inputs and outputs and place a template (submodel) into a block.

Figure 2-2 also shows the graph that would be constructed to define a production and distribution problem, "parts", in which parts, i, and products, j , are produced at factories, f , and shipped to markets, k. The modeler places "block icons" for the factories and markets on the computer screen, links the two blocks to define the transportation activity, and then places an "activity icon" in the factories block twice. As these actions are performed, the user is p rompted for

Pai-chun Ma et al. / Representing knowledge about LP formulation 153

FACTORIES

T X I

i LABOR LABOR I

N A C X I t t E S X A C X I N E B I

. . . . . . . . > . . . . . . . . . > l

RAIINATS PRODUCTS I . . . . . . . . > . . . . . . . . . > 1

PARTS I . . . . . . . . . . . . • I

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

Fig. 2-3. Det~led acti~ties in factories.

the names of the blocks, the decision variables (X, Y and T) and the inputs and outputs of the production activity. If the show-detail ( S H O W - D E T ) command is executed for the factories block, the center screen is cleared, detailing the contents of the block as in fig. 2-3. Given the problem specification shown in figs. 2-2 and 2-3 the following algebraic statement is produced:

Min: y'. y~ cst2f,jXLj f ~ Factories j E

Products

+ E E cstlf , iYf, i fE Factories i~ Parts

+ Z ~-. Y" cSt3Lk.jTLk.Y f~Factories k~M~rkets j ~

Products

Subject to"

~, d / j . jXLj+ ~. cf, t,iYf, i<~sflf.t,V( f~Fact°r ies j ~ Products i ~ Parts l ~ Labor

E bf .m,jXf , j + E a f m i Y f i < ' ~ s f m f m v(f~Fact°ries j~Products iEParts . . . . ' t m ~ Machines

- ~ fLi,jXLj + YLi=O,V( fEFactOries j E Products ~ i E Parts

ef, r.iYf.i<~sfr/r, V(fr:Fact°ries • Rawmats i E Parts

X f , j - E Tf,k,j=O, V{ f E Fact°ries k ~ Markets ~ Products

. ( k ~ Markets E TLk,j>~dmpk,y, V I j ~ P r o d u c t s

j ~ Factories


This model can be developed using two alternative approaches. The first uses basic concepts of LPFORM to construct the model from "first principles". In other words, the components of the model, blocks, activities, links and so on, are described by the user in detail as in the illustration above. The second approach to model formulation involves the use of templates in the knowledge base that fill the blocks positioned on the screen. The formulations resulting from both approaches are identical.

2.1. FIRST PRINCIPLES APPROACH

Figures 2-2 through 2-5 show some of the screens generated by a user defining the Parts problem from first principles. The user can decompose the problem hierarchically. The first layer shown in fig. 2-2 consists of a problem overview-there are only two blocks, one representing factories and the other markets with a single transportation link between them. The second level expands on the network identified in the first with a representation of all of the individual factories, markets and their links. If it is assumed that all factories can ship to all markets, there is no need to draw the second, more detailed, level of the problem. Figure 2-3 shows a further decomposition of a block into different activities. Each actual factory and market will inherit the properties specified for the parent "factories" block; each actual market will inherit the properties of the "markets" block.

After the graph in fig. 2-2 is drawn, the user specifies the product ion activities in the factories blocks using the Def-Activity (D-A) command. Screens in figs. 2-4 and 2-5 are obtained by pointing to the D-A command on the right of the screen and then to the factories block. D-A is modeled after the activity modeling approach in Dantzig [7], in which an activity set is defined by its inputs, outputs, activity coefficients, and objective coefficients (profits or costs).

A C T I V I T Y S E T : p e L r t s . . . . . . . . . . . . .

A C T I V I T Y V A k : ¥ . . . . . . . . . . . . . . . . .

I N P U T S :

l a b o r , m a c h i n e s , ravmats . . . . . . . .

O U T P U T S :

p a x t s . . . . . . . . . . . . . . . . . . . . . . . . . .

0 S 3 . C O E F F T : p o r t o _ c o o t . . . . . . . .

O B J . TYP E : c o o t . . . . . . . . . . . . . .

A C T . C O E F F T S : l a b o r _ p a r a s , c a p a c i t y _ p a r t s .

t e c h _ p a r t 8 . . . . . . . .

U P P E E S O U N D S : # . . . . . . . . . . . . . . . . .

LOWER S O U N D S : # . . . . . . . . . . . . . . . . .

U N I T S : # . . . . . . . . . . . . . . . . .

MATH P LOP : l i n e a r . . . . . . . . . . . .

A C T . T Y P E : p r o d u c t _ m i x . . . . . . .

Fig. 2-4. Define production activity of parts.

Pai-chun Maet al. / Representing knowledge about LP formulation 155

ACTIVITY SET: p roduc t s . . . . . . . . . . ACTIVITY VAR: X . . . . . . . . . . . . . . . . . INPUTS: l a b o r , e a c h i n s s , p a r t s . . . . . . . . . . OUTPUTS: p roduc t s . . . . . . . . . . . . . . . . . . . . . . . . OBJ. COEFFT : p r o d u c t s _ c o s t . . . . . OBJ. TYPE : co l t . . . . . . . . . . . . . . ACT. COEFFTS: l a b o r _ p r o d u c t s ,

c a p a c i t y _ p r o d u c t s . r i c h p r o d u c t s . . . . .

UPPER BOUNDS: # . . . . . . . . . . . . . . . . LOWER BOUNDS: # . . . . . . . . . . . . . . . . . UNITS : # . . . . . . . . . . . . . . . . . MATH PROP : l i n e a r . . . . . . . . . . . . ACT. TYPE : product_mix . . . . . . .

Fig. 2-5. Define production activity of prodcuts.

In the next step, the user specifies the members of the sets represented by factories, markets, products, labor, machines, rawmats, and parts using the SET command. The members of the set can be entered interactively (e.g. "north, south, west"), or by a relational database query (e.g. "SELECT Factory_name FROM Factories WHERE Region = USA."). Here Factories is an external relational database table containing Factory_name and Region fields (among others).

The final step in defining the problem is to specify the direction of optimization using the OPT co~mmand in the lower right corner of the screen. After this interaction, the user saves the problem (using the SAVE command in the top of the screen) and then selects the SOLVE command to generate the LPSPEC statements.

The internal tableau shown in fig. 2-6 and symbol dictionary shown in fig. 2-7 can be used to check the formulation. It has been designed to display simulta- neously both the algebraic and the tableau (block) structure of an LP problem. If the problem is large, the display is spread across several screens.

PROBLEM/HODEL/FUGI~FdlT = pex te .

BOW\COL X(~,~) ¥ ( ~ . i ) T(~ .k ,~) RKS OBJ- '- ÷ S ~ t ; j } c s t I [ t ; j ] * S { t ; i } c s t l [ t ; i ] + S { / ; k ; j } c s t 3 [ f ; k ; j ] MIN Use [~;1] ÷S~ j}d [ f ; l : j] ÷S{i}c [1:1;£] < +el1 [ t ;1 ] Use [1 ;m] +S{j}b[t ;n; j ] ÷S{i}a [ t ;re;i] < +s£m[~ ;m] U n [ t ; i ] -S~j}t [ t ; i ; | ] +1 [t ; i ] -- +01t ; i ] Use [1 ; r ] *S{i}s [ 1 ; r : i ] < ÷ s t r [t ; r ] Uss [~ ; J ] ÷1 [1 ; j ] -S{k}t I f ; k ; j ] : ÷ O [ / ; j ] Supply[k; j ] +S{t}1 ( t ; k ; j] > +drop [k; j ]

Fig. 2-6. Internal tableau of parts model.

156 Pai-chun Maet al. / Representing knowledge about LP formulation

* Symbol c o n v e n t i o n ot p a r t s *

Set ~e ference: S1~BOL: SET ~A/~: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

: F a c t o r i e o NeLning: b l ock , f rom_b lock .

I

1 : Labor Meaning: i n p u t .

a : Machines Meaning: i n p u t .

k : Markets Moaning: t o _ b l o c k .

i : P a r t s Moaning: s e m i _ t i n S , h o d _ p r o d u c t .

J : P roduc t s Meaning: o u t p u t , c o m o d i t y .

r : Ra~ato

Meaning: input.

A c t i v i t y Ee fe renc* : S~BOL: ACTIYITT (VAIIABLE): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Z ( f . j ) : l ( F a c t o r i a s . P r o d u c t s ) T ( f , i ) : Y ( F a c t o r i e e , P a r t s ) T ( ~ , k . j ) : T ( F a c t o r i s s , M a r k s t s , P r o d u c t o )

C o e f f i c i e n t Reference : SYMBOL: COEFFICIENT (DATA) : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

c s t 2 [ f ; j ] : P r o d u c t s _ c o t [ F a c t o r i e s . P roduc t e] d [ t ; 1 ; j ] : Labor_produc t s [ F a c t o r i e s . Labor. P r o d u c t s ] b [f ;n; j ] : C a p a c i t y _ p r o d u c t s [ F a c t o r i e s . g u c h i n e o , P roduc t s ] :f [:t ; f ; ~ ] : Toch_product s [ F a c t o r i e s , PeJrt s , P r o d u c t s ] c e t l [ t ; i ] : P a r t s _ c a t [Fact o r i e8 0 P~r t s] C [ f ; 1 ; i ] : L a b o r _ p a r t s [ F a c t o r i e s . Labor . P a r t s ] a [ t ; n ; i ] : C a p a c i t y _ p a r t s [ F a c t o r i e s .Machines . P a r t s ] • [ i ; r ; i ] : Tech_par t8 [Fact e r i e 8 ° l~evmat o. P a r t e] I [ f ; k ; j ] : 1 [ F a c t o r i e s , X a r k e t , . P roduc t s ] ! If ; i ] : I [ F a c t o r i e s . P a r t s ] 0[~ ; i ] : O [ P a c t o r i o s . P a r t s ] 1 [f ;J ] : 1 [ F a c t o r i e s . P r o d u c t , ] 0 [g ; j ] : 0 [ F a c t o r i e s . P roduc t s ] s f l [ t :1] : L h s ? , ' t u c t o r i s s ' l a b o r [ F a c t o r i e s , Labor] egm[t ;a] : R J ~ u ? " f a c t o r i e s ' m a c h i n e s [ F a c t o r i e s . M a c h i n e s ] s f r [f ; r ] : E h s ? , ' f a c t o r i o s * r a x m a u t 8 [ F a c t o r i e s . kavmats] dnrp [k; j ] : ~ h s ? e " d e m a n d ' n a r k s t s ' p r o d u c t s [Marke t s , P roduc t s ] c e t 3 [ f ;k; j ] : Ob j?e 'gac tor ise 'n~u~kete*product8 [ F a c t o r i e s ,

lqarket s .P roduc t s ]

Fig. 2-7. S y m b o l d i c t i o n a r y o f p a r t s mode l .

2.2. M O D E L M A P P I N G A P P R O A C H

Referring to fig. 2-2, it is intuitively obvious that the Parts model consists of two product-mix problems and a transportation problem. We, thus, can use the


create_block(parts.[~ac~ories.m~rketJ]).

di~_set(tactories,[north,south,w*st]). dit_Jot(markets.[nwh.svh.vwh]). deg_set(products.[~l.~2.t3]). det_eet(labor.[ll.12.13]). de~_eet(machines,[ml,m2,m3]). de~_eet(ravmate,[rl0r2,r3]). de~_sit(parts,[pl,p2,p3]).

call_model(transportation.parts. [~rom_block.to_block.co~odity]. [~ac~ories.me~rkets.products]o [~lov]. It], [gain_or_ion], [1]).

call_model(mult£Jector_product_mix.pezts. [block.material,labor.capital,output], [gactorioe.rawmats,labor.machine.peLrts], [volu,]. [y]. [tech_co*t.labor_co*t.capital_co*l], [t,ch_p~rts.labor_pecrts.capacity_part8]).

call_model(multi_factor_product_mix.parta. [block0material,labor.capital.outpu~], [gectorieo.parts,labor.machine.products], [vol~.] . Ix], [tech_coet.labor_coet.capital_co*t], [tech_products.labor_products,capacity_producta]).

optimize (mLn, parts, cost, symbolic).

Fig. 2-8. LPSPEC statements for model-mapping approach.

CALL-MODEL (C-M) command, accessing these templates in the knowledge base. Figure 2-8 shows the formulation of the same problem using the model mapping approach.

The C-M command links the names of indices, variables and data coefficients in the stored template to those that will be used in the new model. Thus, in this example, "from-block", "to-block", and "commodity" become, respectively, "factories", "markets" and "products". The standard templates are defined to be as general as possible.

3. Overview of inference process

The ability to define and store models for later reuse is a powerful feature that can help in composing and testing the models for large problems. While each user can develop his or her own model base, we are also developing a standard set of problem templates as part of LPFORM. As this is a new capability not available in other systems, it is of interest to explore the possible types of models and how


they can be combined into more complex structures. In this section, we first describe how models are stored in the model base and then briefly outline the structure of the system that determines how they should be selected and combined into larger models. For an alternative approach to a model library, see Bradley and Clemence [4].

A stored LP model consists of the objective function and constraints in algebraic form plus statements that define the values for the data coefficients. The latter consist mainly of arithmetic statements and database retrieval statements that are executed at the time the model is to be run; explicit numerical data values can also be stored if desired. We will not discuss the data handling aspects of LPFORM further in this paper (see Stohr [29] for a more complete description).

The basic building block for the algebraic representation of an LP is a "model piece". This is simply an algebraic term together with its associated summation information or a right-hand side with inequality information. For example: F,/ai.jX~,.i i s a model piece. The objective function and constraints are then simply collections of model pieces.

The objects in the model base need not be complete LP models. In fact, in LPFORM's standard model base, the named objects are more often individual constraints or even fragments of constraints and single model pieces. All of these components are individually addressable. For example, the unique identifier for a model is the model name, while the unique identifier for a constraint is the model name, the constraint type and the row index set associated with the constraint.

When LPFORM interprets a model definition, it first generates a sequence of calls to the model base to retrieve the constraint fragment types relevant to the new model. (If a Call-Model statement is encountered, all the model pieces for a complete model are retrieved.) The second step is to customize the stored model pieces to the current problem. This involves substituting problem names for the dummy names in the stored pieces and, if necessary, changing the index set associated with a model piece or constraint fragment. For example, if a single time period model is to be built but the template pieces contain an index for time, the time index will be dropped automatically. Alternatively, new indices can be added beyond those contained in the stored template by using a "Replicate" command (see Ma et al. [21]). The third step in the process of generating the algebraic form of the model involves arranging the retrieved model pieces into their proper positions in the algebraic statement (see Murphy et al. [25]) for a description of this step).

In this paper, we are concerned only with step 1 above i.e. how L P F O R M selects the constraint fragments and submodels that are needed for the problem statement.


4. Knowledge base for models

As discussed above, the LPFORM model base consists of a collection of constraint fragments and complete LP models of certain standard types. Rules for extracting model components from the model base represent a higher level of knowledge about linear programming. These rules help L P F O R M perform three functions: 1. Translate from the input specification to the algebraic representation. 2. Discover missing or ambiguous components and query the user for clarifica-

tion. 3. Suggest additional problem components (activities of constraints) that may not

have been thought of by the user. The remainder of this section describes this structure of LP model knowledge.

4.1. THE NOTION OF A TRANSFORMATION

LP models represent physical actions of transforming inputs to outputs. A transformation involves some sort of flow. There can be a flow of inputs into a product, a flow of items from one location to another, or a flow of inventories through time. We now define the semantics underlying different types of LP transformations. Then we indicate how LPFORM uses this information to help it compose correct problem statements.

In the broadest sense, LP's are composed of activities (transformations) that consume or produce resources. A resource is described by three dimensions: what is being measured, where it is and when it exists. As a consequence, constraints can be identified by indices for what, where, and when plus other indices that may be required for unique identification. An example, which we discuss in greater detail in section 5, is when we need a balance constraint to determine the amount of a resource available and a second constraint to measure the utilization of the resource. Consider the LP variable, Xij.~. An activity set consists of all distinct occurrences of X for different values of i, j and k. We call the collection of individual indices, "i, j , k" , the index set for X.

There are three basic transformations: transformations in form, time and place. A transformation in form converts a collection of "whats" into another collection of "whats" while leaving place and time identical. Transformations in place and time have analogous definitions for "where" and "when" respectively. The structure of the index sets for these three different types of transformations are shown in fig. 4-1. Here, for example, a transformation in place must, at least implicitly, have "f rom place" and " to place" indices, a transformation in time " f rom when" and " to when" indices and a transformation in form ."from what" and " to what" indices. Each transformation may also have indices for other dimensions and a "how" index that describes, for example, the mode of transportation or a type of processing when there is more than one alternative.


ACTIVITY

I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I I I PLACE TIME FORM

from where Where Where

to where

When from when When

to when

What What from what

to what

How How How

Fig. 4-1. Index roles for basic transformations.

The index types in fig. 4-1 are not always explicit in the problem formulation. For example, if time is unimportant to the decision problem, the time index is dropped. As another example, production activities are often indexed only by their " to what" index (what is produced). The "'from what" index (or indices), indicating what is consumed in the production process, is not used. In this case, there will be no index with a "from-what" role. However L P F O R M can infer the "from-what" using the input structure of the activity. Also, any of the slots may consist of more than one index in the usual sense. For example, if an item is the ith component of the j t h product, the form slot will contain the pair of indices (i, j ) . The LPFORM system has rules to handle such exceptions.

Note that one can also have compound activities, such as simultaneous transformations of time and place, if it takes one period to ship a product so that items shipped at time t are available at their destinations only at time t + 1.

The role of each index provides important information to LPFORM. For example, if any index set contains a time index then, in an LP, it is usual that most other index sets will be indexed by time. As explained in Murphy et al., [25], it is also possible for LPFORM to use the index role information to infer missing components of the formulation.

We organize the information about indices using the notion of frame. A frame is a data structure consisting of "slots" that can hold information or trigger procedures (Minsky [23]). The slots describe the object represented by the frame and its relationships to other objects. L P F O R M uses a separate "Index-role" frame to represent the indices for each activity and constraint set. The slots in Index-role contain the index name and its role in terms of form, place, time and mode.

Pai-chun Ma et al. / Representing knowledge about LP formulation

4.2. NETWORKS OF MODEL RELATIONSHIPS

161

The three types of transformations are the basis for classifying model components using a "semantic net" representation (Winston [31]). A semantic net describes the relationships among entities. In this case, the entities are constraint fragments and models in the model base. The relations are of two types. "Is-a" relations are used to show that one class of components is a subclass of another class; this allows the more special class of objects to inherit properties from the more general class. Thus, a transportation model is a place transformation which in turn is a subclass of linear programs. The second type of relation is "may-contain"; this is used to help the system check the completeness of a model and to suggest other components that may be needed. For example, a standard product- mix model "may-contain" bound constraints on production variables or blending constraints. Figure 4-2 presents an illustrative semantic net that can grow as users add templates. In the next section, we elaborate on the time transformation segment of the network.

Users may wish to add domain-specific knowledge to the basic network of relationships supplied by LPFORM. Thus, the system could be aware of the fact that a refinery model may contain a blending model. Since a blending model may also be part of a model of a chemical plant, the resulting network structure is not a tree.

The network of relationships in the model base is linked to another network that describes the inputs consumed and outputs produced by the models. We will not describe this network here but it is similar to that in Binbasioglu [2].

L i n e a r Program

I I i s - a i s - a

I I P r o d u c t P r o c e s s Mix S e l e c t i o n

1 I n a y - c o n t a i n n a y - c o n t a i n

I . . . . I I I

v v

B l e n d i n s C o n s t r a i n t

I 1 i s - a i a - a

I I Form P l a c e

T r e n s l o r m a t i o n . . . . . T r a n s @ o r m a t i o n

I l i e - a i s - a

I I

1 . . . . . . . . . . . . . . . . . . . I

is-a

I Time

T r a n e ~ o z ~ a t i o n

I I I I

n a y - c o n t a i n J n a y - c o n t a i n I I I

Trunsportation Tr~aehipnsnt Naterial 1

. . . . . . . . . . . . . . . . . . . . . . I

I 1 may - c o n t a i n

1 I I

I I I v v v

Bounds

Kamo~'ce

Fig. 4-2. A semantic net of some LP sub-models.


5. Modeling knowledge and templates

The model base in LPFORM contains standard templates organized as transformations in form, time and place. The model data dictionary shown in fig. 2-7 is part of the stored representation of a model as is the collection of model pieces from which it is composed.

The semantic net described above is physically and logically separate from the model base. Using the "is-a" and "may-contain" relationships, we can organize the information about models into a semantic net. The nodes in the semantic net represent references to LP models or common submodels in the model base. The nodes contain information concerning which templates are needed to form the model, which may be needed, and the conditions under which each referenced template is applicable.

Rather than provide an exhaustive list of the templates in the model base on the one hand and the logical models in the semantic net on the other, we describe some of the relationships and rules that exist under the " t ime" node in the semantic net of fig. 4-2. This will serve also to point-out the important distinction between materials and capital and labor resources.

There are two types of problems having a time dimension. The first is the class of scheduling problems where we want to set up a cyclic schedule. Here, time is not linear in the sense that period T + 1 is the same as period 1. In this situation we want the intelligent system to use modulo arithmetic when indexing in time so that, for example, staff who have not completed a work cycle by the end of period T carry over to the first period. The second is the class of multi-period planning problems where T represents the truncation of an unbounded horizon. If there are any physical products that are inventoried in the model, then there is no cycle unless one wants the ending inventory and labor force to match the beginning inventory and labor force. With these non-cyclic production models the basic structure of the static form and place transformations described above are replicated for each time period and some linking variables and constraints are added.

LPFORM distinguished the cyclic scheduling models from the finite horizon models by incorporating two nodes, "cyclic" and "finite-horizon", linked to the time transformation node by "is-a" relationships. The cyclic LP frame consists of a list that contains procedures for itemizing, possible cyclic schedules. We leave further discussion of cyclic models to another paper.

The finite horizon object is partitioned into components that relate to materials and resources.

5.1. THE DISTINCTION BETWEEN MATERIALS AND RESOURCES

In the theory of production, capital, labor and materials are used to produce goods. When a time dimension is present, each of these resources should be

Pai-chun M a et al. / Representing knowledge about L P formula t ion 163

treated differently in the formulation. Materials differ from capital and labor. We consume materials but we use only the services of resources such as capital and labor.

With materials, if storage is possible, we have inventories and intertemporal links that transfer goods from one period to the next. In the tableau, typical inventory activities have a + 1 in a period t constraint and a - g in a period t + 1 constraint. The constraints that are intersected by the activity are the ones indexed by the material in successive time periods. Here g indicates the gains or losses. That is, the product in period t is the input, along with storage costs, to a process where the output is the additions to the product in period t + 1. The inventory constraint fragment for product j in period t + 1 is:

- gj Ij. ,_ 1 q- Ij,, - E additions, + Y'. reductions, = O. (1) t t

Here the "add i t ions" and "reduc t ions" slots are not specific to the template. They must be filled by matching the template to activities such as buying or selling which, respectively, add to or reduce the level of resource.

We store templates using Dantzig's [7] sign conventions for supply and demand where - gj indicates supply and + 1 indicates use. When writing out the algebraic statement, we reverse the signs to the more common form in some constraints such as a transportation supply constraint.

Once capital stock and labor come into existence, they remain at a positive availability until retired. There are several alternative formulations, depending on whether we aggregate all of the capacity together or we keep track of capital stock and labor by when it is acquired, termed vintaging.

If we aggregate the,capacity added in previous periods, then we have an inventory structure analogous to the structure for materials. In this situation we assume that equipment of different ages performs the same and either there are no retirements or that a fixed percentage is expected to retire each time period. Thus, the only information we have to keep is the total amount of equipment available. The form of the model parallels the structure for inventories:

- a Y t - 1 + Yt - Y'~additionst = 0 (2) t

Uses, - Y~ <~ 0 I

The additions represent the process of adding new capacity in period t and the Y's tell how much capacity is available in each period. The coefficient a is the fraction of capacity that carries over from one period to the next. In period 1 either Y0 is set equal to existing capacity or the variable can be eliminated by having a right-hand side equal to existing capacity. While both formulations are correct, we choose to add constraints specifying the initial levels of the variables. The operational activities, the "uses", describe how the capacity is utilized and are part of the representation of a transformation in form.

164 Pai-chun Ma et al. / Representing knowledge about L P formulation

Note that the distinction between a material and a resource creates the need for a second constraint to account for the use of capacity. The material balance is separate because using the capacity does not consume it so that it remains available in the next time period. The constraints (2) are an important example of when there are two constraints with the same index triples on form, place and time, requiring a fourth index to distinguish them.

If we account for a capital resource by vintage, by which we mean the year acquired, there is an activity with an entry for each constraint in which the resource is used. Say the resource addition activity intersects only one row in each period, its availability varies throughout its life and the efficiency of the equipment varies with its vintage and age. Then the model can have the following structure:

- o Y, 0

J . . . (3) ~_,mt.,,.jX,.,,.j -- o,,Y t <~ O. J

Here, Y, indicates the amount of capacity added in year t, v I through v n indicate the availability of capacity in the periods 1 through n since the equipment was acquired, where n is the life of the equipment. Also, m,,,,.j indexes the amount of capacity required for each unit of X,.,.j, where X,.~4 is the level of operation in mode j in the n th period since the capacity was acquired. The time period associated with this constraint is t + n - 1.

If one distinguishes vintage but the operating characteristics remain the same, the constraints (3) can be replaced by the following single constraint in each time period:

E m t o X , . j - E Vt-k+,Yk ~ Et (4) j k<~t

where E, is the amount of currently existing capacity available in period t. Since the operating characteristics of available capacity are the same over all vintages, we need only have operating variables determined by mode of operation, rot,j, not by mode and vintage. And rather than having separate capacity constraints for each vintage, only one constraint is required.

When there are alternative formulations, some are often more efficient than others in solution time. A good indication of the efficiency of the formulation is the number of nonzeroes in the constraint matrix. Thus, if the v's are constant over the life of the equipment but the equipment has a shorter life than the planning horizon, there is a more efficient formulation than (4) that will produce the same solution:

+ z , - z , _ . - Y, = o

E m t , j g t , j - o y t < ~ O (5) i

Pai-~un Ma et a L / R~resenting know&dge about LP ~rmu~tion

1

1 1 1 1 1 I I i i

1 1 1 ~ 1

1 1 ~ 1 1 I 1 1 1 1

Fig. 5-1. Mat~st~ctureofacfivitiesrepresentingar~ource~tha~edlifeoffiveyears.

165

where Z t is the amount purchased in time period t and n is the equipment life. In this formulation we add the resource acquired, Z, into a total of the resource and then subtract it out at the end of its life. This structure replaces trapezoidal structures dense with l's, as in fig. 5-1, with extra constraints having at most 4 nonzeros.

Thus, when the equipment life exceeds 4 years, there are fewer nonzeros with (5).

Since there may be a representation of the construction of the capital stock, the Z ' s may intersect other constraint rows. If there is no representation of the construction of the capital stock, the only other nonzero coefficient is the cost in the objective function, unless there are free rows that Carry accounting information not involved in the optimization.

When constructing the semantic net, we first distinguish cyclic scheduling models from finite horizon models by incorporating two nodes, "cyclic" and "finite-horizon", linked to the time transformation node by "is-a" relationships. The cyclic LP object has information in the model library consisting of a list that itemizes or contains procedures for itemizing possible cyclic schedules. The finite horizon object is partitioned into components that relate to materials and r e sources .

5.2. FRAME-BASED REASONING FOR MULTI-TIME PERIOD PROBLEMS

We are now in the position to describe the contents of the materials and resource frames and rules that we used to generate the appropriate constraint fragments. The materials object lists the materials that are inventoried, the template constraint (3) and data base references on coefficients for gains or losses during storage (e.g. yeast grows and alcohol evaporates). Also, the frame contains slots for information on inventory capacity or capacities, i.e. whether there are limits and to what products the limits apply.

The resource frame contains the constraints (2) through (6) together with rules that distinguish the situations in which each should be applied. Basically, these rules answer the following questions:

1. Is the availability constant over the planning horizon or declining exponen- tially over time?


2. Does the resource have a fixed life shorter than the planning horizon and constant availability over its life?

3. Is the efficiency constant over the life of the equipment?

If the answers are no to 3, then the problem structure is as in (3) were everything is distinguished by when the equipment is bought and how it is used. If the answer is no to 1 and 2 and yes to 3, then the structure is as shown in (4) where the available capacity is combined into a single utilization constraint. When the answer to 1 and 3 is yes and the equipment life is longer then the planning horizon, we have the structure with the single equipment inventory variable in (2). When 1 is false and 2 and 3 are true, the more efficient structure in (5) is appropriate. Also, when the answers are no to any of the questions, the frame has to contain the appropriate information or database references on availabilities a n d / o r efficiencies. Furthermore, the frame has to contain information on whether there are added restrictions on resource additions or utilization.

The implications of the answers to the three questions may be summarized usmg the ~ n o w i n g t r u t h table:

Value

Question Implication

I 2 3

T F T (2) - - F (3)

F F T (4)

F T T (5)

T T - not possible

The above is sufficient to describe the way L P F O R M handles resources and materials in the context of multi-period plann~" g problems.

There are other variations in time constraints that could be added to the knowledge base. One could add limits on growth in resources or inventories or the availability of overtime capacity.

6. Combining models

Submodels can be combined into larger models simply by matching the names of the variables and sets that are stored in the template submodels to the names that the user wants in the logical model that is being composed. This model-mapping approach was illustrated in section 2. The LPFORM system used the role information on the indices to check that the assignments are consistent and that the template is, in fact, applicable in the new context. The possibilities for further automating this name-matching process and for automatically developing the arithmetic and data retrieval statements needed to supply data to the model is a topic for future research.


The "is-a" and "may-contain" links in the semantic net of logical models obviously allow much flexibility in individualizing LPFORM to suit a particular set of user requirements. The property inheritance supported by the "is-a" links allows shorter model definitions and gives the system better explanatory capabili- ties. The "may-contain" links give the system the power to suggest model components that the user may not have thought of.

The process by which models are composed is described fully in Murphy et al. [25] and Ma [22] and will not be further explained here. However, it is worth noting how LPFORM composes the objective functions of larger models.

Typically, in large linear programs with embedded networks one uses only costs at source nodes and accounts for prices at nodes that are sinks. That is, costs are built up by accumulating expenses as they are incurred and a profit maximizing objective is constructed by calculating revenue where sales are made and subtracting costs where they are incurred.

If one has specified the templates properly, the knowledge base has a slot in all template-defining frames noting which objective function fragments are associated with maximization and which are associated with minimization. The objective function is constructed by subtracting minimization components from maximization and then the problem is solved as a maximization model. If there are no maximization components, the objective remains a minimization problem. Tests are then performed to make sure that there are no variables with maximization components in the objective function having outputs that feed into other outputs. (An output may be sold as an intermediate good, but this must be done by a separate activity from the producing activity.)

Since the objective function pieces are associated with the template, we do not include an object o~i the knowledge base for objective function; instead, we include a set of rules for combining the pieces into the objective function in the portion of the knowledge base containing the rules for constructing the full LP.

We close this section with an example showing how the submodels described above combine into a complete LP. This example illustrates not only how the submodels can be used but also the value of working at the algebraic level when formulating a model. We begin with a standard process selection model:

Min: E E cj,k , j E J k ~ K

Subject to

Z Z am,j,kPj.k<~b,, j ~ J k E K

E ,k>hj k ~ K

Pj,k = production of product j with technology k. b,. = amount of input m.


am.j, k = amount of m used in producing a unit of j . cj, k --- cost of producing a unit of j with technology k. hj = demand for j .

The next step is to add a time dimension and allow inventories for final products.

T T

Uan: E E E c.,,h.k.,+ E E h.Ij., t= l jeff k~K t= l j~J

Subject to

E E am,j,k,tej,k,, <~ bm,t j~J k~K

E h,,,, + Ij.,_,-I.>_.h. kEK Ij.0 = starting inventory

t = time. T = time horizon. hi, ̀ = per unit inventory holding cost. Ij,, = inventory of product j at time t (end of period).

We now expand on the time dimension for the inputs. The input constraints are partitioned by materials and resources. The materials constraints have the standard inventory submodel added. The resource constraints use the form of (5) where the equipment has a fixed life and all vintages have the same availability and operating characteristics.

T T T T

M i n : E E E Cj,k,tej,k,t "~- E E hj,tlj,t "~- E E hm,tlm,t + E E °r,tEr,t t=l jEJ kEK t= l jEJ t= l rnEM t = l r~R

Subject to

Y,.,_, + E ~ , , - Er . , -gr- Yr., = br.,

E E a,o.k.,Py.k.t- Yr., <~ 0 j~J k~K

E E am,j,k,tej,k,t--Im,t-l+Im,t<~bm,t jEJ kEK

E k~K I,,,,o, Ij,0 = starting inventory

Yr.o = existing capacity

M = the set of materials. R = the set of resources.


0r,, = the cost of a unit of resources. Er. , = the amount of resource r acquired in period t. Yr,, = amount of resource available in period t. gr = the life of resource r. br,, = amount of existing capacity retired at the beginning of period t.

Adding a location dimension for materials, factories and product destinations, involves replicating the factories, adding transportation models for materials and products and linking the transportation models to the factories by making the corresponding materials and products constraints at the factories into material balance constraints.

Min : T T

E E E E U.v./.,,,.,Ys,f.m,, q- E E E E Cj,k,t,fej',k,t.f t = l s~S., m~M f~F t = l jEJ k~K fEF

T T "Jr E E E hj,t,/Ij,t,f "~ E E E hm.t.flm,t,/

t=l j~J f~F t=l m~M f~F T T

E E E °r,,./E,,,,/+ E E E E Wf,d.j,tXf.d,j,t t='l r~R f~F t=l f~F j~J d~Dj

Subject to

E Z.,/.,.,,<~q..,..,

Ez, , : ,m, , -Z y' am,j,k,,,/Pj,k.,,/-- Im,t_1./+ l,..t./>~ 0 s~S,,, j~J k~K

Y..,_ I./ + E..,./- Er,t_g,,f + Yr,t,f = br,t, f

jaJ k~.K

E + z:.,_ x.:- I:.,.:- E x:.,,., = o k~K d~Dj

E >1

S m = the set of supply sources for material m. F = the set of factories. Dj = the set of demand points for product j . qs,m,t = limit on the supply of material m, at source s, in period t. Zs,/,m, , = the amount shipped from source s to factory f . Xi.a.j. , = the amount of product j shipped from factory f to demand location d.

Two notions can be learned from this exercise. First, by working at the algebraic level a very large model is developed by combining small m o d d s


without significantly increasing the difficulty in comprehending the model. At the very least, the model still fits on one page. Second, the rules for constructing the large model are explicit. Thus, LP model formulation is amenable artificial intelligence techniques.

Note that if we give the resulting model a name, say "mult iperiod-production- distribution", we can add this model as a node on the semantic net with "is-contained-in" arcs from the process selection, inventory, resource, and transportation models. In the model library we would store information on how these submodels are used and the composition rules in Murphy et al. [25] determine how the pieces fit together.

7. Conclusions

This paper has briefly introduced the LPFORM system and describes the knowledge base for LP models. An important distinction has been made between the physical components of models stored as templates in the model base and logical models that consist of collections of one or more templates and that are represented as nodes in a semantic net. The logical models can be produced as outputs of the system when required. This separation gives the system much flexibility and allows it to be customized quite readily to the needs of a particular user. For example, the algebraic statement of the model can be constructed on a microcomputer, and if the model is too large to solve on a microcomputer, the matrix can be generated on a mainframe. It is similar in concept to the idea of "views" in database theory (see Date [8] chapter 9).

One of the questions with a system like L P F O R M is who is the appropriate user of the system. The often stated goal with decision support systems is to be accessible to the novice user. The target user for L P F O R M is primarily someone knowledgeable about LP, at least through the first successful formulation. The expert's problem is one of building a model efficiently. The novice's problem is deciding what should be modeled. At this point the system provides only limited help in selecting the appropriate representation for the situation to be modeled. Thus, the user needs to know something about linear programming to come up with the initial formulation. Using the call model capability, however, a novice should be able to operate and modify a model already available in the knowledgebase.

Often, systems that contain user aids such as a graphics interface or a model base restrict the freedom of the user. In the case of linear programming the bulk of a model will typically follow a standard pattern with some nonstandard rows or columns added. Thus, a system has to allow complete freedom in model specification. LPFORM does this by allowing the model builder to add directly any row or column to the algebraic statement of the model. Also, any subsequent

Pai-chun Ma et al. / Representing knowledge about L P formulation 171

revisions to a model can be done by returning to the appropriate graphics screen, making the changes and then regenerating the model.

The system is still under development. Currently, the graphics interface works and produces a set of statements that can be read into the model formulator that generates the algebra and maintains a prototype of the knowledgebase. These two pieces are in the process of being physically connected. The system that generates the matrix from the algebra is currently operating on a mainframe computer.

References

[1] Ajay Asthana, LPGRAPH: an expert assistant for graphically formulating linear programs, Ph.D.Th., New York University, 1988. Ph.D. Dissertation.

[2] M. Binbasioglu, Knowledge based modelling support for linear programming, Ph.D.Th., New York University, 1986.

[3] Gordon H. Bradley and Robert D. Clemence, Jr., A type calculus for executable modeling languages, IMA Journal of Mathematics in Management 1 (1987) 277-291.

[4] Gordon H. Bradley and Robert D. Clemence, Jr., Model integration with a typed executable modeling languages, 21st HICSS, Hawaii, 1988.

[5] R.L. Breitman and J.M. Lucas, PLANETS: a modeling system for business planning, Inter- faces 17, 1 (Jan-Feb 1987).

[6] J.B. Creegan, Jr., Dataform: a model management system, Ketron, Inc., Arlington, Virginia, November, 1985.

[7] George B. Dantzig, Linear Programming and Extensions (Princeton University Press, Prince- ton, N.J., 1963).

[8] C.J. Date, An Introduction to Database Systems, 3rd ed. (Addison-Wesley, Reading, Mass., 1981).

[9] Daniel R. Dolk, A generalized model management system for mathematical programming, ACM Transactions on Mathematical Software 12, 2 (June 1986).

[10] Eva System Manual (Expert Vision Associates, Cupertino, CA, 1987). [11] R. Fourer, Modeling languages versus matrix generators for linear programming, ACM

Transactions on Mathematical Software 8, 2 (June 1983). [12] R. Fourer, D.M. Gay and B.W. Kernighan, AMPL: A Mathematical Programming Language

(AT&T Bell Laboratories, Murray Hill, N.J., 1987). [13] Saul I. Gass, Decision-aiding models: validation, assessment, and related issues for policy

analysis, Operations Research 31, 6 (Nov/Dec 1983) 603-631. [14] A.M. Geoffrion, An introduction to structured modeling. Management Science 33, 5 (May

1987) 547-588. [15] Harvey J. Greenberg, A functional description of ANALYZE: a computer-assisted analysis

system for linear programming models, ACM Transactions on Mathematical Software 9, 1 (March 1983) 18-56.

[16] H.J. Greenberg, A natural language discourse model to explain linear programming models and solutions, Decision Support Systems 3 (1987) 333-342.

[17] 1BM Mathematical Programming Language Extended~370 (MPSX/370), Program Reference Manual, SH19-1095 (IBM Corporation, Pads, France, 1975).

[18] D.A. Kendrick and A. Meeraus, GAMS: An Introduction (Scientific Press, Palo Alto, CA., 1988).

[19] Ramayya Krishnan, PM: a logic modeling language for production, distribution, and inventory planning, Proc. Hawaii Infl Conf on System Sciences, Kona, Hawaii, January, 1988, pp. 452-460.


[20] C. Lucas, G. Mitra and K. Darby-Dowman, Computer assisted mathematical programming (modeling system: CAMPS), Computer Journal (1988) to appear.

[21] P. Ma, F.H. Murphy and E A. Stohr, Design of a graphics interface for linear programming, Working Paper No. 136, Center for Research in Information Systems, Graduate School of Business Administration, New York University, New York, 1986.

[22] Pai-chun Ma, An intelligent approach towards formulating linear programs, Ph.D. Th., New York University, 1988.

[23] M. Minsky, A framework for representing knowledge, in: The Psychology of Computer Vision, ed. P. Winston (McGraw-Hill, New York, 1975) pp. 211-277.

[24] F.H. Murphy and E.A. Stohr, An intelligent system for formulating linear programs, Decision Support Systems 2, 1 (Jan-Feb 1986).

[25] F.H. Murphy, E.A. Stohr and P. Ma, Composition rules for building linear programming models from component models, Working Paper, New York University, New York, 1987.

[26] F.H. Murphy, J. Conti, R. Sanders and S. Shaw, Modeling and forecasting energy markets with intermediate future forecasting system, Operations Research, 36, 2 (May-June, 1988).

[27] OMNI Linear Programming System: User Manual and Operating Manual (Haverly Systems Inc., Denville, N.J., 1977).

[28] Linus Schrage, Linear, lnteger, and Quadratic Programming with LINDO (The Scientific Press, Palo Alto, 1987).

[29] E.A. Stohr, A mathematical programming generator system in APL, Working Paper 96, New York University, New York, 1985.

[30] James S. Welch, Jr., PAM - a practitioner's approach to modeling, Management Science 33, 5 (May 1987) 610-625.

[31] P.H. Winston, Artificial Intelligence, 2nd ed. (Addison-Wesley, Reading, Mass., 1984).

Documents

Representing knowledge about linear programming formulation