Object-oriented modelling

Jump to: navigation, search

This page overviews the object-oriented capabilities of ASCEND.

MODELs built from MODELs

The simplest object-oriented capability of ASCEND is to create models as aggregates of smaller models:

MODEL tank;
    V IS_A volume;
    rho IS_A density;

    mdot IS_A mass_rate;
    Vdot IS_A volume_rate;
    Vdot = mdot * rho;

END tank;

MODEL pipe;
    mdot IS_A mass_rate;

    rho IS_A density;
END pipe;

MODEL tank_and_pipe;

    T IS_A tank;
    P IS_A pipe;
    T.rho, P.rho ARE_THE_SAME;

    P.mdot, T.mdot ARE_THE_SAME;
END tank_and_pipe;

Model refinement

As well as aggregating models to producing models from smaller parts, one can refine a model of one type to make something more specialised, using the REFINES keyword.:

MODEL vessel REFINES tank;

    p IS_A pressure;
    R IS_A gas_constant;
    n IS_A factor;

    T IS_A temperature;
    p*V = n * R * T;

    T_amb IS_A temperature;
    T = T_amb + 20 {K};

END vessel;

Here, both new variables and new relations were added. Note that it is possible only to add new relations; relations in base models can not be removed in refinements of the base model (although using the included property of a relations, one can gain something like that ability).

Parameterised models

Models can be set up so that they require certain externally-defined parameters at the time when they are instantiated. For example:

MODEL pump(
    in WILL_BE pressurepipe;
    out WILL_BE pressurepipe;

    dp IS_A pressure;
    out.p = in.p + dp;

END pump;

MODEL pumped_thing;
    L1, L2 IS_A pressurepipe;

    P IS_A pump(L1,L2);
END pumped_thing;

These models show that for parameterised (ie parametric) models, you must first declare the sub-models using IS_A declarations, then you can place them into your parameterised declaration as pump(L1,L2), which is the name of the type of model, followed by the specific instances of the parameters you want.

Further refinement of parametric models is possible using a WHERE clause following the REFINES clause.

For more information, see Parameterised models.

Refinements after declaration

The IS_REFINED_TO declaration allows one to start off by declaring a part to be a base-type and then refine that part to be a more specialised type with a subsequent call. This allows for example arrays of hetergeneous objects to be created.

MODEL flow_sequence;

    E[1..3] IS_A flow_equipment;
    E[1].out, E[2].in ARE_THE_SAME;

    E[2].out, E[3].in ARE_THE_SAME;
    E[2] IS_REFINED_TO flow_meter;

    E[1] IS_REFINED_TO flow_pump;
    E[3] IS_REFINED_TO flow_tank;

END flow_sequence;

The more specialised types (here flow_meter, flow_pump and flow_tank) must be refinements of flow_equipment - e.g.,

MODEL flow_meter REFINES flow_equipment;
END flow_meter;

Refinements and merges after instantiation

ASCEND model instances are dynamically typed. While using a compiled model instance, and using the Tcl/Tk GUI for ASCEND, any instance part can be interactively merged with another compatible part or refined to a derived type to debug the model. This allows interactive exploration of the mathematics without requiring a rewrite of the input files at every step. This practice is not universally endorsed, but the Script logging capability guarantees that all such changes can be captured by the careful modeler and the final set reintegrated in the model source files.