OM does not compile Modelica trunk experiments with tables

[Christian Kral <dr.christian.kral@…>]

In OMEdit I changed the default Modelica library from "default" to "trunk" in oder to load the actual master version from Github automatically. I then tried to simulate the example Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Conveyor but the compilation fails. The error message states:

Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Conveyor_functions.o: In function `omc_Modelica_Blocks_Types_ExternalCombiTimeTable_constructor':
Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Conveyor_functions.c:(.text+0x618): undefined reference to `ModelicaStandardTables_CombiTimeTable_init2'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_Conveyor.makefile:30: recipe for target 'omc_main_target' failed
make: *** [omc_main_target] Error 1
Compilation process failed. Exited with code 2.

This is a table issue, as other examples without tables work OK. However, the experiment simulates fine if the default Modelica version is used.

I am using the version

OMEdit 1.12.0~dev-327-g7dd1e00
Connected to OpenModelica 1.12.0~dev-944-g1a8dd60

[tbc@…]

ModelicaStandardTables_CombiTimeTable_init2 is a new function in ModelicaStandardTables master. I believe you also need to updated C-Sources of ModelicaStandardTables.

[tbc@…]

Maybe the up-to-date binaries of ​https://github.com/modelica/Modelica/pull/2273 are useful for you.

[massimo ceraolo]

Another non-working model with MSL trunk, also with OM 1.12-beta1 is:

model cyc
  Modelica.Blocks.Sources.CombiTimeTable driveCyc(columns = {2},
  extrapolation = Modelica.Blocks.Types.Extrapolation.Periodic, table = [0, 0; 1, 1; 2, 4],
  tableOnFile = false);
end cyc;

It looks like nearly all table models stop to work with trunk version of MSL.
Maybe I'm wrong, but this seems to me a critical (or even blocker) issue for 1.13.
Obviously developers are free to change again the priority in case they do not agree.

[anonymous]

Did you really check the latest master which contains the updated binaries?

[Adrian Pop]

The problem is that we have the same implementation (the one from MSL 3.2.2) that we use for tables regardless of MSL library loaded.
They have changed the table implementation interface in MSL trunk and we need to update our table C code. I have tried to do that but somehow it breaks our tests (is not backwards compatible). I will check it again.

[anonymous]

It should be backward-compatible. Let me know which of your test fails?

[anonymous]

One other idea is to use the provided binaries / build-scripts of MSL tables instead of installing pre-built binaries of MSL 3.2.2.

[massimo ceraolo]

well, maybe it is not a good idea to set "critical" priority for what is just compliance with a trunk version which, in principle, may happen to be changed before next official MSL release.

[tbc@…]

MSL table implementation for v3.2.3 (or whatever it will be called one day) is feature-ready in master. Thus, if there is any backward-compatibility breaking issue, please let me know at GiHub.

[Adrian Pop]

Replying to tbc@…:

MSL table implementation for v3.2.3 (or whatever it will be called one day) is feature-ready in master. Thus, if there is any backward-compatibility breaking issue, please let me know at GiHub.

I asked one of our developer to look into the issue first to get more information so we can tell you where to look for the problem but he had no time. I will try it once again to update the C code to the latest, maybe the problem is solved. If not, I'll get back to you.

[Martin Sjölund]

The current sources don't compile with our C++ runtime. TABLE_SHARE is not set and there are compilation errors for that case (simple solution is to just define TABLE_SHARE, but seems bad if it doesn't work)...

[tbc@…]

Confirmed. Will fix it upstream.

[tbc@…]

Fixed upstream by ​https://github.com/modelica/Modelica/commit/8209e73d7739ebcacd779f0d189d0a2885dfe105.

[tbc@…]

Any news on this ticket?

[Adrian Pop]

Replying to tbc@…:

Any news on this ticket?

Yes. We have 2 tests that fail:
​https://github.com/OpenModelica/OpenModelica-testsuite/blob/master/openmodelica/cruntime/optimization/basic/TT2.mos
​https://github.com/OpenModelica/OpenModelica-testsuite/blob/master/openmodelica/cruntime/optimization/basic/TT3.mos

Basically I think the values we get for those tables are different in MSL trunk than in MSL 3.2.2.

Modelica.Blocks.Sources.CombiTimeTable timeTable(table = [0,1; 1,3; 2,-3; 3,5; 4,7; 5, 0], 
   extrapolation = Modelica.Blocks.Types.Extrapolation.Periodic);
Modelica.Blocks.Sources.CombiTimeTable timeTable(table = [0,1; 1,3; 2,-3; 3,5; 4,7; 5, 0], 
   extrapolation = Modelica.Blocks.Types.Extrapolation.HoldLastPoint);

The non-default extrapolation seems to be the issue.

The problem is that these are optimization tests and I don't really know what is happening in there. Maybe Willi or Lennart can explain more (cc here).

I guess you could test if the values you get from these tables using 3.2.2 vs trunk are the same, or not, by using some Modelica model.

[Adrian Pop]

The PR for 3rdParty update to latest C code from MSL trunk:
​https://github.com/OpenModelica/OMCompiler-3rdParty/pull/23

[tbc@…]

Sorry, cannot really reproduce. But, I can think of my changes for ​msl:#2080 and ​msl:#1627 that lead to more accurate results as time events on interval boundaries are now generated by default for linear interpolation. Since you only have 20 output points (numberOfIntervals=20) in your result files, you will probably not have hit the interval boundaries with MSL 3.2.2, whereas MSL master does. For me this sounds reasonable and acceptable.
You can prove youself if you compile ModelicaStandardTables with DEBUG_TIME_EVENTS defined.

[Adrian Pop]

I think the tests that fail are wrong and we only get that because of the better implementation of tables. I will push the changes in and disable these two tests.

[tbc@…]

This will go to 1.12 or 1.13 then?

[Adrian Pop]

Both. I will push on the 1.12 maintenance branch as well.

[Adrian Pop]

It seems that some ModelicaTest 3.2.1 models do not verify anymore with the MSL trunk table implementation:
​https://libraries.openmodelica.org/branches/history/master/2017-09-24%2017:32:58..2017-09-25%2009:30:42.html
We will need to check those to see if the differences are acceptable.

[Christian Kral <dr.christian.kral@…>]

I very much appreciate your effort for making this work. Thank you.