Incorrect flow direction in Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater?

[HansOlsson]

In this model I noticed that B2 has a few drops of water flowing out of the port at the top of the tank, which is plain weird! I don't think it is any error in symbolic processing in Dymola.

Specifically B2.top_ports[1].m_flow (same as V6.port_a.m_flow) has a negative dip at 741.5878891772804s (followed by a larger positive flow. note: there is a also a positive "dip" at 3262.7830640209s). Physically that should not happen, and top_ports.m_flow has a min-value of 0.

You have to zoom in to notice that B2.m also decreases slightly at that time from 4.972674415057601 to 4.972673539863315 (so about 13 drops of water).

As far as I can tell the model does not directly try to prevent this flow-situation.

Results using Dymola 2019 (and turning off equidistant time grid and storing in double precision). (Still present in current beta, and could be reproduced with other solvers as well.)

[beutlich]

@casella Any feedback?

[beutlich]

Still present with MSL 4.0.0 Alpha.1 and Dymola 2020.

SimulationX 4.0 does not show the negativ flow, but also the positive flow region around t=740s.

SimulationX simulation hangs at about 1913.969, thus I have no comparison plot fo the other time reported for 3262.7830640209s.

[casella]

I had a look at the issue. At time =781.588, a certain number of valves is opened instantaneously: V5, V6, V20, V24, V25, and pump P2 is also turned on. Ideall, water should instantaneously flow from the pump through the valves. However, the pump P2 contains a volume of 100 ml of water, and the pipe has a volume of about 240 ml. Now, the water model used here is StandardWater, that takes into account the (very small) compressibility of cold water. This very small compressibility triggers an extremely fast transient that reduces the pressure for a few microseconds (I can't actually zoom in enough in Dymola to see this transient), causing the valve to get a reverse delta-p and then sucking some drops of water from the top.

There are multiple issues here.

The first is that we are talking about fictitious physical behaviour, becaus in practice opening the valves and turning on the pump will need a lot more than a few microseconds, so this fast dynamics will never be triggered in real life. This would require to use ramps instead of boolean signals, hence different pump and valve models.

The second problem is that in real life you would first turn on the pump and shortly (but not instantaneously) after open the valves, to make sure the pressure build-up is enough to get the right flow direction. This delay is not modelled in the controller, which is highly idealized.

The third problem is that whenever you connect a valve model to the top port of a tank, you have to ensure that either the valve is closed, or the delta-p is positive. A negative delta-p doesn't mean zero flow rate, it actually means water entering the circuit, which is something that a) Modelica.Fluid cannot represent and b) should never ever happen in practice.

The fourth problem is that this model uses incredibly accurate physical model (including fluid compressibility), coupled to highly idealized controller and actuation models (no delays, no actuator response time). Hence, some kind of artifact is often inevitable.

I managed to avoid the issue by adding one more state to the controller, which allows to first turn on P2 and open V5, V24 and V25, and then after one second when the pressure upstream V6 is well stabilized, open the valve into the tank. I need to implement the same also for V3, which has a symmetric behaviour on the other side of the circuit, then I will push the whole thing.