e-companion ONLY AVAILABLE IN ELECTRONIC FORM

Transcription

1 OPERATIONS RESEARCH doi /opre ec e-companion ONLY AVAILABLE IN ELECTRONIC FORM informs 2010 INFORMS Electronic Companion Optimization Services: A Framework for Distributed Optimization by Robert Fourer, Jun Ma, and Kipp Martin, Operations Research, doi /opre

2 Optimization Services: A Framework for Distributed Optimization Online Supplement Robert Fourer, Jun Ma Department of Industrial Engineering and Management Sciences, Northwestern University, Evanston, Illinois 60208, USA, {4er@iems.northwestern.edu, maj@iems.northwestern.edu} Kipp Martin Graduate School of Business,University of Chicago, 5807 South Woodlawn Avenue, Chicago, Illinois 60637, USA, kmartin@chicagobooth.edu 1. Introduction This is meant to be an online supplement to the paper, Optimization Services: A Framework for Distributed Optimization by Fourer, Ma, and Martin. This supplement contains expanded coverage of how to represent an optimization instance using OSiL plus a detailed example of how to call an Optimization Services (OS) solver over the network. 2. Optimization Services Instance Language To complete the specification of a linear problem (possibly with integer variables), the OSiL schema incorporates the complextype LinearConstraintCoefficients, that defines a <linearconstraintcoefficients> section that contains the nonzero coefficients in the constraints. The coefficients are described by use of a standard three-array sparse matrix storage scheme: an array of nonzero coefficients in a child element <value>, a corresponding array of row indices or column indices in a child element <rowidx> or <colidx>, and in a child element <start> an array that indicates where each row or column begins within the previous two arrays. There are other ways of specifying a constraint coefficient matrix, and we considered designing OSiL to offer a choice of alternatives. In the end we chose to include only the three-array scheme, because it is simple, compact, and easily converted to and from other schemes by auxiliary software. Linear constraints have the general form lb-const linear-expr ub-const, allowing for the special cases lb-const =, ub-const = +, and lb-const = ub-const (an equality 1

3 constraint). The lb-const and ub-const values that aren t infinite are naturally stored in OSiL s <constraints> section. Finally, a decision must be made about the handling of the linear objective coefficients. One or more objectives may be included with the constraints, identified by lb-const and ub-const values that are both infinite. This design is attractive for its simplicity; but the objective coefficients are potentially scattered among the constraint coefficients, and are hard to extract for the purposes of some solvers. Instead, OSiL places the nonzero objective coefficients in the separate <objectives> section. This approach has the further advantage of generalizing cleanly to the nonlinear case. Optimization problems may incorporate expressions that are not linear and a true standard must accommodate these as well. A natural way to represent general expressions in XML is to define an element for each operator or function, with child elements specifying the operands or arguments. Each child may itself be an element for an operator or function, so that the entire graph of the expression is defined recursively in a natural way. As an example, Figure 1 shows the OSiL representation of the term ln(x 0 x 1 ) that appears in Equation (3). These representations are placed in a <nonlinearexpressions> section of the OSiL file, that is defined by a NonlinearExpressions complextype in the OSiL schema. <ln> <times> <variable idx="0"/> <variable idx="1"/> </times> </ln> Figure 1: The OSiL representation of ln(x 0 x 1 ). One of the greatest challenges of our project was to figure out how to define this schema, to permit efficient parsing of the many elements representing operators and functions that can reasonably be considered fundamental to optimization problems. There are over 200 such elements, as shown in Figure 2. In addition to the usual smooth nonlinear functions such as log and cosine, there are comparison and logical operators, statistical functions and distributions, and common spreadsheet operators. The key to writing an efficient schema to encompass all of the potential elements of an expression is to first define a general complextype OSnLNode, and an abstract element of that type, also named OSnLNode, as shown in Figure 3. Then each element corresponding to 2

4 a different node of the expression graph is defined by a complextype that extends OSnLNode and by an element of that complextype. Figure 4 shows as an example the definition of the element <times> from Figure 1, via the complextype <OSnLNodeTimes>. The line <xs:sequence minoccurs="2" maxoccurs="2"> specifies that the element has exactly two children, corresponding to the two operands of any multiplication operator. This arrangement analogous to the use of virtual classes in object-oriented programming languages permits a parser to validate an OSiL file against the schema without a complex conditional or switch statement to find each element among the many possibilities. A detailed explanation of the schema and parser issues is beyond the scope of this paper, but can be found in Fourer, Ma, and Martin (2007). Linear expressions are a special case of nonlinear ones, and so in principle OSiL requires no special features for linear objectives and constraints. It makes sense to handle the linear case specially, however, because there is a particularly efficient way to write linear expressions (in terms of coefficient lists) and because there are many optimization algorithm prepared to take advantage of this efficiency. We considered other cases that could be handled specially, but in the end decided that only quadratic expressions merited special handling in OSiL, because they can also be viewed in a simple way as coefficient lists, and are the target of several specialized algorithms that are widely implemented. OSiL represents each quadratic term by four values in a <quadraticcoefficients> section: an identifying number for the Category Examples Number in Category Arithmetic Plus, Sum, Power 10 Elementary Log, Factorial, Round 22 Trigonometric Cos, Arccos, Cosh 24 Statistics Mean, Percentile, Npv 30 Probability BetaDist, GammaCum, NormalInv 92 Boolean Leq, Or, InSet, AllDiff 26 Variable Variable, RandomVariable 5 Terminal Number, String, Identifier 3 Constant PI, INF, TRUE, NAN 8 Other Quadratic, XPath, Complements 12 Figure 2: Number of element types in OSiL s general expression graphs. 3

5 <xs:complextype name="osnlnode" mixed="false"> </xs:complextype> <xs:element name="osnlnode" type="osnlnode" abstract="true"> </xs:element> Figure 3: Definition of a generic expression-graph node is OSiL. <xs:complextype name="osnlnodetimes"> <xs:complexcontent> <xs:extension base="osnlnode"> <xs:sequence minoccurs="2" maxoccurs="2"> <xs:element ref="osnlnode"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:element name="times" type="osnlnodetimes" substitutiongroup="osnlnode"> </xs:element> Figure 4: Definition of the <times> element in OSiL. objective or constraint in which it lies, indices of its two variables, and a coefficient. An example is given in Fourer, Ma, and Martin (2007). 3. Calling an Optimization Solver The goal of our research is to provide a framework for making optimization a service. The purpose of the COIN-OR OS project is to provide a reference implementation of the framework. Here we illustrate how the reference implementation of the framework is used to solve an optimization model in a distributed environment. In this illustration the client machine has a problem instance rosenbrockmod.osil (see Equations (1)-(4) in the main paper) that is sent to the server for optimization. In each of the steps below the OSSolverService client reads a configure file at the command line and implements the options in the configure file. The reader may wish to refer back to Figure 18 in the main paper while reading the material in this appendix. Step 1: Use the OSSolverService method getjobid() method to get a job ID. In this step, and each of the steps that follow, a configuration file is given to the OSSolverService. The configuration file provides the necessary information for the OSSolverService to perform 4

6 the required task. A call to the OSSolverService is illustrated below. In the call the configuration file is named testremotegetjobid.config: OSSolverService -config../data/configfiles/testremotegetjobid.config The options listed in the configuration file testremotegetjobid.config are as follows: -servicelocation -servicemethod getjobid This configuration file specifies two options. The first option, servicelocation, specifies the location of the server performing the service. The second option, servicemethod, is equal to getjobid and this tells the OSSolverService to request a job ID from the server. The server response to this request is a job ID that is a very long string involving IP numbers, time of day, etc. For illustration purposes, assume the job ID returned is xyz123aug3010am. Step 2: Next, the model instance is submitted using the send() method. Again, a configuration file, testremotesend.config is passed to the OSSolverService: OSSolverService -config../data/configfiles/testremotesend.config The options in testremotesend.config are as follows: -servicelocation -servicemethod send -osil../data/osilfiles/rosenbrockmod.osil -osol../data/osolfiles/sendwithjobid.osol The first line is again the service location of the server that will perform the optimization service. The second option is again the servicemethod and tells the OSSolverService that the send() method should be used. The send() method requires an optimization instance and options for the solver. The third option in the configuration file is osil and this specifies the location of the optimization instance. Similarly the last option, osol, specifies the location of the file that contains the options provided to the solver. The sendwithjobid.osol file is <osol> <general> <jobid>xyz123aug3010am</jobid> <contact transporttype="smtp"> kipp.martin@chicagogsb.edu </contact> <solvertoinvoke>ipopt</solvertoinvoke> </general> </osol> 5

7 The OSoL file provides the Job ID and an address of the sender. The Web Service will send an to this address notifying the sender when the job is complete. There is also an option telling which solver to use, in this case the COIN-OR solver Ipopt. The result returned by server is true if the job is successfully submitted, false otherwise. Step 3: The knock() service method is used to find the status of a job with a specific ID, or other jobs on the server and other summary statistics. Again, a configuration file is given to the OSSolverService on the client machine: OSSolverService -config../data/configfiles/testremoteknock.config The testremoteknock.config file is: -servicelocation -servicemethod knock -osplinput../data/osplfiles/knock.ospl -osol../data/osolfiles/knock.osol The configuration specifies the service location just as before and also specifies that the servicemethod is knock. The knock() service method takes two arguments. The location of the file for the first argument is specified by the osplinput option. This argument provides information on the type of summary statistics that are desired. These options are specified using OSpL (Optimization Service Protocol Language). The OSpL file, knock.ospl, is <ospl> <processheader> <request action="getall"/> </processheader> <processdata/> </ospl> In this example, the key element in the OSpL file is <request action="getall"/>, which tells the server to return information on all of the jobs. The result of this request is very detailed information on all of the jobs solved by the server. This information is in OSpL format. The last option, osol, is the location of the file for the second argument for the knock() service method. For example, the user who wishes to override the <request action="getall"/> request, which can be quite voluminous, can specify a specific jobid in the osol option file and only information on that job is returned: 6

8 <osol> <general> <jobid>xyz123aug3010am</jobid> </general> </osol> A segment of the string that is returned in OSpL format is illustrated below. In this case we can see that the job with jobid xyz123aug3010am has finished. <jobs> <job jobid="xyz123aug3010am"> <state>finished</state> <serviceuri> <submittime> t00:27: :00</submittime> <starttime> t00:27: :00</starttime> <endtime> t00:27: :00</endtime> <duration>2.531</duration> </job> </jobs> Step 4: The last step is to retrieve the solution and display the results in a browser. The configuration file testremoteretrieve.config provides the necessary option values: OSSolverService The testremoteretrieve.config file is: -config../data/configfiles/testremoteretrieve.config -servicelocation -servicemethod retrieve -osol../data/osolfiles/retrieve.osol -osrl./test.osrl -browser /Applications/Firefox.app/Contents/MacOS/firefox The first two options in the configure file are as in the previous steps. They specify the location of the Web service and the service method. In this case the servicemethod is retrieve i.e. get the answer. The third line is the option that specifies the location of the options file. In this example, the options file contains the job ID that was assigned in Step 1, xyz123aug3010am, so that the server knows which job result to return. The file retrieve.osol is actually identical to the file knock.osol illustrated above. The osrl option on the fourth line tells the OSSolverService where to write the result of the optimization. In this case the solution result in the OSrL protocol is written into a file called test.osrl in the directory where the OSSolverService is executing. The last line is the location of the browser on the client machine. The optimal solution displayed in the browser is shown 7

9 in Figure 5. Figure 5: The optimization result displayed in a browser. 4. Using the AMPL and GAMS with Optimization Services Assume that the AMPL executable ampl (or ampl.exe on Windows) obtained from www. ampl.com, the OS OSAmplClient, and the AMPL test problem rbrockmod.mod which is: Minimize (1 x 0 ) (x 1 x 2 0) 2 + 9x 1 (1) Subject to x x x x 0 x 1 25 (2) ln(x 0 x 1 ) + 7.5x x 1 10 (3) x 0, x 1 0 (4) 8

10 are all in the same directory. To solve this problem locally by calling the OSAmplClient from AMPL, using the nonlinear COIN-OR solver Ipopt, first start AMPL and then execute the following commands: # take in modified rosenbrock # assume the problem is in the AMPL directory model rbrockmod.mod; # tell AMPL that the solver is OSAmplClient option solver OSAmplClient; # now tell OSAmplClient to use Ipopt option OSAmplClient options "solver ipopt"; # now solve the problem solve; This will invoke Ipopt locally and the result in OSrL format will be displayed on the screen. In order to call a remote solver service, after the command option OSAmplClient options "solver ipopt"; set the solver service option to the address of the remote solver service: option ipopt options "service In this case it is necessary that the Ipopt solver be part of the OS build on the server. GAMS is used in a similar fashion. Assume that the Rosenbrock model in (1) (4) is expressed in the GAMS modeling language in the file rbrockmod.gams. Then, using the appropriate binaries that can be built from the source code available at the COIN-OR GAMSlinks project (projects.coin-or.org/gamslinks), the model is optimized as follows. gams rbrockmod nlp=os optfile=1 The option optfile=1 tells GAMS to read the file os.opt for additional options. os.opt file is writeosil osil.xml writeosrl osrl.xml service solver ipopt The first line instructs GAMS to output the model instanced to osil.xml. The second line instructs GAMS to write the solver output to osrl.xml. The service option specifies the location of the solver. Finally, the last option solver specifies that the COIN-OR solver Clp is to be used for model solution. The 9

11 5. Protocol Layers In Figure 6 we illustrate in more detail what the user sees in Figure 6 of the main paper. In particular, note the presence of an HTTP Request, an HTTP Header, and an HTTP Body. The body contains a SOAP envelope. Inside the SOAP envelop is the element <retrieve> which is a method specified in the OShL communication protocol. This protocol contains another element <osol> which is a specific instance of the OSoL representation protocol. 10

12 Figure 6: OShL and OSoL protocols inside a SOAP envelope inside an HTTP body. 11

13 References Brooke, A., Kendrick, D., Meeraus, A GAMS, A User s Guide. Scientific Press, Redwood City, CA. Updated at Czyzyk, J., Owen, J.H., Wright, S.J Optimization on the Internet. OR/MS Today 24(5) Czyzyk, J., Mesnier, J., Moré, J.J The NEOS server. IEEE Journal on Computational Science and Engineering Dolan, E.D., Fourer, R., Goux, J.-P., Munson, T.S., Sarich, J Kestrel: An Interface from Optimization Modeling Systems to the NEOS Server. INFORMS Journal on Computing Fourer, R., Gassmann, H.I., Ma, J., Martin, K An XML-Based Schema for Stochastic Programs. Annals of Operations Research Fourer, R., Gay, D.M., Kernighan, B.W AMPL: A Modeling Language for Mathematical Programming, 2nd edition. Brooks/Cole, Cengage Learning, Florence, KY. Fourer, R., Goux, J.-P Optimization as an Internet Resource. Interfaces 31(2) Fourer, R., Ma, J., Martin, K OSiL: An Instance Language for Optimization. Forthcoming in Computational Optimization and Applications published online dx.doi.org/ /s Fourer, R., Ma, J., Martin, K Optimization Services: A Framework for Distributed Optimization. Online Supplement. gsbkip.chicagogsb.edu/optimization ServicesOnline.pdf. Ma, J Optimization services (OS), a General Framework for Optimization Modeling Systems. Ph.D. Dissertation, Department of Industrial Engineering & Management Sciences, Northwestern University, Evanston, IL. publications/thesis2005.pdf. Rosenbrock, H.H An Automatic Method for Finding the Greatest or Least Value of a Function. Computer Journal

14 Skonnard, A., Gudgin, M Essential XML Quick Reference. Pearson Education. 13