Model Buildings.Controls.OBC.Utilities.Validation.OptimalStartCoolingNegativeStartTime fails verification

[AndreaBartolini]

The model Buildings.Controls.OBC.Utilities.Validation.OptimalStartCoolingNegativeStartTime fails the verification vs the data produced by Dymola for the following signal:

• optStaCoo.tOpt

herebelow the reference and actual transient:

The optStaCoo.tOpt signal depends on the optStaCoo.optCoo.dTHVACOn.y signal that is the sampling of the max values of the signal optStaCoo.optCoo.dTHVACOn.u.
The last signal optStaCoo.optCoo.dTHVACOn.u is obtained by integrating the signal TRoo.u.

Herebelow the transient of the above listed signals:

It is possible to see that the discrepancy between the reference and the actual value is generated by the integration of the high-frequency components of the signal TRoo.u, that shows some numerical differences between Dymola and OpenModelica in the part of the transient in which the model fails the verification.

Probably that high-frequency components are generated by some numerical oscillations of the solver, that are slightly different in Dymola and OpenModelica.

[casella]

Did you try to reduce the tolerance by a factor 10 in both tools and see what happens?

[AndreaBartolini]

By reducing the tolerance of a factor 100 in OpenModelica (OpenModelica tolerance = 1e-8) the transient generated by OpenModelica overlaps the same generated by Dymola at the original tolerance (Dymola tolerance = 1e-6)

A reduction of the tolerance by a factor 10 in OpenModelica (1e-7) is not enough to overlap the transient generated by Dymola
at the original tolerance (1e-6).
By reducing both OpenModelica and Dymola tolerance to 1e-7 (factor 10) is not enough to overlap the transient generated by Dymola and Openmodelica.

[AndreaBartolini]

The same analysis is also valid for the following similar models:
Buildings.Controls.OBC.Utilities.Validation.OptimalStartCoolingPositiveStartTime that fails the verification of the following variable:

• optStaCoo.tOpt

and Buildings.Controls.OBC.Utilities.Validation.OptimalStartHeating that fails the verification of the following variables:

• optStaHea.optOn
• optStaHea.TZon
• optStaHea.tOpt

Both of them overlap the reference transients by reducing the tolerance in OpenModelica by a factor 100 (tolerance = 1e-8)

[casella]

To me the conclusion is that these models should be tested for validation with a tighter tolerance and that would be the end of the story.

I made a proposal to have a specific annotaton for that, see modelica/ModelicaSpecification#3473, but it sparked a lot of controversy. @AndreaBartolini, @mwetter, please also comment on that.

In the meantime, I guess we could reduce the tolerance of those experiments in Buildings by a factor 10, since usually verification is carried out by further tightening the tolerance by another factor 10. It's not standardized (as my proposal would allow), there are no guarantees it always works, and it would make the simulation when you don't bother about verification unnecessarily slower, but it should probably work.

[AndreaBartolini]

I completely agree with @casella

[casella]

I mean, comment on modelica/ModelicaSpecification#3473

[mwetter]

I added my comment to the MSL discussion.

[casella]

Comment was for @AndreaBartolini 😄

Thanks for the support!

[AndreaBartolini]

I mean, comment on modelica/ModelicaSpecification#3473

I'll do ASAP ;)