Assignment of external objects not conform with MLS

[tbeu]

Customer asked for UDP support in SimulationX. Thus I tried to figure out why SerialPackager fails in SimulationX. The reason is that the external objects, i.e. there constructors are used in assignments which is illegal according to the MLS 3.3 (rev 1) section 12.9.7: "Only the constructor may return external objects and external object can only be bound in component declarations and neither modified later nor assigned to."
Thus the current design of the SerialPackager and the Communication package is bad in two ways 😒

1. External objects in connectors are not legal since the connect statement is equivalent to an assignment equation.
2. Constructing the external object in when initial() is not legal at all.

Whereas SimulationX is tolerant with the first problem the second problem is a really bad design failure. I changed the construction of the external object from something like

model Packager
  Interfaces.PackageOut pkgOut;
  protected
    Integer bufferSize;
  equation
    when initial() then
      bufferSize = something;
      pkgOut.pkg = SerialPackager(bufferSize); // create external object here
    end when;
end Packager;

to

model Packager
  Interfaces.PackageOut pkgOut(pkg = SerialPackager(bufferSize));
  protected
    Integer bufferSize;
  equation
    when initial() then
      bufferSize = something;
    end when;
end Packager;

which still violates the first problem but could fix the second one. However, this now reveals the bad design of the auto propagation of the buffer size. It is not clear which external object defines the auto buffer size and which external object uses the derived buffer size.

In the need for a quick fix for the second problem I would consider to either use a fixed buffer size or refer to some global parameters like e.g. Modelica.Mechanics.MultiBody.World of the MSL holds.

@bernhard-thiele, @MartinOtter What do you think? Can we find a workaround in order to get the customer project running soon? Do you have other ideas to fix the second problem (or even the first problem to make the library really standard conform)? I am willing to contribute of course.

[bernhard-thiele]

I don't think that the auto propagation logic is wrong, but I agree that it is contrived. The external object is propagated through causal connectors, so the first block (that which doesn't have an input) needs to construct the external object. The problem is that we need to know the required size of the buffer when constructing it. For this an initial equations system is used which determines the buffer size.

I just tested the fix that you proposed pkgOut(pkg = SerialPackager(bufferSize)) with Dymola 2015 and it worked.

Regarding the specification I'm not so dead sure how to interpret it. If one is not allowed to "assign" to external objects, then even the constructor can't assign to it? Isn't assignment used in the MLS in the sense of algorithmic assignment while otherwise we talk from binding equations, e.g., MLS 3.3 Section 3.8: "For an assignment v:=expr or binding equation v=expr, v must be declared to be at least as variable as expr."?

Anyway, I don't like the complex propagation stuff myself so much and thought about adding an alternative simpler packaging system but never did it.

Are you aware that there is already an option to use a fixed buffer size? You can set parameter useBackwardPropagatedBufferSize = false and thus enable parameter userBufferSize. Did you try this as a workaround?

[tbeu]

Quick answer: Please read again: External objects can only be bound in component declarations. Assigments in equation or algorithm sections are not legal.

[tbeu]

Longer answer: I changed the constuction of all external object instances to component declarations (as suggested above). This way SimulationX finally was able to successfully finish the symbolic analysis, i.e. resulted in a runnable simulation model. The problem then was that the buffer size was zero and hence adding the first data to the package failed (with ModelicaError). I did not yet switch the useBackwardPropagatedBufferSize parameter to false. I will try it next week.

[tbeu]

Please test my proposed changes and pull them if you want.

[bernhard-thiele]

Merged your branch in a42cb1b

I can't test it in the moment in Dymola due to our license being use by somebody else, but it looks good...

[tbeu]

Thanks for merging. Please do test once you have the license.

[bernhard-thiele]

Just tested it and it worked fine.

[tbeu]

I tested all the SerialPackager example models in SimulationX: They work as expected provided that external solvers (i.e. CVODE Method or Fixed Step Solver) are selected. 😌 Currently it does not work if internal solvers ((ME)BDF) are chosen but this is left up to the SimulationX developers.

I'll close this issues though only the second issue is fixed (from SimulationX side). I still cannot say that MDD is standard conform. I rather recommend it to remove from github description.

[tbeu]

See https://trac.modelica.org/Modelica/ticket/1669 and https://trac.modelica.org/Modelica/ticket/1705 for related issues on external objects.