3

So far, using Wolfram System Modeler 4.3 and 5.1 the following minimal example would compile without errors:

model UnitErrorModel
    MyComponent c( hasUnit = "myUnit" );

    block MyComponent
        parameter String hasUnit = "1";
        output Real y( unit = hasUnit );
    equation
        y = 10;
    end MyComponent;

end UnitErrorModel;

But with the new release of WSM 12.0 (the jump in version is due to an alignment with the current release of Wolfram's flagship Mathematica) I am getting an error message:

Internal error: Codegen.getValueString: Non-constant expression:c.hasUnit

(Note: The error is given by WSMLink'WSMSimulate in Mathematica 12.0 which is running System Modeler 12.0 internally; here asking for the "InternalValues" property of the above model since I have not installed WSM 12.0 right now).

Trying to simulate the above model in OpenModelica [OMEdit v. 1.13.2 (64-bit)] reveals:

SimCodeUtil.mo: 8492:9-8492:218]: Internal error Unexpected expression (should have been handled earlier, probably in the front-end. Unit/displayUnit expression is not a string literal: c.hasUnit

So it seems that to set the unit attribute I cannot make use of a variable that has parameter variability? Why is this - after all shouldn't it suffice that the compiler can hard-wire the unit when compiling for runtime (after all the given model will run without any error in WSM 4.3 and 5.1)?

EDIT: From the answer to an older question of mine I had believed that at least final parameters might be used to set the unit-attribute. Making the modification final (e.g. c( final hasUnit = "myUnit" ) does not resolve the issue.

gwr
  • 465
  • 6
  • 17
  • Does it simulate if you only use "Model Center" and "Simulation Center". `WSMLink'WSMSimulate` sounds like it is something related to the Matematica functionality. – jrhodin May 15 '19 at 17:44
  • @jrhodin I have removed WSM 12.0, but it would not compile there using "Model Center" and "Simulation Center" only, when I had it installed. I thought that at least a "final" parameter could be used to set a unit-attribute... – gwr May 15 '19 at 17:45
  • 1
    This works in Dymola, even in pedantic mode (which is more strict in checking if the code is conform with the Modelica specification). – marco May 16 '19 at 05:56
  • @marco So it seems, that the example is not really violating Modelica specs? – gwr May 16 '19 at 05:59
  • Yes, from a Dymola user point of view it definitely does. – marco May 16 '19 at 06:05
  • 1
    Does it make a difference whether you use `constant` instead of `parameter`? – matth May 16 '19 at 08:14
  • @matth Yes, I just tried and it does not cause an error! A `parameter` would be more natural and convenient, but at least I just need marginal changes in my library. I am still not finding a reason from the specs for a `parameter` being a violation... – gwr May 16 '19 at 08:31
  • 1
    Yes, parameter would be nicer, and should probably work, but at least you have a workaround for now. You can also use `replaceable constant` and set the unit during instantiation. – matth May 16 '19 at 09:10
  • And another idea that should work: `parameter String hasUnit = "1" annotation (Evaluate=true);` Then it will be evaluated during compilation and becomes a string literal. But to change it, you will have to recompile! Also, you might want to send an email to Wolfram and ask why it does not work anymore. – matth May 16 '19 at 11:00
  • @matth Sorry to mention this a bit late, but I cross posted on [Wolfram Community](https://community.wolfram.com/groups/-/m/t/1684057); you may find WRI‘s answer there interesting. They have filed a proposal for the Modelica specs as they see `constants` more fitting for the unit attribute. – gwr May 16 '19 at 17:59

1 Answers1

0

I have been given feedback on Wolfram Community by someone from Wolfram MathCore regarding this issue:

You are correct in that it's not in violation with the specification, although making it a constant makes more sense since you would invalidate all your static unit checking if you are allowed to change the unit after building the simulation. We filed an issue on the specification regarding this (Modelica Specification Issue # 2362).

So, MatheCore is a bit ahead of the game in proposing a Modelica specification change that they have already implemented. ;-)

Note: That in Wolfram System Modeler (12.0) using the annotation Evaluate = true will not cure the problem (cf. the comment above by @matth).

As a workaround variables used to set the unit attribute should have constant variability, but can nevertheless by included in user dialogs to be interactively changed using annotation(Dialog(group = "GroupName")).

gwr
  • 465
  • 6
  • 17