Improve handling of modifiers in OMEdit

[Francesco Casella]

Open a new model and drag a rotational inertia model there. Then go to the Parameters window, Modifiers tab. If you now writew(start = 1), this is not accepted, only w(start=1) is. This is quite confusing, since whitespace should be irrelevant here.

Another problem is that once you have successfully added a modifier via the GUI, it doesn't show up the next time you open the Modifiers tab. This is problematic, because it obliges you to look at the textual code to see what extra modifiers (besides parameter binding equations) have been added to the code.

[Adeel Asghar]

Fixed in r23631.

The modifier won't show up in the Modifiers Tab. They will end up in Parameters Tab.

[massimo ceraolo]

This issue has been solved for inertias, but not for other components having state variables.

For instance the second part (modifiers don't show up) the issue is there at least for capacitors and inductors.

[Adeel Asghar]

Replying to ceraolo:

This issue has been solved for inertias, but not for other components having state variables.

For instance the second part (modifiers don't show up) the issue is there at least for capacitors and inductors.

Try fd0cb66/OMEdit

[massimo ceraolo]

Is it possible to just overwrite omedit.exe? Just in case, where can I get that file from?

[massimo ceraolo]

I think inititalisation boxes must be present for variables that are taken derivative of in constitutive equations: they indicate energy storage elements and initial conditions for differential equations (i.e. they are state variables for isolated components).

A partial list is:

• capacitor: its voltage
• inductor: its current
• mass: its position and speed
• rotational inertia: angular position and speed.
• spring: position difference

If this approach is followed, among the above, the following components should be corrected:

• capacitor and inductor (currently no initial condition is shown)
• mass (position and speed instead of speed and acceleration)
• rotational inertia (acceleration should be removed)

NOTE According to this approach also Dymola is partially wrong since offers also the chance to setting accelerations, that are not state variables.
I'm not sure why they have also added acceleration, and therefore I recommend not to
show them, unless there is a clear reason for doing that.

But before recommending this approach I would like to hear other opinions about it.
Does anyone agree or disagree?

[Francesco Casella]

With respect to mechanical models, I'm checking this out with Martin Otter.

In the meantime, my understanding is that with all variables which have a literal start attribute (not a parameter or an expression, because that typically means the library designer has built-in the right choice) it should be possible to change this through the graphical interface, without having to manually write the modifier in the code.

This includes all the variables mentioned by Massimo, plus acceleration in mechanical models, as there are cases where one might want to specify the initial acceleration instead of the states (Modelica tools can handle this nicely). I don't see anything wrong with giving the initial acceleration, in fact I guess it was done on purpose.

Of course, in some cases, setting fixed = true on variables that have a literal value as start attribute don't make much sense, but that's ok, you just don't do it.

My 2 cents :)

[massimo ceraolo]

My reasoning was simple:
1) at least as a first step, we want to have a minimum number of check boxes
2) in calculus, to solve systems of linear differential equations each derivative is to be associated to an initial condition for the variable whose derivative is taken of.

But simple not always means correct...

[Adeel Asghar]

Well, I have similar understanding as of Francesco. According to my understanding of Modelica specification anything that fulfills any of the following conditions should be in the dialog,

• Has a parameter prefix.
• Has a start/fixed binding.
• Has dialog annotation.

Commit b9e092e/OMEdit implements based on the above 3 conditions.

[massimo ceraolo]

I see.
For instance in the inertia there is the row in MSL code:

SI.AngularAcceleration a

"Absolute angular acceleration of component (= der(w))"
annotation (Dialog(group="Initialization", showStartAttribute=true));

that, no question, implies that OMEdit must show the box.
I'm still not sure that having an initilalization box for acceleration is a good idea, but this is another story.

[Francesco Casella]

This is Martin Otter's reply to my enquiry:

Q1: How are these variables selected by Dymola for inclusion in the Initialization tab? Are they the values of the variables which have a start attribute?

Whenever "start" or "fixed" attribute is set in a declaration, a start value is included in the parameter menu (or "annotation (Dialog(showStartAttribute=true))");

Q2: What is the rationale of also allowing to fix the value of acceleration? Are there any use cases for this?

In order to formulate steady-state problems (v=0, a=0).

[Adeel Asghar]

Replying to casella:

This is Martin Otter's reply to my enquiry:

Q1: How are these variables selected by Dymola for inclusion in the Initialization tab? Are they the values of the variables which have a start attribute?

Whenever "start" or "fixed" attribute is set in a declaration, a start value is included in the parameter menu (or "annotation (Dialog(showStartAttribute=true))");

This is exactly what we are doing now :). One think that he might forgot to mention is if a variable has start or fixed attribute in the extends clause.

[massimo ceraolo]

Q2: What is the rationale of also allowing to fix the value of acceleration? Are there any use cases for this?

In order to formulate steady-state problems (v=0, a=0).

AFAIK an Inertia component will have zero acceleration only when the sum of the applied torques is zero (Newton's second law).
I cannot imagine the effect of explicitly stating an initial acceleration a=0: if torques sum up to zero it is superfluous, otherwise it creates a conflicting condition.

Naturally in a system, say dx/dt=f(x,u), the steady-state is imposed setting to zero dx/dt, i.e. the derivatives of all the state variables.
But I cannot envisage how this can be exploited in Modelica, except for special cases (in which initial conditions to derivatives can be set trough direct writing on code).
BTW, if we wanted to offer users the possibility to zero the derivatives of state variables, we, for instance had to show in dialogs also the check-boxes to set initial values for voltage of inductors and current of capacitors!

[Francesco Casella]

Replying to ceraolo:

Q2: What is the rationale of also allowing to fix the value of acceleration? Are there any use cases for this?

In order to formulate steady-state problems (v=0, a=0).

AFAIK an Inertia component will have zero acceleration only when the sum of the applied torques is zero (Newton's second law).
I cannot imagine the effect of explicitly stating an initial acceleration a=0: if torques sum up to zero it is superfluous, otherwise it creates a conflicting condition.

Think of any system with elastic forces (e.g., a suspension). If you state v = 0 and a = 0, the initial equations coupled to the system equations will allow to determine the equilibrium position (which is another state).

This happens all the time, e.g., in the case of vehicle models.

BTW, if we wanted to offer users the possibility to zero the derivatives of state variables, we, for instance had to show in dialogs also the check-boxes to set initial values for voltage of inductors and current of capacitors!

Check-boxes to set the initial voltage of capacitors should indeed be there, since the capacitor code reads:

model Capacitor "Ideal linear electrical capacitor"
  extends Interfaces.OnePort(v(start=0));

and the variable v has a literal start modifier. I'm not sure I understand comment:12, IMHO the fact that the start attribute is changed in an extended class should be irrelevant.

Setting the initial value of a variable state derivative (to zero, or to any other value) is another thing. We can't do this directly in Modelica, because the der(v) is not declared explicitly, only v is, so there is no way to set its a fixed = true attribute. Either you define a variable for the derivative, as in

der(v) = a;

and then set fixed = true on that variable, or you do this in the initial equation, possibly governed by boolean or enumeration parameters, as done in the Blocks library and in the Fluid library.