Solving equilibrium problems using extended mathematical programming

Abstract

We introduce an extended mathematical programming framework for specifying equilibrium problems and their variational representations, such as generalized Nash equilibrium, multiple optimization problems with equilibrium constraints, and (quasi-) variational inequalities, and computing solutions of them from modeling languages. We define a new set of constructs with which users annotate variables and equations of the model to describe equilibrium and variational problems. Our constructs enable a natural translation of the model from one formulation to another more computationally tractable form without requiring the modeler to supply derivatives. In the context of many independent agents in the equilibrium, we facilitate expression of sophisticated structures such as shared constraints and additional constraints on their solutions. We define shared variables and demonstrate their uses for sparse reformulation, economic equilibrium problems sharing economic states, mixed pricing behavior of agents, and so on. We give some equilibrium and variational examples from the literature and describe how to formulate them using our framework. Experimental results comparing performance of various complementarity formulations for shared variables are provided. Our framework has been implemented and is available within GAMS/EMP.

Appendix

In this Appendix, we present a brief description of our source code and introduce our recently developed alternative EMP interface that allows set notation to be specified in the empinfo file. The former may be useful for interested readers to understand the internal mechanism of our framework, and the latter may provide a concise and compact way of describing agent information.

1.1 Internal mechanism of the EMP equilibrium framework

Basically, our framework performs a model transformation of an EMP model into an MCP model. Key components to implement the transformation are (i) a dictionary, (ii) an EMP parser, and (iii) expression graphs and their derivative computation routines.

The dictionary contains mapping information between variables and equations of a given model and its flattened (or scalar) version. Internally, numeric indices are used to refer to variables and equations, and vector notation (surrounding the name in single quotes) is flattened. In Table 5, we present an example of the mapping information of Listing 5. For clarity, we attached characters x and e for variables and equations. This information can be obtained by specifying Dict option in the option file jams.opt.

Table 5 Mapping of variables and equations between the original model and its flattened model

The EMP parser reads the empinfo file and builds a table of agent ownership information of variables and equations using the numeric indices by referring to the dictionary. The table consists of two arrays of sizes n and m, where they correspond to the sizes of the variables and equations of the flattened model, respectively. Whenever the parser encounters the name of a variable or an equation, it identifies its numeric index using the dictionary and marks the ID of the agent owning it in the corresponding array. Figure 1 shows an example of the agent ownership table of Listing 5. It is assumed that agent ID starts with 1, and its order follows the order of the agents specified in the empinfo file. For shared constraints and shared variables, special agent IDs are stored using which we can identify a list of the agents sharing them.

Finally, using the table, the corresponding MCP function is constructed by computing the KKT conditions of each agent’s problem. This is performed using expression graphs and their derivative computation routines.

Fig. 1

An example of the agent ownership table

Expression graphs represent nonlinear equations of a model. They take the form of a sequence of operations. For example, in GAMS, $(x+y)^3$ is internally represented by a sequence of PushV 1, AddV 2, PushI 3.0, and CallArg2 21, where x and y are assumed to be mapped to numeric indices 1 and 2, respectively. Operands are pushed onto the stack first via PushV or PushI before an operation is performed on them, and its result (if there is any) is pushed back onto the stack. Hence, in this case, operand x is pushed first, and an addition, which also takes its second operand y, is performed on them. The result of the addition and a constant 3.0 are pushed onto the stack, and operation 21, which corresponds to the power, is applied to them. If we take a derivative of $(x+y)^3$ with respect to x, then a new sequence of PushV 1, AddV 2, CallArg1 9, and MulI 3.0 is generated, where operation 9 represents a square $(\cdot )^2$ operation. One can verify that the sequence represents $3(x+y)^2$. Two different expression graphs can be easily added (or subtracted) to form an addition (or a subtraction) of nonlinear equations. Linear equations are handled directly by storing their coefficients, and their derivative computations are straightforward. In this way, we can construct the MCP functions described in this paper.

1.2 An alternative interface allowing set notation in the empinfo file

So far, we have instantiated sets or used vector notation when we specify agent information in the empinfo file. For example, on lines 20–21 in Listing 3 each element of set i was instantiated by using the loop and put statements, and on lines 33 and 35 in Listing 5 vector notation was used to represent the entire elements of x, mkt, and p. The main reason we specify in this way is that the current implementation does not allow a direct specification of sets in the empinfo file.

This could potentially prevent us from taking advantage of using a set notation, such as a compact representation of a set of variables and equations sharing similar structure. For example, in Listing 12 we had to take an additional loop over set k to slice variable q(i,k) among the agents. In the cases where there are a large number of such variables or equations, they may involve many tedious loop and put statements and result in a less concise representation of agents’ problems.

To resolve these issues, we provide an alternative interface, called EMP/Set, which allows sets to be specified in an empinfo file. The EMP/Set interprets a specification of a set as enumerating all of its elements. For example, in the aforementioned case we may put q(i,k) directly in the empinfo file without instantiating each element in set k.

Table 6 shows the contents of the empinfo file obtained by applying the EMP/Set syntax to some representative examples of this paper.¹⁰ Basically, when a set is specified,¹¹ all of its elements are enumerated by our interface. Thus, specifying cons(m) using the EMP/Set syntax is equivalent to writing loop(m, put cons(m););. If a set appears in the objective variable, for example set i in Table 6, then our interface additionally assumes that a set of optimization agents is specified, where each agent is indexed by an element of set i. They are assumed to have the same direction to optimize. This provides a compact way of representing a set of agents that share the same structure. In this case, set i plays a role as a slicing set.

Other than the set specification, the EMP/Set syntax requires a new keyword s.t. (implying subject to) for optimization agents and a separator comma between items (variables and equations). Vector notation is no longer supported as sets can be specified. All other syntactic requirements are the same as the original syntax, for example variables come first and equations follow them in the case of an optimization agent.

Table 6 Application of the EMP/Set syntax to examples in the paper

Below we show how we may use the EMP/Set interface for Listing 3. To write an EMP specification in a file, we use a pair of macros $onecho and $offecho. It writes the lines between them in a file, empinfo.txt in this case. Finally, to parse the file we include the empmodel.gms file using $libinclude macro and pass the file name as its argument.

The EMP/Set interface (empmodel.gms) works on top of the existing interface. For a given file written in the EMP/Set syntax, it will automatically transform the set specifications into equivalent loop and put statements and generate another file empinfo.gms in which an empinfo file is written using the original syntax. Then the resulting file empinfo.gms will be included, and its empinfo specification will be parsed by the GAMS/JAMS solver.

We believe the combination of the simplified EMP/Set interface and the more complex and flexible original syntax will allow users to easily specify simple structures and also build more complex EMP models. The implementations are consistent and can be easily updated to incorporate new features as they are developed.