Empty tank error in Modelica.Fluid.Vessels.BaseClasses.PartialLumpedVessel

[MatthiasBSchaefer]

In
3434527
we changed the assert statement to fluidLevel > 0
but the default is defined:
input SI.Height fluidLevel = 0
So all examples, which do not modify this input fail (e.g. Modelica.Fluid.Examples.TraceSubstances.RoomCO2 ,see https://www.ltx.de/download/MA/Compare_MSL_v4.1.0/Testruns/Dymola/Modelica/_report/Modelica.Fluid.Examples.TraceSubstances.RoomCO2/testcase_report.html#)

[MatthiasBSchaefer]

Especially the example Modelica.Fluid.Examples.Tanks.EmptyTanks, which should
"Show the treatment of empty tanks" (=description string of the example) probably won't work without a fluidLevel of (exactly) zero.

[HansOlsson]

The simplest would be to change the assert to >= 0.

[MatthiasBSchaefer]

The simplest would be to change the assert to >= 0.

I tested it and it would solve all failures except for Modelica.Fluid.Examples.Tanks.EmptyTanks.

But i am not sure if exactly zero means a singularity in the energy balance equations again

[casella]

I'm afraid I misunderstood the scope of the partial classes involved in the making of the OpenTank model when I fixed #4526 via PR #4527. The fluidLevel variable is defined in PartialLumpedVessel

ModelicaStandardLibrary/Modelica/Fluid/Vessels.mo

Lines 269 to 270 in b4a4b03

	input SI.Height fluidLevel = 0
	"Level of fluid in the vessel for treating heights of ports";

and is meant to be used to deal correctly with ports at different heights that may be shut off by the automatic check valve behaviour if the level gets below their height. However, this base class is also used for models such as ClosedVolume (used in the now-failing TraceSubstances.RoomCO2) where the "level" is not used, so it should have a default.

Notice that PartialLumpedVessel defines a maximum level fluidLevel_max that should never be exceeded, lest the fluid overflows, but it doesn't define a minimum level. In fact, this class is general enough that one could, e.g., later define the reference for level = 0 at the middle of the vessel, instead of at the bottom. There is no point restricting the level to be positive or non-negative in derived classes, the level could well go below zero without any problem, provided this corresponds to a non-empty vessel. Hence, the previously formulated assert

assert(fluidLevel > -1e-6*fluidLevel_max, "Fluid level (= " + String(fluidLevel) + ") is below zero meaning that the solution failed.");

(that was changed in #4527) was unnecessarily restrictive and should have actually been removed. Also notice that the height field of the VesselPortData record

ModelicaStandardLibrary/Modelica/Fluid/Vessels.mo

Line 538 in b4a4b03

parameter SI.Height height = 0 "Height over the bottom of the vessel";

has no min = 0 attribute, so it could legitimately be assigned a below-zero value. Again, nothing wrong in general with negative levels, it really depends how you define the level in the first place.

So, the assertion on the level always being positive should not be have been put on PartialLumpedVessel.fluidLevel, which is too generic. It should rather be put in the OpenTank model, where level (which is then passed as value for fluidLevel when extending from the base class) has a definite meaning:

• a cylindrical shape with vertical axis is assumed
• with a flat bottom
• hence volume = level * crossArea

BTW, this is not the only possible choice of semantics of level. Another tank model could not have such a cylindrical shape, and not necessarily level = 0 implies volume = 0. This is just a feature of OpenTank. Hence, level > 0 should be asserted in OpenTank. Once again, it needs to be > 0, not >= 0, because the OpenTank model is ill-defined at zero level.

Additionally, the Modelica.Fluid.Examples.Tanks.EmptyTanks example model should be modified in the same way the ModelicaTest.Fluid.TestComponents.Vessels.TestSimpleTank was modified, i.e. by having a small but positive height for the bottom port that prevents the tank from getting completely empty.

I will follow up with a PR that fixes all these issue.

[casella]

Thanks @MatthiasBSchaefer for pointing this out!