Implement single precision for matlab result files

[ceraolo]

According to a set of tests I made, the OM matlab output size with is between 2 and 8 times dymola's.

I checked the two binaries and found that:
1) as default Dymola saves numbers in single precision (while OM double precision)
2) Dymola does not save several copies of variables which are identical (for instance the current in the positive pin of a resistor and in the resistor itself), nor of variables that are the opposite of saved ones (for instance the current in the positive and negative pins of a resistor)

AFAIK currently there are no options in OM to select either 1 or 2.

I cannot evaluate the difficulty of implementing 2 in OM, since it depends on its inner data structure, but it seems to me that 1 should be very easy.

In case this is true, I recommend implementing at least 1: for plotting purposes single precision is by large sufficient in the vast majority of cases.

I will set this ticket's priority to high just thinking to point 1 (2 has a lower priority).

[sjoelund.se]

(2) is always enabled in OpenModelica. And (1) is insufficient in many cases (I quite often see reports when people find "odd" results in Dymola plots).

However, note that (2) depends on what analysis OpenModelica can perform on the equation system. If you can find a model that produces 4x as many trajectories as Dymola due to aliases, please create a ticket for it.

There is also (3) - do not output protected variables (which is the default in both tools).

[sjoelund.se]

​https://github.com/OpenModelica/OMCompiler/pull/1913 will be coming soon. It seems to work fine although OMEdit needs an option for it

[ceraolo]

Replying to sjoelund.se:

(2) is always enabled in OpenModelica.

I've seen different things. Check the RL*.* files enclosed The DYM version has 7 variables, OM's has 26. In practice no alias is there.

And (1) is insufficient in many cases (I quite often see reports when people find "odd" results in Dymola plots).

I think the need of double precision on outputs is VERY rare. Consider that I've been simulating (and teaching students to simulate) with different programs for decades!
Very often when students quote "odd" results it is because they use a too small number of output points. Maybe this was also the case you were thinking of?

[sjoelund.se]

@ceraolo: Both list 34 variables. For some reason your result has 26 variables. If I simulate it locally, my OM produces 10 variables...

Your OM has 8 parameters:
inductor.L, resistor.R, resistor.T, resistor.T_ref, resistor.alpha, step.height, step.offset, step.startTime

Your Dymola has 14 parameters (only additions listed):
ground.p.i, ground.p.v, inductor.n.v, resistor.R_actual, resistor.T_heatPort, signalVoltage.n.v

Mine has 9 parameters: adds resistor.T_heatPort

The weird part is your result has no aliases. What settings did you translate RL with?

So your attached file has 26 trajectories/variables, whereas Dymola has 7 trajectories for 19 vars, and mine simulate with stock OM settings has 10 trajectories for 25 vars.

Dymola:

0: [u'Time']
1: [u'resistor.v']
2: [u'resistor.p.v', u'signalVoltage.p.v', u'signalVoltage.v', u'step.y']
3: [u'resistor.n.v', u'inductor.v', u'inductor.p.v']
4: [u'resistor.LossPower']
5: [u'resistor.i', u'resistor.p.i', u'resistor.n.i', u'inductor.i', u'inductor.p.i', u'inductor.n.i', u'signalVoltage.p.i', u'signalVoltage.n.i', u'signalVoltage.i']
6: [u'inductor.der(i)']

OMC:

0: [u'time']
1: [u'inductor.i', u'inductor.n.i', u'inductor.p.i', u'resistor.i', u'resistor.n.i', u'resistor.p.i', u'signalVoltage.i', u'signalVoltage.n.i', u'signalVoltage.p.i']
2: [u'der(inductor.i)']
3: [u'ground.p.i']
4: [u'ground.p.v', u'inductor.n.v', u'signalVoltage.n.v']
5: [u'inductor.v', u'inductor.p.v', u'resistor.n.v']
6: [u'resistor.LossPower']
7: [u'resistor.R_actual']
8: [u'resistor.v']
9: [u'signalVoltage.v', u'resistor.p.v', u'signalVoltage.p.v', u'step.y']

Where it seems we don't detect the three signals ground.p.i, resistor.R_actual, and ground.p.v=inductor.n.v=signalVoltage.n.v are not time-varying.

[sjoelund.se]

@ceraolo: I guess you might have some flags disabling preOptModules in your OMEdit? That's the module responsible for removing the aliases.

[sjoelund.se]

I created ticket:4574 to store the signals that are not time-varying in the data_1 matrix. The simflag -single will store the data_2 matrix in single precision (the parameters in data_1 are stored in double precision like previously).

It works fine in OMEdit, although you have to add -single to the extra simflags manually. Ask Adeel if you want a checkbox in the GUI to pass the single precision flag or perhaps if you want the drop-down box to say mat (double) and mat (single).

[ceraolo]

Replying to sjoelund.se:

@ceraolo: I guess you might have some flags disabling preOptModules in your OMEdit? That's the module responsible for removing the aliases.

ahh!
I had:
--removeSimpleEquations=none --preOptModules+=unitChecking

And did not consider them (nor considered their effects on the matlab file)
Now I have 10 variables, much less than the original 26. The most important in this circuit is current, which is replicated many times. Indeed OM now proposes one current and 8 aliases. Very good!

It works fine in OMEdit, although you have to add -single to the extra simflags manually. Ask Adeel if you want a checkbox in the GUI to pass the single precision flag or perhaps if you want the drop-down box to say mat (double) and mat (single).

I will do this. I will try also to ask adeel to make single precision as default, just in case he agrees (and other users of this forum don't object).

[sjoelund.se]

I'd suggest making a configuration option to set a default for single/double precision. If the default is double, we get fewer support emails and people can still select single precision if they want a smaller result-file.

[casella]

Replying to ceraolo:

I think the need of double precision on outputs is VERY rare. Consider that I've been simulating (and teaching students to simulate) with different programs for decades!

This depends on the modelling domain. If you model thermo-fluid systems, it is often the case that you have pressures of the order of 1e6-1e7 Pa and pressure losses of the order of 10 Pa, so the mass flow rate depends on dp = p1-p2. If dp is not explicitly computed and stored in the model and you try to reconstruct it by computing p1 - p2 in single precision, you may get a lot of numerical garbage. The worst thing is, often students take this garbage as Gospel.

So, I support Martin's idea of keeping double as default.

Very often when students quote "odd" results it is because they use a too small number of output points. Maybe this was also the case you were thinking of?

That's another typical case. We have a default of 500 intervals (another Dymola legacy), but maybe 2000 or 5000 would be a much better default.

[ceraolo]

That's another typical case. We have a default of 500 intervals (another Dymola legacy), but maybe 2000 or 5000 would be a much better default.

Agree. Maybe 500 points were a good default 20 years ago, not now.
MS don't recommend any default. Maybe the OM default can be upgraded to 2000 or 5000? If in doubt we can choose 2500, i.e. 5 times the current default?