Consistent notation for presenting complex optimization models in technical writing

Surveys in Operations Research and Management Science 21 (2016) 1–17

Contents lists available at ScienceDirect

Surveys in Operations Research and Management Science journal homepage: www.elsevier.com/locate/sorms

Review

Consistent notation for presenting complex optimization models in technical writing Michael D. Teter a , Alexandra M. Newman a,∗ , Martin Weiss b a

Operations Research with Engineering PhD Program, Mechanical Engineering Department, Colorado School of Mines, Golden, CO 80401, United States

b

European Commission - DG JRC, Institute for Energy and Transport, Sustainable Transport Unit, Via Enrico Fermi 2749 - TP 441, I-21010, Ispra, Italy

article

info

Article history: Received 18 June 2015 Received in revised form 16 May 2016 Accepted 16 May 2016

abstract With an increase in computational power, and with recent advances in software, practitioners are formulating ever more complicated optimization models, many of which are drawn from interdisciplinary applications and are designed to reflect the details of real-world systems. While such models have proven useful in providing implementable solutions with a verified impact, they are also more cumbersome to document in a clear and concise manner. In this paper, we recommend: (i) conventions for defining sets, parameters, and variables, (ii) ways of presenting the objective and constraints, and (iii) means by which to organize formulations. While other conventions may be perfectly acceptable, we suggest one set of guidelines for graduate students, academics, and practitioners in need of clearly and easily presenting a large, complex optimization model. Self-study and/or the introduction of these principles into an applied, advanced graduate class can remove ambiguity from model formulations and improve the communication between modelers and their intended audience. © 2016 Elsevier B.V. All rights reserved.

Contents 1. 2. 3.

4. 5. 6. 7. 8.

9.

∗

Introduction and background............................................................................................................................................................................................ Indices and sets .................................................................................................................................................................................................................. Parameters.......................................................................................................................................................................................................................... 3.1. Notation.................................................................................................................................................................................................................. 3.2. Physical units ......................................................................................................................................................................................................... Variables ............................................................................................................................................................................................................................. Objective function .............................................................................................................................................................................................................. Constraints.......................................................................................................................................................................................................................... Extensions for stochastic programs .................................................................................................................................................................................. Additional examples .......................................................................................................................................................................................................... 8.1. Blending.................................................................................................................................................................................................................. 8.2. Aggregate planning................................................................................................................................................................................................ 8.3. Scheduling .............................................................................................................................................................................................................. 8.4. Capital budgeting................................................................................................................................................................................................... 8.5. (Stochastic) facility location.................................................................................................................................................................................. Further advice and conclusions......................................................................................................................................................................................... Acknowledgments ............................................................................................................................................................................................................. References...........................................................................................................................................................................................................................

Corresponding author. E-mail addresses: [email protected] (M.D. Teter), [email protected] (A.M. Newman), [email protected] (M. Weiss).

http://dx.doi.org/10.1016/j.sorms.2016.05.001 1876-7354/© 2016 Elsevier B.V. All rights reserved.

2 3 4 4 5 6 7 7 9 9 9 10 11 12 14 15 16 16

2

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

1. Introduction and background Implementable and implemented, complex applications of optimization have become a reality in the past three decades owing to advances in both hardware and software. Correspondingly, graduate students, academics and novice practitioners can struggle with the way in which to mathematically formulate these optimization models in a consistent and understandable manner. Our intended audience is not the practitioner working with an already-established lexicon. Rather, we seek to suggest possible means to clearly express optimization models for those struggling to do so. In particular, we address graduate students in engineering and applied science and those beginning to work in applied research settings who wish to present their mathematical models in formal and technical writing, e.g., as a technical paper, journal article, or conference presentation. We also target those researchers who have yet to establish a lexicon, in part, because they might have been working with more theoretical models. With this audience in mind, our article is intended for self-study or as reference in graduate-level courses for those unfamiliar with written formulation techniques of complex models. An instructor or primary investigator could direct students or research associates to this writing. Mathematical programming now consists not of wiring ‘‘three patch-boards, which became like masses of spaghetti’’ [1], as it did during the first implementation of the Simplex method (and, at which, Dantzig was ‘‘appalled’’), but of sophisticated hardware and software, including algebraic modeling languages e.g., AMPL [2,3], and solvers, e.g., CPLEX [4], MINLPBB [5], and the toolkit MINOTAUR [6,7]. Optimization models of three decades ago were simple, often expressed as linear programs of the form: minimize cx subject to Ax = b x≥0 or as (mixed) integer programs of the form: minimize cx + dy subject to Ax + By = b x ≥ 0, y binary (or integer) or as nonlinear programs of the form: minimize f(x) subject to g(x) ≤ b h(x) = c where A and B are m × n and m × n′ matrices of left-hand-side constraint coefficients, respectively, c and d are 1 × n and 1 × n′ row vectors of objective function coefficients, respectively, b is an m × 1 column vector of right-hand-side data values for each constraint, and x and y are vectors of continuous and discrete decision variables, respectively, that conform. While we later suggest differentiating parameters and variables in their notational appearance based on the specificity required to express an applied model, note here that classical mathematical programs in their most general form use notation that differentiates a matrix (which is expressed here with a capital letter) and a vector (which is expressed here with a boldface, lower case letter). The functions f(x), g(x), and h(x) represent nonlinear expressions. For methodological development and small models, these forms suffice. However, for large, complex models expressing real-world details such as those found in chemical engineering [8], civil engineering [9], electrical engineering [10], mechanical engineering [11], and mining engineering [12], for example, a reader can become lost in the weeds of notation, the objective function, and the constraints. Authors have emphasized the need to write well technically, and have suggested conventions in this vein, e.g., [13,14], and the references contained therein. Both Gillman [15] and Higham [16] provide handbooks on expressing mathematics, the former author concentrating purely on notation, and the latter including the communication of mathematics through writing a textbook or journal article, or preparing a presentation. Here, we focus specifically on presenting optimization models with the operations research field in mind. Authors have provided technical guidance as to how to appropriately formulate a mathematical model. Brown [17] and Brown and Rosenthal [18] describe good practice in applied optimization modeling, including writing, formulating models, using modeling languages and spreadsheets, and analyzing results. Brown and Dell [19] provide excellent examples of how to formulate a model based on its structure. Newman and Weiss [20] describe some of these papers in more detail, and point to tutorials on optimization modeling and associated algorithms in general. These papers cover the foundations of the mathematics associated with building and implementing optimization models. By contrast, Powell [21] discusses the dialect of dynamic programming and proposes a standard notation for stochastic (dynamic) programming problems. We also focus on the presentation of the mathematics within formal and technical writing, but within a more general framework, not on the accompanying description or the dissemination of a model’s results to a wider audience. We emphasize that our conventions are only suggestions. Thus, our intentions mimic those of Halmos [22], who states that his essay on ‘‘How to write mathematics’’ is subjective, i.e., that it might have been called ‘‘How I write mathematics’’. He emphasizes the importance of good choice of specific mathematical notation as well as the way in which an entire paper should be written. Similarly, our article enables the reader with good mathematical knowledge of his formulation to write it in a cohesive format that is easy to parse and understand. It is the authors’ experience as instructors, research directors (in a lab or university environment), and as journal editors that practitioners will substitute code for a mathematical formulation. We suggest that a formulation, in its entirety, should contain a section on indices and sets, parameters (with units), variables (with units), the objective function, and the constraints, in that order, written with mathematical symbols, as appropriate. The writer should never include modeling language code such as GAMS or AMPL as a substitute for a mathematical formulation unless said code is for internal consumption, e.g., a project group within a research lab. Not only are these modeling languages not universally known among practitioners, but coding constructs can only approximate mathematical notation. Furthermore, poor coding conventions can lead to misinterpretation or errors of translation.

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

3

Table 1 Operator comparisons. Comments are used to make the code more readable, while modulo operators can be used to express constraints recurring, e.g., every week during a month-long horizon. Note that some languages express the same operator multiple ways (not shown) and that even simple operators can be expressed differently in various languages.

In-line comment Modulo operator Power operator Not equal to operator Equal to operator

MATLAB

AMPL

GAMS

R

C++

% mod(x,y) Power(x,y) ∼= ==

# x mod y xˆy

* mod(x,y) x**y

=

=e=

# x%%y xˆy != ==

// x%y pow(x,y) != ==

<>

<>

As an example of how code differs from mathematical notation, let us consider a simple upper bound B placed on a variety of variables xi , where the numerically valued elements i belong to the set I and only the first G instances of xi are subject to this bound. In mathematics, we would write: xi ≤ B,

∀i ∈ I ∋ i ≤ G

In GAMS code, this set of inequalities is written:

CONSTRAINT(i)$(i<=G) x(i) <= B; while in AMPL, the set of inequalities is written:

subject to CONSTRAINT {i in I: i
4

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

is a subset of a larger set nor possesses indices; the latter attribute indicates that this set exists for each element of some different set. For an example of elements within a simple, distinct set, consider: l∈L that might represent the set of locations, e.g., a mill, stockpile or waste dump. If several (different) indices are called out within a set, the author should use related names with decorations, such as ˆl, ˜l and l′ ; this draws an association between indices which belong to the same set. Sets can become more complicated, for example, if they contain a group of elements that form part of a larger set. Such a group is called a subset, for which it may be advisable to choose related notation. For example: T ′ ⊂ T : the set of months within the first year of the time horizon.

There may be a case in which two indices from the same ordered set are necessary; in this case, t and t ′ would be appropriate. In the rare case of three indices, use t, t ′ , and tˆ. Sometimes, the elements of a set depend on the elements of another set. A commonly occurring example in scheduling is a set of predecessor activities, which depends on an activity itself. More concretely, in a model in which we are determining the time at which each activity can start, its start time is contingent upon the completion of various activities that must have been done prior. In this case, each activity a, in a set of activities A, has its own set of predecessors. This construct can be thought of as an indexed set. Like subsets, indexed sets (and indices) should be related in name to the set to which the indices belong. For example: aˆ ∈ Aˆa : the set of predecessor activities for activity a. It is inadvisable to use A to represent the set of activities and Aa to represent the corresponding indexed set. That leaves the reader wondering whether A has a subscript or not. Indices should be associated with an indexed set, not with other indices; avoid placing an index on an index: lt ∈ L. The indexed set itself should be denoted with subscripts, not with parentheses (which can be confused with arguments of functions); use l ∈ Lt , not l ∈ L(t ). Finally, it is important to differentiate between parameters and sets, because these are different types of constructs. For example, if T is a set of time periods, then do not write t = 1, . . . , T . Either define T as a parameter denoting the length of the horizon and write t = 1, . . . , T or, in the absence of defining new notation, write either t ∈ T or t = 1, . . . , |T |. Whether to index over a named set (i.e., t ∈ T ) or over a set of integers (e.g., t = 1, . . . , T ) might depend on whether the writer wishes to use a set of arbitrary members (in which case the former convention can be adopted) or a set of items that are naturally numbered in sequence (in which case the latter convention can be adopted). We now turn to a discussion of parameters. 3. Parameters Parameters, or known quantities, can assume one of the following two forms: (i) raw data, and (ii) derived quantities. In either case, these correspond to known values, and, despite this, formal optimization models omit all numerical values, replacing them instead with general letters that use the same type of naming convention, regardless of whether the data are raw or derived. However, if the distinction between raw and derived data is important, then two separate sections defining each type of notation can be created. Summary statistics of numerical values behind the general letters introduced in a Model section can be presented in a subsection within a Numerical Results section. If it is important to report more than summary statistics on actual numerical values, these should be placed in tables (preferably in an (on-line) appendix, depending on how extensive the data are). 3.1. Notation The author must carefully weigh the emphasis on application only versus mathematical structure within the application. In the former case, if the names of parameters and variables do not appear too unwieldy (i.e., one can express the objective function and each of the constraints in one or two lines), then the descriptive-words naming convention may be appropriate [19]. This enables the reader to obtain a general sense of the formulation without searching for notation definitions. However, it is often more difficult to discern mathematical structure and relate said structure to solution methodologies when words are used in the formulation. For example, one learns linear algebra, on which much of linear programming solution techniques are based, using simple symbols, not words, to express parameters and variables. Without noting a preference for any particular school of thought, we adopt a shortened naming convention, because we assume that many applied research papers place equal weight on the application and the solution methodology, the latter of which depends heavily on the mathematical structure of the problem. In this vein, we suggest that each piece of data should be represented by a single letter, or a letter with subscripts to differentiate the parameter value based on elements of one or more sets. Beale et al. [26] suggest that placing multiple letters together might give the reader the impression that the product of each letter in question is meant. To avoid such confusion and to keep the mathematical expressions as succinct as possible, one might use: Q : the quantity available of an item

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

5

or Qi : the quantity available of item i where i would reside in the set of items I . Alternatively, here and throughout the paper, one might express this as: I : set of available items Qi ∀i ∈ I : the quantity available of item i

where the former suggestion is more concise and enforces consistency, while the latter extends better to more challenging situations, such as to those in which two subscripts are associated with the same set, or in which indexing exists over a subset or union of sets; the latter suggestion also allows the set to be defined more clearly, i.e., without an index, subsequent to which the index is defined directly when used (here, as a subscript on the parameter). Without stating a preference, we adopt the former notation throughout the paper. There is no limit to the number of subscripts which can adorn a parameter, but common sense should prevail. It may be better to split the parameter into multiple stems to forgo a subscript. As an example in which one subscript is omitted (though this process could certainly be repeated to eliminate multiple subscripts):

Qijkmt : the maximum quantity of commodity k ∈ K that can be shipped from location i ∈ I to location j ∈ J via transportation mode m ∈ M on day t ∈ T

might be better expressed, assuming two transportation modes in the set M, i.e., rail and air, as:

r Qijkt : the maximum quantity of commodity k ∈ K that can be shipped via rail from location i ∈ I

to location j ∈ J on day t ∈ T a Qijkt

: the maximum quantity of commodity k ∈ K that can be shipped via air from location i ∈ I to location j ∈ J on day t ∈ T .

In this example, superscripts on the stem of a piece of notation are used to differentiate between characteristics of a parameter, and the set M and the corresponding indices m are eliminated as subscripts. For ease of comprehension, we suggest that these differentiators be phonetic and distinguish themselves from other subscripts already used in the parameter. That is, although we could have phrased the definition as ‘‘shipped via train’’ (instead of ‘‘shipped via rail’’), the r superscript both reflects the transportation mode and avoids confusion between the subscript of time, which a t (for train) superscript might have introduced. One could also use r and a, respectively, as the stem of the parameters, if one had enough letters, but sometimes there is so much notation that it is preferable or even necessary (if one wants to limit oneself to the Roman alphabet) to use a stem for a given family of parameters, and superscripts to differentiate among those parameters in the family. Additionally, the common stem Q relates the two parameters more readily. Putting indices in a superscript can cause those indices to be misinterpreted as parameter differentiators or as exponents, especially if the indices assume numerical values. Decorations over the stem can be used in place of superscripts. For example, one could use Q and Q¯ , for minimum and maximum quantities, respectively. To fully understand how the notation fits into the formulation, each piece should be followed by a definition, in which each subscript (index) should be called out. That is, in the example above, Qi represents ‘‘the quantity available of item i’’, and not simply ‘‘the quantity.’’ One should italicize subscripts and, in general, all notation, within a definition to ensure clear differentiation from the rest of the text. Sometimes, it is tempting to sneak a numerical value into the formulation, rather than adhering to the convention of letters only. For example, if demand D (constant throughout the course of a day) is given in terms of units per hour, but an expression applies to a day, one may write the term: 24 · D (to express demand over a day). However, we recommend defining a parameter that represents the number of hours in a day, e.g., H, and then writing the expression H · D. This allows the formulation to be expressed more generally, and keeps the reader from wondering ‘‘why is 24 the coefficient of D and what is special about that number?’’ 3.2. Physical units Parameters should always be introduced with the corresponding units. This allows the reader to ensure correctness of the model and to understand the way in which a quantity is measured for a particular application; the numerical results should also then be consistent with how the units are given in the formulation. Authors must decide whether to present physical units according to the International System of Units (SI) metrics or according to alternative metrics such as the ones used in the Common Wealth Nations or the United States. Although SI metrics are nowadays the world’s most widely used system of measurement, the appropriateness of the chosen metrics depends on the audience and the data source. For example, the mining industry in the United States often uses feet, gallons, etc., rather than SI units. Whatever the choice, one set of metrics should be used consistently throughout an article.

6

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

Physical units should be spelled out upon first occurrence, e.g., at the end of the definition of each parameter in brackets or parentheses. In doing so, common grammatical rules should be followed, i.e.:

• combining units and their metric prefixes into one word (e.g., kilometer, megawatt); • combining two units with a hyphen or a space (e.g., newton-meter, newton meter), while ensuring consistency of choice throughout the article;

• using lowercase letters even when symbols of units are capitalized (e.g., kelvin, newton, grams); • adding a plural, if required (e.g., kilometers, newtons). For completeness, the writer may want to include (−) following instances for which there are no units, e.g., in the case of a fraction or when data indicate the count of an item. The spelling of SI units can differ between British and American English (e.g., metre and litre versus meter and liter, respectively). One type of English spelling should be used. As a matter of convention, a space is placed between data and their units but not between data and the percentage sign, e.g., 23 MJ but 23% [27]. 4. Variables Variables, i.e., unknown values, should be given with indices and subscripts, as appropriate, in much the same way as parameters. For example:

xijkmt : the number of units sent from location i ∈ I to location j ∈ J of commodity k ∈ K via transportation mode m ∈ M on day t ∈ T

might be better expressed, assuming two transportation modes (rail and air), as:

xrijkt : the number of units sent from location i ∈ I to location j ∈ J of commodity k ∈ K on day t ∈ T via rail xaijkt

: the number of units sent from location i ∈ I to location j ∈ J of commodity k ∈ K on day t ∈ T via air.

Beale et al. [26] suggest that variables be distinguished in appearance from parameters in that the former are represented with lower case letters, while the latter are represented by upper case letters. While this designation is relatively arbitrary, we follow that of Beale et al. here, and, at any rate, we recommend for lengthier formulations that variables be expressed in one case while parameters are expressed in another. In this way, the mathematical structure of the optimization model, e.g., whether the model contains any nonlinearities, is more readily apparent. Variables with similar intent (e.g., flows of a commodity, or power produced) may have the same stem. In a mixed integer program, it is common to call the continuous variables x, and the binaries (or integers) y (or z, or w ). Some conventions interchange x and y. We suggest avoiding the use of variants of x to represent both continuous and binary variables so that the reader can better discern the mathematical structure of the problem at a glance, e.g., ‘‘how many constraints contain only integer variables?’’, ‘‘are there special types of constraints, such as knapsacks or covers, present?’’. A time-dependent variable (or parameter) usually has the index representing time at the end of the list of subscripts to simplify expressing the concept of ‘‘the previous one.’’ That is, xijk,t −1 is easier to parse than, for example, xij,t −1,k . Auxiliary variables are helpful to clarify the presentation of a formulation. One of the most common auxiliary variables is the inventory variable. Writing a production scheduling model using only production variables would be difficult to understand. However, common sense must prevail when using such variables. For example, defining an objective as the sum of three variables, and then writing three equality constraints to express the meaning of said variables could be considered cumbersome at best:

minimize

3 

xi

i =1

subject to x1 = A



yj

j∈J

x2 = B



zk

k∈K

x3 = C

 l∈L

wl .

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

7

In other words, we suggest using auxiliary variables (xi , in this case) if they possess a clear function that makes the presentation of the model more palatable; avoid them when the danger of unnecessary complication presents itself. As with parameters, we recommend specifying the units on variables upon first definition.

5. Objective function With the exception of certain feasibility problems, which arise, for example, in scheduling, an optimization model will contain (at least) one objective function, which is expressed as a functional form involving (some of) the variables, and, in all likelihood, the parameters. Much of what we suggest in this and the subsequent section follows standard optimization constructs, which are explained, e.g., in [3] or in the references contained in [20]. If functional forms are used for the objective or elsewhere in the formulation, we suggest keeping the same arguments, e.g., f (x) and f (q) would be unclear. When combining the variables to form terms in the objective (and in the constraints), always place parameters before variables to adhere to algebraic conventions: Cx

instead of

xC .

It is sometimes conventional to call the objective function z, and to set z equal to the functional form. Unless necessary for the development of the model description, this construct should be avoided, as it uses an additional variable, potentially unnecessarily so. The additional variable provides another good example of where mathematical exposition and code diverge. Specifically, when coding, although the addition of the objective function variable can add both a variable and a constraint, the variable typically gets removed in the presolve stage of a good solver. (Without its removal, the extra variable essentially remains basic throughout the linear programming solves of the optimization routine, and the calculations of the dual variables and reduced costs in the simplex method are essentially equivalent.) Whether the variable is added by necessity of the modeling language syntax or by choice, having the objective expressed with a single variable can be convenient if, for example, the practitioner wishes to over-constrain the objective and induce infeasibility in the model to determine cuts for an integer program; with the extra variable, it is only necessary to do a simple bound change, rather than to add a constraint. Only in rare circumstances, e.g., in certain relaxation and decomposition procedures, does the objective hold for all members of a set. Generally, to ensure mathematical correctness, all indices must be under control via appropriate summations; for example, the expression should read:

maximize

  a∈A aˆ ∈Aˆ

xaaˆ , a

rather than

maximize



xaaˆ

∀a ∈ A.

aˆ ∈Aˆ a

It is important to ensure that summations are placed in the correct order (i.e., indices in simple sets before indexed sets, when elements in the former sets are subscripts on the latter sets) and are not used over expressions in which the indices do not exist.

6. Constraints Constraints can be either equalities or inequalities, and, in an explicit formulation, are expressed as a function of the parameters and variables. For easy reference, all constraints should be numbered consecutively, which can be done automatically in any reasonable word processor. With multiple groups of constraints, one can employ an alpha-numeric numbering scheme, i.e., (1a), (1b), (1c). . . for the first group of constraints, and so on; this relates all constraints in the same group to a given overall constraint number. Nonnegativity and any other simple restrictions on the variables (e.g., integrality) should be placed at the end of the constraint set. Not only is this practice conventional, it allows the reader to see once again at a glance which notation in the problem corresponds to a variable, and what the domain of that variable is. The units on the left- and right-hand sides of the expression must match. In each constraint, all indices must be under control, either via a summation sign or via a ‘‘for all’’ symbol. In most cases, the same indices should be under control on both sides of the expression. For example, if the number of units sent from location i to location j of commodity k on day t via rail must be less than or equal to the maximum quantity of such units sent: r xrijkt ≤ Qijkt

∀i ∈ I , j ∈ J , k ∈ K , t ∈ T

we use the ‘‘for all’’ qualifier on all indices. If, instead, Qˆ ijtr is defined as the maximum quantity (considering all commodities) that can be shipped via rail between location i and location j in time t, then we control the k subscript on the x-variable by summing on it, and qualify

8

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17 Table 2 Constraints should be ordered in a methodical manner, depending on the variables they contain. Ordering of constraints

Variables contained in constraints within the ordering

1 2 3 4 5 6 7 8 9 10

x xˆ x′ Combinations of x, xˆ , and/or x′ y z (x, xˆ , and/or x′ ) and y (x, xˆ , and/or x′ ) and z y and z All variables

the remaining indices with the ‘‘for all’’ sign:



xrijkt ≤ Qˆ ijtr

∀i ∈ I , j ∈ J , t ∈ T .

k∈K

For consistency, the order in which the indices appear as they are qualified should be the order in which they appear as subscripts on the parameters and variables. In general, the order of the indices should be the same on different parameters and variables (even if some indices are omitted on some of the notation). As with a summation construct, indices in simple sets should appear before indexed sets when elements in the former set are subscripts on the latter sets. The suggestion in Section 4 concerning splitting xijkmt into two separate variables, xrijkt and xaijkt , follows from the number of subscripts on the former variables and the fact that there are only two transportation modes, i.e., the cardinality of one of the sets to which one of the indices belongs is relatively small. Consider the opposite case, in which we have relatively few subscripts, yet the cardinality of the sets to which the corresponding indices belong is rather large. If we wish to limit the number of units traveling from location i to location j by rail (r), air (a), barge (b), highway (h), and sea (s) to their respective maximum quantities (note that the subscripts on commodity type and time period have been omitted here): xrij ≤ Qijr ∀i ∈ I , j ∈ J xaij ≤ Qija ∀i ∈ I , j ∈ J xbij ≤ Qijb

∀i ∈ I , j ∈ J

xhij ≤ Qijh ∀i ∈ I , j ∈ J xsij ≤ Qijs ∀i ∈ I , j ∈ J ,

it is more convenient to define a set of modes m ∈ M containing the elements (rail, air, barge, highway, and sea), and write:

xijm ≤ Qijm

∀i ∈ I , j ∈ J , m ∈ M .

If the number of indices becomes too large, to prevent an excessive number of summation signs and/or qualifiers following the ∀ symbol in a constraint, one can create ordered ‘‘tuples’’ of indices and place them in a set. Such a tuple for the above example might appear as follows: ∀ (i, j, m) ∈ K. The match between the index and set names is lost, but the expression is more compact. Such compactness might be especially important if further qualification is necessary, e.g., such that i ̸= j and m > 1. Those exceptions could be defined upfront as part of the exclusions from the set K. Complex, real-world formulations often contain many constraints, which makes it difficult for the reader to obtain a global notion of the formulation at hand. Two guidelines are particularly important in this respect: (i) ensure that constraints containing similar variables appear together; and (ii) create sets to allow for sufficient generalization of similar constraints. We explain both of these recommendations here: Given a formulation with multiple variables, e.g., x, y, z, and w , where one or more of these variables may be decorated (e.g., xˆ , x′ ), and a variable may appear either as the only one in certain constraints, or in a subset of constraints, consider the ordering given in Table 2. Not only does such an ordering help to group similar concepts and makes the formulation easier to explain, but it also reveals mathematical structure more readily. To group the constraints more explicitly, a ‘‘sub-equation’’ environment may be used. Among other formatting characteristics, this environment labels all constraints within ‘‘sub-equation’’ group n as (na), (nb), (nc), . . . , where n is a positive integer. If constraints hold for all elements of a set, they should be expressed using the appropriate constraint qualifier. For each formulation, a name can be placed in parentheses to the left of the objective, e.g., (P ); one can then refer to the problem using this more memorable name rather than referring to an arbitrary range of objective and constraint numbers. Following the presentation of the notation, the objective function and each set of constraints, there should be a section with an English description in papers and reports.

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

9

7. Extensions for stochastic programs Special considerations should be made when documenting a stochastic program. Borrowing the notation from Section 1 in which we introduced the generic linear, integer, and nonlinear optimization models, a two-stage stochastic linear program with recourse can be written: min cx + Eh(x, ξ˜ ) x∈X

where h(x, ξ˜ ) = min ˜fy y≥0

˜ ≥ By ˜ + d˜ , subject to Dy and X = {x : Ax = b, x ≥ 0}. A central notational issue concerns distinguishing deterministic input parameters, denoted A, b, and c in the above model, from input ˜ and ˜f. As shown in the ˜ D, ˜ d, parameters that are stochastic, denoted by the random vector ξ˜ , which consists of random elements from B, model formulation, first-stage decisions, x, reside outside the expected value operator, and second-stage decisions, y, are contained inside the expectation. The former must be made knowing only the probability distribution governing the random vector ξ˜ , and the latter are made knowing a specific realization of ξ˜ . See, for example, discussions in [28–30]. We suggest separating both the parameters and decision variables by whether they are deterministic (first stage) or stochastic (second stage) when presenting the formulation. Note that one way ˜ With ω ∈ Ω of differentiating deterministic and stochastic parameters is by use of a ‘‘∼’’ on the latter, as we have shown, e.g., with ξ˜ and d. ω ˜ representing a sample point in the sample space of ξ , a realization of the random parameters is denoted, for example, by ξ and dω . There is a second-stage decision vector for each such realization, and so we similarly write yω . Two-stage models, like the one we sketch above, are perhaps the most pervasively used stochastic programs, but this recourse model extends to allow for multiple stages. Other models satisfy constraints with a prespecified probability, employ notions of stochastic dominance, and incorporate measures of risk (see, e.g., [31,32]). The notation that we present here translates well to these types of models. In the following section, we illustrate a stochastic program using the extended notation (including subscripts).

8. Additional examples In the previous sections of this paper, we introduce reasonable and helpful conventions for writing clear mathematical formulations, and illustrate them with specific examples highlighting the concept in question. However, the goal of our paper is to present guidelines for entire formulations, not simply segments thereof. In this section, we therefore present unclear and reformulated optimization examples that arise in a variety of applications (i.e., blending, aggregate planning, scheduling, capital budgeting, and facility location).

8.1. Blending

Indices and Sets:

• o: oil type • T : set of oil types Parameters:

• do : amount of attribute contained in each oil type o = 1, . . . , 5 • M: maximum amount of attribute in the oil blend Variables:

• xo : amount of oil type o to include in the blend Constraint:

 o∈T

d o · xo ≤ M ·



xo

o∈T

This example suffers from the following notational difficulties:

• • • • •

The use of o as a symbol (in this case, as an index), which can easily be confused with zero. Indices that do not appear notationally connected with their corresponding sets. Indices redundantly specified by number and as elements of a set. Lack of a phonetic and consistent naming system for parameters in terms of case and letters. Lack of units.

10

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

We can rewrite the example as follows: Indices and Sets:

• t ∈ T : set of oil types t Parameters:

• At : amount of attribute contained in each oil type t (ounces/gallon) ¯ maximum amount of attribute in the oil blend (ounces/gallon) • A: Variables:

• xt : amount of oil type t to include in the blend (gallon) Constraint:



At · xt ≤ A¯ ·



xt

t ∈T

t ∈T

Note that blending examples can also be nonlinear. For example, blending can be a polynomial function of the decision variables [33]. In this case, the index, set, and variables would remain the same, but the parameters would differentiate themselves by order of the blending term, i.e., Ait would represent the contribution of the attribute in the ith order term for oil type t, and the constraint would be expressed as [34]: subject to

   3 2 t ∈T A1t · xt t ∈T A3t · (xt ) t ∈T A2t · (xt )    + ≤ A¯ + ( t ∈T xt )2 ( t ∈T xt )3 t ∈T xt

8.2. Aggregate planning Suppose that a mine produces metal, and can also store it in inventory, to meet a known demand during each time period over the planning horizon. Production in each time period is capacitated, and each worker produces at the same rate. Both inventory costs and penalties for labor fluctuations from one time period to the next are assessed. A corresponding aggregate planning model might appear as follows: Indices and Sets:

• k: time periods Parameters:

• • • • •

p: maximum amount a worker can produce in any time period b: maximum production in any given time period c: cost to discourage inter-temporal workforce fluctuations, proportional to the square of the change ($ per worker2 ) h: inventory holding cost ($/ton-time period) dk : demand in time period k (tons)

Variables:

• Lk : number of people employed in time period k • J k : inventory at the end of time period k (tons) • uk : change in the labor force from time period k − 1 to time period k Objective and Constraints: minimize



c · (uk )2 + h · J k



k∈K

subject to Lk = Lk−1 + uk J k = J k−1 + p · Lk−1 − dk Lk ≤ b/p Lk , J k ≥ 0

∀k ∀k ∀k ∀k

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

11

This example suffers from the following notational difficulties:

• • • • • • • •

The set K is not defined. (It does not suffice simply to define the index corresponding to the set.) A standard index for time is t. Units are not always given. The parameter b is not particularly phonetic. A standard symbol to represent inventory is I. The use of the auxiliary variable uk is not necessary. If it is used, it could be capitalized to match the cases of the other variables. The index k is used both as a superscript and as a subscript. No convention is adopted for the initial conditions. We can rewrite the example as follows:

Indices and Sets:

• t ∈ T : set of time periods Parameters:

• • • • •

p: maximum amount a worker can produce in any time period (tons/worker) p¯ : maximum production in any given time period (tons) c: cost to discourage inter-temporal workforce fluctuations, proportional to the square of the change ($ per worker2 ) h: inventory holding cost ($/ton-time period) dt : demand in time period t (tons)

Variables:

• Lt : number of people employed in time period t (workers) [Let L0 = 0] • It : inventory at the end of time period t (tons) [Let I0 = 0]

Objective and Constraints: minimize



c · (Lt − Lt −1 )2 + h · It



t ∈T

subject to It = It −1 + p · Lt − dt Lt ≤ p¯ /p Lt , It ≥ 0

∀t ∈ T ∀t ∈ T ∀t ∈ T

8.3. Scheduling Although it is common to use binary decision variables in scheduling models, we first present a linear program that could be used to schedule three-dimensional, notional blocks containing ore and waste, for extraction from a multi-level, open pit mine, over a fixed time horizon:

Indices and Sets:

• b ∈ B: set of three-dimensional blocks, i.e., candidates for extraction • c ∈ Cb : predecessor blocks c for block b • t ∈ T : set of time periods Parameters:

• Tb : tonnage contained in block b ¯ maximum amount that can be extracted in any given time period (tons) • M: Variables:

• xbt : fraction of block b to extract in time period t

12

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

Constraints:



xbt ≤ 1 ∀b ∈ B

t ∈T

xbt ≤



xcu

∀ b ∈ B , t ∈ T , c ∈ Cb

u∈T :u≤t



¯ Tb · xbt ≤ M

∀t ∈ T

b∈B

where, because we assume continuity of the variables in this case, we enforce precedence in relative proportions. This example suffers from several notational difficulties:

• The use of dissimilar names for similar constructs, e.g., blocks and their predecessors; tonnage in a block and maximum tonnage extractable in a time period.

• The use of similar names for different constructs, e.g., time and tonnage. • The interspersion of a constraint qualifier on time between two that address blocks. We can rewrite the example as follows: Indices and Sets:

• b ∈ B: set of three-dimensional blocks, i.e., candidates for extraction • b′ ∈ Bˆb : predecessor blocks b′ for block b • t ∈ T : set of time periods Parameters:

• Mb : amount of material contained in block b (tons) ¯ maximum amount that can be extracted in any given time period (tons) • M: Variables:

• xbt : fraction of block b to extract in time period t

Constraints:



xbt ≤ 1 ∀b ∈ B

t ∈T

xbt ≤



∀b ∈ B, b′ ∈ Bˆb , t ∈ T

xb′ t ′

t ′ ∈T :t ′ ≤t



¯ Mb · xbt ≤ M

∀t ∈ T

b∈B

Note that many scheduling models possess integer variables. For example, the decision variables could have been defined as 1 if we extract block b by time period t, and 0 otherwise. In this case, the index, set, and parameter definitions would remain the same, but the precedence constraint could be expressed as: subject to xbt ≤ xb′ t

∀b ∈ B, b′ ∈ Bˆb , t ∈ T

where now we cannot extract block b until each of its predecessors b′ has been extracted. (The amount of material contained in each block could be used in a different constraint, e.g., blending.) As an alternative, should the construct b′ ∈ Bˆb appear to the writer to contain a profusion of b’s, notation such as p ∈ Pˆ b could be used with the caveat that although, in this case, p is a predecessor block, it is also a block b in and of itself. 8.4. Capital budgeting The following is an example representing a mathematical model created within GAMS and then documented for collaboration amongst colleagues.

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

13

Indices and Sets:

• • • •

s: system fy: fiscal year y: year c: criterion

Parameters:

• • • • •

costs,y : cost for each system s in its program year y scores,c : the average score for each system s and criterion c risks : the associated risk with each system s times : lifetime of system s budgetfy : budget in fiscal year fy

Variables:

• costupfy : the amount by which the budget is exceeded in fiscal year fy • counts,fy : 1 if we include system s in the solution in fiscal year fy, 0 otherwise

Objective and Constraints: EQUATIONS Obj..

Maximize Z = [



[scores,′ effect ′ + scores,′ power ′ + scores,′ speed′ ] · counts,fy /times ] +

 (1 − risks ) · counts,fy s,fy

s,fy|intheset (s)

TotalCost..

 [costs,y · (counts,fy−y+1 − counts,fy−y )] ≤ budgetfy + costupfy

∀fy

s ,y

A misunderstanding associated with writing code rather than math involves the representation of the objective function with an equation such as Z = · · · , when the objective is really a function (that differentiates itself from constraints, for example, that can be equations). Another difficulty with this style of presentation is the confusion of syntax such as fy|intheset(s). The subscript fy could be interpreted as f · y, as a subscript with two letters fy, or as two separate subscripts f , y. Similar confusion arises with the subscript(s) fy − y + 1 in that the constraint appears to contain an error whereby the subscript y is being summed over on the left-hand side, while the constraint itself holds for all instances of the subscript y itself. Writing in this ‘‘code’’ style does not ‘‘keep the reader in mind’’ [22], nor does it allow for clear, written communication to more general audiences, e.g., the readers of a journal article, or the listeners in a conference talk or seminar. One possible interpretation of the above formulation is that fy and y are different subscript names, which we shall rewrite as y′ and y, respectively. We can assign sets S , C , and Yˆ to contain the sets of systems, criteria and years, respectively. The expression intheset(s) denotes the set of years in which it is possible to procure system s, which we will rewrite as Ys . Then, we can express the above formulation in the following more readable format:

max





scoresc ·

s∈S ,c ∈C ,y′ ∈Ys

subject to

  

countsy′  times

+



(1 − risks ) · countsy′

s∈S ,y′ ∈Ys



costsy · (counts,y′ −y+1 − counts,y′ −y ) ≤ budgety′ + costupy′

∀y′ ∈ Ys

s∈S y∈Yˆ :y
Additionally, the user may want to add a penalty to the objective for exceeding the budget; such a penalty was absent from the original model, perhaps owing to poor parameter and variable definitions (not shown here), and lack of units (still absent—but could be thought of as ‘‘utils’’ in the objective, normalized across time for ‘‘score’’ but not for ‘‘risk,’’ and dollars in the constraints).

14

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

8.5. (Stochastic) facility location Consider a deterministic facility location problem (e.g., [35]) in which we determine both the facilities to open and whether or not to serve a customer from a given facility to minimize total distance incurred from serving all the customers, subject to a cardinality constraint on the number of open facilities,and aconstraint that all customers be served by exactly one facility. (Here, the ‘‘distance’’ parameter, dij , can combine the demand of customer j with the distance from j to i so that dij would possess units of the product of demand and the actual distance traveled.) Such a formulation would appear as follows:

Indices and Sets: i∈I j∈J

candidate facility locations customers

Data: distance from customer j to facility i (km) budget in terms of total number of facilities

dij k

Variables: xi yij

1 if location i is selected; 0 otherwise 1 if customer j’s demand is served by facility at location i; 0 otherwise

Formulation:



min x, y

dij yij

j∈J i∈I



s.t.

xi ≤ k

i∈I

xi ≥ yij  yij = 1

i ∈ I, j ∈ J j∈J

i∈I

xi ∈ {0, 1}

i∈I

yij ∈ {0, 1}

i ∈ I, j ∈ J

Note that we have already employed good formulation practice, by, for example:

• Using standard notation such as i for a facility index and j for a customer index. • Relating an index with a lower-case letter to a set with the corresponding upper-case letter. • Being consistent with the use of subscripts to represent indices. This formulation extends to a two-stage stochastic programming model in which the facilities are located in the first stage, and the decisions of which customers to serve via which facilities are made in the second stage, after observing the random distance from customer j to facility i (see, e.g., [36]). Here, we use dω ij to denote a realization of the random distance from j to i, where again this distance can incorporate demand. Index ω ∈ Ω is over the sample space (the set of scenarios), and the vector dω occurs with probability φ ω . Adhering to the suggestions presented in Section 7, we suggest the following notation and corresponding formulation:

Indices and Sets: i∈I j∈J

ω∈Ω

candidate facility locations customers sample space of scenarios

Data: dω ij

φω k

random distance from customer j to facility at i under scenario ω (km) probability of scenario ω budget in terms of total number of facilities

Variables: xi yω ij

1 if location i is selected; 0 otherwise 1 if customer j’s demand is served by facility at location i under scenario ω; 0 otherwise

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

15

Formulation: min x, y

s.t.

 

φ ω dωij yωij

ω∈Ω j∈J i∈I



xi ≤ k

i∈I

xi ≥ yω ij  ω yij = 1

i ∈ I, j ∈ J , ω ∈ Ω j ∈ J,ω ∈ Ω

i∈I

xi ∈ {0, 1}

i ∈ I,

yij ∈ {0, 1}

i ∈ I, j ∈ J , ω ∈ Ω

ω

Note that, in a stochastic program, we prefer to use a superscript index for scenarios, to distinguish this index from others. First-stage variables, xi , are not indexed by ω because their values must be determined before observing the random demand. Second-stage variables, yω ij , are indexed by ω because they differ by scenario in that customers are assigned to facilities after realizing their random demands. 9. Further advice and conclusions Well read and well cited textbooks adopt a convention and adhere to it. Ahuja et al. [37] use cij , lij and uij as costs, lower and upper bounds, respectively, on arc (i, j). The variable xij denotes the corresponding arc flow. Bertsimas and Tsitsiklis [38] use bold letters for vectors and matrices and unbold for singletons; they employ the standard form we give in the introductory section of this paper, thereby, inter alia, providing an excellent description of Dantzig–Wolfe decomposition. Wolsey [39] and Martin [40] adopt many of the same conventions as the former authors, making the two texts rather complimentary. The latter author uses standard notation in his formulations, e.g., ct as the marginal production cost in time t, ht as the holding cost in time t, and It as the amount of inventory held at (the end of) time t. Brown and Dell [19] note that ‘‘Sadly, our literature still publishes many articles that feature astonishingly muddled formulations.’’ By contrast, writers who follow a structure such as the one we set forth here learn to separate sets from data from variables, to include units where appropriate, to present the objective function and constraints in an understandable and mathematically correct manner, and to accomplish all of this while using clear notation. This is particularly important for students who have never been introduced to optimization modeling before or who, like one of the authors of this paper, had more than a decade-long separation between his undergraduate and graduate studies, which can be common both for military students and for those civilians who, recognizing that ‘‘their company could definitely do things better!’’, return mid-career to pursue an advanced degree. Following notational guidelines such as these has resulted in the authors’ and associated students’ involvement in many applications that have been both successfully implemented and published in outlets such as Interfaces. Because optimization models are growing in complexity, thereby presenting a challenge with respect to their conveyance, we recommend guidelines for consistent optimization model formulation to help practitioners more effectively document their work. In summary, our suggestions are:

• A formulation, in its entirety, contains a section on indices and sets, parameters (with units), variables (with units), the objective function, and the constraints, in that order.

• The mathematical description is written in math, with mathematical symbols, as appropriate, and not in a modeling language. • In order to differentiate sets from other constructs that occur within the same formulation, a symbolic convention, e.g., capital script letters, is used. To relate the element to the set, a corresponding lower case letter is employed.

• Indices are associated with an indexed set, not with other indices as subscripts. • If the emphasis is on application only, longer expressions might be used to name parameters and variables; if the emphasis is on the mathematical structure within the application, shorter expressions should be used.

• There is no limit to the number of subscripts which can adorn a parameter, but common sense should prevail. • Placing indices as superscripts can cause those indices to be misinterpreted as parameter differentiators or as exponents, especially if • • • • • • • • • •

the indices assume numerical values. Decorations can also be used in place of superscripts. One should italicize subscripts and, in general, all notation, within a definition to ensure clear differentiation from the rest of the text. Parameters and variables must have corresponding units when they are introduced. Variables, i.e., unknown values, should be given with indices and subscripts, as appropriate, in much the same way as parameters. In lengthier formulations, variables are expressed in one case while parameters are expressed in another. Variants of x do not represent both continuous and binary variables; in this way, the reader can better discern the mathematical structure of the problem at a glance. Auxiliary variables can possess a clear function that makes the presentation of the model more palatable but are not used when the danger of unnecessary complication presents itself. Arguments of functional forms used for the objective or elsewhere in the formulation should remain the same. Summations are placed in the correct order. All constraints are numbered consecutively. The order in which the indices appear as they are qualified is the order in which they appear as subscripts on the parameters and variables.

16

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17

• The order of the indices is the same on different parameters and variables. • Constraints containing similar variables appear together, and sets allow for sufficient generalization of similar constraints. • In a stochastic program, parameters and decision variables are separated based on whether they are deterministic (first stage) or stochastic (second stage). Good exposition can enhance readability and understanding of such a formulation, e.g., in a research paper, in an oral presentation, or in an internal document. Complementing the material from the previous sections, we advise the following:

• Ensure that parentheses (, {, [ match, and that they are used and closed appropriately; do not overuse them. For example, (Cx) is not necessary, and clutters the formulation, while (C − C ′ )x is necessary. • If letters outside of the Roman alphabet are required, Greek is acceptable. Avoid using letters to represent parameters and/or variables •

• •

•

•

from an alphabet unfamiliar to English speakers, e.g., Cyrillic, Chinese, or Wingdings. Otherwise, it is difficult for a reader or presenter to articulate what he has written, and equally difficult for an audience to understand it. Refrain from using reserved words or notation that can be confused with other common, significant characters, e.g., avoid the use of o, O, e, π or any combination of characters that resembles sin, other trigonometric functions, arg, min, max, etc. (unless you are using them in the context of their reserved meaning). Make sure there are no inter-model inconsistencies, such as using the same (or nearly the same) parameter name for more than one construct, when presenting two or more formulations in the same paper. Employ standard letters that sound like the word being defined, and be consistent throughout a relevant series of research papers (either your own or follow-on work from others). For example, d is often used to represent demand, I inventory, t and T time, and r discount rate. The letters x and y normally correspond to variables, while a, b, and c (or A, B, and C ) often represent parameters. It is important to maintain uniformity of standard constructs, e.g., the Lagrangian multiplier being displayed as a bold vector, λ. Familiar notation enables a reader or listener to more easily comprehend and internalize complex formulations. Use industry-standard notation to the extent possible and appropriate when writing an interdisciplinary formulation. For example, ϵ is often used for strain in structural engineering. This establishes credibility with those in the area of application who may not be familiar or comfortable with optimization models. Avoid using commas to separate multiple subscripts unless there is an arithmetic operation performed on the subscript, e.g., use xijt or xij,t −1 versus xi,j,t or xi,j,t −1 ; commas tend to clutter the subscripts, especially when several of them exist.

Evidence supporting the necessity of following suggestions, such as the ones we propose, is demonstrated through the examples in Section 8. There are also professional requirements to writing technically proficient papers as operations research practitioners. For example, United States Government criteria require competence in these areas [41]; the expectations of the abilities of US Army officers in the Operations Research career field [42] are similar. The US government’s desire to further applied mathematical programming prowess, among other operations research areas, is demonstrated through large, analytical organizations forming ‘‘Communities of Best Practice.’’ These organizations have identified a shortfall exhibited in the capabilities of analytical professionals, in part caused by an assumption that all operations research practitioners are well versed as to how to express themselves. While academic journals do not generally publish a standard lexicon, samples such as ‘‘Style-Instructions.pdf’’ posted on the Operations Research journal website issue suggestions for authors seeking to publish in INFORMS journals. We suggest here little by way of hard-andfast rules; but, we hope that our standards will be accepted and used, as appropriate, in the academic literature and in other applied research arenas. Acknowledgments The authors would like to thank Dr. Ed Klotz (IBM ILOG CPLEX development team, Incline Village, NV), Emeritus Professor Kevin Wood (Operations Research Department, Naval Postgraduate School, Monterey, CA), and several referees for their helpful comments on earlier drafts of the paper. The authors acknowledge the assistance of Professor David Morton of Northwestern University in the construction of the stochastic programming material. The views expressed here are those of the authors and may not be considered as an official position of either the United States Government or of the European Commission. References [1] R.E. Bixby, A brief history of linear and mixed-integer programming, in: M. Grötschel (Ed), Documenta Mathematica—Optimization Stories, Berlin, Germany, 21st International Symposium on Mathematical Programming, Journal der Deutschen Mathematiker-Vereinigung, 2012, pp. 107–12. [2] AMPL, AMPL—A Mathematical Programming Language, AMPL Optimization LLC, Albuquerque, NM, 2009. [3] R. Fourer, D. Gay, B. Kernighan, AMPL—A Modelling Language for Mathematical Programming, Thomson Brooks/Cole, Pacific Grove, CA, 2003. [4] IBM. ILOG CPLEX. IBM—International Business Machines Corporation, Incline Village, NV, 2009. [5] S. Leyffer, User manual for MINLP-BB, 1998. University of Dundee. [6] A. Mahajan, S. Leyffer, C. Kirches, Solving mixed-integer nonlinear programs by QP-diving. Preprint ANL/MCS-2071-0312, Argonne National Laboratory, Mathematics and Computer Science Division, 2012. [7] A. Mahajan, S. Leyffer, J. Linderoth, J. Luedtke, T. Munson, MINOTAUR: a toolkit for solving mixed-integer nonlinear optimization. Wiki-page, 2011. http://wiki.mcs.anl.gov/minotaur. [8] P. Flisberg, M. Rönnqvist, S. Nilsson, Billerud optimizes its bleaching process using online optimization, Interfaces 39 (2) (2009) 119–132. [9] A. Guerra, A. Newman, S. Leyffer, Concrete structure design using mixed-integer nonlinear programming with complementarity constraints, SIAM J. Optim. 21 (3) (2011) 833–863. [10] S. Frank, I. Steponavice, S. Rebennack, Optimal power flow: A bibliographic survey I—formulations and deterministic methods, Energy Syst. 3 (3) (2012) 221–258. [11] K. Pruitt, S. Leyffer, A. Newman, R. Braun, A mixed-integer nonlinear program for the optimal design and dispatch of distributed generation systems, Optim. Eng. 15 (1) (2014) 167–197. [12] M.A. Martinez, A.M. Newman, A solution approach for optimizing long- and short-term production scheduling at LKAB’s Kiruna mine, European J. Oper. Res. 211 (1) (2011) 184–197. [13] G.D. Gopen, J.A. Swan, The science of scientific writing, Am. Sci. (1990) http://www.americanscientist.org/issues/pub/the-science-of-scientific-writing/2. [14] M. Weiss, A. Newman, A guide to writing articles in energy science, Appl. Energy 88 (11) (2011) 3941–3948. [15] L. Gillman, Writing Mathematics Well: A Manual for Authors, Mathematical Association of America, Washington, DC, 1987. [16] N.J. Higham, Handbook of Writing for the Mathematical Sciences, SIAM, Philadelphia, PA, 1998.

M.D. Teter et al. / Surveys in Operations Research and Management Science 21 (2016) 1–17 [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42]

17

G.G. Brown, Top ten secrets to success with optimization, Phalanx 37 (4) (2004) 12 ff. G.G. Brown, R.E. Rosenthal, Optimization tradecraft: Hard-won insights from real-world decision support, Interfaces 38 (5) (2008) 356–366. G.G. Brown, R.F. Dell, Formulating integer linear programs: A rogues’ gallery, Informs Trans. Ed. 7 (2) (2007) 153–159. A. Newman, M. Weiss, A survey of linear and mixed integer optimization tutorials, INFORMS Trans. Ed. 14 (1) (2013) 26–38. W.B. Powell, Approximate Dynamic Programming: Solving the Curses of Dimensionality, Volume 703, John Wiley & Sons, 2007. P.R. Halmos, How to write mathematics, Enseign. Math. 16 (2) (1970) 123–152. A.BG. Armacost, personal communication, August 2013. C. Ragsdale, Spreadsheet Modeling and Decision Analysis: A Practical Introduction to Business Analytics, Cengage Learning, 2014. S.G. Powell, K.R. Baker, Management Science: The Art of Modeling with Spreadsheets, John Wiley & Sons, Hoboken, NJ, 2013. E. Beale, G. Beare, P. Tatham, The DOAE reinforcement and redeployment study: A case study in mathematical programming, in: P. Hammer, G. Zoutendijk (Eds.), Mathematical Programming Theory and Practice: Proceedings of the NATO Advanced Study Institute, Elsevier, Figueira da Foz, Portugal, 1974, pp. 417–442. NIST. International system of units (si) @ONLINE, 2008. URL http://physics.nist.gov/Pubs/SP330/sp330.pdf. A. Shapiro, D. Dentcheva, A. Ruszczynski, Lectures on Stochastic Programming: Modeling and Theory, Volume 16, Society for Industrial and Applied Mathematics and the Mathematical Programming Society, Philadelphia, PA, 2014. D.P. Morton, R.K. Wood, Restricted-recourse bounds for stochastic linear programming, Oper. Res. 47 (6) (1999) 943–956. J. Birge, F. Louveaux, Introduction to Stochastic Programming, Springer, New York, NY, 2011. R.T. Rockafellar, S. Uryasev, Optimization of conditional value-at-risk, J. Risk 2 (3) (2000) 21–42. D. Dentcheva, A. Ruszczynski, Optimization with stochastic dominance constraints, SIAM J. Optim. 14 (2) (2003) 548–566. M. Rusin, The structure of nonlinear blending models, Chem. Eng. Sci. 30 (8) (1975) 937–944. R. Rardin, Optimization in Operations Research, Prentice Hall, Upper Saddle River, NJ, 1998. S. Owen, M. Daskin, Strategic facility location: A review, European J. Oper. Res. 111 (3) (1998) 423–447. A. Koç, D. Morton, Prioritization via stochastic optimization, Manage. Sci. 61 (3) (2015) 586–603. R. Ahuja, T. Magnanti, J. Orlin, Network Flows: Theory, Algorithms, and Applications, Prentice Hall, Englewood Cliffs, NJ, 1993. D. Bertsimas, J. Tsitsiklis, Introduction to Linear Optimization, Athena Scientific, Belmont, MA, 1997. L. Wolsey, Integer Programming, John Wiley & Sons, New York, NY, 1998. K. Martin, Large Scale Linear and Integer Optimization: A Unified Approach, Kluwer Academic Publishers, Boston, MA, 1999. Army Modeling and Simulation Office. Competencies for job series 1515: Operations research analysts, 2014. URL http://www.ms.army.mil/sp-div/cp36-compORSA.html. Headquarters, Department of the Army. DA Pamphlet, 600–3 Commissioned Officer Professional Development and Career Management. Washington, DC, DEC 2014.