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
by 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
Print
publication date October 2000;
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.
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:
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
= 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 (
u*,v*)
is also optimal for > 0
(Charnes et al. 1994). This problem is corrected by converting
the ratio form into an equivalent linear programming problem as follows:
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:
where:
= 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 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 =1.0
means that a firm is considered efficient, while a value <1.0
means a firm is inefficient. Thus, a value of =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 (=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:
where:
= 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 =1.0
signifies that the DMU is efficient; a value of >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/[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 =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 =1, and
inefficient if >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):
Inequality constraints are turned into equality constraints by adding
a vector of m slack variables:
The problem is now written as :
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 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:
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 ujm,
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
(=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:
where:
= capacity measure,
ujm = quantity of output
m produced by firm
j,
xjn = quantity of input
n used by firm
j,
n
Fx =
inputs belonging to the set of fixed factors,
nVx = inputs belonging
to the set of variable factors,
jn = 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 ,
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:
Alternatively, to impose nonincreasing returns to scale requires the
following equation to be used:
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
- Information on GAMS can be obtained from the GAMS
website at www.gams.com.
- “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.
- Variables can also be of type negative, binary,
or integer.
- A list of available solvers can be found at the
GAMS website, www.gams.com.
- For a complete list of dollar control operators,
see the GAMS users guide.
- A complete list of model status codes and solve
status codes can be found in the GAMS users guide.
- A complete list of output file types can be found
in the GAMS users guide.
- This result only holds when both models assume
constant returns to scale. Models with variable returns to scale
are discussed in a subsequent section.
- 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.
- 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
