Aspen SCM‎ > ‎SCM Planning‎ > ‎

3. Generic Rows and Columns

Generic rows and columns do not correspond exactly to the constraints and decision variables in a mathematical formulation. In a mathematical formulation a constraint or a decision variable represents a class of constraints or decision variables. A decision variable may appear more than once in a constraint.

For instance, in a multi-time-period model a material balance constraint may include two instances of the decision variable for stock: at the end of the preceding time period, zp,t-1; and at the end of the current time period, zpt :

MBALpt:     zp,t-1 + ypt – zpt = 0        for all p,t

In SCM Planning this can be implemented in several different ways. One of them is to define one generic column for the stock for the current time period and another generic column for the stock for the preceding time period. Each of these generates columns with the same names, e.g. Z.CR.1 might be generated from the generic column for:
  • stock at the end of the current time period for time period 1;
  • stock at the end of the preceding time period for time period 2.
Another approach (which is more consistent with the way that SCM Planning works) is to define a single generic column for the stock at the end of a time period but two generic rows, one for the current time period and another for the next time period.

Thus generic rows and columns can be considered as fragments of a logical constraint or decision variable as defined in a mathematical formulation. In many cases there is a direct correspondence between generic rows and columns and the logical constraints and decision variables. But in other cases two or more generic rows or columns are required to represent the logical constraint or decision variable. 

You define a generic row or column by specifying it in the set ROW or COL and defining its entries in the table ROWS or COLS. The Code of the entry in ROW or COL should be unique in that set but is not used in the names of the rows or columns which are generated for it. Similarly the Description in ROW or COL is merely descriptive; as it is usually displayed in the tables indexed by ROW or COL, it should list the identifier for the generic row or column and the subscripts which index it.

The rows or columns which are generated for a generic row or column are determined by the entries in the table ROWS or COLS. For each element of ROW or COL you specify:
  • FLD1: a character string to be used as a constant string at the start of the row or columns name;
  • FLD2 – FLD6: sets which index the generic row or column; or blank if all the sets have been defined. The name of a set may be preceded by an asterisk (*) to indicate that the set is “disconnected” from the value of a related set which has been “established”; see Families of Sets and the No-match Flag;
  • TYPE: blank if the row or column is generated with the GEN command (i.e. normally); REGEN when the row or column is to be generated with a REGEN or SLPGEN command and DELTA when a column is to be generated by a SLP command;
  • TABL: an entry in the POL set or the name of a table which, possibly through other tables, resolves to an entry in the POL set, i.e. a policy. This entry defines the “rim” of the row or column: for a row it specifies the type of row (equality, ≤ or ≥) and the right-hand side; for a column it specifies the bounds (or integer restrictions) and the cost. The entire chain of tables from the entry in ROWS(*,TABL) or COLS(*,TABL) through to the entry in POL is known as the policy chain. If the entry in TABL does not resolve to an entry in POL, e.g. it is blank, the row or column is not generated in the matrix.


Back                                Next
Comments