Non-uniform choice of some MSL models' initialization variables

[modelica-trac-importer]

Reported by massimo.ceraolo on 11 Dec 2015 17:28 UTC
Dialog boxes of several MSL models show initialisation group with edit fields for initialization values.
But there is not an uniform choice of the initialization variables.

I take for examples Modelica.Mechanics.Rotational.Inertia and Modelica.Electrical.Analog.Basic.Inductor.

In the first case the initialization check boxes refer to phi, w and a, in the second case to the inductor current i.

The use of phi, w and i is immediately justified: these are variables whose derivatives are taken of in the respective models, and therefore are state variables of the unconnected components.
State variables need to be initialized because they own the past history of the considered model. Often they are directly related to an energy storage (e.g. the energy of inductors is (1/2) Li^{2, of a translating mass (1/2)mv}2, etc).

Indeed, 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. this further justifies the choice as initialization edit fields for variables that are equated to derivative of other variables, i.e. state variables.

A total different story is instead to be told regarding acceleration a. That one is not a state variable. Furthermore acceleration cannot be set in case the model structure is such that the torques at the inertia flanges are known, since initial acceleration is a mathematical consequence of the initial torques.

The rationale behind allowing setting also the initial acceleration can be to allow so set simultaneously w=0 and a=0: in this case both derivatives of state variables are set to zero, and this could help in finding a steady-state initial condition.
It is noteworthy, however that in this case the sum of the torques acting at the two ends of Inertia must not be independent variables (thus known at initialization phase). They are instead to be a function of angular position. Setting w=a=0 can force the initialization algorithm, to search the position corresponding to a null torque (summing the two flanges') on the inertia, if it exists.

In my opinion the two cases are totally different. Having input fields to select initial values of state variables is a natural consequence of the fact that differential equations are to be solved for a given set of initial conditions. Having an input field for acceleration, is just a tool to allow to indirectly select an initial "position" of the system, that corresponds to a null torque sum.

Furthermore I note that the approach followed in case of inertia has not been followed in the case of inductor: there the state variable is current (and an input field for initial current is provided). A quantity proportional to the derivative of current is the inductor voltage, but initial inductor voltage IS NOT included among the initialisation fields.

Naturally everything I said with reference with inertia and inductor can be extended easily to many (if not all) the MSL models.

Purpose of this ticket is to propose a uniform way of deal with initialization, at least in the most basic MSL components, e.g. those in Modelica.Electrical.Analog.Basic, Modelica.Mechanics.Rotational.Components, and Modelica.Mechanics.Translational.Components.

The idea is:

• the basic MSL models provide start values for all the state variables (i.e. variables whose value is the value of the derivative of other variables)
• other start values are dropped.

For instance, if this approach is followed, Inductor would remain as it is, while the dialog annotation for variable a in Inertia should be deleted.

More in general the advantages of this approach would be:

• models are treated uniformly (differently from now)
• the most important input fields are retained in dialogs
• input fields relating to initialization of variables that are not state variables of the unconnected component can obviously be still be set acting directly on the code. Once they are set in the code, they will appear are in the model dialog and can be modified from there.

---

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

[beutlich]

@ceraolo As far as I figured out, there are three kinds of start parameter modelling utilized in current MSL.

model T1855
  model A "No explicit start parameter (as e.g., in Mass)"
    Real x "ODE state";
    equation
      der(x) = exp(time);
    annotation(Documentation(info="<html>See <a href=\"modelica://Modelica.Mechanics.Translational.Components.Mass\">Modelica.Mechanics.Translational.Components.Mass</a></html>"));
  end A;
  model B "With additional parameter (as e.g., in Integrator)"
    Real x(start=x0, fixed=true) "ODE state";
    parameter Real x0 "Start value";
    equation
      der(x) = exp(time);
    annotation(Documentation(info="<html>See <a href=\"modelica://Modelica.Blocks.Continuous.Integrator\">Modelica.Blocks.Continuous.Integrator</a></html>"));
  end B;
  model C "With Dialog.showStartAttribute annotation (as e.g., in Inertia)"
    Real x "ODE state" annotation(Dialog(showStartAttribute=true));
    equation
      der(x) = exp(time);
    annotation(Documentation(info="<html>See <a href=\"modelica://Modelica.Mechanics.Rotational.Components.Inertia\">Modelica.Mechanics.Rotational.Components.Inertia</a></html>"));
  end C;
  A a(x(start=1, fixed=true)) annotation(Placement(transformation(extent={{-120,70},{-100,90}})));
  B b(x0=1) annotation(Placement(transformation(extent={{-90,70},{-70,90}})));
  C c(x(start=1, fixed=true)) annotation(Placement(transformation(extent={{-60,70},{-40,90}})));
  annotation(Documentation(info="<html>See issue <a href=\"https://github.com/modelica/ModelicaStandardLibrary/issues/1855\">#1855</a></html>"));
end T1855;

Variants B and C are to be preferred since the start parameter can be directly set in the GUI and is visible in the auto-generated documentation.

[max-privato]

Variants B and C are to be preferred since the start parameter can be directly set in the GUI and is visible in the auto-generated documentation.

I agree.

What's your opinion about the difference in prompting (through GUI) for initial acceleration in inertia and not prompting for initial voltage (or derivative or current) on inductors, as I discussed in the ticket's body?
My ticket questioned the utility of requesting through their GUIs initial acceleration in inertias and other components.

[beutlich]

What's your opinion about the difference in prompting (through GUI) for initial acceleration in inertia and not prompting for initial voltage (or derivative or current) on inductors, as I discussed in the ticket's body?

In my opinion the Dialog.showStartAttribute annotation should be removed for non ODE state variables. I believe that Modelica.Mechanics.Rotational.Components.Inertia.a is the only such case. @tobolar Do you agree?

ModelicaStandardLibrary/Modelica/Mechanics/Rotational.mo

Lines 2481 to 2483 in bf71854

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

[MartinOtter]

Modelica.Fluid has a complete different initialization and it would not be useful to take the simplistic approach from the proposal above. It is therefore not possible to make initialization uniform in MSL.
I agree that it would be useful to have a uniform handling of initialiization. However, this is a very hard topic.

For reasons of backwards compatibility, I would not remove GUI initialization elements now, but only if a reasonable initialization concept is available for the whole MSL.

[beutlich]

@MartinOtter What do you think about removing the Dialog.showStartAttribute annotation from Modelica.Mechanics.Rotational.Components.Inertia.a as I porposed above?

[max-privato]

For reasons of backwards compatibility, I would not remove GUI initialization elements now, but only if a reasonable initialization concept is available for the whole MSL.>

I cannot envisage how eliminating the annotation containing "showStartAttribute=true" from rotational inertia can create compatibility problems, since it regards just the GUI.
However, if this GUI-control of starting acceleration is eliminated from inertia, the corresponding starting acceleration dialog on translational mass should also be eliminated. The corresponding code is slightly different from inertia, since it contains:

SI.Acceleration a(start=0) "Absolute acceleration of component";

but I still I cannot envisage compatibility problems.

[HansOlsson]

I cannot envisage how eliminating the annotation containing "showStartAttribute=true" from rotational inertia can create compatibility problems, since it regards just the GUI.

It cannot not break models, but it can confuse users, i.e. break the user experience.
If they were used to the current parameters; and suddenly some parameters disappear. Additionally (at least in Dymola) existing models using the start-attribute will still show the parameters, which will add to the confusion.

I'm not arguing that setting a.start=0 is a good idea, just that we need to consider user expectations - and preferable we should replace it with something better. I would thus wait with the change until we have a better replacement.

[max-privato]

It cannot not break models, but it can confuse users, i.e. break the user experience.
If they were used to the current parameters; and suddenly some parameters disappear.

From my viewpoint, today the user that sees the option of setting start value of acceleration just wonders why it is there (since acceleration it is not a state variable)., and just ignores it.
If that acceleration control disappears, the user either notes the change or not. In both cases, if it is true that setting acceleration start value through that control is useless, and I think it is, the user experience is unchanged (if he does not note the change) or improved (if he notes it).

I don't dare say that no problem exists in which the start value of acceleration is needed, but these must be very special ones, that require experienced programmers that can directly program it in the code.

So, for what may matter, I still support the removal of that control.

[HansOlsson]

From my viewpoint, today the user that sees the option of setting start value of acceleration just wonders why it is there (since acceleration it is not a state variable)., and just ignores it.

That parenthesis indicates a fundamental misunderstanding on the parts of those users, and we need to be better at educating users.

The start-value semantics in Modelica is deliberately decoupled from selection of state-values; that is especially important for Modelica.Media where we might use different variables - but it also applies for the rotational library (e.g. in combination with gears).
That's why we have fixed-attribute for selecting start-values and stateSelect-attribute for selecting states, replacing the previous idea of initializing states.

However, there are separate reasons why initializing acceleration is not ideal.

[max-privato]

That parenthesis indicates a fundamental misunderstanding on the parts of those users, and we need to be better at educating users.

OK. there are some hypotheses behind the implication non-state variable => non intitial condition needed.

When I wrote that parenthesis I was in the mental framework of linear lumped-component systems, and a very broad range class of non-linear mechanical systems. I also added that my consideration was not universal, since I added that there might well be problems for which the initial value of start acceleration might be needed. For instance problems involving jerk (third derivative of space). I vehicles bounding jerk is an important purpose of design.

However I take seriously you sentence:
"we need to be better at educating users".
This enforces this ticket when we say that if a start value for acceleration is useless, leaving it there is confusing and, definitely, "contra-educating"

[HansOlsson]

OK. there are some hypotheses behind the implication non-state variable => non intitial condition needed.

That is an over-simplification, and we changed MSL a few years back in the other direction.

Obviously the initial values of states must be determined based on the the initial conditions.
One possibility would be to give initial values directly for states, x, and the most general possibility that we give any initial conditions h(x, y)=0 and compute x from those (together with the dynamics equations der(x)=f(x, y) and g(x,y)=0).
Having fixed-start values for some non-states, i.e. P*(y-y0)=0 is between those extremes.

This enforces this ticket when we say that if a start value for acceleration is useless, leaving it there is confusing and, definitely, "contra-educating"

It isn't useless; if we set start-value and make it fixed=true it will force the model to start in a certain way. (I.e. with the given acceleration - assumedly zero.)
Similarly as if we set start-value for angle or position - even if we connect a fix gear and have some other angles and positions as states.

It's important that users understand the need to set fixed=true to enforce that the start-values really matter; regardless of whether it is a state or not.

If we don't have fixed=true then tools will need to select default initial conditions and in that specific case the selected states will matter, but we updated examples in MSL to avoid such cases a few years back. (And users should really pay attention to those default choices.)

However, there are other issues with the likely intent for fixed start-values for accelerations - but that will require more investigations - and the solution seems to be more complex.

[MartinOtter]

How to initialize an inertia in steady state? Currently, the user can set w.start=0 and a.start=0. If a.start=0 is removed, it is no longer possible to initialize in steady state from the GUI.

Revolute and prismatic joints have the same concept (phi, w, a) start values can be set.

The advantage of this approach is that all possible, meaningful options can be set from the GUI. I do not see a reason why restricting this.

Other models have an explicite selection "initialize state" or "initialize in steady state". This is usually done if initialization is more complex, e.g., if a state vector is present or various different variables that have to be consistently set (as in the Fluid library).

Again, I would only make a change here and at other other places of MSL if there is a uniform concept for initialization available.

[beutlich]

I wonder why you closed this. Especially I am confused if this means a closed as wontfix. If there is something to be improved we should keep the issue open.

See at least #2896 for some minimal improvement to have a consistent initialization dialog of translational Mass and rotational Inertia. In both components, steady-state initialization is possible.

[HansOlsson]

I agree with @beutlich and would like to add some notes:

And I still believe the entire concept of "steady-state initialization" needs to be reconsidered (as already indicated in previous replies).

I am working on analyzing this for the future as part of working on implementing better steady-state initialization (we are talking months not minutes (1) ), but the result so far show that steady-state initialization using "a.start=0" as part of models does not work in an intuitive way. I'm thus also reluctant to add that in #2896

For this ticket either we remove it from the dialog now (as proposed in this ticket as far as I understand), or we keep the ticket open and consider solutions when we have more information. Hopefully it will still be possible to hit the MSL 4.0.0 milestone.

1: Note, some of you might know that there are planned improvements for steady-state initialization in Dymola 2020 - but they are primarily for other issues. (The Dymola kernel used in 3DEXPERIENCE R2020x will as a minimum contain the same improvements.) And I'm fully aware that (global) settings in tools differ from settings for component-models.

[beutlich]

For this ticket either we remove it from the dialog now (as proposed in this ticket as far as I understand),

Yes, my intention was and still is to remove the Dialog.showStartAttribute annotation from Modelica.Mechanics.Rotational.Components.Inertia.a, though I now added it for Mass.a in #2896 just for the sake of consistency and being confused. As far as I figured out, Inertia.a is the only such case in MSL of being not an ODE state variable and having this annotation.

[max-privato]

For this ticket either we remove it from the dialog now (as proposed in this ticket as far as I understand)

Exactly so.
Obviously I did not analyse in depth things as is done in this discussion, but as a final user perspective considering initial acceleration as an initial condition of a translating mass or rotating inertia appeared tricky. I did envisage that there might be possible complicated situations in which setting acceleration at t=0 could play some role, but was not sure whether this should be something to be presented in the standard dialog box. As I see from the discussion that this is still an open subject.

[beutlich]

I updated #2896 and created #2897 to consistently consider Mass and Inertia start parameter dialogs and to remove Dialog.showStartAttribute annotation from the highest derivatives.

[MartinOtter]

I am the library officer of the Rotational library and it is my decidion to not make this change (only make a change in the future if a better concept for initialization is available)

[christiankral]

@MartinOtter @beutlich shall we close this issue as wontfix now?

[beutlich]

@MartinOtter @beutlich shall we close this issue as wontfix now?

No, the issue is still relevant after #2896 and #2897 got closed without merging. It truely is sad story and a lot of misunderstanding. 😞