Tech Memo Home | Publications Home
CONTENTS
Introduction
Brief Overview of DEA
Input-Oriented Technical Efficiency
Output-Oriented Technical Efficiency
Output-Oriented Model with Slack Variables
Measuring Capacity with an Output-Oriented DEA Model
Modeling Returns to Scale
Modeling Capacity Utilization
Summary and Conclusions
Endnotes
Acknowledgments
References Cited
Acronyms

NOAA Technical Memorandum NMFS-NE-160

Measuring Technical Efficiency and Capacity in Fisheries by Data Envelopment Analysis Using the General Algebraic Modeling System (GAMS): A Workbook

John B. Walden1 and James E. Kirkley2
1National Marine Fisheries Serv., Woods Hole Lab., 166 Water St., Woods Hole, MA  02543
2College of William & Mary, Virginia Inst. of Marine Science, Gloucester Point, VA 02362

Web version posted November 26, 2004

Citation: Walden JB, Kirkley JE. 2000. Measuring Technical Efficiency and Capacity in Fisheries by Data Envelopment Analysis Using the General Algebraic Modeling System (GAMS): A Workbook. US Dep Commer, NOAA Tech Memo NMFS NE 160; 15 p.

Information Quality Act Compliance: In accordance with section 515 of Public Law 106-554, the Northeast Fisheries Science Center completed both technical and policy reviews for this report. These predissemination reviews are on file at the NEFSC Editorial Office.

Acrobat Download complete PDF/print version

Introduction

This workbook presents several programs for modeling production efficiency and fishing capacity which were prepared for the National Marine Fisheries Service Workshop on Capacity Estimation in Marine Fisheries (“National Capacity Workshop”) held in Silver Spring, Maryland, during September 29 - October 1, 1999. The programs are written in the General Algebraic Modeling System (GAMS) language, a mathematical programming language used in a variety of linear, nonlinear, and mixed-integer programming models, general equilibrium models, and network models.[1]

Each program in this workbook uses data envelopment analysis (DEA) to calculate measures of productive efficiency and fishing capacity. DEA was developed over 20 yr ago as a tool in management science to examine efficiency in the public sector (Charnes et al. 1994). The programs are based on a DEA model written in GAMS by Olesen and Petersen (1996), who argue that GAMS is preferable to the specialized DEA software packages currently available because of the flexibility that GAMS offers. The user can easily modify GAMS code to account for changes to the “standard” DEA model, and can exert greater control over output formats, features not typically available in the specialized packages. These features are important in fisheries where production analysis often differs from that available with the standard models.

The programs in this workbook are simplified versions of those programs presented at the National Capacity Workshop, and are designed to show the basic GAMS syntax for developing DEA models. Because there was little time at the workshop to discuss all of the programs, this workbook was prepared. Each workbook program is preceded by a description of the mathematical model on which it is based, and then followed by an explanation of important program sections.
BRIEF OVERVIEW OF DEA

Charnes, Cooper, and Rhodes first introduced DEA in 1978. DEA extended the Farrell (1957) technical measure of efficiency from a single-input, single-output process to a multiple-input, multiple-output process. Since then, DEA has been used to assess efficiency in many different areas, ranging from the public sector to natural resource sectors such as the fishing industry.

DEA uses linear programming methods to extract information about the production process of each decision-making unit (DMU, e.g., firm or fishing vessel). This information extraction is accomplished by calculating a maximum performance measure for each firm, and comparing this measure to similarly calculated measures for all other firms. Each firm’s performance measure traces out a best-practice frontier, and all DMUs lie either on or below the frontier (Charnes et al. 1994). A best-practice frontier maps out the maximum level of output (minimum level of input) that could be produced (used) for any given level of input (output). Figure 1 shows a graphical representation of an output-oriented DEA model with a single input for 10 firms. The best-practice frontier is traced through the points representing the maximum level of output for a given input; any points below the frontier are deemed inefficient. For example, the DMU at point (8,12) produces 12 units of output with 8 units of input, while the DMU at point (8,9) produces 9 units of output with 8 units of input. The second DMU is deemed to be inefficient compared to the first because only 9 units of output (versus 12) are produced for the same level of input. Inefficiency for any DMU is determined by comparison to either another DMU or to a convex combination of other DMUs on the frontier which utilize the same level of input and produce the same or higher level of output. The analysis is accomplished by requiring solutions that can increase some outputs (decrease some inputs) without worsening the other inputs or outputs (Charnes et al. 1994).

The one-input, one-output case can be expanded to cases involving multiple inputs and multiple outputs. Charnes et al. (1978) proposed a method in which the multiple-input, multiple-output model was reduced to a ratio with a single “virtual” input and single “virtual” output by estimating a set of weights depicting each DMU in the most favorable position relative to other DMUs. In equation form, the model is as follows:

equation a

where:

yrj = quantity of output r produced by firm j,
xij = quantity of input i produced by firm j,
ur = weight for output r,
vi = weight for input i, and
e = small positive quantity.

The estimated ratio provides a measure of technical efficiency for each DMU. However, there are an infinite number of solutions because if (u*,v*) is optimal, then (betau*,betav*) is also optimal for beta > 0 (Charnes et al. 1994). This problem is corrected by converting the ratio form into an equivalent linear programming problem as follows:

equation b

Färe et al. (1994) developed a variation of the preceding linear programming approach to model efficiency, productivity, and capacity. The models they use measure the efficiency of individual producers by constructing a “best-practice frontier” through a piecewise linear envelopment of the data generated by all producers in the group. Estimates generated by those models are therefore “relative” measures based on the best producers within the group.

The following sections describe several linear programming models to estimate input and output technical efficiency and capacity output based on the approach used by Färe et al. (1994). Each model is accompanied by an example and description of a GAMS program to solve the model.


INPUT-ORIENTED TECHNICAL EFFICIENCY

An input-oriented technical efficiency model examines the vector of inputs used in the production of any output bundle, and measures whether a firm is using the minimum inputs necessary to produce a given bundle of outputs. Efficiency is measured by the maximum reduction in inputs which will still allow a given output bundle to be produced. Figure 2 depicts the results of an input-oriented model using a single-input, single-output example. Firms to the right of the frontier are deemed to be inefficient because they could produce the same level of output for less input. For example, the point (6,5) means 6 units of input are used to produce 5 units of output. Another firm is using 3 units of input to produce 5 units of output. The first firm is technically inefficient compared to the second firm because much more input is used to produce the same level of output.

Färe et al. (1994) proposed the following input-oriented DEA model to measure technical efficiency:

equation123

where:

l = efficiency measure to be calculated for each DMU j,
ujm = quantity of output m produced by DMU j,
xjn = quantity of input n used by DMU j, and
zj = intensity variable for DMU j.

Since the variable l is calculated for each DMU, the preceding formulation is estimated once for each DMU in the data set. Equations 1 and 2 define a set of constraints for each output and input. If there are two outputs, Equation 1 will define a set of constraints, one for each output. A value of l=1.0 means that a firm is considered efficient, while a value l<1.0 means a firm is inefficient. Thus, a value of l=0.70 means that a firm could reduce its inputs by 30%, and produce the same level of output. An example of the GAMS formulation for this model is shown in Figure 3. In this example, there are two outputs, called “spec1” and “spec2”, and four inputs, called “fix1”, “fix2”, “var1”, and “var2”.[2]

Lines 1-6 define six sets to be used in the model. Sets are the basic building blocks of GAMS, and correspond to the m, n, and j indexes in the DEA technical efficiency equations. Line 1 defines a set called “inout” which has as members “spec1”, “spec2”, “fix1”, “fix2”, “var1”, and “var2”. All inputs and outputs are defined as members of one set initially. Lines 2 and 3 define subsets of “inout” that contain, respectively, the outputs (m) or inputs (n), initially included as members of “inout”. Subsets can only contain elements which exist in a previously defined set. Lines 4-6 define sets which correspond to index j. Line 4 defines a set called “obs” which contains 500 members. Line 5 defines a subset of “obs”, called “subobs”, which in this case holds the first 10 members of set “obs”. Declaring “subobs” to be a subset of “obs” allows different sets of data to be used as long as they contain between 1 and 500 observations. In GAMS syntax, the “*” operator in a set declaration signifies all elements between 1 and 10. This is simpler than typing in 1,2,3,...,10, especially when there are a large number of observations. Line 6 declares another subset of “obs”, called “actobs”, which is initially empty. This is referred to in GAMS as a dynamic set, because its membership can change.

Line 7 is an example of an alias statement, which allows the set “subobs” to be referred to using either the name “subobs”, or “subobs1”. As shown in line 22, this is needed for the “loop” statement. Line 8 reads the data that will be used in the model through the use of the “table” statement. In this example, a table “act”, with indexes “obs” and “inout”, is declared, and the values are initialized with the “table” statement. The rows of table “act” correspond to observations (j), while the columns correspond to either inputs or outputs. The column headings need to align with the data contained in the column, so each data element is right justified. For large data sets, it is usually easier to read in an external file containing the data. An example of this will be shown in a subsequent program. Line 9 uses a semicolon to end the “table” statement. It is generally good practice to end every GAMS statement with a semicolon, as is shown on lines 6, 7, and 9.

Lines 10-13 define the variables to be used in the model. Variables are sometimes referred to as activities, columns, decision variables, or endogenous variables. Variable values are generally unknown until after the model is solved. The two variables in this example are called “lambda” and “weight”. “Lambda” is the decision variable to be optimized, while “weight” is the intensity variable that corresponds to zj in Equations 1, 2, and 3. Line 13 declares “weight” to be a positive variable. The default variable type in GAMS is free, meaning variables can take on positive or negative values.[3] The decision variable “lambda” must be of type free.

Lines 14-18 define the equations used in the model. Equations must first be declared in GAMS (lines 15 and 16) and then defined (lines 17 and 18). “Constr1” is indexed over the sets “output” and “obs”, while “constr2” is indexed over the sets input and “obs”. When the equations are defined in lines 17 and 18, the subsets “actobs” and “subobs” are substituted for the set “obs”. The reason will be clear after examining programming lines 22-28. Being able to index an equation is a very powerful tool. “Constr1” actually defines 20 different equations because there are two outputs and 10 observations, and this is succinctly represented by one equation definition. On lines 17 and 18 immediately after the equations are found two dots “..”; these are required by GAMS in the equation definition.

Lines 19 and 20 define a parameter “score1”, used to hold results from the model. Line 21 defines a model called “tedea”, which consists of two equations, “constr1” and “constr2”. An alternative way to define this model would be as follows: “model tedea /all/;”. This indicates that GAMS should use all (or in this case both) of the equations in the model. By specifying which equations to include in the model, one has the ability to use several different model formulations in the same program.

Lines 22-28 solve the model. In a DEA model, the linear programming problem is solved once for each DMU, which is accomplished in GAMS through the use of the “loop” statement (line 22). Because the subset “subobs” is referenced in the equation definitions, the loop has to be indexed over subset “subobs1” (which has been declared previously to be an alias for “subobs”). In line 23, the set “actobs” is made an empty set, which is needed for each pass through the loop. In line 24, one observation is added to the set “actobs”, which is the current observation of subset “subobs1”. Referring back to the equation definitions on lines 17 and 18, this has the effect of indexing “constr1” only over the set “output”, and indexing “constr2” only over the set input, because “actobs” only contains one observation (j0). Comparing these equations with the mathematical model reveals that the right- and left-hand sides of Equation 1 have been switched and that the inequality has been reversed. However, the fundamental relationship of the equation remains the same. Line 25 tells GAMS to use the OSL solver to solve the LP model. The default solver that comes with GAMS is BDMLP, but this software was found not to solve more complex models at each iteration. Both the OSL and the MINOS5 solvers are able to solve most DEA problems[4]. Line 26 solves the model through the SOLVE statement, by telling GAMS to minimize “lambda”. Line 27 stores the value of “lambda” obtained from each solve statement in the parameter “score1”. The “.l” extension tells GAMS to use the solution value of “lambda”. The “loop” statement is then closed on line 28 with a “);”. Line 29 uses the display statement in GAMS to print the values held in parameter “score1” to the listing file.

Results from this model are shown Table 1 (along with the results from the output-oriented model which will be presented in the next section). Only observation #4 is deemed to be efficient (l=1.00). All other observations could reduce their inputs and still produce the same level of output, if they used their inputs as efficiently as observation #4.


OUTPUT-ORIENTED TECHNICAL EFFICIENCY

Output technical efficiency is a measure of the potential output of a DMU given that inputs are held constant. Färe et al. (1994) modeled the output technical efficiency measure for any DMU using linear programming:

equation c

where:

t = output technical efficiency measure,
ujm = quantity of output m produced by DMU j,
xjn = quantity of input n produced by DMU j, and
zj = intensity variable for DMU j.

An example of the GAMS formulation for this model is shown in Figure 4. This example uses the same inputs and outputs as the previous example. A value of t=1.0 signifies that the DMU is efficient; a value of t>1.0 indicates that the DMU is inefficient. For example, a score of 1.25 means that it should be possible to increase all outputs from a DMU by 25% with the same level of inputs.

In Figure 4, line 1 is an example of a dollar control operator[5]. This operator allows comments to be placed on lines using a “/*” to begin the comment and a “*/” to end the comment. Line 2 shows an example of a comment in the GAMS program. Lines 3-8 are the same as lines 1-6 in the input-oriented program, and define the sets used in the program.

Lines 10-13 demonstrate a way to read in data from an external file. In this example, a comma-separated value (CSV), Microsoft Excel file is read into the program. Line 10 names the table “act”, and defines it to consist of dimension “obs” and “inout”. Line 11 shows the use of the dollar control operator “$ondelim”, which allows GAMS to read a CSV-formatted file from Microsoft Excel. Line 12 uses the “$include” command to read into GAMS the contents of an external file (in the format shown in Figure 5). The first column of the input file must have a heading of “dummy” for the file to be properly read into GAMS.

Lines 14-17 define the variables used in the model, while lines 18-22 declare the equations and then define them. Line 25 defines an external file where results will be written, and names this file “primal”. Lines 26-32 are the same as in the input-oriented program, with the exception that the variable “theta” is to be maximized rather than “lambda” minimized.

Lines 33-37 write messages to an external file indicating whether the model was solved at each iteration. This is important because the model may fail to solve some observations but may successfully solve others. By examining these messages, the user can easily see if the model solved at each iteration. Line 33 is telling GAMS that the file referenced by the name “primal” is the current file, and items referenced through further use of the “put” statement are to be written to that file. Lines 34-37 use an “if-else” construct to determine what messages will be written to file “primal”. Line 34 tests the return codes from GAMS to determine if the model solved correctly. The suffix “.modelstat” appended to “tedea” tests for a return code of “1”, which indicates that the solution is optimal. The suffix “.solvestat” informs the user that the solver terminated normally and there were no problems solving the model when the return code is “1”. If the model solved correctly and the solver completed normally, then line 35 instructs that the observation number, the term “optimal”, and the term “normal completion” be written out to a file. If these conditions do not exist, then lines 36 and 37 indicate that the codes which are returned should be written to the file[6].

Lines 39-44 write the technical efficiency results to a CSV file which can be opened in Excel. Line 40 tells GAMS that the file will be of type “.csv”, by using the suffix “.pc”, and setting this equal to 5[7]. Lines 42 and 43 use a loop structure to print out the observation number (or DMU) and the efficiency estimate that was stored in parameter “score1”. Line 44 closes the open file “res” with the “putclose” command.

Results from the output-oriented model are summarized in Table 1. The inefficient firms are identical to those found using the input-oriented model. In fact, results for the output-oriented model are equal to 1/l[8]. Theta values from the output-oriented model indicate how much each DMU should be able to increase output production given that the inputs are held constant. For example, in Table 1, firm (observation) #1 had a value of t=1.10. This value indicates that this firm should have been able to increase production of both “spec1” and “spec2” by 10% (e.g., 13,295x1.1; 27,065x1.1), if inputs were used as efficiently as firm (observation) #4.



AN OUTPUT-ORIENTED MODEL WITH SLACK VARIABLES

In the output-oriented technical efficiency model, DMUs are deemed to be efficient if t=1, and inefficient if t>1. For the inefficient DMUs, outputs are expanded proportionally by multiplying theta times output. However, by incorporating slack values, nonradial levels can be obtained which are greater then radially expanded output levels. In a linear programming model, slack values are derived by converting inequality constraints to equality constraints and adding slack variables. A full discussion of slack values is given in Intriligator (1971), but the general approach can be seen in the following simple example from Intriligator (1971):

equation d

Inequality constraints are turned into equality constraints by adding a vector of m slack variables:

equation e

The problem is now written as :

equation f

The non-negativity condition on the slack variables ensures that the inequality constraints are met. Revising the output-oriented model in the prior section yields the following model formulation:

equation 4-8

Equation 4 defines a set of constraints for each output which equates theta times the observed output level for DMU j to the sum over all DMUs of the intensity variables (zj) times each DMU’s output level, minus the slack output level. The non-negativity constraint (Equation 7) on the slack variable means that the variable will have a value of zero or greater. When the left-hand side of Equation 4 equals the summation on the right-hand side, the slack variable is zero. When the left-hand side is less than the summation on the right-hand side, the slack variable is positive, so that the equality constraint holds. Adding the slack variable to each side of Equation 4 yields the following:

equation 9

The zj variables map out the linear segments of the frontier (Färe et al. 1994), and determine frontier output. By adding the value of the slack variable sm to the term tujm, the output for product m on the left-hand side of Equation 9 is exactly equal to the frontier output on the right-hand side.

GAMS[9] allows the user to display the values of the slack variables directly, but slack variables can also be included by modifying the constraints and incorporating them explicitly. An example is Figure 6, which uses the original output-oriented technical efficiency program from the previous section.

In Figure 6, lines 1-13 set up the problem in the same manner as the original output technical efficiency measure. Lines 14-18 define the variables to be used and include two new variables that were not in the previous example. The variables “slack1”, to handle output slack, and “slack2”, to handle input slack, are declared on lines 17 and 18[10]. Line 19 specifies that both slack variables are positive. Lines 23-24 define the equations that now incorporate the slack variables. Both equations have equality constraints rather than the inequality constraints that were in the original output efficiency model. On line 36, the output slack values returned by the model are stored in parameter “score2”. Results from the program are then written to a file on lines 45-60.

Table 2 shows results from the output-oriented DEA model. Values of theta (the decision variable) are the same as obtained from the output-oriented technical efficiency model. Slack values for output “spec1” are provided for each observation except #4, which is on the best-practice frontier (t=1 and slack values are zero). For all observations, the slack for “spec2” is zero.


MEASURING CAPACITY WITH AN OUTPUT-ORIENTED DEA MODEL

Färe et al. (1994) developed a DEA model of capacity based on the definition of capacity given by Johansen (1968): Capacity is the “maximum amount that can be produced per unit of time with existing plant and equipment, provided that the availability of variable factors of production is not restricted.” To model capacity, the input vector is separated into a subvector of fixed inputs, and a subvector of variable inputs. The subvector of fixed inputs is bounded by observed values, while the bounds on the variable inputs are allowed to vary. This essentially constrains production by the fixed factors, consistent with the Johansen definition.

The mathematical model proposed by Färe et al. (1994) is as follows:

equation g

where:

t = capacity measure,
ujm = quantity of output m produced by firm j,
xjn = quantity of input n used by firm j,
nequation 2Fx = inputs belonging to the set of fixed factors,
nequation 2Vx = inputs belonging to the set of variable factors,
ljn = input utilization rate of variable input n by firm j, and
zj = intensity variable for firm j.

Programming of this model formulation in GAMS is shown in Figure 7. One advantage GAMS has over other available DEA programs is that it allows direct estimation of l, the variable input utilization rate. The value of lambda is the ratio of the optimal use of each input to its actual usage. For example, a value of 1.25 means that the variable input should be increased 25% for a firm to be on the best-practice frontier.

This GAMS model differs from the output-oriented model in that the set of inputs is divided into two subsets containing either fixed or variable inputs (lines 4 and 5). Lines 6-15 are the same as in the output-oriented DEA program, with the exception of lines 10 and 15. Line 10 instructs GAMS not to print the following lines to the listing file. This is particularly useful in reducing the size of the listing file when the data set is quite large. Line 15 instructs GAMS to resume printing to the listing file.

Lines 16-19 declare the variables used in the program. The variable “lambda” (line 19) is declared over the set of variable inputs. Lines 21-24 declare the model equations with the input constraints addressed. Lines 31-44 are similar to the GAMS program used to model output-oriented efficiency.

Lines 47-61 direct the output results to a CSV file that can be read in Microsoft Excel. Lines 45 and 46 estimate capacity in GAMS internally rather than externally. Capacity for each DMU is calculated by multiplying theta by each output, and then summing over all outputs. Lines 52-61 use a series of “loop” statements to write the results to a CSV file. Lines 51-54 put in header information, while lines 55-61 write the data values and model results to a file.

Table 3 presents the results from this model, and lists the level of variable inputs used by each firm and the optimal variable utilization rate, lambda. The optimal variable utilization rate indicates how each firm would have to change the use of each variable input to operate at capacity. For example, for observation #2, variable input 1 would need to be decreased to 5.04 (8x0.63), and variable input 2 would need to be increased to 185.4 (127x1.46).


MODELING RETURNS TO SCALE

The previous programs implicitly assume constant returns to scale. From an economic viewpoint, allowing variable returns to scale results in a less restrictive model than that imposed by constant returns to scale. From an operations research viewpoint, just the opposite is true because an additional constraint, convexity, is imposed on the model. The practical implication of “imposing” variable returns to scale is that it is easier for some observations to be deemed efficient and placed on the frontier because imposition of the convexity constraint means that the supporting hyperplane does not have to pass through the origin (Charnes et al. 1994).

To impose variable returns to scale, the following equation is added to the model:

equation h

Alternatively, to impose nonincreasing returns to scale requires the following equation to be used:

equation i

Imposing variable or nonincreasing returns to scale requires a single equation in GAMS. To show the programming steps in GAMS, only the necessary adjustments to the previous capacity output program are shown in Figure 8.

The DEA constraint imposing variable returns to scale is declared on line 5, and then defined on line 9. Line 10 declares a model “tedea”, which includes all four equations. Line 9 could be modified to impose nonincreasing returns to scale by changing the “=E=” (equality) to an “=L=” (inequality).

Table 4 shows results from an output-oriented DEA model under three different assumptions: 1) nonincreasing returns to scale (NRS), 2) variable returns to scale (VRS), and 3) constant returns to scale (CRS). Both the NRS and CRS results are identical. With the VRS model, it is easier for DMUs to be placed on the best-practice frontier. This is evident in Table 4 in that more observations have a score of 1.00 under the VRS model then under the NRS or CRS models. Further explanation into why this occurs can be found in Charnes et al. (1994) and Färe et al. (1994).


MODELING CAPACITY UTILIZATION

Capacity utilization (CU) generally refers to the proportion of potential capacity that is used, and is typically measured as the ratio of actual output to capacity output (Kirkley and Squires 1999). This ratio generally cannot exceed 1.0. Färe et al. (1989) proposed that CU be measured as the ratio of output technical efficiency to capacity output. This ratio corrects for downward bias that could arise because actual observed output may be inefficiently produced. Shown in Figure 9 is a GAMS program which estimates technical efficiency, capacity output, and capacity utilization.

The entire program will not be reviewed, but key lines will be highlighted. Lines 28-31 define the four equations to be used. These equations have been previously defined in the programs for output technical efficiency and capacity output. A parameter “score1(obs,*)” is defined on line 33, which will hold results from two different models. The “*” allows use of explicit labels in the parameter instead of a specific set. This is seen on line 45, where the label “TE” is used to hold the value of theta estimated by GAMS.

Lines 38 and 39 define two separate models. The first (line 38) defines “tedea”, which models output technical efficiency, and the second (line 39) defines “cap”, which models capacity output. These models are solved in two different “loop” statements, with the results stored in parameter “score1”. Capacity utilization is calculated in line 69, and then also stored in “score1”. Capacity for each vessel is calculated in lines 70 and 71. The estimates of technical efficiency, capacity output, total capacity, and capacity utilization are written to a file in lines 72-91.

Table 5 presents the results from this program using output-oriented DEA models with constant returns to scale. For all observations (except observation #4), observed capacity utilization was less than the unbiased capacity utilization, as expected.


SUMMARY AND CONCLUSIONS

Various DEA models were presented which estimate input-oriented technical efficiency, output-oriented technical efficiency (with and without explicit slack variables), capacity, and capacity utilization. Each model was accompanied by a GAMS program. A key objective was to demonstrate the flexibility of GAMS in modeling DEA problems. This is particularly important in fisheries where production problems generally differ from the “standard” model.


ENDNOTES

  1. Information on GAMS can be obtained from the GAMS website at www.gams.com.
  2. “Spec1” and “spec2” are species landed by each vessel; “fix1” and “fix2” are fixed inputs; and “var1” and “var2” are variable inputs. The order in which variables are read into GAMS in the data table does not matter, and the GAMS language is not case sensitive.
  3. Variables can also be of type negative, binary, or integer.
  4. A list of available solvers can be found at the GAMS website, www.gams.com.
  5. For a complete list of dollar control operators, see the GAMS users guide.
  6. A complete list of model status codes and solve status codes can be found in the GAMS users guide.
  7. A complete list of output file types can be found in the GAMS users guide.
  8. This result only holds when both models assume constant returns to scale. Models with variable returns to scale are discussed in a subsequent section.
  9. There is a global option in GAMS which allows one to obtain the slack values from the equation listing. Inserting the line “option solslack=1;” forces the equation to display slack variables rather then level values. A parameter could then be defined to hold the results from the equation output as follows: “Parameter score3(subobs1,output)=constr1.l(output,subobs1);”. However, in this approach, the level values for the equations cannot be simultaneously obtained. For more information on this, refer to the GAMS user manual.
  10. Because the DEA program is being executed once per DMU in the data set, the slack variables do not need to be indexed over the set “obs”. An alternative formulation for the output slack variable would be “slack1(output, actobs)”.

ACKNOWLEDGMENTS

We thank Rita Curtis, Phil Logan, Barbara Rountree, and Fred Serchuk for helpful comments and suggestions.


REFERENCES CITED

Charnes, A.; Cooper, W.; Lewin, A.; Seiford, L. 1994. Data envelopment analysis, theory, methodology and applications. Norwell, MA: Kluwer Academic Publishers.

Charnes, A.; Cooper, W.; Rhodes, E. 1978. Measuring the efficiency of decision making units. Eur. J. Oper. Res. 2(6):429-444.

Färe, R.; Grosskopf, S.; Kokkenlenbergl, E. 1989. Measuring plant capacity utilization and technical change: a nonparametric approach. Int. Econ. Rev. 30(1989):655-666.

Färe, R.; Grosskopf, S.; Lovell, C. 1994. Production frontiers. New York, NY: Cambridge University Press.

Farrell, M.J. 1957. The measurement of productive efficiency. J. R. Stat. Soc. Ser. A 120(3):253-290.

Intrilligator, M.D. 1971. Mathematical optimization and economic theory. Englewood Cliffs, NJ: Prentice-Hall.

Johansen, L. 1968. Production functions and the concept of capacity. In: Recent research on the function of production. Namur, France: Namur University Center for Study and Research.

Kirkley, J.; Squires, D. 1999. Capacity and capacity utilization in fishing industries. [Unpubl. manuscr.]. Gloucester Point, VA: Virginia Institute of Marine Science.

Olesen, O.B.; Petersen, N.C. 1996. A presentation of GAMS for DEA. Comput. Oper. Res. 23(4):323-339.


Acronyms

CU = capacity utilization
CRS = constant returns to scale
CSV = comma-separated value
DEA = data envelopment analysis
DMU = decision-making unit
GAMS = General Algebraic Modeling System
NRS = nonincreasing returns to scale
VRS = variable returns to scale

www.nefsc.noaa.gov
NMFS Search
Link Disclaimer
webMASTER
Privacy Policy
(File Modified Jul. 01 2016)

This page has had 6 visits today, 25 visits this week, 74 visits this month, 437 visits this year