Simulation results obtained with the NF are scrambled up

[Francesco Casella]

After some recent commits to the NF, a lot of models from the MSL simulate successfully but fail upon verification, see e.g. ​Modelica.Electrical.Analog.Examples.AmplifierWithOpAmpDetailed

Judging from the comparison of old and new results, it seems that the problem is not that the simulation is somwhat wrong, but rather than there are some mismatches between the variables and their names in the results.

There are also recurring ​error messages, such as

Error: Could not read variable sineVoltage.v in file
Modelica_3.2.2_Modelica.Electrical.Analog.Examples.AmplifierWithOpAmpDetailed_res.mat.
Warning: Get data of variable sineVoltage.v from file
Modelica_3.2.2_Modelica.Electrical.Analog.Examples.AmplifierWithOpAmpDetailed_res.mat failed!

and also some information is reported in the log regarding the erroneously reported variables such as

Variables in the reference:time,opAmp.q_fp1,opAmp.q_fr1,opAmp.q_fr2,opAmp.q_fr3,opAmp.v_in,opAmp.v_source,opAmp.x

Variables in the result:constantVoltage.V,constantVoltage1.V,opAmp.Avcm_val,opAmp.Avd0,opAmp.Avd0_val,opAmp.CMRR,opAmp.Cin,opAmp.I1,opAmp.I2,opAmp.Ib,opAmp.Imaxsi,opAmp.Imaxsi_val,opAmp.Imaxso,opAmp.Imaxso_val,opAmp.Ios,opAmp.Rcm,opAmp.Rdm,opAmp.Rout,opAmp.Ts,opAmp.Vos,opAmp.fp1,opAmp.fp2,opAmp.fp3,opAmp.fp4,opAmp.fz,opAmp.q_fp1,opAmp.q_fr1,opAmp.q_fr2,opAmp.q_fr3,opAmp.sr_m,opAmp.sr_m_val,opAmp.sr_p,opAmp.sr_p_val,opAmp.v_in,opAmp.v_source,opAmp.vcm,opAmp.vcm_abs,opAmp.vcp,opAmp.vcp_abs,opAmp.x,resistor.R,resistor.T,resistor.T_ref,resistor.alpha,resistor1.R,resistor1.T,resistor1.T_ref,resistor1.alpha,resistor2.R,resistor2.T,resistor2.T_ref,resistor2.alpha,sineVoltage.V,sineVoltage.freqHz,sineVoltage.offset,sineVoltage.phase,sineVoltage.signalSource.amplitude,sineVoltage.signalSource.freqHz,sineVoltage.signalSource.offset,sineVoltage.signalSource.phase,sineVoltage.signalSource.startTime,sineVoltage.startTime,time

This issue shows up in a lot of models and may explain why the number of models compiled with the NF that currently pass verification (26) is much lower than the number of models that pass simulation (48). Please have a look at that.

[Francesco Casella]

The smallest test case for debugging is ​Modelica.Blocks.Examples.NoiseExamples.Densities

[Martin Sjölund]

Hmmm, I think part of the issue with reporting is it can't read variables is due to using the mat-file from the reference files which includes Dymola-specific variables dummy and derdummy. We should probably compare with the csv-file instead... That won't fix the issues with the failing signals though.

[Martin Sjölund]

Just debugging the info.json-file and the result-files, uniformDensity_y in Densities is indeed calculated incorrectly. But the generated equations according to the debugger are identical.

The difference in the generated code is:

  tmp1 = Less(data->localData[0]->realVars[2] /* add.y variable */,data->simulationInfo->realParameter[8]);
  tmp2 = Greater(data->localData[0]->realVars[2] /* add.y variable */,data->simulationInfo->realParameter[7]);

With -d=newInst:

  RELATIONHYSTERESIS(tmp1, data->localData[0]->realVars[1] /* add.y variable */, data->simulationInfo->realParameter[8], 0, Less);
  RELATIONHYSTERESIS(tmp2, data->localData[0]->realVars[1] /* add.y variable */, data->simulationInfo->realParameter[7], 0, Greater);

But there is noEvent around the call, so this seems a little odd.

[Martin Sjölund]

It seems the type in the relation is different in the two. a < b has type Real in the old one and Boolean in the new inst (all relations return Boolean, so the reason of the type should be the real type, right?)

[Martin Sjölund]

Should be fixed in ​https://github.com/OpenModelica/OMCompiler/pull/2180

[Francesco Casella]

It will be interesting to see what happens with @sjoelund.se's commit.

In the meantime, please notice that last night something happened which made the situation even worse: ​https://libraries.openmodelica.org/branches/history/newInst/2018-02-08%2021:07:03..2018-02-09%2009:00:38.html

I'm not sure what 'Configuration hash (OMC settings or the testing script changed)' actually means. Can you please check?

[Martin Sjölund]

The configuration hash changes when I change something. In this case, I started using the CSV reference files instead of the Dymola-specific MAT reference files.

[Francesco Casella]

Unfortunately we still have 31 models out of 48 that fail in MSL 3.2.2 due to this issue

​https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.2/Modelica_3.2.2.html

[Per Östlund]

It seems this particular issue was indeed fixed by sjoelund.se's commit, and with a few other fixes, notably f6ac4dd0, the majority of the models that simulate now also simulate correctly. The few models that still have issues seem to have issues unrelated to the results files.

[Francesco Casella]

Great!