Should simulation really not depend on the output of getInstanceName()?

[casella]

Section 3.7.4.5 defines getInstanceName() with the following non-normative text:

[The simulation result should not depend on the return value of this function.]

I see several issues with this.

The first question is, what's the point of writing a prohibition in the conditional instead of in the indicative, as in "The simulation result shall not depend on the return value of this function? What if it does, you get a slap on the wrist but then it's OK?

The second is, what's the point of putting a prohibition in the non-normative part of the specification? That makes it void and null by definition, I would say.

The third is, why is this text actually there at all? What's wrong at having the simulation result depending on the instance name? I can't really see what the problem could be.

The Modelica Standard Library actually contains models whose simulation results indeed depend on the return value of this function, and for a very good reason. The model Modelica.Blocks.Interfaces.PartialNoise sets the local seed of a random number generator by applying a hash function to the output of getInstanceName(). This guarantees that each separate instance of models extending it computes a different seed at initialization, so that each of them outputs a different pseudo-random number sequence.

To me, this is a perfectly legitimate use of getInstanceName(), and actually a smart idea by the library authors.

I would therefore propose to remove that non-normative line of text outright from the MLS.

[HansOlsson]

Section 3.7.4.5 defines getInstanceName() with the following non-normative text:

[The simulation result should not depend on the return value of this function.]

I see several issues with this.

The first question is, what's the point of writing a prohibition in the conditional instead of in the indicative, as in "The simulation result shall not depend on the return value of this function? What if it does, you get a slap on the wrist but then it's OK?

Using https://www.rfc-editor.org/rfc/rfc2119 as a guide "should not" is a (strong) recommendation against, but that there may exist special cases when it makes sense.

Whereas "shall not" would just prohibit it.

The second is, what's the point of putting a prohibition in the non-normative part of the specification? That makes it void and null by definition, I would say.

Since it is a recommendation, it also seems weird to have it in the normative text.

The third is, why is this text actually there at all? What's wrong at having the simulation result depending on the instance name? I can't really see what the problem could be.

The Modelica Standard Library actually contains models whose simulation results indeed depend on the return value of this function, and for a very good reason. The model Modelica.Blocks.Interfaces.PartialNoise sets the local seed of a random number generator by applying a hash function to the output of getInstanceName(). This guarantees that each separate instance of models extending it computes a different seed at initialization, so that each of them outputs a different pseudo-random number sequence.
To me, this is a perfectly legitimate use of getInstanceName(), and actually a smart idea by the library authors.

As indicated above "should not" mean that there can be valid reasons, and this seems like one.

On the other hand having a model:
output Real y1=(if getInstanceName()=="add") then u1+u2 else u1*u2;
would be bad; and similarly for other cases where the behavior of the model depends on its instance name.

Or in other words: if users are supposed to select instance names to select the desired behavior (using getInstanceName()) there's something wrong with the design of the model. (Note: Having matching instance names for inner/outer is separate.)
Users aren't supposed to do that for the PRNG - so it seems fine.

[bilderbuchi]

Since it is a recommendation, it also seems weird to have it in the normative text.

I'm afraid I don't follow/agree. Some sentence being normative or non-normative seems orthogonal/unrelated to the specific requirements level (must/should/may) used in the sentence.
I'm not aware why may/should seem weird to have in a normative text? (Cf. many other technical standards, e.g. zmq) Could you elaborate?

[HansOlsson]

Since it is a recommendation, it also seems weird to have it in the normative text.

I'm afraid I don't follow/agree.

Hmm...

On second thought I agree that it isn't that weird, and we could make it normative.

[henrikt-ma]

On the other hand having a model: output Real y1=(if getInstanceName()=="add") then u1+u2 else u1*u2; would be bad; and similarly for other cases where the behavior of the model depends on its instance name.

Among all the things that can surprise users and make working with Modelica unpredictable and hard, being able to rename components without changing simulation results is a small but important property worth fighting for. With simulation results depending on getInstanceName(), one is deliberately breaking this principle, so I do agree with the specification's strong recommendation not to do so.

[HansOlsson]

To discuss:

• Keep recommendation, right?
• Move to normative?

[HansOlsson]

Language group: Favor