Nominal values for mixing volume

[mwetter]

Setting proper nominal values for the states in the mixing volume is difficult because the volume is a non-literal parameter for some models. This issue is to look into scaling the state variables (U, m, mXi and mC) so that they are around unity, regardless of the size of the volume. Once they are unity, a possible reason (bad scaling of states) can be ruled out when looking at simulation performance issues.

@Mathadon : This is FYI. I will look into it for Buildings because I like to have larger test problems before moving it into the Annex 60 library.

[Mathadon]

It could be interesting to run also IDEAS.Examples.PPD12.Ventilation. This is a 9 zone model of a terraced house with a ventilation system and a heating system.

I think the overhead for normalising U, m, and mXi may be larger than the possible gains. I'm also wondering in what algorithms or solver parts it actually matters? For sequential equations I don't think it matters. For explicit Euler I also don't think it matters and for implicit integrators I guess it could matter.
From what I recall from numerical math I also think that normalising by computing U/U_nominal will have a smaller impact than computing U-U_nominal. We already do this by setting T_ref = 273.15 in the computation of the enthalpy, but performance could possibly be improved further by setting T_ref=293.15?

[mwetter]

The nominal value is used for scaling when the state is close to zero. Below are CPU time comparisons for 4 large test problems:

Performance is slightly better, except for DualFanDualDuct where the solver runs at one point into numerical issues. These were eventually resolved and I believe could as well have happened with the master as the new formulation gives better scaling, not worse scaling.

@Mathadon I think we should use this change and will propose it for the Annex60 library. Can you run the test case?

The test cases were run with the following script:
scripts_to_run_benchmark.zip

[Mathadon]

In the script I see that you used Radau integration. I'm not a big fan of Radau since it does not obtain the promised tolerance in our Modelica speed increase paper.

I also compared Lsodar and Dassl for ����Buildings.Examples.ChillerPlant.DataCenterContinuousTimeControl. In this example Dassl is slower after adding scaling and LSodar is faster:

Fyi Buildings.Examples.DualFanDualDuct.ClosedLoop does not run with Evaluate=true.

I also ran IDEAS.Examples.PPD12.Ventilation using Dassl:

The same model using Euler results in +- identical computation times.

I.e. the results are not consistents, the change adds equations/complexity and it's not yet clear for me either why it should help (e.g. what operations (solving linear system, etc) benefit from this and in what integrators are they used).
I think we should look into this further if we want to put it into Annex 60?

[mwetter]

On the master (commit e74f3a1), in ConservationEquation.mo, the following (hack) is made to set the nominal value, then

  Modelica.SIunits.Mass[Medium.nXi] mXi(nominal=1E-6)
    "Masses of independent components in the fluid";

then

simulateModel("Buildings.Fluid.HeatExchangers.Examples.WetCoilDiscretizedMassFlow", stopTime=3600, method="dassl", tolerance=1e-04, resultFile="WetCoilDiscretizedMassFlow");

works in Dymola 2017 FD01. However, without a nominal value set, which is what is on the master, the model fails for tolerance = 1E-4, 1E-5 and 1E-6. It works with 1E-7 (but the verification with JModelica fails.)
Hence we should scale these states.

[mwetter]

I will close this as state selection and scaling will be addressed through ibpsa/modelica-ibpsa#1412

[mwetter]

Branch was issue629_states_scaling