Decision Support Systems 64 (2014) 43–56
Contents lists available at ScienceDirect
Decision Support Systems journal homepage: www.elsevier.com/locate/dss
An expanded database structure for a class of multi-period, stochastic mathematical programming models for process industries Narain Gupta a,⁎, Goutam Dutta b, Robert Fourer c a b c
Management Development Institute, Mehrauli Road, Sukhrali, Gurgaon 122007, India Indian Institute of Management, Ahmedabad 380015, India AMPL Optimization, USA
a r t i c l e
i n f o
Article history: Received 28 May 2013 Received in revised form 9 March 2014 Accepted 18 April 2014 Available online 30 April 2014 Keywords: Decision support system Process industries Optimization Stochastic programming (SLP) Database structure Management science
a b s t r a c t We introduce a multiple scenario, multiple period, optimization-based decision support system (DSS) for strategic planning in a process industry. The DSS is based on a two stage stochastic linear program (SLP) with recourse for strategic planning. The model can be used with little or no knowledge of Management Sciences. The model maximizes the expected contribution (to profit), subject to constraints of material balance, facility capacity, facility input, facility output, inventory balance constraints, and additional constraints for non-anticipativity. We describe the database structure for a SLP based DSS in contrast to the deterministic linear programming (LP) based DSS. In the second part of this paper, we compare a completely relational database structure with a hierarchical one using multiple criteria. We demonstrate that by using completely relational databases, the efficiency of model generation can be improved by 60% compared to hierarchical databases. © 2014 Elsevier B.V. All rights reserved.
1. Introduction and motivation We introduce a user friendly, model data independent, model solver independent, stochastic optimization based DSS for strategic planning in a process industry. This research is an extension of an earlier work by Dutta [12], and Dutta & Fourer [14,24] where a multi-period optimization based DSS was developed for process industries. Fourer [24], in his seminal work, showed that the fundamental principles of relational database construction could be used to represent a linear program. This work was carried out for a single period deterministic optimization. Dutta [12] and Dutta & Fourer [13,14] extended the research of single period planning to multiple period planning. These applications ranged from a steel company in India [17,19], a steel company in North America [12,13], to a pharmaceutical company in Western India [15] and even further to an aluminum company [16] in Eastern India. The DSS customized for the integrated steel plant in North-America, demonstrated a potential impact of 16–17% increase in the bottom line of the company [13]. In the first part of the paper, we discuss the design and development of a multiple period, multiple scenario DSS. While several researchers [4,22,27,28] have done work in the application of stochastic optimization and a set of researchers [11,18,20] has worked on the need for user friendly DSS, this is probably the first attempt that tries to integrate ⁎ Corresponding author. Tel.: +91 124 4560000, +91 9818037324. E-mail addresses:
[email protected] (N. Gupta),
[email protected] (G. Dutta),
[email protected] (R. Fourer).
http://dx.doi.org/10.1016/j.dss.2014.04.003 0167-9236/© 2014 Elsevier B.V. All rights reserved.
these two concepts. Here, we attempt to address the following seven questions in detail: 1. How is the database structure of a SLP model different from a deterministic LP model? 2. How are the diagnostic rules in the database structure of a multiscenario DSS and model different from a multi-period deterministic model? 3. What are the key features of a multi-period, multi-scenario optimization based DSS? 4. How are multi-dimensional data values reported, with scenarios as an additional dimension? 5. In what way can the optimal results be represented in a multi-period, multi-scenario optimization based DSS? In the second part of this paper, we compare the performance of hierarchical and relational structures on a deterministic DSS. A single period optimization based DSS by Fourer [24] and a multiple period optimization based DSS by Dutta and Fourer [12,14] compare hierarchical and relational databases. In this paper, we develop a DSS with a completely relational structure and compare the performance with Dutta & Fourer's [14] partially relational database structure. We ask two additional questions that were not addressed in the earlier research. 6. What is the performance of the relational database structure compared to the hierarchical database structure in a multi-period planning model?
44
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
7. What are the issues related to database structure design for linear programming when we have a choice of different variations of relational and hierarchical databases? This research is further extended to design and develop a completely relational database structure for a generic, multi-period, multi-scenario, optimization-based DSS. We study the reasoning behind the increased difficulty in the design and implementation of the DSS and discuss how to expand the DSS, to include multiple scenarios. 1.1. Outline of the paper The paper introduces database structure and SLP in Section 1. In Section 2, we review the literature on database optimization interface, SLP, and its application in industries. In Section 3, we address how the database structure of an SLP model is different compared to the deterministic model (question 1 of Section 1). Section 4 addresses the question of how the diagnostic rules of multi-period multi-scenario DSS are different from the rules of a multi-period single scenario DSS. We also address the question about the additional rules implemented in the DSS (question 2 of Section 1). This section also describes the key steps of optimization, and the important features of the DSS, followed by issues related to data storage, retrieval, loading, and update (questions 3 and 5 of Section 1). In Section 5, we address the basic features of the DSS with respect to data reporting, updating, and creating multi-dimensional included layouts (question 4 of Section 1). In Section 6 of the paper, we address the sixth and seventh questions about how a completely relational database structure performs compared to a partially relational and partially hierarchical one. We conclude the paper in Section 7 with the future scope of the research, and the list of references. The Appendix A describes the mathematical formulation of the SLP. 2. Literature review An LP can be represented in several ways depending on the need of the user and the system. Earlier work [11,25] summarizes the common methods of LP representation schemes in practice. The LP representation is approached in the literature as Structured Modeling [1–3], Graph-Grammar [5–7], Netform [10], and Block Schematic Diagram [20]. The matrix generator (MG) form of an LP representation, which is a translation form, has been attempted by several authors. For instance, DATAFORM (Ketron Inc., 1975), and UIMP [18] are common matrix generators. Research on mathematical optimization [25] recognizes that it is difficult to develop an LP representation form which can be commonly understood by modelers, computers, and practitioners. To manage the sales, considering production, sales, and foreign exchange, a modeling environment has been proposed by Combos et al. [8] in their paper. This modeling environment was based on data warehousing and knowledge discovery in databases. Rudberg & Thulin [21] described how the Advance Planning System (APS) can act as an enabler in the adaptation of logistics and supply chain principles. The APS described by them is a decision support system for supply chain planners. They used case study findings to present the power of decision support. Recent research [23] uses a simulation modeling approach in sales and operations planning for decision support. Valente [28] presented a simulation and optimization based decision support system to address uncertainty in the model parameters. They addressed the different complexities involved in modeling uncertainty. Most of the existing studies talk about supply chain planning and decision making, using decision support tools. A comparative study [11] of LP representation schemes such as MG, algebraic languages, and block-schematic languages, reports that very few LP representation schemes have been implemented in commercial software systems. Other approaches are still at the prototype stage of development. A study on relational databases [24] in the context of an
LP formulation visualizes the subset of the Cartesian product of sets of the LP as a relation in the mathematical sense. From the database viewpoint, the structure of an LP can be represented by two sets of entities, variables and constraints, along with a many-to-many relationship that records which variables are associated with which constraint. To represent non-linear models, stochastic models, and other types of models, the model schema can be expanded. The tables for the coefficients store only the non-zero elements in the array representation. Thus, the representation conforms closely to the MPS format used for input by most of the optimizers. Fourer [24] emphasizes how the development of a database structure with a direct relation to the variables and the constraints of a large scale mathematical programming can lead to a user friendly DSS. Fourer [24] describes the algebraic formulation of a single period deterministic model and the corresponding database structure. Further extensions by Dutta and Fourer [12–15] present a multi period deterministic model and a hierarchical database structure, and compare it to a partially relational database structure. In this research, we compare and contrast the design and performance of a completely relational data structure and a partially relational and partially hierarchical data structure of a multi period deterministic planning model. This research also emphasizes how the uncertainty in the parameters can be captured in a multi scenario planning model. We design and develop a completely relational database structure for the multi scenario planning model and discuss the increase in design and computational complexity which has been caused due to the inclusion of uncertainty in the parameters. In this research, we also address uncertainty in the model parameters, and extend the multi-period optimization model [12] to develop and implement a two stage SLP in a DSS. The study, being generic, is capable of modeling uncertainty in any parameter in the optimization model. The size of the optimization model increases significantly with the increase in the number of uncertain parameters in the model. The efficiency of optimization model generation and the performance of the database structure primarily depend on the size of the model. Considering this, we realize the need to study a completely relational database structure in the context of an SLP. A review of literature also reveals that not much work has been published on relational databases for an SLP which can demonstrate the implementation of a user-friendly DSS. The research primarily focuses on the design and development of a completely relational database structure in the context of a class of multiple scenario mathematical optimization models, and compares it to the performance of a hierarchical database structure. 2.1. Two-stage stochastic linear program (SLP) with recourse The two stages of the stochastic program are defined by a set of decisions made in those stages. The decisions made in the first stage are the decisions which are implemented before the realization of the randomness in the system. The second stage decisions are the ones which are implemented after the realization of the randomness. The decisions made in the first stage are non-anticipative in nature, and do not depend on the outcome of the randomness. The focus of the SLP is to rectify the decision taken for the first stage, well in advance, such that the solution remains the same regardless of the outcome of the random realization. To simplify the understanding of the two-stage SLP with recourse, we discuss an example, which is the first SLP with recourse, formulated by Ferguson & Dantzig [4]. The term recourse is defined by Fragniere [9] as the decision variables adapting to the different outcomes of the random parameters at each time period. In a stochastic program with recourse, the response of the randomness of the model is corrected as a part of the model. We introduce SLP using the deterministic equivalent linear program developed by Ferguson & Dantzig [4]. It is a generalized two-stage program: c1 c2
The cost vector of the first stage The cost vector of the second stage
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
X1 The first stage decision vector The second stage decision vector X2 X1 and X2 are nonnegative decision vectors for all scenarios Second Stage Decision variable in different scenarios, for X(i)2 i = 1,2,3 The likelihood probability of the occurrence of scenario 1 p1 The likelihood probability of the occurrence of scenario 2 p2 The likelihood probability of the occurrence of scenario 3 p3 A The matrix representing technological coefficients (assumed to be deterministic) The random vector that varies in different scenarios, for b(i)2 i = 1,2,3
Minimize Expected Contribution ð 1Þ ð 2Þ ð3Þ Z ¼ c1 X1 þ p1 c2 X 2 þ p2 c2 X 2 þ p3 c2 X : 2
ð2:1Þ
Subject to A11 X1 ¼ b1
ð2:2Þ
ð1Þ
A21 X1 þ A22 X
ð2Þ
A21 X1 þ A22 X
ð3Þ
A21 X1 þ A22 X
2¼
ð1Þ
b
2
ð2Þ
2¼
b
2¼
b
ð3Þ
ð2:3Þ
2
ð2:4Þ
2:
ð2:5Þ
A stochastic program with three scenarios is presented above. The superscript of the second stage decision vector denotes the decisions in each of the scenarios. 3. Database design issues for scenario based SLP models In this section, we address the first question of Section 1 by describing the difference between the database structure of an SLP model and the deterministic LP model where we answer the first question in Section 1. The SLP model has six fundamental elements. Five of the six elements, namely, Materials, Facilities, Activities, Storages, and Times have been described in detail in earlier research by Dutta [12], and Dutta & Fourer [14]. The new element Scenarios is described to represent uncertainty. 3.1. The relational structure of the data model in SLP This database structure mainly contains two sub-databases. The files of the first sub-database are defined as Data Files. The files of the second sub-database are defined as Model Files. 3.1.1. The Data Files The key Data Files are [Times], [Scenarios], [Materials], [Facilities], [Activities], and [Storages] (see Fig. 1). These files can be distinctly identified in the figure, as their file name is written in white font with a black background. These files contain all such data and model parameters which do not vary over different time horizons and over different scenarios. These files are also named as non-time and non-scenario dependent files. Each of these data files enlists the materials, facilities, activities operating on facilities, storage areas, time horizons, and scenarios under consideration, respectively. Six fundamental sets are defined corresponding to these six data files. All the time and scenario dependent Data Files (other than the files stated above) maintain a composite primary key named UID (Unique Identification), which is
45
made up of a combination of primary keys of corresponding linked non-time and non-scenario dependent data files. Each of these nontime and non-scenario dependent files maintains a primary key to uniquely identify the items in the lists. These files are indexed over pairs, triples, and quadruples of the six sets. 3.1.1.1. Times. The Data File [Times] enlists all the planning horizons. This file is indexed over the set, times (T). This file also contains the data which varies only with reference to time and not with change of material, facilities, activities, or scenarios. The [Times] file is linked with the time and scenario dependent files namely [MatTimeScene], [FacTimeScene], [Input], [Output], [ActTimeScene], [ActInput], [ActOutput], [StoreTimeScene], and [StoreMatList] in a one-to-many relationship. The data file relationship type ONE is indicated on the key data files, while the other files have a MANY type relationship with the key files. 3.1.1.2. Scenarios. The Data File [Scenarios] enlists all the potential scenarios representing the states of nature. This file is indexed over the set scenarios (L), and contains the probability of occurrence of each scenario. This file is also linked in a one-to-many relationship with all the time and scenario dependent files as the [Times] file described above. 3.1.1.3. Materials. The Data File [Materials] enlists all the raw materials, work in progress, and finished goods in the scope of the model. This file also stores the data related to the initial inventory of each of the materials. It is indexed over the set materials (M), and linked to [MatTimeScene] in a one-to-many relationship. The [MatTimeScene] data file contains the data related to the upper bound, lower bound, sell price, purchase price, and carrying cost for materials in different time horizons and scenarios. This file also receives the optimal product mix from the optimizer (See Fig. 2). We discuss the [MatTimeScene] Data File in detail as an illustration. The other Data Files of the model share similar characteristics as the [MatTimeScene] file. For example, the units of a raw material bought, sold, or inventoried are dependent on time periods and an occurrence of scenarios. Alternatively, units of activities operated on a facility, units of materials used as an input in an activity, or units of materials produced as an output from an activity vary over time periods and scenarios. The composite primary key of the Data File [MatTimeScene] is made up of a combination of three fields namely MatID, SceneID, and TimeID. The ID fields are primary keys of [Materials], [Scenarios], and [Times] files. The fields BuyMin, BuyMax, BuyPrice, SellMin, SellMax, SellPrice, InvMin, InvMax, and InvCCost may vary over time periods and scenarios (See Table 1). The optimal values of decision variables are reported in the time and scenario dependent fields BuyOPT, SellOPT, and InvOPT. 3.1.1.4. Facilities. The Data File [Facilities] enlists all the facilities where all the activities operate and transform the raw materials into work-inprocess or finished goods (See Fig. 3). This file is indexed over the set facilities (F), and linked with [Input], [Output], and [FacTimeScene] files in a one-to-many relationship. The [Input] and [Output] files contain the data related to the upper bound and lower bound of the materials that may flow through different facilities in different time horizons and over all the scenarios. These files also receive the optimal unit of each material that should be used as an input at each facility, and the optimal unit of each material that should be produced as an output at each facility across time horizons and scenarios. The file [FacTimeScene] contains the data related to the upper bound and lower bound on the capacity that should be operated at each facility. This file receives the facility capacity which would be used in the optimal solution.
46
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
Fig. 1. Relational database structure of SLP model for strategic production planning.
3.1.1.5. Activities. The Data File [Activities] lists all the activities across all the facilities (See Fig. 4). This file is linked to the [ActInput], [ActOutput], and [ActTimeScene] files in a one-to-many relationship. This file is indexed over the set activities (A). The [ActInput] file contains the data related to the rate at which each material will be used as an input at each activity. The [ActOutput] file contains the ratio in which each material can be produced at each activity in different time horizons and over all the scenarios. The file [ActTimeScene] contains the data related to the upper bound and lower bound on the unit of activities that can be operated at each facility, the cost of operating each unit of activity at each facility, and the unit of capacity that will be used by one unit of activity at each facility. This file also receives the optimal units of each activity that should be operated at each facility in the optimal solution.
Table 1 One to one correspondence of [materials] table's fields and the parameters and variables of the optimization model. Param./var.
Fig. 2. Materials related files.
vinv jl0 ubuy jlt buy cjlt sell ljlt usell jlt csell jlt
Fields of the tables
Param./var.
Fields of the tables
[Materials]MatInvZero [MatTimeScene]BuyMax [MatTimeScene]BuyPrice [MatTimeScene]SellMin [MatTimeScene]SellMax [MatTimeScene]SellPrice
linv jlt uinv jlt cinv jlt buy xjlt xsell jlt xinv jlt
[MatTimeScene]InvMin [MatTimeScene]InvMax [MatTimeScene]InvCCOST [MatTimeScene]BuyOPT [MatTimeScene]SellOPT [MatTimeScene]InvOPT
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
47
Fig. 3. Facilities related files.
3.1.1.6. Storage areas. The Data File [Storages] enlists all the storage areas. This file is indexed over the set storages (S), and linked with [StoreTimeScene] and [StoreMatList] in a one-to-many relationship. The [StoreTimeScene] file contains the upper and lower bounds on the total storage capacity of each storage area. The file [StoreMatList] contains the upper bound and lower bound on the capacities of each material that can be stored in the storage areas across different time horizons and scenarios. This file also receives the optimal units of each material that are stored in each storage area in the optimal solution. 3.1.2. Model files As stated above, Model Files is an alternative database form of an LP representation (See Fig. 5). This contains three files namely [Variables], [Constraints], and [Coefficients]. The variables file contains the model parameters — upper bound, lower bound, and the objective function coefficient of each decision variable. This file also receives the optimal product mix and the reduced costs associated with the decision variables. The file [Constraints] lists the constraints and the parameters associated with each constraint namely the right hand side of each
constraint. This is the file which receives the dual values associated with each constraint. The [coefficients] maintains all the pairs of constraints and variables whose technological coefficient is non-zero. 3.1.3. Relational nature of the database and an alternative LP representation The database structure of the DSS is an alternative representation of the SLP. The parameters and decision variables of the SLP model have a one-to-one correspondence with the fields of the tables of the database. As an illustration, we tabulate the decision variables, and parameters of the set Materials (See Table 1). The model parameters — upper bound and lower bound on the number of units allowed to be purchased, BuyMin and BuyMax, have a one-to-one correspondence with the [MatTimeScene]BuyMin and [MatTimeScene]BuyMax fields of the [MatTimeScene] file. Similarly, the decision variable such as the optimal unit of purchase of materials corresponds to the [MatTimeScene] BuyOpt field of the [MatTimeScene] file. A similar one-to-one correspondence exists between the remaining model parameters and the decision variables with the fields of the database files as shown in Table 1.
Fig. 4. Activities related files.
48
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
Fig. 5. Model files.
4. Optimization
generic diagnostic rules, in addition to the rules presented in an earlier publication [14], are as follows.
Interested readers are encouraged to refer to the publications by Dutta and Fourer [14,24]. We describe the steps of optimization (See Fig. 6) as follows: 1. The data describing the fundamental elements of the SLP are collected from the field and entered into the DSS. 2. The constraints of the SLP optimization model are generated in [Constraints]. The data required for the generation of constraints like RHS values are extracted from the Data Files. 3. All the data required for the [Variables] file are extracted from the appropriate Data Files. 4. Once the [Variables] and the [Constraints] file are loaded, a matrix representation of the SLP is generated in the file PROBLEM.TXT. 5. The PROBLEM.TXT is given as an input to the CPLEX optimization. The optimizer returns the optimal solution in a file SOLUTION.TXT. 6. The SOLUTION.TXT is read by a Report Writer (RW). The RW leaves the optimal solution in the Model Files, and also in the appropriate fields of the Data Files. The optimal solution can be displayed using the optimal solution screens, or exported to spreadsheets etc. 4.1. Diagnostic rules A set of diagnostic rules was established and implemented in the database to ensure that the SLP would be complete and free from errors. These rules avoid multiple potential infeasibilities in the SLP solution, caused due to erroneous data entry. The rules also ensure the correctness of the SLP decisions. Most of the diagnostics are performed immediately before the data is saved in the database. A few of the
Fig. 6. Steps of optimization.
Rule 1: The probability attached to each scenario in an SLP should be non-negative and less than or equal to one. Rule 2: The sum of probabilities associated with all the scenarios in an SLP should be exactly equal to one. Rule 3: The number of records in a time and scenario dependent file should be less than or equal to the Cartesian product of the number of records in the [Times], [Scenarios], and other files which are linked in a one-to-many relationship. Rule 4: The number of records in the [MatTimeScene] file should be less than or equal to the Cartesian product of the number of records in the [Materials], [Times] and [Scenarios] files. Rule 5: The number of records in the [FacTimeScene] file should be less than or equal to the Cartesian product of the number of records in the [Facilities], [Times], and [Scenarios] files. Similar diagnostic rules are implemented for the [Input], and [Output] files. Rule 6: The number of records in the [Activities] file should be less than or equal to the Cartesian product of the number of records in the [Activities], [Times], and [Scenarios] files. Similar diagnostic rules are implemented in the [ActInput], and [ActOutput] files. Rule 7: The number of records in the [StoreMatList] file should be less than or equal to the Cartesian product of the number of records in the [Storages], [Times], and [Scenarios] files. Similar diagnostic rules are implemented in the [Storage Areas] file. Rule 8: The number of records in the [Coefficients] file should be less than or equal to the Cartesian product of the number of records in the [Variables], and [Constraints] files. The reasoning behind implementing this rule is that the number of non-zero technological coefficients in a linear program can be less than or equal to the product of the number of variables and number of constraints. Rule 9: The optimal decisions resulting from the optimizer for the first stage of the SLP (i.e. first time period) should be implementable and therefore identical for all scenarios. These constraints are known as non-anticipativity or implementability constraints in the SLP. We define the non-anticipativity constraints in brief for readers who are not familiar with stochastic programming. Sen [27] argues that most stochastic programming models assume that the uncertainty involved in the model is exogenous. The decisions made at any stage would not depend on future outcomes of random parameters or on future decisions. Essentially the phenomenon is called non-anticipativity. Non-anticipativity means the future is uncertain and cannot be known before realization of the random data. According to Sen and Higle [26], stochastic programming assumes that the distribution of the random parameters is known and independent of the decision vector. Also, the
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
parameters are independent of each other. Therefore, some constraints are incorporated in the stochastic program to ensure that the scenarios sharing a common history have identical decisions. In stochastic programming literature, these constraints are known as non-anticipativity or implementability constraints. In the mathematical sense, the requirement of implementability requires that the decisions of all the scenarios of t = 1 (first stage) are identical. One of the ways to ensure the implementability of the first stage decisions is to create only one decision variable for t = 1 which represents the decision for all the scenarios of t = 1. Alternatively, one may create one decision variable corresponding to each scenario for t = 1, and create constraints to ensure that the decisions of all the scenarios for t = 1 are equal. To maintain the compactness and readability of the mathematical program on paper, we followed the latter solution to ensure the implementability of the first stage decision. It would be advisable for the developers of the matrix generator for the SLP based DSS not to create a copy of the decision variable for each scenario in t = 1, while using only one decision variable. This method can save a significant component of the model generation time from not creating the copy of the decision variables, the implementability constraints, and constraints corresponding to scenarios l = 2, 3…so on, and t = 1. We write the decision variables against each scenario for t = 1 and the implementability constraints for the sake of better explanation and compactness of the mathematical program, but we do generate the decision variables only for the first scenario for t = 1, and similarly the required constraints. This results in a significant amount of saving in time to generate the model.
5. Features of the multi-period, multi-scenario DSS in the SLP This section attempts to address the second question raised in the Introduction and motivation section of the paper. Data retrieval and storage procedures are critical features of this DSS. The core tasks performed by the DSS are generation of variables, constraints, and coefficients files, and thereby the text-file in MPS format, and reporting the optimal solution generated by the optimizer back to the database. The DSS is operated in three different modes — Data, Update, and Optimal. The Data mode is used to enter and load the data. The Update mode is used to update the parameter values directly to the data files and model files as described in Section 3. In the Optimal mode, a user can see the optimal solution and optimal summary of the cash flows. We report cash flows as nominal and discounted cash flows. The issues related to data reporting, data loading, and data updates can be referred to in the authors' previous publication [12,14]. The difficulty in the design, development, and use of the database structure and thereby the impact on the computational performance of the optimization model is addressed using a completely relational database design.
5.1. Input data reporting In the Data Mode, if any file is opened, a data input screen is displayed. The data defining optimization model instance and data are entered in the Data mode. The database has a systematic sequence of entering the data. The user needs to first enter the data into the files corresponding to six fundamental sets. An instance of the data in the six files creates the model structure. Once the model structure instance is developed, users do not need to interact with these six fundamental files any further. The auto-load feature of the DSS ensures that the data defining the model structure is automatically visible in the input screens of the time and scenario dependent files and included layouts. This eliminates the potential occurrence of inconsistencies of the data in the database tables due to multiple times, or erroneous data entry.
49
5.2. Data loading The optimization data can be loaded in the DSS by multiple means. The DSS allows the importing of all the data files one by one using separate procedures. We also facilitated this DSS to import all the files simultaneously in a single procedure.
5.3. Update issues In a multi-period optimization model, the time required to generate a model instance (variables, constraints, and coefficients files) is significantly higher compared to the solution time of an optimizer. This DSS provides a unique facility of updating the parameters directly to the data files, and the model instance in Update mode. A change in the SLP model parameters is automatically updated and reflected in the Data Files as well as Model Files directly. Due to the direct update, the time required to re-generate these files is saved, which in turn reduces the total optimization time and improves the processing speed of the DSS. The update of model parameters in the Data Files and Model Files becomes increasingly difficult in this DSS. The difficulty arises due to the addition of the scenario indexing. For example, the [ActOutput] file was indexed over four sets – materials, facilities, activities, times – in Dutta & Fourer [14]. The file is now indexed with five sets. To update a parameter [ActOutput]ActOutRate, the addition of a fifth set scenarios increases the number of searches required by the number of scenarios.
5.4. Time-scenario dependent included layout This section attempts to address how optimal results can be presented in a multi-period, multi-scenario DSS (question five of Section 1). The display and reporting of the model parameters are not straight in generic multi-periods, multi-materials, multi-facilities, multi-activities, multi-storages, and multiple scenario optimization models. In an included layout, the layout of one file can be included in another file. For instance, a facility's main layout corresponding to [Facilities] displays the time and scenario dependent material–facility input and output layouts corresponding to [Inputs], and [Outputs] respectively (See Fig. 7). The DSS is featured with included layouts for all sets — Materials, Facilities, Activities, and Storages. An included layout enables the selection and analysis of individual records separately. Every layout facilitates the sorting of records according to the indexed fields of the files. 5.5. Reporting optimal summaries Reporting optimal solutions, cash flows, and optimal summaries of cost components is a complex task in a multi-scenario optimization. The complexity arises due to the multi-dimensionality of the data such as a series of cost components, corresponding to each time period, and each scenario. The DSS is facilitated to view cash flow summaries with four options including the grand summary, time-scenario summary, time wise summary, and scenario wise summary. The grand summary readily provides the solution to the SLP (See Fig. 8). Fig. 8 Grand summary of cash flow. Using scenario wise summaries, one can determine the perfect information (PI) solution. The expected value of perfect information (EVPI) can be determined as a difference of the PI solution and the SLP solution. The DSS also helps to determine the value of the stochastic solution (VSS). The VSS can be determined as a difference between the SLP solution and the expected value of the expected value solution (EVV). The EVV is the optimal solution of the SLP where the first stage decision vector of the SLP is fixed as the optimal solution of the ‘mean value LP problem’. The ‘mean value LP problem’ is the single scenario, multiple period planning model in this research.
50
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
Fig. 7. Time scenario included layout of facilities file.
5.6. Reporting the optimal solution The optimal solution is reported to the users in the Optimal Mode. A separate screen along with the layout of input parameters is provided to show the optimal values and the reduced cost of the decision variables, and the dual values of the constraints (See Fig. 9). A post optimality analysis can also be performed in the Optimal Mode for critical parameters. We report two forms of cash flows, namely nominal (Eq. (1)) and discounted cash flows. If the DSS is used for long term strategic planning, it is essential that one uses an objective function (Eq. (2)) which is discounted over the planning period with the interest rate and takes the time value of money into consideration. 6. Comparison of hierarchical and relational data models This section describes how a hierarchical database structure behaves in the context of optimization (Questions 6 and 7 of the first section). A hybrid database of hierarchical and relational database structures named PROCESS1 [13] (See Fig. 10), and a completely relational database structure designed in this study for multi-period, multi-scenario
Fig. 8. Time scenario optimal layout of [materials].
optimization and named PROCESS2 are compared (See Fig. 11). Since PROCESS1 is a multi-period single scenario hierarchical database, we use a multi-period, single scenario version of the PROCESS2 relational database. The two variations are compared on several criteria in the following sections. 6.1. Ease of use (data search, sort, and update) Searching of data values is easier in PROCESS2 than in PROCESS1. In PROCESS1 most of the searches take place at the sub-file level. For instance, in PROCESS2, the decision variable InvOpt is generated using the [MatTimeScene] file. The current record of the [MatTimeScene] file contains the data for the inventory upper bound. If InvMax is zero, the variable will not be generated. If InvMax is non-zero, the required bounds and the objective function coefficient can be retrieved from the current record of the [MatTimeScene] file. However, in PROCESS1, the data InvMax lies in the sub-file corresponding to the current record of the Model File [Materials]. The retrieval of the data from the sub-file requires additional time to search and generate the variable. Similar difficulties arise while generating other decision variables including SellOpt, ButOpt, ActOpt etc. Sorting is an essential operation in model generation and for display layouts. To understand the difficulty in sorting, we need to understand the concept of indexing of fields. Indexing drastically improves the ability to search and find records. Indexing is nothing more than an additional copy of the data, sorted and attached to each unique entry for the field assigned indexed. It is possible to create more than one index on the table thereby providing additional rapid search and sort capabilities. In PROCESS2, a required parameter is stored at the file level. While searching for a parameter in a file of PROCESS2, a sorting operation would be performed. This sorting operation requires the indexing and creation of a copy of the file. In PROCESS2 one additional copy of a file will be created. In PROCESS1, a required parameter is stored at a subfile level. Searching a parameter requires a sorting operation at both the file level and at the corresponding sub-file level. This requires sorting of the first level file and sub-files. This results in the creation of a copy of several files. Sorting operations require the comparison of a
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
51
Fig. 9. Grand summary of cash flow.
large number of records. The required numbers of comparisons are significantly larger in PROCESS1 compared to PROCESS2. The creation of a copy of a file and sub-files in PROCESS1 also requires more memory in comparison to PROCESS2.
6.2. Data storage space Building a composite primary key which is the unique identification number (UID) requires repeat groups of foreign keys of the [Materials],
Fig. 10. PROCESS1 — partially hierarchical and partially relational database structure.
52
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
Fig. 11. PROCESS2 — completely relational database structure.
[Facilities], [Activities], [Storages], [Scenarios] and [Times] files. This results in an increased requirement of disk space in PROCESS2. The requirement for disk space further increases, due to the indexing of each data file of the database over the foreign key of [Scenarios] file i.e. SceneID. At the same time we assert that the ease of use of the linked data is not compromised, as the data once entered is directly available in other input layouts. 6.3. Ease of development It is observed that the development of the DSS based on PROCESS2 provides greater ease of development than PROCESS1. We describe
two different cases where PROCESS2 facilitates ease of development over PROCESS1.
6.3.1. Examination and display of time dependent data In the user and application environment of the DSS, the records of the tables are displayed for data update and examination. In PROCESS1, searching, sorting, deleting, and updating operations cannot be directly performed on the data that lie in the sub-files without accessing the corresponding main file. In PROCESS2, the time dependent data lies in the first level files. In this case all the time dependent data can be displayed and examined simultaneously. For instance, the SellMax, or
Table 2 PROCESS2 over PROCESS1 (model generation time). Model
No. of coefficients
Hierarchical model: PROCESS1 (seconds)
Relational model: PROCESS2 (seconds)
Reduction (seconds)
S1 (steel 1) S2 (steel 2) S3 (steel 3) S4 (steel 4) S5 (steel 5) S6 (steel 6) S7 (steel 7) S8 (steel 8) S9 (steel 9) S10 (steel 10) S11 (steel 11)
1110 2214 3268 4440 5577 6763 7893 8755 9405 10,557 11,810
5 9 13 18 23 29 34 36 40 47 55
2 3 4 9 10 10 12 13 16 17 19
3 6 9 9 13 19 22 23 24 30 36
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
53
SellPrice of all the materials for all time periods, and all scenarios can be examined by displaying the records of the [MatTimeScene] file. 6.3.2. Deletion of records In PROCESS2, a single query can delete the records containing time and scenario dependent data. This is so because such records are a part of the first level files. In PROCESS1, the time dependent data is stored in the sub-files of the main files. To delete a sub-record, one needs to scan the records of the main file, and locate the data of the sub-file. 6.4. Efficiency of optimization model generation This section demonstrates the performance of a relational database structure compared to a hierarchical database structure. We observe a significant efficiency of optimization model generation using PROCESS2 over PROCESS1. We compare the performance of the two processes in terms of the time to generate the optimization model on identical operating systems (Windows OS). We run optimization models using a P-3 processor with 2.44 MHz frequency and 512 MB RAM Computer. The sum of the three components' time to generate the constraints file (CGT), variables file (VGT) and writing the matrix file (MWT) is called the model generation time (MGT). This comparison signifies the efficiency of optimization model generation solely due to the relational nature of database structures compared to hierarchical ones. To strengthen our argument of better optimization model generation efficiency of PROCESS2 over PROCESS1, we generate 30 model variants of four process industries (Steel, Aluminum, Pharmaceutical, and Polymer). In Table 2 we present the comparison of only the steel company model instances with an increasing number of non-zero coefficients. In Table 3 we study and compare the model generation times across four companies using PROCESS2 and PROCESS1 (See Fig. 12 and Table 3). We outline the following observations on the speed of problem generation between the two processes. 1. The time required to solve the model using CPLEX optimizer is of the order of 0.01 s. 2. We observe an approximately 60% reduction in time required to generate the model (an instance of steel model) using PROCESS2 (21 s) over PROCESS1 (58 s) (See Fig. 13 and Table 2).
Fig. 12. PROCESS2 vs PROCESS1.
industry. This may require solving the SLP model multiple times after entering the appropriate sets of data. Since the time to generate the model is very high in PROCESS1, a 60% reduction in time to generate the model using PROCESS2 can be considered a significant improvement while testing the model with multiple industry data, or multiple scenario data of an industry. It is also to be noted that the time required to solve the problem will be much larger than the time required to generate the model when dealing with a growing number of scenarios in a mixed integer linear program (MILP). The suggested database PROCESS2 would still be better than PROCESS1 in terms of time to generate the model where integer variables are not involved in a SLP. In large scale MILP optimization models, the advantage of PROCESS2 outperforming PROCESS1 may not be very visible and useful. However, our results of PROCESS2 outperforming PROCESS1 are still valid and important because the current model has been tested with real data of a large scale steel company, and most of the production problems of process industries are likely to be similar to the problems of the steel company discussed in this paper. 7. Conclusions and further direction
The 60% reduction in time required to generate the optimization model using PROCESS2 compared to PROCESS1 is due to the relational nature of the database schema of PROCESS2. As discussed in Section 6.1, most of the searches, sorting, and update of the data happens at the sub-file level in PROCESS1, while the relational database design of PROCESS2 enables it to search, sort and update the data directly at the file level. The multiple scenarios optimization model leads to the replication of the mathematical model for each scenario, thereby resulting in an increase in the size of the model. The number of constraints, variables, and technological coefficients to be generated, increases in proportion to the number of scenarios. The reduction in time to generate the complete optimization model becomes vital when the size of the model is significantly large. Users may like to run multiple instances of the model using different sets of data from different industries, or different numbers of scenarios from the same
This paper attempts to address the issues in constructing a relational database structure for an SLP formulation. We followed the principles of designing a relational database by Fourer [24] and Dutta & Fourer [14]. The research provides insights for designing relational databases for generic SLP models. We established and implemented generic advance diagnostic rules of data loading, data reporting, and database schema. This demonstrates how multiple dimension data can be reported into the database as well as to the user. We recognize from literature that the bulk of industry data lies in databases. We foresee ample potential to implement the relational databases in the context of a class of SLP models. We need to test the efficacy of these database construction principles by using this DSS with real data from different industries. The claims of this research can be strengthened further by conducting a more exhaustive
Table 3 PROCESS2 over PROCESS1 (model generation time). Model
No. of coefficients
Hierarchical model: PROCESS1 (seconds)
Relational model: PROCESS2 (seconds)
Reduction (seconds)
Steel Pharma Polymer Aluminum
12,236 631 131 5156
58 3 2 22
21 1 1 14
37 2 1 8
54
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
Fig. 13. Efficiency model generation time.
comparative analysis by replication of the same research with real data from more industries. We also need to test the principles of database construction in another application of stochastic programming. A forthcoming paper will discuss the database construction and application of Stochastic Optimization based DSS in Asset Liability Management. It requires further studies to explore the issues of relational database construction in the context of non-linear programming model representation. The application of this stochastic optimization based DSS across multiple process industries for strategic planning can be a good extension to this research. The extension of the relational database structure and development of a multi-period, multi-scenario optimization DSS with an application in an integrated supply chain environment can be another interesting extension to this research. The research can be extended to compare the databases including other data structures different from relational databases. Acknowledgment We thank the Research and Publication, Indian Institute of Management Ahmedabad, India for financially supporting the research. Appendix AA.1. Model formulation We define sets, parameters, variables, objective function and constraints of the SLP as follows. Time Data: T = {1… T} is the set of time periods in the planning horizon, indexed by t. ρl is the interest rate per period in each of the scenario l, taken as zero if there is no discounting. Scenario Data: L = {1… L} is the set of scenarios in the planning horizon, indexed by l. pl is the probability of occurrence of the scenario l. Materials Data: M is the set of all materials, indexed by j. buy buy lbuy jlt , ujlt , cjlt are the lower limit, upper limit, and cost per unit of material j purchased, for each j ∈ M, l ∈ L, and t ∈ T respectively. sell sell lsell jlt , ujlt , cjlt are the lower limit, upper limit, and revenue per unit of material j sold, for each j ∈ M, l ∈ L, and t ∈ T respectively. inv inv linv jlt , ujlt , cjlt are the lower limit, upper limit, and holding cost per unit of material j inventoried, for each j ∈ M, l ∈ L, and t ∈ T respectively. vinv j0 = initial inventory of material j, for each j∈M. Mconv ⊆ {j ∈ M, j′ ∈ M : j ≠ j′} is the set of conversions: (j, j′) ∈ Mconv means that material j can be converted to material j′. = number of units of material j′ that result from converting α conv j j0 lt one unit of material j, for each (j, j′) ∈ Mconv, l ∈ L, t ∈ T.
cconv = cost per unit of material j of conversion from j to j′, for each (j, j j0 lt j′) ∈ Mconv, l ∈ L, t ∈ T. Facilities Data: F is the set of facilities, indexed by i. cap lcap ilt , uilt are the minimum, and maximum unit of capacity of facility i that must be used, for each i ∈ F, l ∈ L, and t ∈ T respectively. ccap ilt = cost of outsourcing a unit of capacity at facility i, for each i ∈ F, l ∈ L, and t ∈ T. Fin ⊆ F is the set of facility inputs: (i, j) ∈ F in that material j is used as an input at facility i. in lin ijlt, and uijlt are the minimum, and maximum amount of material j that must be used as input to facility i, for each (i, j) ∈ F in, l ∈ L, t ∈ T. Fout ⊆ F is the set of facility outputs (i, j) ∈ F out that material j is produced as an output at facility i. out lout ijlt , and uijlt are the minimum, and maximum amount of material j that must be produced as output at facility i, for each (i, j) ∈ F out, l ∈ L, t ∈ T. Activities Data: A is the set of activities, indexed by k. F act ⊆ {(i, k) : i ∈ F} is the set of activities: (i, k) ∈ F act means that k is an activity available at facility i. act lact iklt, uiklt, are the minimum, and maximum number of units of activity k that may be run at facility i, for each (i, k) ∈ F act, l ∈ L, t ∈ T. cact iklt = the cost per unit of running activity k at facility i, for each (i, k) ∈ Fact, l ∈ L, t ∈ T. ract iklt = the number of units of activity that can be accommodated in one unit of capacity of facility i, for each (i, k) ∈ F act, l ∈ L, t ∈ T. Ain ⊆ {(i, j, k, t) : (i, j) ∈ F in(i, k) ∈ F act, t ∈ T} is the set of activity inputs: (i, j, k, t) ∈ Ain means that input material j is used by activity k at facility i during time period t. αin ijklt = units of input material j required by one unit of activity k at facility i in time. Period t, in scenario l, for each l∈L, and (i, j, k, t) ∈ Ain Aout ⊆ {(i, j, k, t) : (i, j) ∈ Fout(i, k) ∈ Fact, t ∈ T} is the set of activity outputs: (i, j, k, t) ∈ Aout means that output material j is produced by activity k at facility i during time period t. αout ijklt = units of output material j produced by one unit of activity k at facility i in time. Period t, scenario l, for each, l∈L, and (i, j, k, t) ∈ Aout Storage-areas Data: S is the set of storage areas, indexed by s. lstor slt = lower limit on total material in storage area s, for each s ∈ S, l ∈ L, and t ∈ T. ustor slt = upper limit on total material in storage area s, for each s ∈ S, l ∈ L, and t ∈ T.
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
A.2. Variables
A.5. Constraints
sell inv are the units of material j bought, sold, and invenxbuy jlt , xjlt and xjlt toried for each j ∈ M, l ∈ L, and t ∈ T respectively. units of material j in storage area s, for each j ∈ M, s ∈ S, l ∈ L, xstor jslt and t ∈ T. initial inventory of material j, for each j ∈ M. xinv j0 units of material j converted to material j′, for each (j, j′) ∈ xconv j j0 lt Mconv, l ∈ L, t ∈ T. units of material j used as input by facility i, for each (i, j) ∈ F in, xin ijlt l ∈ L, t ∈ T. units of material j produced as output by facility i, for each (i, xout ijlt j) ∈ Fout, l ∈ L, t ∈ T. units of activity k operated at facility i, for each (i, k) ∈ F act, l ∈ xact iklt L, t ∈ T. units of capacity vendored at facility i, for each i ∈ F, l ∈ L, and xcap ilt t ∈ T.
For each j ∈ M, l ∈ L, and t ∈ T, the amount of material j made available by purchases, production, conversions and beginning inventory must equal the amount used for sales, production, conversions and ending inventory: X
buy
xjlt þ
ði; jÞ∈ F
A.3. First stage variables
out
xconv 1jj xin 1ij xout 1ij xact 1ik xcap 1i
Maximize the sum over all time periods of revenues from sales less costs of purchasing, holding inventories, converting, operating activities at facilities, and cost of operating facilities: ZN ¼
pl
X
Z ðl; t Þ
ð1Þ
t ∈ T
l ∈ L
conv conv
inv
α j0 jlt x j0 jlt þ xjlt−1 conv sell
¼ xjlt þ
X ði; jÞ∈ F
X
in
xijlt þ in
ð j; j Þ∈M 0
conv
inv
x j j0 lt þ xjlt : conv
ð4Þ For each (i, j) ∈ Fin, l ∈ L and t ∈ T, the amount of input j used at facility i must equal the total consumption by all the activities at facility i: X
in
xijlt ¼
in
act
α ijklt xiklt :
ð5Þ
in
X
out
xijlt ¼
out
act
α ijklt xiklt :
ð6Þ
out ði; j;k;t Þ∈A
For each i ∈ F, l ∈ L and t ∈ T, the capacity used by all activities at facility i must be within the range given by the lower limit and the upper limit plus the amount of capacity vendored: X
cap
lilt ≤
ði;kÞ∈ F
act
act
cap
cap
xiklt =r iklt ≤uilt þ xilt :
ð7Þ
act
For each j∈M, the amount of material inventoried in the plant before the first time period is defined to equal the specified initial inventory: inv
inv
x j0 ¼ v j0 :
ð8Þ
For each j ∈ M, l ∈ L and t ∈ T, the total amount of material j inventoried is defined as the sum of the inventories over all storage areas:
A.4. Objective
X
ð j ; jÞ∈M 0
For each (i, j) ∈ F out , l ∈ L and t ∈ T, the amount of output j produced at facility i must equal the total production by all the activities at facility i:
units of material j bought, for each j∈M, in first period. units of material j sold, for each j∈M, in first period. units of material j in storage area s, for each j∈M, s∈S, in first period. total units of material j in inventory (storage), for each j∈M, in first period. units of material j converted to material j′, for each (j, j′) ∈ Mconv, in first period. units of material j used as input by facility i, for each (i, j) ∈ F in, in first period. units of material j produced as output by facility i, for each (i, j) ∈ F out, in first period. units of activity k operated at facility i, for each (i, k) ∈ Fact, in first period. units of capacity outsourced at facility i, for each i∈F, in first period.
xinv 1j
X
out
xijlt þ
ði; j;k;t Þ∈A
xbuy 1j xsell 1j xstor 1js
55
Objective function for nominal cash flows
X
stor
inv
xjslt ¼ xjlt :
ð9Þ
s∈S
For each s ∈ S, l ∈ L and t ∈ T, the total of all materials inventoried in storage area s must be within the specified limits: stor
lslt ≤
X
stor
stor
xjslt ≤uslt :
ð10Þ
j∈M
ZD ¼
X
pl
!
X
−t
ð1 þ ρl Þ Z ðl; t Þ
t∈T
l∈L
ð2Þ
buy
buy
ð11Þ
sell
sell
ð12Þ
stor
stor
ð13Þ
xjlt ¼ x1 j for each of the j∈M; l∈L and t ¼ 1
where,
Z ðl; t Þ ¼
A.6. Implementability (non-anticipativity) constraints
Objective function for discounted cash flows
X
sell sell cjlt xjlt −
j∈M
−
X
buy buy cjlt xjlt −
j∈M
X
ði;kÞ∈ F
act
X
X cap cap act act ciklt xiklt − cilt xilt i∈ F
X
inv inv cjlt xjlt − j∈M ð j; j0 Þ∈Mconv
conv conv c j j0 lt x j j0 lt
ð3Þ
xjlt ¼ x1 j for each of the j∈M; l∈L and t ¼ 1 xjslt ¼ x1js for each of the j∈M; s∈S; l∈L and t ¼ 1 inv
inv
xjlt ¼ x1 j for each of the j∈M; l∈L and t ¼ 1
ð14Þ
56
N. Gupta et al. / Decision Support Systems 64 (2014) 43–56
conv
conv
x j j0 lt ¼ x1jj for each ð j; j0Þ∈M in
in
out
out
in
act
act
act
cap
cap
conv
; l∈L; and t ¼ 1
in
xijlt ¼ x1ij for each ði; jÞ∈F ; l∈L; and t ¼ 1
xijlt ¼ x1ij for each ði; jÞ∈ F ; l∈L; and t ¼ 1
xiklt ¼ x1ik for eachði; kÞ∈F
; l∈L; and t ¼ 1
xilt ¼ x1i for each i∈F; l∈L; t ¼ 1
ð15Þ ð16Þ
ð17Þ
ð18Þ
ð19Þ
All variables must lie within the relevant limits (bounds) defined by their respective bounds. References [1] A.M. Geoffrion, An introduction to structured modeling, Manag. Sci. 33 (5) (1987). [2] A.M. Geoffrion, The formal aspects of structured modeling, Oper. Res. 31 (1) (1989). [3] A.M. Geoffrion, Computer based modeling environments, Eur. J. Oper. Res. 41 (1989). [4] A.R. Ferguson, G.B. Dantzig, The allocation of air craft to routes — an example of linear programming under uncertain demand, Manag. Sci. 3 (45) (1956). [5] C.V. Jones, Attributed graph-grammars and structured modeling, Ann. Oper. Res. 38 (1992). [6] C.V. Jones, An introduction to graph-based modeling systems, part I: overview, ORSA J. Comput. 2 (2) (1990). [7] C.V. Jones, An introduction to graph-based modeling systems, part II: graphgrammars and the implementation, ORSA J. Comput. 3 (3) (1991). [8] C. Combes, C. Rivat, A modeling environment based on data warehousing to manage and to optimize the running of international company, Int. J. Prod. Econ. 112 (1) (2008) 294–308. [9] E. Fragniere, J. Gondzio, Stochastic Programming from Modeling Language, Ch-1, 2002. [10] F. Glover, D. Kingman, N. Phillips, Netform modeling and applications, Interfaces 20 (4) (1990). [11] F.H. Murphy, E.A. Storh, A. Asthana, Representation scheme for linear programming models, Manag. Sci. 38 (7) (1992). [12] G. Dutta, An optimization-based decision support system for strategic planning in process industries, A Doctoral Dissertation1996.
[13] G. Dutta, R. Fourer, An optimization-based decision support system for strategic and operational planning in process industries, Optim. Eng. 5 (2004). [14] G. Dutta, R. Fourer, Database structure for a class of multi-period mathematical programming models, Decis. Support. Syst. 45 (4) (2008). [15] G. Dutta, R. Fourer, A. Majumdar, D. Dutta, An optimization based decision support system for strategic and operational planning within process industries: case of pharmaceuticals industry in India, Int. J. Prod. Econ. 102 (2007). [16] G. Dutta, N. Gupta, R. Fourer, An optimization-based decision support system for strategic planning in a process industry: the case of Aluminium Company in India, J. Oper. Res. Soc. 62 (2011). [17] G. Dutta, G.P. Sinha, P.N. Roy, N. Mitter, A linear programming model for distribution of electrical energy in a steel plant, Int. Trans. Oper. Res. 1 (1) (1994). [18] G. Mitra, UIMP: user interface for mathematical programming, ACM Trans. Math. Softw. 8 (3) (1982). [19] G.P. Sinha, B.S. Chandrashekaran, N. Mitter, G. Dutta, S.B. Singh, P.N. Roy, A.R. Choudhary, Strategic and operations management with optimization at Tata Steel, Interfaces 25 (1) (1995). [20] J.S. Welch, PAM A — practitioner approach to modeling, Manag. Sci. 33 (5) (1987). [21] M. Rudberg, J. Thulin, Centralized supply chain master planning employing advanced planning systems, Prod. Plan. Control 20 (2) (2009) 158–167. [22] P. Kalland, J. Mayer, Computer Support for Modeling in Stochastic Programming, Institute for Operations Research, University of Zurich, 1993. (CH-8044, http://www.unizh.ch/ior/Pages/Deutsch/Mitglieder/Kall/bib/ka-may-95a.pdf , date 10th March 2006, 10.30 AM). [23] R. Affonso, F. Marcotte, B. Grabot, Sales and operations planning: the supply chain pillar, Prod. Plan. Control 19 (2) (2008) 132–141. [24] R. Fourer, Database structure for mathematical programming models, Decis. Support. Syst. 20 (1997). [25] R. Fourer, Modeling language versus matrix generator for linear programming, ACM Trans. Math. Softw. 9 (2) (1983). [26] S. Sen, J.L. Higle, An introductory tutorial on SLP models, Interfaces 29 (2) (1999) 33–61. [27] S. Sen, Stochastic Programming: Computational Issues and Challenges, http://www. sie.arizona.edu/faculty/addenda/sen/encycl3.pdf, 30th March 2006, 11.00 AM, Encyclopedia of OR/MS, in: S. Gass, C. Harris (Eds.), 2000. [28] Christian Valente, Design and Architecture of a Stochastic Programming Modeling System, Dissertation at Brunel University, 2011. Narain Gupta is an Assistant Professor of Operations Area at Management Development Institute, Gurgaon, India (www.mdi.ac.in ). Goutam Dutta is a Professor of Production and Quantitative Methods area at Indian Institute of Management, Ahmedabad, India. Robert Fourer is the President of AMPL Optimization, Inc. USA.
