Conditional modelling

From ASCEND
Jump to: navigation, search

Conditional modelling, in the context of ASCEND, refers to the use of a solver which can change the equations for which it is seeking a solution, depending on the current values of the guessed variables in the model, as the solution progresses. An example of a use for conditional modelling is that pipe flow can change from laminar to turbulent depending on the speed of the flow; in the laminar region the friction equations are very different to those in the turbulent region.

ASCEND currently provides just one solver that can solve this type of model, called CMSlv, but the architecture is such that other conditional solvers (aka MINLP solvers?) can also be connected if desired.

The CMSlv solver in ASCEND uses the 'boundary crossing' algorithm, and is currently fully functional, but requires the closed-source CONOPT solver. ASCEND users can get a free trial copy of CONOPT, see What if I do not have CONOPT for more details.

Syntax

The documentation on ASCEND syntax is a little dated, so the current syntax will be summarised here.

Logical relations

You write logical relations in the declarative part of your MODEL using the following syntax:

mybool1, mybool2 IS_A boolean_var;
mybool1 == mybool2;

Boundary conditions

To declare a boolean variable that becomes TRUE when a certain real-valued boundary is crossed, use the CONDITIONAL statement along with a logical relation:

myvar1, myvar2 IS_A solver_var;
CONDITIONAL
    myboundary1: myvar1 < myvar2;
END CONDITIONAL;

mybool1 IS_A boolean_var;
mybool1 == SATISFIED(myboundary1);

Note that normally the relations inside a CONDITIONAL section would be inequalities. In fact the relations can be equalities as well, or even logical relations. In the case of real-valued equality conditions, the following syntax is advisable, to specify a tolerance limit:

mybool1 == SATISFIED(myequality1, 1e-8 {kJ/kg});

Conditional relations

To use the value of a boolean var to control what equations are active in your model, use a WHEN statement (continuing from the previous model:

myvar3 IS_A solver_var;

mycondexpr1: myvar3 = 2 * (myvar1 - myvar2);
mycondexpr2: myvar3 = sin(myvar1 - myvar2);

WHEN(mybool1)
    CASE TRUE:
        USE mycondexpr1;

    CASE FALSE:
        USE mycondexpr2;
END WHEN;

You can use multiple variables in your WHEN list, which occasionally saves some typing. Also there is the OTHERWISE clause.

WHEN(mybool1,mybool2)
    CASE TRUE,FALSE:
        ...
    CASE FALSE,FALSE:

        ...
    OTHERWISE:
        ...
END WHEN;

The following are important observations about the implementation:

  • The WHEN statement does not mean conditional compilation. We create and have available the data structures for all of the variables and equations in each of the models. This is actually a requirement for the solution algorithms of conditional models. All the models and equations whose name is given in each of the cases should be declared inside the model which contains the WHEN statement.
  • The variables in the list of variables can be of any type among boolean, integer or symbol or any combination of them. That is, we are not limited to the use of boolean variables. Obviously, The list of values in each case must be in agreement with the list of variables in the number of elements and type of each element. In other words, order matters in the list of variables of the WHEN statement, and parentheses are enclosing this list to make clear such a feature.
  • Names of arrays of models or equations are also allowed inside the scope of each CASE.

The WHEN statement represents an important contribution to modeling: it allows the user to define the domain of validity of both models and equations inside the cases of a WHEN statement. This feature enormously increases the scope of modeling in an equation-based modeling environment.

Mainly, there are two different ways in which the WHEN statement can be used.:

  • First, the WHEN statement can be used to select a configuration of a problem among several alternative configurations.
  • Second, in combination with logical relations, the WHEN statement can be used for conditional programming. That is, a problem in which the system of equations to be solved depends on the solution of the problem. A typical example of this situation is the laminar-turbulent flow transition. The selection of the equation to calculate the friction factor depends on the value of the Reynolds number, which is an unknown in the problem.

Other conditional syntax

There is also syntax for providing conditional functionality in the METHODS section of a model. See SWITCH, IF, SELECT and also see Vicente Rico-Ramirez' thesis (in our publications page).

The EVENT syntax (experimental) supports instantaneous boundary events, as opposed to 'region-like' conditional behaviour, but only has relevance for dynamic modelling.

Examples

Some complete worked examples exist, for the following cases:

Further documentation

The primary reference for ASCEND's conditional modelling is:

  • Vicente Rico-Ramirez' thesis, Representation, Analysis and Solution of Conditional Models in an Equation-Based Environment (PDF available from our publications page)

Further source of documentation (some of which is a proposed implementation) include:

Slack variables

Note that in some optimisation problems, it is possible to model conditional expressions without the need for specialised conditional syntax. This approach has been used in the current thermodynamics library in ASCEND.

For an example, see the model iapws95_2phase in the models/johnpye/iapws95.a4c file in the ModelLibrary.

There are some very worthwhile comments on how to go about using slack variables in the following document (page 17):

http://www.gams.com/dd/docs/solvers/conopt.pdf

Slack variables won't normally work with regular NLA problems, since there is nothing to drive the slack variables to zero when they are not active. In those cases, sometimes the abs function can help to create simple conditional behaviour.

Boundary crossing in dynamic models

Some work is being done on adding support for integration of conditional dynamic models. This is taking place as part of the IDA solver work.

Future

It is proposed that we implement an open-source alternative optimiser for ACEND so that CONOPT is not a requirement for conditional modelling. A good candidate appears to be IPOPT

See also Integration of Conditional Models.

See also SELECT, which is used to produce flexible models that are not, strictly, conditional models in the sense that is intended here.