CombiTimeTable not working with NF

[massimo ceraolo]

The file "Test3.mo" when used with the file "Test.txt" does not run with NF.
Error message:

[2] 22:28:19 Translation Error
[C:/dev/OM64bit/OMCompiler/Compiler/NFFrontEnd/NFEvalFunction.mo: 993:9-993:97]: Internal error NFEvalFunction.evaluateKnownExternal: failed to evaluate ModelicaStandardTables_CombiTimeTable_init2

With OF I get the error message:

[2] 22:32:19 Translation Error
[Modelica.Blocks.Sources: 2175:5-2176:48]: Variable combiTimeTable1.tableID not found in scope Modelica.Blocks.Sources.CombiTimeTable$combiTimeTable1.

[3] 22:32:19 Translation Error
[Modelica.Blocks.Sources: 2177:5-2178:48]: Variable combiTimeTable1.tableID not found in scope Modelica.Blocks.Sources.CombiTimeTable$combiTimeTable1.

but the model runs correctly.

Finally, the model runs smoothly with Dymola.

[Per Östlund]

I can't reproduce your results with either the NF or the OF. The NF compiles without any warnings or errors, while the OF complains about unused input variables in some of the functions (which the NF doesn't check yet).

Are you using any additional compiler flags that might influence the flattening? I tried both with and without the obvious -d=evaluateAllParameters, but that made no difference with either of the frontends.

[Per Östlund]

I tried using OMEdit too, and then the variable does indeed fail with the error you mentioned. It works if the "Evaluate all parameters at compile time" option is disabled though, but oddly enough it works when using omc directly with the -d=evaluateAllParameters flag. I'm not sure what's different when compiling the model from OMEdit, I will have to investigate more.

[Per Östlund]

Fixed in bdcee90d. The NF now ignores external objects when deciding which parameters to evaluate, since external objects shouldn't be evaluated at compile-time.

The reason why I couldn't reproduce the issue at first was because tableID in CombiTimeTable was changed to be a parameter in MSL 3.2.3, while earlier it was a continuous variable. OMEdit loads MSL 3.2.3 by default and doesn't reload it even if the model's uses-annotation indicates that a different version should be used, while compiling the model by passing it directly to omc causes MSL 3.2.2 to be loaded instead as per the annotation.

[massimo ceraolo]

thank you!

[Francesco Casella]

Replying to perost:

The reason why I couldn't reproduce the issue at first was because tableID in CombiTimeTable was changed to be a parameter in MSL 3.2.3, while earlier it was a continuous variable. OMEdit loads MSL 3.2.3 by default and doesn't reload it even if the model's uses-annotation indicates that a different version should be used, while compiling the model by passing it directly to omc causes MSL 3.2.2 to be loaded instead as per the annotation.

Not following the uses annotation is not a good thing. I opened #4134 on this topic almost two years ago, do you think that is an easy fix?

Besides, MAP-LIB plans to release MSL 4.0.0 with conversion scripts next year, so we'll also have to deal with them soon.

[Per Östlund]

Replying to casella:

Replying to perost:

The reason why I couldn't reproduce the issue at first was because tableID in CombiTimeTable was changed to be a parameter in MSL 3.2.3, while earlier it was a continuous variable. OMEdit loads MSL 3.2.3 by default and doesn't reload it even if the model's uses-annotation indicates that a different version should be used, while compiling the model by passing it directly to omc causes MSL 3.2.2 to be loaded instead as per the annotation.

Not following the uses annotation is not a good thing. I opened #4134 on this topic almost two years ago, do you think that is an easy fix?

#4134 is about which version to load when there are conflicting uses-annotations. When it comes to OMEdit though it loads a version of the MSL at startup, and the compiler will not discard and load another version of a library automatically. OMEdit does print out the warning from the compiler that another version is already loaded, but this is easy to ignore I guess.

[Francesco Casella]

Replying to perost:

#4134 is about which version to load when there are conflicting uses-annotations.

You're right. BTW, I added one more comment to that ticket.

When it comes to OMEdit though it loads a version of the MSL at startup, and the compiler will not discard and load another version of a library automatically.

This is not ideal, I opened #5427 on the topic.

OMEdit does print out the warning from the compiler that another version is already loaded, but this is easy to ignore I guess.

You can always ignore warnings, but sometimes this has consequences, as the original case of this ticket demonstrates. This will impossible to ignore when we get MSL 4.0.0, see #5427.

[Arinomo <trista.arinomo@…>]

Replying to perost:

Fixed in bdcee90d. The NF now ignores external objects when deciding which parameters to evaluate, since external objects shouldn't be evaluated at compile-time.

I've got a simmilar error when the "Evaluate all parameters at compile time" is enable. Using a version V1.14.0-dev-26499-g3e12ff23da.

[Francesco Casella]

Replying to Arinomo <trista.arinomo@…>:

Replying to perost:

Fixed in bdcee90d. The NF now ignores external objects when deciding which parameters to evaluate, since external objects shouldn't be evaluated at compile-time.

I've got a simmilar error when the "Evaluate all parameters at compile time" is enable. Using a version V1.14.0-dev-26499-g3e12ff23da.

I tried a simple model using CombiTimeTable, Evaluate all parameters, and -d=newInst

model M
  Modelica.Blocks.Sources.CombiTimeTable combiTimeTable1(table = [0, 0; 1, 1; 2, 4]);
equation
annotation(
    uses(Modelica(version = "3.2.3")));
end M;

It worked just fine. @Arinomo, can you post an example that allows to reproduce your problem?

[Arinomo <trista.arinomo@…>]

Replying to casella:

It worked just fine. @Arinomo, can you post an example that allows to reproduce your problem?

Herre is my Test model:

model Quicktest
  Modelica.Blocks.Sources.CombiTimeTable combiTimeTable1(extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint, smoothness = Modelica.Blocks.Types.Smoothness.ConstantSegments, table = [0, 14; 10, 18; 20, 14], tableOnFile = false) annotation(
    Placement(visible = true, transformation(origin = {-18, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation

  annotation(
    Icon(coordinateSystem(preserveAspectRatio = false)),
    experiment(StartTime = 0, StopTime = 50, Tolerance = 1e-06, Interval = 0.1),
    __OpenModelica_commandLineOptions = "--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=initialization,evaluateAllParameters,NLSanalyticJacobian -d=initialization ",
    __OpenModelica_simulationFlags(lv = "LOG_STATS", outputFormat = "mat", s = "dassl"));
end Quicktest;

[Francesco Casella]

Works for me, both with old and new frontend. I'm using v1.14.0-dev-26534-g3ae6d2dc06 (64-bit) on Windows 10. Which version are you using?

[Arinomo <trista.arinomo@…>]

Im using OMEdit V1.14.0-dev-62-g21f82f33 (64-bit)
Connected to v1.14.0-dev-202-g09f079c67 (64-bit) on Windows 10.

Hmm.. thats a bit strange. But what does it means, when there are a translation errors but the simulation works properly? shouldn't translation error abort the simulation process?

[Francesco Casella]

Sounds like you're using a very old nightly build. Please try the latest one

[Adrian Pop]

I think the problem might be with the flags you have enabled: -d=evaluateAllParameters.
That forces evaluation of all parameters.

[Francesco Casella]

@adrpo, that is supposed to have been fixed, see comment:3. I'm running the model including that annotation on a recent nightly build, and it works fine.

[Adrian Pop]

@casella: true, is a combination of that flag and the old nightly-build.