Tags and keywords
WaterTank
with a supporting ConstraintBlock WaterTankConstraint
:Recall please this:
And remember also that there is no actual physical vapor flowing back into a WaterTank
via Port iConsumption
, it's just a signal flow of a quantity of type VaporRate_mL_per_h
, used to track how much water must be left in the tank.
It is assumed here that the redefined tankVolume
50,000 for the scenario has units of litres (L) because:
Now 50,000 L = 50 m^3 corresponds to a cube of about 3.68 m length, which is too large for the water tank of a mere domestic humidifier for a room, but possible for a commercial humidifier for a large building:
And finally, the ongoing Webel whinge about the example breaking the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) policy, because the value 50,000 appear both as a parameter to be set at startup on tankVolume
and then again buried as a magic value 50000 in the constraint equation, it SHOULD probably simply be the same as the bound parameter tankVol
:
{watV=tankVol-min(50000,x)}
{der(x)=consIn/lpsm}
This just means of course the tracker variable x
is not supposed during integration to exceed the entire initial tank volume (and will be ignored if it is).
Note that the units work fine here as long as the "vapor" is a volumetric rate (mL/h).
We're now going to work through the state machines (before diving into the
VaporGenerationPlant
).