8.4 Specifying Constraints

Plain Constraints
Vector Constraints
Where Conditions on Constraints
Export Constraint Values to Data File
Export Constraint Values to Excel Spreadsheet
Export Constraint Values to Database

The constraints for the model follow immediately after the objective function. Either the keyword SUBJECT TO or a semicolon is required as a separator between the objective function and the constraints.

There are two kinds of constraints:

Plain constraints that are regular single constraints, similar to those LP packages accept in their input files

Vector constraints that are defined over indexes and MPL then expands to a list constraints when generating the model.

Plain Constraints

Plain constraints are constraints that are defined without any indexes. They are normally used with constraints containing plain variables and fixed vector variables. Plain constraints can also contain summations of vector variables as long as all the indexes for the variables are accounted for.

Naming the Constraint

The name of the constraint is optional. It can be of any length, but must not contain spaces or other delimiters. If you omit the name, it defaults to �ci�, where i is the number of the constraint. The constraint name must be followed by a colon.

Using meaningful names for the constraints is a good modeling practice and makes the model easier to work with. The constraint name you provide is used where applicable when MPL solves the model or generates input files.

The Constraint Equation

The constraint name is followed by an equation, which is entered as two formulas, separated by a comparison. The comparison between the formulas can be any of the following:

     Less than or equal constraint:      <   <=
     Equal constraint:                   =
     Greater than or equal constraint:   >   >= 

The reason there are two formulas in each constraint is so that variables can be entered on both sides of the comparison. This can enhance the readability of the model. For example if a variable has a negative coefficient it can be moved over to the other side of the comparison in order to make it positive. When MPL reads in the model, it moves all variables to the left side, all constants over to the right side, and changes signs where necessary.

If you refer to a variable more than once in a constraint, the coefficients will be added together in the model. For more information on writing formulas, you can refer to Chapter 9: Buiding Formulas

Examples:

    3 (Sb1 + Co1 + So1)  =  2 (Sb2 + Co2 + So2) ;
    Overtime   :  Over  >  50% * 170 Workforce ;
    Production :  SUM(shifts: Prod[shifts])  <  3750 ;

You can extend each constraint over many lines. You must end each constraint with a semicolon ';' to seperate it from the next constraint. Forgetting the semicolon is one of the more common mistakes people make when formulating MPL models.

Vector Constraints

Very often models contain constraints that are subscripted, called vector constraints. For example, a vector constraint can be defined in this way over a number of periods and products. A vector constraint is entered by following the constraint name with a list of indexes inside brackets. The index list can contain one or more indexes. When MPL parses the model, it will expand each vector constraint to a list of plain constraints, based on the contents of the index list.

Naming Vector Constraints

The constraint name in MPL, which is required for vector constraints, can be of any length. The name cannot contain any spaces or other delimiters. See Chapter 5.2: Basic Input Elements for more information on names and list of delimiters.

In some cases you may want to use MPL to generate an input file for the LP package. Most LP packages are limited to eight characters for names and therefore only the first few characters will be used when the names are built by MPL. Therefore, to avoid name conflicts, it is necessary to use the becomes operator '->' to abbreviate the name. This feature allows you to use long, descriptive names in your MPL model, and at the same time meet your LP package requirements for short names.

Example:

       SUBJECT TO
          InventoryBalance[product,month]  -> Ibal:

Even though you can use fairly long names for constraints in MPL you might sometimes want to use longer names or description for documentary purposes. MPL allows you to do that by following the definition with the keyword IS and a text description. If the description contains spaces you will need to enclose it with quotation marks.

Example of the IS command:

       SUBJECT TO
          InventoryBalance[product,month]
          IS "Balance of Inventory for each <product> per <month>";
Using Subranges of Indexes in Constraints

If you do not want to generate constraints for all values of a particular index you can use a subrange of the index. You can also use subranges when you want to use different constraints for certain values of the index, i.e. only the first index value.

Examples:

       InventoryBalance[month=Jan..Nov] :  ...
       InventoryBalance[month<=Jun] :  ...
       InventoryBalance[month=Dec] :  ...
The Constraint Equation

As with plain constraints, the constraint definition is followed by an equation, which is entered as two formulas, separated by a comparison. The formulas in vector constraints can contain vector variables, coefficients and summations.

Example:

In the example above, each of the variables referred to is a vector variable defined over the indexes product and period. When reading the model, MPL will map these variable indexes to the same indexes used to define the constraint InventoryBalance. Each index for a referred variable must be accounted for in either the constraint or an enclosed summation. For example, if the Inventory variable had been defined with a third index, that could not be mapped, MPL will report this with an error message.

Where Conditions on Constraints

Sometimes you want to be able to limit the number of constraints defined in a vector constraint dependent on the contents of a data vector. In this case you can use a WHERE data condition following right after the definition of the vector. This will result in only those constraints being created where the condition is met.

Example of where condition:

     SUBJECT TO
        InventoryBalance[product,month]
         WHERE (month > Jan) :

Export Constraint Values to Data File

After optimizing the problem, MPL can export the constraint values to separate data files which can be used to report the solution back to the user. Following the constraint declaration, enter the keyword EXPORT TO, followed by the keyword SPARSEFILE and parentheses containing the filename you want MPL to export to.

       InvtBal[i,j]  EXPORT TO Sparsefile("invtbal.dat");

This will write the slack and the shadow price values for each entry of the InvtBal constraint vector to a text file in the standard sparse format. You can change which values will be exported by entering one or more of the following keywords directly after the keyword EXPORT: Activity, Slack, ShadowPrice, RhsValue, RhsLower, RhsUpper. If you want all of above entries you can use instead the ALL keyword.

MPL also allows you write solution values for constraint vectors to data files in the same format as is used in the standard MPL solution files.

      ProdCap[i,j]  EXPORT TO Solutionfile("prodcap.sol");

When exporting to text files using the solution file format all the options the Solution File Options dialog box will have effect.

Export Constraint Values to Excel Spreadsheet

MPL can also export the constraint values to an Excel spreadsheet where it can be used to report the solution back to the user. Following the declaration of the constraint vector, enter the keyword EXPORT TO, followed by the keyword EXCELRANGE and parentheses containing the Excel workbook name and the Excel range name you want to export to. For example:

    SUBJECT TO
       CutReq[cuts]:

          EXPORT ShadowPrice TO EXCELRANGE("ShadowPrice") : ...

In the above example, MPL will open the Excel spreadsheet Cutstock.xls, locate the range ShadowPrice and then export the shadow prices for the constraint vector CutReq.

The EXCELRANGE command can also be used to export solution values for plain constraints. If the range give contains more than one cell, only the first cell will be used for the exported value.

You can also export the data in sparse column format where the first columns store the values for the indexes followed by a column containing the constraint values. In this case, you use the EXCELSPARSE command to specify that the data is to be written in a sparse format. For example:

    SUBJECT TO
     CutReq[cuts]:

        EXPORT ShadowPrice TO EXCELRANGE("CutsTable", 5) : ...

In this example the Excel range CutsTable contains four columns. The first column stores the values for the index Cuts followed by three columns containing the widths, the demand, and the excess for each cut. The shadow price for the for the CutReq constraint vector will be stored in the fifth column of the CutsTable range.

If the Excel range contains the data as a Excel List there will be an extra row at the top of the range that contains the name of each column. MPL allows you to skip that row automatically by using the EXCELLIST command instead of the EXCELSPARSE command.

If you are writing multiple constraint vectors to the same Excel spreadsheet, you can omit the workbook filename on all entries after the first one. Please note, that since variable and constraint exports are performed at a different time than imports, you will need to specify the spreadsheet workbook filename on the first export statement even if it is the same as the one you were importing from. Please refer to Chapter 4.9 for more details on the options section.

Export Constraint Values to Database

If you are using the Database Connection option you can export the constraint solution values back to the database after solving the problem. This allows you to present the solution to the end-user using the reporting capabilities of the database package.

In order to export constraint solution values follow the definition of the constraint with the keyword EXPORT TO followed by the keyword DATABASE and parentheses containing the table name and the column/field name you want to export to.

Example:

         SUBJECT TO
            FactoryCapacity[factory]
                EXPORT ShadowPrice TO DATABASE("Factory","ShadowPrice"):  ...

In the above example, MPL will open the database table Factory, locate the columns FactID and ShadowPrice, and then export in the shadow price values for the constraint FactoryCapacity. For further information on exporting constraint values please refer to Chapter 11.4: Export Constraint Values to Database


Back To Top | Maximal Home Page | Table of Contents | Previous Page | Next Page