instance name

[modelica-trac-importer]

Reported by AHaumer on 5 May 2008 08:10 UTC In some professional applications it is desired that each component reports its own settings to a log-file (e.g. using Modelica.Utilities). To be able to distingiush between the reports (you might have mutliple instances of the same component) each component should be able to access its own fully qualified instance name, e.g. "model.subCircuit.componentxy". Of course the specification should prohibit abuse (e.g. changing the component's behaviour depending on its name). Anyhow, such a read-only variable "instanceName" would be a great improvement.

---

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

[modelica-trac-importer]

Modified by dietmarw on 6 May 2008 07:06 UTC

[modelica-trac-importer]

Comment by HansOlsson on 8 Sep 2008 19:23 UTC Language grp at 58th design meeting:

Seems that we could add (need complete proposal). So many other bad designs are possible without using instanceName.

[modelica-trac-importer]

Modified by HansOlsson on 8 Sep 2008 19:23 UTC

[modelica-trac-importer]

Modified by AHaumer on 26 Jan 2010 15:36 UTC

[modelica-trac-importer]

Modified by AHaumer on 26 Jan 2010 15:36 UTC

[modelica-trac-importer]

Comment by christiankral on 23 Mar 2010 18:29 UTC

Proposal

The proposal for the getting the name of the actual instance is to implement an internal function

getInstanceName()

which returns a string with the actual instance name.

[modelica-trac-importer]

Comment by PHarman on 30 Mar 2010 10:54 UTC What would such a function return at the top-level of a model?

• An empty string "" (This makes most sense considering it should be the instance name, but would look strange in logging messages)
• The name of the class e.g. "MyModel".
• The full reference of the class e.g. "MyPackage.MyModel".
• An error
• Something else?

[modelica-trac-importer]

Comment by HansOlsson on 15 Sep 2010 15:09 UTC Planned to include in some way in Modelica 4; there is the issue how to prevent that this function is used in e.g. if-clauses to modify the model behaviour.

[modelica-trac-importer]

Comment by Volker Beuter on 23 Nov 2010 23:57 UTC I think this is a good idea, but I cannot see how to prevent "abuse" without being too restrictive. Think of the case, where a logging message is only to be written for a certain instance (in order to prevent duplicate messages). Here usage in an if expression ought to be allowed. It ought to be possible to apply string operations to the returned string (e.g. removing the path) and store this in a string parameter. If you want to rule out any dependence of the model on its instance name you do not only have to control the getInstanceName() function itself but also such depending parameters. This would mean a lot of extra semantics I suppose. Why not tolerate such abuse and just consider it as a bad style?

[modelica-trac-importer]

Comment by Martin Sjölund on 24 Nov 2010 07:09 UTC Only allowing it to be used in a statement that can not change the state of a simulation would be an obvious restriction, i.e. only function calls without return values (plus assert() and terminate()).

If it's only to be used for logging there should be no need to store a function of the value as a parameter. Simply call the function in the statement that is going to use getInstanceName() and let compilers optimize away the call. Another way to prevent duplicate messages would be to have a parameter Boolean printMessages in the class and only turn it on for classes that should print the messages (or let the external function function filter out duplicates).

[modelica-trac-importer]

Comment by otter on 29 Nov 2010 12:05 UTC Proposal at the 68th design meeting:

New built-in function: getInstanceName()

Returns a string with the name of the model/block that is simulated, appended with the fully qualified name of the instance in which this function is called.

Example:

package MyLib
  model Vehicle
     Engine engine;
     ...
  end Vehicle;

  model Engine
     Controller controller;
     ...
  end Engine;

  model Controller
  equation
    print("Info from: " + getInstanceName()); 
  end Controller;
end MyLib;

If MyLib.Vehicle is simulated, the call of getInstanceName() returns:

"Vehicle.engine.controller"

One might add to the specification that [misuse of this function, e.g., if the model equations are dependent on the return value, might trigger an error.]

Poll: in favor: 14: against: 0, abstain: 2

[modelica-trac-importer]

Modified by otter on 29 Nov 2010 15:12 UTC

[modelica-trac-importer]

Comment by otter on 24 Jan 2011 11:14 UTC At 69th design meeting:

Add to specification text the following comment

[The simulation result should not depend on the return value of this function. If this function is not called inside a model or block (e.g. the function is called in a function or in a constant of a package), the return value is not specified]

[modelica-trac-importer]

Comment by otter on 24 Jan 2011 11:16 UTC At 69th design meeting:

Add to specification text:

If this function is not called inside a model or block (e.g. the function is called in a function or in a constant of a package), the return value is not specified.

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

[modelica-trac-importer]

Comment by dietmarw on 25 Jan 2011 08:07 UTC Please don't forget the komma after "e.g." --> "e.g., ..."

[modelica-trac-importer]

Modified by hansolsson on 28 Sep 2011 12:49 UTC

[modelica-trac-importer]

Modified by hansolsson on 14 Dec 2011 10:43 UTC