The NF wrongly computes cardinality when translating MultiBody model

[Francesco Casella]

The code to simulate ​Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel is generated successfully when the model is tested by Hudson, which I assume calls the simulate API function.

However, if I try to simulate it in OMEdit with -d=newInst, the following error is obtained:

[1] 14:15:49 Symbolic Error
[Modelica.Mechanics.MultiBody.Interfaces: 732:5-733:65]: Assertion triggered during translation: "Connector frame_a of visualizer object is not connected".

which is wrong, since the port is definitely connected to a fixed component, see ​the source code.
This is the transcript of the OMEdit log:

cd("C:/Users/Francesco Casella/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel") 14:19:18:915
"C:/Users/Francesco Casella/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel" 14:19:18:915
#s#; 0.001; 69.063; 'cd("C:/Users/Francesco Casella/AppData/Local/Temp/OpenModelica/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel")'

clearCommandLineOptions() 14:19:18:918
true 14:19:18:918
#s#; 0; 69.063; 'clearCommandLineOptions()'

setMatchingAlgorithm("PFPlusExt") 14:19:18:920
true 14:19:18:921
#s#; 0.003; 69.066; 'setMatchingAlgorithm("PFPlusExt")'

setIndexReductionMethod("dynamicStateSelection") 14:19:18:921
true 14:19:18:931
#s#; 0.01; 69.076; 'setIndexReductionMethod("dynamicStateSelection")'

setCommandLineOptions("+simCodeTarget=C") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+simCodeTarget=C")'

setCommandLineOptions("+target=gcc") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+target=gcc")'

setCommandLineOptions("-d=initialization,newInst") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("-d=initialization,newInst")'

setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false")'

setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false") 14:19:18:931
true 14:19:18:931
#s#; 0; 69.076; 'setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false")'

setCommandLineOptions("+profiling=none") 14:19:18:931
true 14:19:18:931
#s#; 0.004; 69.08; 'setCommandLineOptions("+profiling=none")'

setCommandLineOptions("-d=infoXmlOperations") 14:19:18:935
true 14:19:18:935
#s#; 0; 69.08; 'setCommandLineOptions("-d=infoXmlOperations")'

translateModel(Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel,startTime=0, stopTime=4, numberOfIntervals=500, method="dassl", tolerance=1e-06, outputFormat="mat", variableFilter=".*") 14:19:18:935
false 14:19:19:166
#s#; 0.231; 69.311; 'translateModel(Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel,startTime=0, stopTime=4, numberOfIntervals=500, method="dassl", tolerance=1e-06, outputFormat="mat", variableFilter=".*")'

errors:=getMessagesStringInternal() 14:19:19:166
{record OpenModelica.Scripting.ErrorMessage
    info = record OpenModelica.Scripting.SourceInfo
    filename = "C:/OpenModelica1.14.0-dev-64bit/lib/omlibrary/Modelica 3.2.2/Mechanics/MultiBody/Interfaces.mo",
    readonly = false,
    lineStart = 732,
    columnStart = 5,
    lineEnd = 733,
    columnEnd = 65
end OpenModelica.Scripting.SourceInfo;,
    message = "Assertion triggered during translation: \"Connector frame_a of visualizer object is not connected\".",
    kind = .OpenModelica.Scripting.ErrorKind.symbolic,
    level = .OpenModelica.Scripting.ErrorLevel.error,
    id = 98
end OpenModelica.Scripting.ErrorMessage;} 14:19:19:173
#s#; 0.007; 69.318; 'errors:=getMessagesStringInternal()'

showing that the translate API is used instead.

It seems that something goes wrong there with this cardinality-based assert.

[Adeel Asghar]

The link that you shared says,

Running command: translateModel(Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel,tolerance=1e-06,outputFormat="mat",numberOfIntervals=5000,variableFilter="time|wheel1.angles.1.|wheel1.angles.2.|wheel1.angles.3.|wheel1.der_angles.1.|wheel1.der_angles.2.|wheel1.der_angles.3.|wheel1.x|wheel1.y",fileNamePrefix="Modelica_trunk_Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel")

So its also using translateModel.

One thing I noticed is that I am using MSL version 3.2.3 and you have 3.2.2.

[Per Östlund]

Here's a script to reproduce the issue:

loadModel(Modelica,{"default"},false,"",false);
loadModel(ModelicaReference,{"default"},false,"",false);
getComponentAnnotations(Modelica.Mechanics.MultiBody.Parts.Fixed);
setCommandLineOptions("-d=newInst");
translateModel(Modelica.Mechanics.MultiBody.Examples.Elementary.RollingWheel);
getErrorString();

I have no clue why looking up annotations of Modelica.Mechanics.MultiBody.Parts.Fixed messes up the new frontend though. I'll investigate more tomorrow.

[Per Östlund]

Fixed in 58b2c7d8.

The issue was that the NF, like the OF, uses System.getUsesCardinality() to determine whether a model uses cardinality or not, to avoid doing unnecessary work if it doesn't. However, it turns out that that function isn't magical, and you actually need to use System.setUsesCardinality() to set the flag as appropriate during instantiation.

The NF didn't do that, so it just used whatever value the flag happended to have. It worked as long as only the NF was used, because the default value was true. But the interactive API still uses the old frontend, which depending on the API call used might change the cardinality flag depending on whether the queried model contains cardinality or not.

[massimo ceraolo]

[...] But the interactive API still uses the old frontend [...]

Ehm... I've waited for years that OM speeds up when opening models. This would be a boon for teaching: today opening models could even require more than simulating them.
I know that the NF is much faster than old's. I expect that using it interactively would be improve model-opening speed a lot (as well as also model dragging-by-keyboard speed, which is also very low today)
May I ask when switch to NF-based interactive API will occur?
Thanks

[Per Östlund]

Replying to ceraolo:

[...] But the interactive API still uses the old frontend [...]

Ehm... I've waited for years that OM speeds up when opening models. This would be a boon for teaching: today opening models could even require more than simulating them.
I know that the NF is much faster than old's. I expect that using it interactively would be improve model-opening speed a lot (as well as also model dragging-by-keyboard speed, which is also very low today)
May I ask when switch to NF-based interactive API will occur?
Thanks

There're currently no hard plans for when to start using the NF for the interactive API. The NF has now reached a state where doing so is starting to make sense though. Reimplementing the whole API will be a lot of work, but maybe we could start with the most common ones used by OMEdit.

[Adrian Pop]

I've been working on this for some time now and I'm trying to push my changes in, but there are still some remaining issues. My changes include using the NF for getComponentAnnotations which is the biggest hog when working with OMEdit. The plan is to have this in master and nightlies as soon as possible.

[massimo ceraolo]

thanks a lot @perost and @adrpo.
I'll stay tuned!