Inheritance through Modification

1 General Description

The class concept with inheritance is the key to reuse of modeling knowledge in Modelica. However, in contrast to many other object-oriented languages Modelica also provides inheritance through modification via so-called modifiers. This makes reuse even easier, and can be expressed very concisely. In fact, the three operations: inheritance, specialization through modifications, and object instantiation can be expressed within a single Modelica declaration.

A modifier modifies one or more declaration(s) from an inherited class by changing some aspect(s) of the inherited declarations. The most common kind of modifiers just changes the default value (start value) in a declaration equation.

class Rocket Real altitude(start = 59404); end Rocket;

2 Modifiers in Variable Declarations

Modifiers change the type of a declared variable by modifying specified member declarations of the unmodified type. For example, the Real type of the variable A2 has its default declaration equations for its members (unit and fixed) replaced by those given by the modifiers unit = "Voltage" and fixed = true.

class Mod Real A1; // Scalar variable Real A2(unit = "Voltage", fixed = true); // Scalar with modifiers end Mod;

3 Modifiers for Continuous-time or Discrete-time Variables

For variables with higher levels of variability such as continuous-time or unclocked discrete-time we have the following restriction. A (non-input) variable with continuous-time or unclocked discrete-time variability without a declaration binding equation is not allowed to be modified.

The reason is that if there is not already a declaration equation for a variable in a model with balanced equation count , adding a new equation via a modifier will increase the number of equations and thus destroy the balancing of the modified model. This does not apply to constants and parameters which are not variables to be solved for during simulation, have defaults of value zero and anyway always have to be defined at compile-time for a model to be compiled and simulated. It does not apply to variables with an input prefix since they are assumed to be defined by some connection or actual parameter passed at function calls. For example:

model Vars parameter Real x0; Real x1; discrete Real x2; Real x3 = 35.7; end Vars;

Now let us see some legal and illegal modification of above model

model VarsModify Vars y0(x0=8.33); // Legal modification, x0 is a parameter Vars y1(x1=7.1); // Illegal modification, x1 is without binding equation Vars y2(x2=3.77); // Illegal modification, x2 is without binding equation Vars y3(x3=55.1); // Legal modification, x3 has a binding equation end VarsModify;

4 Modifiers for Array Variables

Regarding modifiers for array variables, it is important to remember that each attribute has the same dimensionality as the array itself.

class Arr Real A3[2,2]; // Array variable Real A4[2,2](start = {{1, 0}, {0, 1}}); // Modifies the start value for the whole array Real A5[2,2](unit = {{"Voltage", "Voltage"}, {"Voltage", "Voltage"}} ); end Arr;

5 Modification of Protected Elements

Protected elements may not be modified or redeclared in class modifications, despite the fact the protected elements are inherited.

class D parameter Real a; // a is a public element protected parameter Real b; // b is a protected element end D;
class D1 = D(a = 10); // OK, since a is public
class D2 = D(a = 10, b = 20); // Illegal, since b is protected!

6 Single Modification Rule

Two arguments of a modification are not allowed to denote the same attribute of a declared element, quite self-evident, but easy to forget in the context of array fields.

class C1 parameter Real x[3]; end C1;
class C2 = C1(x = {1, 1, 1}, x[2] = 2); // Error: x[2] designated twice

7 Flattening of C2

We see in the report for the flattening of C2 that som error occurred. It is illegal to modify x[2] twice.

instantiateModel( C2 )