Compare computing time between IDEAS and Annex 60 for boiler with pump

[mwetter]

The folder IDEAS_a60 contains a comparison between a simplified boiler model from IDEAS and from Annex60.

The output of both models are similar (but not exactly the same, mainly due to the difference in the pump (IDEAS has no inertia) ).

[mwetter]

Moved all models to branch issue15_cpu

[mwetter]

For Annex60 and dassl, I run

simulateModel("IDEAS_Thermal_Components_Examples_Boiler_validation_a60", 
stopTime=4e+06, method="dassl", resultFile="IDEAS_Thermal_Components_Examples_Boiler_validation_a60");
...
Integration terminated successfully at T = 4000000
   CPU-time for integration      : 1.1 seconds

Next, I run IDEAS as

simulateModel("IDEAS_Thermal_Components_Examples_Boiler_validation", 
stopTime=4e+06, method="dassl", resultFile="IDEAS_Thermal_Components_Examples_Boiler_validation");
...
Integration terminated successfully at T = 4000000
   CPU-time for integration      : 1 seconds

IDEAS was 10% faster.

---

Next, I tried the radau solver with tolerance 1e-6.
(We typically use 1e5 to 1e6, the default seems to low.)

For IDEAS, I get

simulateModel("IDEAS_Thermal_Components_Examples_Boiler_validation", stopTime=4e+06, 
method="radau", tolerance=1e-06, resultFile="IDEAS_Thermal_Components_Examples_Boiler_validation");
...
Integration terminated successfully at T = 4e+06
   CPU time for integration                  : 2.32 seconds

For Annex60, I get

simulateModel("IDEAS_Thermal_Components_Examples_Boiler_validation_a60", stopTime=4e+06, 
method="radau", tolerance=1e-06, resultFile="IDEAS_Thermal_Components_Examples_Boiler_validation_a60");
...
Abszissa table vector values must be increasing
The stack of functions is:
Modelica.Math.Vectors.interpolate
Modelica.Math.Vectors.interpolate(heater.heatSource.QVector, heater.heatSource.modVector, heater.heatSource.QAsked, 1)
x2 > x1
The following error was detected at time: 3958920.427589733
Abszissa table vector values must be increasing
The stack of functions is:
Modelica.Math.Vectors.interpolate
Modelica.Math.Vectors.interpolate(heater.heatSource.QVector, heater.heatSource.modVector, heater.heatSource.QAsked, 1)
Integration terminated successfully at T = 4e+06
   CPU time for integration                  : 3.08 seconds

IDEAS was 25% faster. The warning comes from IDEAS.Thermal.Components.Production.Boiler_a60.

---

Next, I looked at the number of states:
IDEAS has the following state:

IDEAS.Thermal.Components.Production.Boiler_a60

Annex 60 has the following states:

exp.vol.m
exp.vol.medium.T
heater.heatedFluid.vol.dynBal.medium.T
pump.filter.x[1]
pump.filter.x[2]
pump.vol.dynBal.medium.T

There, is 1 versus 5 states. The additional states are from the pump, which uses by default
a control volume with dynamic energy balance. This can be disabled. The pump
also uses a 2nd order filter at the input signal to approximate the start up transients. This
also seems numerically beneficial as it avoids step changes in the pressure if the pump
is connected to an on/off controller. This feature can also be disabled.

I disabled the states in the pump in Annex60 by setting

pump(dynamicBalance=false, filteredSpeed=false)

Then, the computing time is 2.2 seconds, about 5% faster than IDEAS (or for practical reasons,
they are about the same computing time).

Annex60 still has the following states:

exp.vol.m
exp.vol.medium.T
heater.heatedFluid.vol.dynBal.medium.T

The states from the expansion vessel could be avoided by using Annex60.Fluid.Sources.FixedBoundary, but I have not done this.

Hence, it looks like the difference in computing time was because of the differential equation for the pump, which have been removed.

[mwetter]

Note that in IDEAS.Thermal.Components.Interfaces.Partials.TwoPort, the section

  Modelica.SIunits.TemperatureDifference dT(start=0)=if noEvent(
    flowPort_a.m_flow >= 0) then T - T_a else T_b - T 
    "Outlet temperature minus inlet temperature";

uses noEvent. This is not correct. There should be an event as dT is discontinuous.

[rubenbaetens]

The use of noEvent for dT is indeed not entirely correct. I must check the code, but i think we introduced dT only as output variable allowing a more easy debugging and plotting while we use T, T_a or T_b for simulating the physics. As such, we didn't want to introduce events if they don't impact our results.

[rubenbaetens]

Overall good to know that the difference is due to the pump model. I came to a similar conclusion on thursday seeing the results and it's comparison of Damien, as i noticed that the results of the simulation where not the same and could be subscribed to the inertia equations of the pump.

[saroele]

We might have been a bit too ambitious in trying to reduce events at some point :-o

[mwetter]

If you want to use a variable for reporting only, then a "trick" is to make it a conditional variable, which you can enable by default. See for example
https://github.com/iea-annex60/modelica-annex60/blob/master/Annex60/Fluid/Interfaces/PartialTwoPortInterface.mo#L30-L40
Then, if a model uses this variable in an equation, there will be a warning if the model is checked in Dymola's pedantic mode.

(Looking at this model, we can actually remove the homotopy function as the sta* is only used for reporting. I will open a ticket for this.)

[damienpicard]

The CPU time is compared with different alogrithms.
The extra states of the Buildings pump model are disabled.

Only the Dassl algorithm is fasater for the IDEAS model than for the annex 60 case (_a60).

The following images give the comparison:

[saroele]

Nice overview. Just to be sure: did you compare the trajectories for one or more variables in order to be sure that all solvers find the same (correct) solution?

[damienpicard]

I checked the boiler outlet temperature and the results are very simular. No other solution is found but the accuracy is different.