Add ModelicaTest_trunk_cpp to nightly tests and add validations

[Rüdiger Franke]

Currently the Cpp runtime is only tested against MSL trunk. The tests should include ModelicaTest_trunk as well, in order to better reflect the current status. Only ModelicaTest covers Modelica.Math.Matrices, for example.

The documentation says that these tests are auto-generated. Could the Cpp tests be extended with a validation?

[Martin Sjölund]

There are no reference files to compare against for MSL trunk :(

[Rüdiger Franke]

Aren't the reference files the same as for the C runtime?

[Martin Sjölund]

Yes, but we do not have reference files for the C runtime MSL trunk. Only MSL 3.2.1 (maintenance).

[Adrian Pop]

That means we can add it as to the library testing but there will be no verification.

[Rüdiger Franke]

Hmmm... are you servers powerful enough to also test + validate Cpp with MSL 3.2.1? Or maybe replace MSL_trunk_cpp with MSL_3.2.1_cpp?

MSL_3.2.1_cpp, including validation, and ModelicaTest_trunk_cpp should give the best information.

[Martin Sjölund]

Perhaps. But just adding ModelicaTest_trunk_cpp would take more than an hour. The cppruntime tests take around twice as long as the C runtime tests despite failing on more tests and the frontend+backend taking the same amount of time.

[Adrian Pop]

Modelica Test coverage with C runtime takes 26 minutes currently.
Adding ModelicaTest_trunk_cpp and MSL_3.1.1_cpp with verification should not be that much.
I'll try to add these for tomorrow morning.

Library testing takes around 5-6 hours but is ran at night so it doesn't impact that much.

[Adrian Pop]

Maybe for later on, when we have more time, another alternative would be to change the library coverage so we build and run the models for:

• C runtime
• Cpp runtime
• FMU C runtime
• FMU Cpp runtime

for each model in a library.

A bit of work would be needed but that would make for way better testing.
Also we would skip duplicating jobs in Hudson for different runtimes.

[Rüdiger Franke]

That sounds fantastic!

The backend appears to generate different code for FMU than for simulation -- The DrumBoiler example simulates with Cpp, but fails to compile as Cpp FMU, because some names of algebraic loops are not resolved. A bit out of topic: but can you confirm that the backend generates different code for FMU?

The FMU tests might be restricted to models with external I/O. There hardly finds models with external I/O and experiment settings in Modelica libraries.

[Martin Sjölund]

The generated code is the same for the FMU and normal code, but the solver is different since it uses FMI for Modelica Exchange (right?). This is true for the C-code FMU at any rate. But you need to create some wrapper functions, etc.

[Adrian Pop]

Added MSL_3.2.1_cpp and ModelicaTest_trunk_cpp jobs to Hudson.
I'll close the ticket and we'll see in the morning what's going on.

[Rüdiger Franke]

Thanks! About 30 mins per test -- and some low hanging fruits, like the failed table tests.

Regarding our side discussion on regular simulation vs. FMI export: the former only generates the Jacobian A for states; the latter generates the full {{A, B}, {C, D}} Jacobian for inputs and outputs as well. This is where the Cpp runtime struggles for more complex models like the DrumBoiler. But it's also an additional challenge for the backend (see e.g. #3266).

[Rüdiger Franke]

OK, the failed table tests are related to the frontend. But nevertheless appear low hanging. A name clash with clocked equations?

[Adrian Pop]

Yes, it seems that there are some clash issues with Clock as a basic type and Modelica.Blocks.Sources.Clock. I'll open another ticket about that.

[Martin Sjölund]

I think there already is one such ticket.

[Martin Sjölund]

​m:#1538 is the ticket

[Adrian Pop]

Well, ​m:#1538 a Modelica trac ticket. I think we can handle it in the compiler by checking the environment (which is top for the Clock basic type).

[Martin Sjölund]

Well, there is still the problem that you are not allowed to declare the class (possibly). So why should we handle it?

Anyway, easiest way would be to use +std=3.2, I think. Because there are no 3.3 features in MSL.

[Adrian Pop]

This is ModelicaTest trunk that has these failures, not MSL:
​https://test.openmodelica.org/hudson/job/ModelicaTest_trunk_Flattening/lastCompletedBuild/testReport/
but I guess you're right and even in ModelicaTest there are is no Clock usage.
I opened #3273 about it and we'll see what we do about it.
From my side I think we should handle it as is not that complicated. Issue a warning and continue.

[Rüdiger Franke]

It should really be treated, considering that more than 100 table tests are failing and others don't seem to have a problem with it -- at least did no-one respond to ​m:#1538 within 9 months.

r25505 fixes a similar issue in the Cpp runtime that occurs with Modelica.Fluid.Dissipation.Utilities.Functions.General.SmoothPower.

Btw.: there is an encoding problem with the error message in
​https://test.openmodelica.org/libraries/ModelicaTest_trunk_cpp/files/ModelicaTest.Fluid.Dissipation.Verifications.PressureLoss.General.dp_idealGas_DPMFLOW.err

error: ‘pow’ cannot be used as a function

The original compiler message is more descriptive:

error: ‘pow’ cannot be used as a function
         tmp24 = pow(x, pow);
                           ^

[Martin Sjölund]

No encoding error in that file for me; did you set your browser to force non-detected encoding?

HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Sat, 11 Apr 2015 08:29:43 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Last-Modified: Sat, 11 Apr 2015 02:57:43 GMT
  ETag: "a09-5136a0b7177c0"
  Accept-Ranges: bytes
  Content-Length: 2569
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Encoding: utf-8

[Rüdiger Franke]

I didn't set up anything related. But tested Firefox under Linux, Safari and Chrome under OSX as well as IE under Windows. All show me that same wrongly encoded error message.