2

While the Advanced Modelica Tutorial: Developing Modelica Libraries is from 2003, I would still believe that the code from page 29 would give a causal connector (RealPort) with a replaceable type:

connector RealPort
  replaceable type SignalType = Real;
  extends SignalType;
end RealPort;

While this code works in the current release for Wolfram SystemModeler, Open Modelica v1.16.0-dev.03 (64-bit) complains, giving the following error:

Class 'SignalType' in 'extends SignalType' is replaceable, the base class name must be transitively non-replaceable.

So, who is right about transitive non-replaceability here and how to do this correctly?

References:

  • Section 6.2.1 Modelica Language Specification v3.5-dev ("Transitive non-Replaceable")

  • Section 7.1.4 Modelica Language Specification v3.5-dev ("Restrictions on Base Classes and Constraining Types to be Transitively Non-Replaceable")

gwr
  • 465
  • 6
  • 17
  • OpenModelica for sure. This was allowed in previous Modelica specifications but not anymore. Dymola with Pedantic Mode also complains: "Check of RealPort: Base class SignalType is replaceable". Without Pedantic Mode, Dymola allows this and issues a warning. – Adrian Pop Jul 14 '20 at 21:32
  • 2
    You can however use short class definition instead of extends: replaceable type SignalType = Real; connector RealPort = SignalType; This should work fine. – Adrian Pop Jul 14 '20 at 21:33

1 Answers1

4

The class above is not transitively non-replaceable and thus translation should fail.

The problem that the non-replaceable rule intends to avoid is a set of model such as:

connector RealPort
  replaceable type SignalType = Real;
  extends SignalType;
end RealPort;

type MySignal
  type SignalType=Integer;
  extends Real(...);
end MySignal;

connector MyPort=RealPort(redeclare type SignalType=MySignal);

The problem with those classes is to that SignalType in MyPort seems to be two things at once, and it is not clear where the problem was introduced, as the redeclare seems consistent with the constraining class and the original class looked ok.

(Transitively just mean that you can have intermediate non-replaceable classes to confuse things.)

And the work-around by Adrian Pop is a good solution.

Hans Olsson
  • 11,123
  • 15
  • 38
  • 1
    Ok, but why then do tools like Dymola and SystemModeler “lure” me to believe that I can get away with violating the specs? (SystemModeler never gives a warning) So that code becomes less portable to non-proprietary tools? ;-) – gwr Jul 15 '20 at 08:35
  • 2
    Dymola always gives a message indicating that it is wrong. (At least in versions I tested.) However, normally it's a warning as there exists old models that used this, and breaking old models when a new rule is introduced also breaks portability. – Hans Olsson Jul 15 '20 at 08:55