Aspen SCM‎ > ‎SCM Planning‎ > ‎

4. How the Matrix is Generated

In order to be able to configure the ROWS, COLS and POLI tables correctly, you need to understand how the LP matrix is generated from them.

In accordance with the industry-standard formats for LP matrices (e.g. MPS), Aspen SCM Planning generates the matrix column-wise. That is, it generates each potential column and then works out the entries which that column has in each of the potential rows.

Generating Columns

For each entry in the set COL it performs a nest of loops over the sets specified in FLD2 – FLD6 (strictly speaking the nest is over FLD1 – FLD6 but by convention FLD1 is a constant, so there is no loop). As it loops over a set, it sets the internal index for that set just as it would do for an IN loop; this “establishes” the value of that set. If a set appears more than once in this nest and its name is not preceded by an asterisk, the value of the set is established by the first entry and no further loop occurs for subsequent entries. But if subsequent entries are preceded by asterisks, these “disconnect” the entries and induce separate, independent loops over the set.

Once values have been established for all the sets which index a generic column, reference is made to the entry in COLS(*,TABL). If this is itself an entry in POL, the corresponding values in POLI are used as the bounds (or integer restrictions) and cost of the specific column.

If the entry in COLS(*,TABL) is the name of a table, the value is worked out of the entry in that table using the currently-established values of the sets which index the column. The table must be of character data type; it may be a conventional 2-dimensional table or it may be a multi-dimensional incidence table.

Note that it is only the name of the table which is specified in COLS(*,TABL). If it is a 2-dimensional table, e.g. MYTABLE(MYROWS,MYCOLS), the value which is retrieved is MYTABLE(@,@). Thus the values of the indexing sets MYROWS and MYCOLS must have been established by the loops over FLD2 – FLD6.

Each of the rows of a multi-dimensional incidence table lists values for its indexing sets followed by the value of the table for that “tuple” in the column $ENTRY. Rather than looping explicitly over those sets among FLD2 – FLD6 which index the multi-dimensional table and then testing for non-blank entries in the table, Aspen SCM Planning suppresses these explicit loops. Instead it loops over the rows of the multi-dimensional table and establishes the values of all its indexing sets to be those for this row of the multi-dimensional table. It then uses the value in $ENTRY for that combination of indexes. Note that this establishes values for all the sets which index the multi-dimensional table, not just those which are among FLD2 – FLD6.

The value in the table (whether 2- or multi-dimensional) may either be an entry in the POL set or the name of another table. If it is the latter, a further attempt is made to resolve this; and so on by recursion until either an entry in POL is found, or it resolves to something which is neither a POL nor the name of a table. If this happens, no columns are generated for this combination of indexes; this is often deliberate: the convention is to make the chain resolve blank if no column is to be generated. There is a further possibility to beware of: if the chain contains a cycle, i.e. one of the tables refers to a table which has appeared before in the chain, this causes an infinite loop in GEN and crashes Aspen SCM.

Transportation Example

Consider a typical decision variable xij in a transportation model. This represents the amount of some material from source i used at destination j. Suppose that source i is represented by the set SOURCE and that destination j is represented by the set DEST. In practice these two sets may have the same elements, but it is easier to understand the implementation if we regard them as distinct. Then we may define our column in the set COL with the Code “X” and the Description “X SOURCE  DEST”. In the table COLS we specify


where POS is an element of POL which defines a decision variable which is positive and has zero cost (see Policies).

In this case we will define xij for each combination of i in SOURCE and j in DEST. If we wish to restrict the combinations of i and j for which xij is defined, we specify COLS(X,TABL) = IFITOJ where IFITOJ is a character table which takes the value “POS” for those combinations of i and j for which we want the variable xij and which is blank otherwise. We can create this table in two ways:
  • as a 2-dimensional table IFITOJ(SOURCE,DEST);
  • as a multi-dimensional incidence table IFITOJ(IFITOJ.S,IFITOJ.H) where IFITOJ.S and IFITOJ.H are sets which we create to be its row and column sets. We must ensure that IFITOJ.S has sufficient elements for however many xij we require. We define IFITOJ.H to have the three elements SOURCE, DEST and $ENTRY.
Clearly it is easier to set up and manipulate the explicit table. The multi-dimensional incidence table has the advantage of greater efficiency, but is harder to set up and use. It becomes necessary if we have an incidence relationship which involves three or more sets. Do not cascade multi-dimensional incidence tables, i.e. have one such table whose values in $ENTRY are the names of other such incidence tables: this is horribly inefficient. Instead ensure that the values in $ENTRY are either in POL themselves or are the names of explicit 2-dimensional tables.

Beware of one feature of multi-dimensional incidence tables when used in an LP model: the name of such an incidence table must not exceed 6 characters. This is because Aspen SCM Planning creates two image tables based on the name of the table: $<table> and $<table>C. If <table> has more than 6 characters, these tables will have identical names, and the matrix will not be generated correctly.

In practice, if you are considering using a multi-dimensional incidence table, you should consider an alternative: to use the rowset of the multi-dimensional incidence table as an explicit part of your mathematical formulation and data structures. You will often find that this yields a neater implementation.

Generating Rows

Once GEN has generated a specific column, it then loops through the generic rows which have non-blank entries in the table COEF for the generic column. (There is no point working out what the specific rows are for a generic row if it is known in advance that all the coefficients for the column in those rows will be zero.)

The specific rows for a generic row are generated in a manner which is entirely analogous to that for generating columns. However, it is far more likely that the value of a set will already have been established. Consider a typical availability constraint:

Σj xij ≤ Ai        for all i

where xij is the decision variable for the amount of material from source i used at destination j and Ai is the availability of the material at source i.

We have seen how we can define the decision variables using the set COL and the table COLS. Suppose that the availabilities are held in the table AVAIL(SOURCE,1) and that we want to call our rows AV. Then we may define our row in the set ROW with the Code “AV” and the Description “AV SOURCE”. In the table ROWS we specify


where AVL is an element of POL which we shall define in Policies.

Beware of using multi-dimensional incidence tables in ROWS(*,TABL) or any part of the policy chain for rows. Multi-dimensional incidence tables are efficient in COLS(*,TABL) because they change the way that the loops work for columns. There is never any need to find which tuples exist for an arbitrary value of one of the indexing sets. But this is required where one of the indexing sets of a row has already been established for the column which appears in the row.

Generating Coefficients

Coefficients of generic columns in generic rows are specified in the table COEF which has character data type. Entries in COEF may be:
  • numeric, e.g. 1, –1, 2.5;
  • the name of a table;
  • a non-linear function whose name appears in the NLF set;
  • a constant whose name appears in the CONS table;
  • blank, in which case no entries are generated for the generic column in this generic row.
Where the entry in COEF is the name of a table, it may be a 2-dimensional table or a multi-dimensional table. If it is 2-dimensional it may either contain numbers or the name of another table, i.e. be part of a nested hierarchical table which ultimately resolves to numbers. In any case, at each stage the values of the indexing sets must have been established, i.e. had their internal indexes set.

If the generated coefficient for a specific column in a row resolves as zero, no entry is written in the matrix. If all the row entries for a specific column resolve as zero, the specific column is suppressed and does not appear in the generated matrix.

Back                                Next