Definition of Simulation Model

[modelica-trac-importer]

Reported by petfr on 18 Apr 2012 09:58 UTC The notion of simulation model is used in many places in the specification, but the definition is very fuzzy. I improved the definition in Section 1.2 somewhat, and also added it to the glossary:

Section 1.2: (updated):

A class must have additional properties, including being globally balanced (Section 4.7), in order that its flat Modelica structure can be further transformed into a set of differential, algebraic and discrete equations (= flat hybrid DAE, see Appendix C) that could possibly be solved/simulated. Such classes are called simulation models.

Glossary item:

simulation model: a model that fulfills certain conditions which are necessary but not sufficient for simulation, including fulfilling the condition of being globally balanced (See Section 4.7). See also the notion of structurally non-singular, which is also is a necessary condition for simulation.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/730

[modelica-trac-importer]

Comment by hansolsson on 18 Apr 2012 10:33 UTC I agree that it is a bit fuzzy; and to me the problem is that the definition is still backwards. The intent is that a simulation model is a model intended to be simulation, and that implies semantic restrictions; and not the other way as in the current specification.

Thus something like:

Section 1.2: A model intended to be simulated on its own is called a 'simulation model' and must satisfy additional semantic restrictions, e.g. it may not contain components of partial models, see section 4.4.2 (the intent is that those should be redeclared). Note that satifsying the semantic restrictions does not guarantee that the model can be initialized from the initial conditions and integrated forward in time.

- Note that I deliberately did not include balancing here: The local balancing is necessary for all non-partial models (regardless of whether they are simulation models or not); at least for the parameter values used and ideally for all valid parameter values. The global balancing then follows from the local balancing and the restrictions on simulation models.

[modelica-trac-importer]

Comment by hansolsson on 18 Apr 2012 12:13 UTC I noticed that the previous version did not completely fit into 1.2 and thus the next attempt is:

1.2 Scope of the Specification The semantics of the Modelica language is specified by means of a set of rules for translating any class described in the Modelica language to a flat Modelica structure.

A model intended to be simulated on its own is called a simulation model. The flat Modelica structure is also defined for other cases than simulation models; including functions (can be used to provide algorithmic contents), packages (used as a structuring mechanism), and partial models (used as base-models). This allows correctness to be verified for those classes, before using them to build the simulation model.

There are specific semantic restrictions for a simulation model to ensure that the model is complete (see e.g. Section 4.4.2); they allow its flat Modelica structure to be further transformed into a set of differential, algebraic and discrete equations (= flat hybrid DAE). Note that satisfying the semantic restrictions does not guarantee that the model can be initialized from the initial conditions and integrated forward in time. ...

[modelica-trac-importer]

Comment by petfr on 18 Apr 2012 13:06 UTC A further attempt is:

1.2 Scope of the Specification

The semantics of the Modelica language is specified by means of a set of rules for translating any class described in the Modelica language to a flat Modelica structure.

A class (of specialized class model, class or block) intended to be simulated on its own is called a simulation model.

The flat Modelica structure is also defined for other cases than simulation models; including functions (can be used to provide algorithmic contents), packages (used as a structuring mechanism), and partial models (used as base-models). This allows correctness to be verified for those classes, before using them to build the simulation model.

There are specific semantic restrictions for a simulation model to ensure that the model is complete (see e.g. Section 4.7); they allow its flat Modelica structure can be further transformed into a set of differential, algebraic and discrete equations (= flat hybrid DAE). Note that satisfying the semantic restrictions does not guarantee that the model can be initialized from the initial conditions and simulated.

Motivation: I used class sintce the first sentence uses class. I changed reference to 4.7 since the whole 4.7 is about semantic restrictions whereas 4.4.2 is about prefixes and environment to simulation models. I used simulate instead of integrate since we use the term simulate for this elsewhere in the specification.

Comment: It seems unnecessary to write simulation model or block in many places. Why just not use simulation model everywhere according to the above definition?

Comment 2: Globally balanced (Sec 4.7) is a semantic restriction that make sense for simulation models. This is a check we want to make before trying to simulate. Sec 4.4.2 defines how the environment can handle inputs and outputs not defined in the simulation model.

Moreover, there are problems in Section 4.7

Under Globally Balanced

I added a new restriction for globally balanced models:

• ??new restriction (see component t in example 2): A non-partial model or block may not contain an instance of a partial model.

Also, counting equations, these two make sense together with definitions by the environment in 4.4.2

• The number of input and flow-variables present in each (top-level) public connector component. • The number of (top level) public input variables that neither are connectors nor have binding equations [i.e., top-level inputs are treated as known variables].

but they clash with the restriction:

• In a non-partial model or block, all non-connector inputs of model or block components must have binding equations. [E.g. if the model contains a component, firstOrder (of specialized class model) and firstOrder has ‘input Real u’ then there must be a binding equation for firstOrder.u.]

Perhaps reformulate:

• In a non-partial model or block, (top level) non-connector inputs of a simulation model need not have binding equations but all non-connector inputs of model or block components must have binding equations. [E.g. if the model contains a component, firstOrder (of specialized class model) and firstOrder has ‘input Real u’ then there must be a binding equation for firstOrder.u.]

Also, the following restriction does not make sense for me, delete it?

• A component declared with the inner or outer prefix shall not be of a class having top-level public connectors containing inputs. ??why?

[modelica-trac-importer]

Comment by hansolsson on 24 Apr 2012 15:41 UTC I agree that we can define 'simulation model' to include both models and blocks, and that it will be more consistent and easier to read

As for the text:

On 2nd thought we should probably keep 1.2 free of forward references and I regret that I introduced one (so neither 4.4.2 nor 4.7 should be referenced in my opinion).

The reason is that this is sort of a short introduction defining the scope and there are so many implicit references (what exactly is flattening?, model?, equation?, initial conditions?) that just adding one reference will be odd.

As for the new proposed restriction on globally balanced (these should have been made into separate tickets).

I believe the issue is that the specification text has an odd structure: Globally Balanced Semantic Restrictions (should always be valid) Simulation models are Globally Balanced.

The semantic restrictions always apply; and not part of Globally Balanced/Simulation model - but necessary for the conclusion. I agree that this is not really clear, and we could reword it - but exactly how is not clear.

1. As indicated above the restriction for non-partial is already present, but separated out as part of "All simulation models and blocks are globally balanced.", since a simulation model may not contain components of partial models.

[And checks for non-partial models containing components of partial models is an important reason for the definition of locally balanced.]

2. We could add 'top-level', but since it 'top-level' connector of components it is more 'next level', so it might be more confusing than helping. However, I don't see the clash for the inputs. (For simulation model see earlier.)

An example might help:

block FirstOrder
  input Real u;
  output Real y;
equation
  der(y)=y-u;
end FirstOrder;
model A
  FirstOrder firstOrder(u=time);
end A;

Here FirstOrder is locally balanced, and we count 'u' as having a binding equation. In model A we must give a binding equation for firstOrder.u; and the binding equation is not counted locally in A (in general we do not have to care much about modifiers for locally balanced). Note that instead of counting 'u' as having a binding equation we could have ignored inputs such as 'u' in the variable count; for some reasons that was more complex.

The counting part ensures that a non-connector input to a model is counted as though it has a binding equation. And then the restriction ensures that components of that model have a binding equation (locally at the next level).

It would have been possible to allow "delaying" this binding until we make a complete simulation model and allow deep hierarchical modifiers for this; but it would be bad style. We could also have required that they have a default binding, but that would introduce too many non-good defaults.

3. The last one 'A component declared with the inner or outer prefix shall not be of a class having top-level public connectors containing inputs' is about a quite odd case:

It would be possible to remove the restriction, but it will require other changes.

Let's start by looking at the issue:

model A
  B b1,b2,b3;
  inner Integrator Integ;
...
end A;
model B
  outer Integrator Integ;
...
end B;

Locally in B we should not connect to the input of Integ, even though we normally should connect to inputs of components. Instead we have to perform that connection for the inner Integrator in A. Obviously this fails if we try to automatically add the inner component; so we have to restrict that as well.

So, yes - we could (probably) remove this restriction if we modified the other rules.

But exactly how is not crystal clear to me, and since I am not aware of any use-cases it is easier to keep the restriction for now.

[modelica-trac-importer]

Comment by dietmarw on 15 Aug 2012 08:22 UTC Left-over tickets from the now closed [milestone:ModelicaSpec3.3] milestone which basically means it should go into [milestone:ModelicaSpec3.4] right?

[modelica-trac-importer]

Comment by hansolsson on 6 Sep 2016 15:15 UTC After removing the forward reference (as discussed above) and improving the grammar slightly it becomes:

1.2 Scope of the Specification

The semantics of the Modelica language is specified by means of a set of rules for translating any class described in the Modelica language to a flat Modelica structure.

A class (of specialized class model, class or block) intended to be simulated on its own is called a simulation model.

The flat Modelica structure is also defined for other cases than simulation models; including functions (can be used to provide algorithmic contents), packages (used as a structuring mechanism), and partial models (used as base-models). This allows correctness to be verified for those classes, before using them to build the simulation model.

There are specific semantic restrictions for a simulation model to ensure that the model is complete; they allow its flat Modelica structure to be further transformed into a set of differential, algebraic and discrete equations (= flat hybrid DAE). Note that satisfying the semantic restrictions does not guarantee that the model can be initialized from the initial conditions and simulated.

-- It would be good to discuss this text at the design meeting.

[modelica-trac-importer]

Changelog removed by hansolsson on 6 Sep 2016 15:15 UTC

[modelica-trac-importer]

Comment by hansolsson on 12 Sep 2016 12:28 UTC Design group: A few too many "class" but otherwise ok in new text. The "flat Modelica structure" in first paragraph (not changed) suggests that there is another document defining "flat Modelica structure" (but there isn't) - so would be good to rewrite, but "simulation model" part is ok. Agreement on change. Favor: 6 Against: 0 Rest abstain

[modelica-trac-importer]

Comment by hansolsson on 23 Sep 2016 10:30 UTC Resolved in r9487