Nominal value for use in stream equations

[modelica-trac-importer]

Reported by stefanv on 12 Jan 2016 18:40 UTC Section 15.2, specifically the top of page 187, of the 3.3rev1 specification gives two implementations of a function called positiveMax used in generating stream equations.

One comment in this implementation refers to a function named "nominal", where "nominal(v) is the nominal value of v". Presumably, this refers to v.nominal.

However, the specification doesn't define a default value for the nominal attribute of Real, and many of the types appearing in libraries (e.g. Modelica.SIunits.MassFlowRate) don't have a nominal modification. Thus, there is no way to know what "the nominal value of v" is in many cases.

This makes the definitions in 15.2 somewhat useless to an implementor.

---

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

[modelica-trac-importer]

Comment by otter on 12 Jan 2016 22:48 UTC The default nominal value of a Real number is 1.0 (maybe this was just forgotten to define in the specification or this definition is present somewhere).

[modelica-trac-importer]

Comment by beutlich on 12 Jan 2016 23:03 UTC See also https://github.com/xogeny/ModelicaBook/issues/241.

[modelica-trac-importer]

Comment by stefanv on 13 Jan 2016 00:41 UTC Replying to [comment:2 beutlich]:

See also https://github.com/xogeny/ModelicaBook/issues/241.

And that page points out that the specification explicitly states, in section 4.8.7, that the spec does not define a default nominal value. Thus, my original issue still stands.

[modelica-trac-importer]

Comment by hansolsson on 13 Jan 2016 09:29 UTC A default value of the nominal attribute is deliberately not specified in the specification.

This allows tool figure out reasonable nominal values (using e.g. propagation - without having to specify priorities) allowing good scaling of residuals and error estimates - and since it is not exactly defined how to compute these residuals and error estimates the unspecified scaling of them makes no major difference.

That implies that nominal(v) used here is not the nominal attribute of v, but whatever the solver would use as nominal value for v in the error estimator if v were a state. I agree that it should be clearer. However, note that this is a recommended implementation and there is also some additional freedom in how it is done.

(However, using 1 is a reasonable guess for the nominal value if we don't have more information. Using 1e-9 or 1e9 for no good reason is not reasonable.)

[modelica-trac-importer]

Comment by fcasella on 13 Jan 2016 17:56 UTC Being among the creators of the stream connector concept, I have to admit that this is weak point in the concept: the scaling value for regularization around zero flow rate can have a significant impact on the numerical robustness of the model, but it is outside the direct control of the modeller, and is handled by obscure tool heuristics.

That said, I agree with Hans that using propagation among alias variables is probably a good idea to improve the behaviour of the regularized inStream equations.

On the other hand, I don't agree in principle that 1 is a better default nominal value than 1e9 or 1e-9 - this all depends on the units of the mass flow rate and on the system size range. We are lucky that the SI unit for mass flow (kg/s) is such that the design values are between 1e-2 and 1e2 in most cases, thus centered around 1 and with a fairly small range (compare to power variables, which can span 12 orders of magnitude from milliWatts to GigaWatts, depending on the application). I guess we implicitly acknowledged this fact when we defined stream connectors. But this is purely by chance. If the mass flow rate was measured in Farad, 1e-9 would probably be better than 1, and if it was measured in Pascal, 1e9 would probably be better than 1.

[modelica-trac-importer]

Comment by otter on 13 Jan 2016 18:11 UTC Just to make it clear: If a tool has no information about a nominal value, in most cases a nominal value of 1 is a good candidate (especially when using SI units and with applications on earth). A default nominal value of 1e9 would in most cases just give wrong simulation results. If this default nominal value is not appropriate, the user has to provide an explicit one.

Note, this does not only hold for fluid systems. Just take any linear system and simulate it with either a tiny (1e-9) or huge (1e9) input and you will get exactly the same effect: The simulation engine cannot know whether 1e-9 is numerical noise and should be treated as zero; so switching step-size control off, or whether 1e-9 is a very meaningful value and step-size is by no means allowed to be switched off. Only the user can give this information. If the user does not give such information, a (default) nominal value of one seems to be the only reasonable choice.

It seems not possible to improve this situation and the only (minor) improvement that can be made is to explain this in a comment in the Modelica specification.

[modelica-trac-importer]

Comment by stefanv on 13 Jan 2016 18:23 UTC Well, we could begin by setting SIunits.MassFlowRate.nominal to 1 if that is truly a good choice for that unit.

[modelica-trac-importer]

Comment by hansolsson on 14 Jan 2016 13:08 UTC I checked what the specification says in 4.8.7:

The attribute nominal gives the nominal value for the variable. The user need not set it even though the standard does not define a default value. [The nominal value can be used by an analysis tool to determine appropriate tolerances or epsilons, or may be used for scaling. For example, the absolute tolerance for an integrator could be computed as “absTol=abs(nominal)*relTol/100”. A default value is not provided in order that in cases such as “a=b”, where “b” has a nominal value but not “a”, the nominal value can be propagated to the other variable).]

Thus in 15.2 we should could add "nominal value for v - see section 4.8.7".

Replying to [comment:7 stefanv]:

Well, we could begin by setting SIunits.MassFlowRate.nominal to 1 if that is truly a good choice for that unit.

The problem is that that the default value would interfere with propagation of other nominal values. What we could add in 4.8.7 is a comment: 'If there is no value to propagate the tool should use a non-zero value, it may use additional information (e.g. min-attribute) to find a suitable value, and as last resort use 1.'

[And I would also use: absTol=abs(nominal)*relTol - without the "/100"]

[modelica-trac-importer]

Modified by hansolsson on 7 Sep 2016 11:17 UTC

[modelica-trac-importer]

Comment by hansolsson on 12 Sep 2016 12:51 UTC Take all 3 changes: reference in 15.2, add default discussion in 4.8.7 and remove /100. Favor: 6 Against: 0 Rest abstain.

[modelica-trac-importer]

Comment by hansolsson on 23 Sep 2016 13:09 UTC Resolved in r9490