3d visualization is broken because of initialization

[Adrian Pop]

modelica3d.mos script:

loadModelica3D();getErrorString(); 
loadString("model DoublePendulum 
extends Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum; 
inner ModelicaServices.Modelica3D.Controller m3d_control; 
end DoublePendulum;");getErrorString(); 
simulate(DoublePendulum); getErrorString();

adrpo@ida-liu050 ~/dev/OpenModelica/build/bin/
$ ../omc modelica3d.mos 
true
""
true
""
record SimulationResult
    resultFile = "",
    simulationOptions = "startTime = 0.0, stopTime = 1.0, numberOfIntervals = 500, tolerance = 1e-006, method = 'dassl', fileNamePrefix = 'DoublePendulum', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''",
    messages = "Simulation execution failed for model: DoublePendulum
assert            | debug   | No system for the symbolic initialization was generated.
assert            | info    | simulation terminated by an assertion at initialization
",
    timeFrontend = 2.268670310355102,
    timeBackend = 23.60382163839716,
    timeSimCode = 0.6926140243766298,
    timeTemplates = 0.7079724098002336,
    timeCompile = 4.992600859056393
end SimulationResult;
"Notification: The given system is mixed-determined.   [index > 0]
Notification: The given system is mixed-determined.   [index > 1]
Notification: The given system is mixed-determined.   [index > 2]
Notification: The given system is mixed-determined.   [index > 3]
Error: No system for the symbolic initialization was generated.

[Adrian Pop]

The question is what can we do to fix this.
I wonder if we could fix the modelica3d code to circumvent this issue.

[Lennart Ochel]

The following system causes the error:

Variables (2)
========================================
1: world.z_label.cylinders[1].rotated:DISCRETE(fixed = false protected = true ) .DoublePendulum, .Modelica.Mechanics.MultiBody.World, .Modelica.Mechanics.MultiBody.Visualizers.Internal.Lines$world$z_label, .Modelica.Mechanics.MultiBody.Visualizers.Advanced.Shape$world$z_label$cylinders, .Boolean type: Boolean 
2: $PRE.world.z_label.cylinders[1].rotated:DISCRETE(fixed = false protected = true ) .DoublePendulum, .Modelica.Mechanics.MultiBody.World, .Modelica.Mechanics.MultiBody.Visualizers.Internal.Lines$world$z_label, .Modelica.Mechanics.MultiBody.Visualizers.Advanced.Shape$world$z_label$cylinders, .Boolean type: Boolean 


Equations (3, 3)
========================================
1/1 (1): world.z_label.cylinders[1].rotated = $PRE.world.z_label.cylinders[1].rotated   [dynamic]
2/2 (1): world.z_label.cylinders[1].rotated = $PRE.world.z_label.cylinders[1].rotated   [dynamic]
3/3 (1): world.z_label.cylinders[1].rotated = $PRE.world.z_label.cylinders[1].rotated   [dynamic]

[Lennart Ochel]

The equation is probably accidentally introduced multiple time by inlineWhenForInitialization.

[Lennart Ochel]

Now, I can describe the issue more precisely:

There is one when-algorithm for each element of world.z_label.cylinders[:].rotated. That means one when-algorithm that assign to world.z_label.cylinders[1].rotated, and on when-algorithm that assign to world.z_label.cylinders[2].rotated and one when-algorithm that assign to world.z_label.cylinders[3].rotated.
Since all of these when-algorithm are inactive during initialization, v = pre(v) equations are introduced for all lhs of those when-algorithm. The key point here is, that arrays get expanded in algorithm. Therefore, each algorithm introduce the same equations for the same three variables and we end up with three of each of them.

I think it is needed to expand the arrays due to the specification. So maybe the library need to be changed.

[Adrian Pop]

Fixed in r25016.
It can be done better by sending the hashtable for lhscrefs from inlineWhenForInitializationSystem and only when you come back you add the equations for the unique variables.
Modelica3D (at least DoublePendulum) works now.

[Mahder Alemseged Gebremedhin]

Just saw this ticket. I can comment on the expansion issue. I actually tried to fix this model somehow (well a related issues). The issue is things like world.z_label.cylinders[:].rotated should not have been expanded when cylinders is a non record type. As it is written now crefExpand will expand this array. Because, as lennart said, if one array member is assigned to in an algorithm section then the whole array is considered as modified. However arrays of models, blocks ... should not be expanded at all (Except in the front end. e.g expanding connector arrays). Only arrays of simple types and records need to be expanded anywhere else.

I tried to fix the expansion and counting of variables after this model started failing for changes I made. Managed to fix the counting issues but then SimCode creation failed for some models. So I decided to put it aside for a while and finish up with the PowerSystems issues and reverted part of the change I made.

I will anyway try to fix the SimCode issues as well and commit the changes.

[Lennart Ochel]

Replying to adrpo:

Fixed in r25016.
It can be done better by sending the hashtable for lhscrefs from inlineWhenForInitializationSystem and only when you come back you add the equations for the unique variables.

I improved the workaround that way, because the previous hack was a huge performance issue for bigger models (c45436).