The Structured Modelling Language (SML)

Blocks (Submodels)

The main extension of SML over AMPL is the introduction of the keyword 'block':

 set COMMODITIES;
 block Net{k in COMMODITIES}: 
    var Flow{ARCS} >=0;
    ...
 end block;

A block groups a set of model declarations (set, var, param, subject to, minimize/maximize) together. These can be repeated over an indexing set (as any AMPL entity can). A block is a natural representation of a subproblem in AMPL.

Blocks can be nested. Several blocks can be defined on the same level, thus creating a tree of blocks.

All entities within the block are local variables to this block. They are all repeated over the indexing set indicated in the block command. The above piece of code actually defines a variable Net_Flow:

 var Net_Flow{k in COMMODITIES, ARCS} >=0;

Blocks can also be defined with the alternative syntax

 set COMMODITIES;
 block Net{k in COMMODITIES}:{
    var Flow{ARCS} >=0;
    ...
 }

Scoping

From within the block all model components that were defined in the block and its ancestor blocks can be used in definitions. Model components defined in a sublock can be used by need to be accessed "through" the name of the subblock. That is from outside the block variable Flow can be referred to as

 Net[k].Flow[j];

Model components defined in sibling blocks (i.e. blocks defined on the same level) or their child blocks cannot be used.

Stochastic Programming

A stochastic programming block can be defined as

 block alm stochastic using (NODES, PARENTS, PROBS, STAGES): {
   ...
 }

Here 'alm' is the name of the block, 'STAGES' and 'NODES' are sets of stages and nodes respectively, 'PARENTS{NODES}, PROBS{NODES}' are parameter arrays indexed over the set NODES that give the parent node and the conditional probability of a given node respectively. The parent of the root node must be set to the string "null". The PARENTS array must imply the same number of stages as are given in the STAGES set.

Note:

PARENT is a (symbolic) parameter indexed over the set NODES that gives for every node in NODES the name of its parent node. For the root node it is required that PARENT[root] = "null"

There are a variety of specifiers that can be applied to model components declared within a stochastic block:

• Components can be declared in only some of the stages. This can be specified in two ways:
  • either by using the 'stages' keyword in the definition

        subject to Inventory{i in ASSETS} stages (STAGES diff {first(STAGES)}):
          ...
    

  • or by specifying a stage block:

        set first := STAGES diff {first(STAGES)};
        stage first:
          subject to Inventory{i in ASSETS}:
            ...
        end stage
    

  • also with the alternative syntax:

        set first := STAGES diff {first(STAGES)};
        stage first:{
          subject to Inventory{i in ASSETS}:
            ...
        }
    

• All model components declared in a stochastic block are by default indexed over the NODES set. Some parameters or variables only have one value for every stage not for every node within the stage. These can be defined by the 'deterministic' keyword:

        param Liability deterministic, >=0;
  

  Bug:

  This is understood by the parser, but not implemented yet in the backend

• It is possible to explicitly refer to the node or stage of a component (for example to refer to parameters declared outside the stochastic block):

   param Liability{STAGES}; //an alternative deterministic parameter
   block alm stochastic using (NODES, PARENT, PROBS, STAGES): {
     subject to CashBalance:
        sum{i in ASSETS} xs[i] =  Liability[stage] + sum{i in ASSETS} xb[i];
     ...
   }
  

  Here the constraint CashBalance is repeated over all nodes in the stochastic block, whereas the keyword 'stage' in the constraint is replaced by the stage of the constraint.

  Bug:

  Rather than implementing this as keywords 'node'/'stage' this should be done by declaring dummy variables for the NODES, STAGES set:

   block alm stochastic using (nd in NODES, ANCESTORS, PROBS, st in STAGES):
    ..
        ...  Liability[st] +...
  

Expectation Constraints

Add something on how to write Expectation type constraints

Known problems

Read the Known Problems page to see the current limitations in SML.