verify whether hZone is filled in

[Mathadon]

  parameter Modelica.Units.SI.Length hFloor = 0  "Absolute height of zone floor";

is used when TwoZone is used. When the parameter is not filled in, non-physical results will be generated. We should somehow verify that the parameter has been filled in correctly.

A first approach would be to throw a warning if the default value has not been changed. But ideally we can verify whether the values 'add up'. @kldjonge have you looked into such an approach in the past?

I propose to handle this issue separately from the pending merge requests.

[kldjonge]

A quick idea. At component level we can check the following: If an internal wall component is horizontal you would expect that the connecting hFloor values are not equal. This could prompt a warning to check the hFloor input.

[kldjonge]

To check if things 'add up' on building level you will need to have information about the building as a whole that is not available so would require a user input. But, at some point, it might be better to just NOT have a default value for the hFloor and just require this input in all models.

Older models will be 'broken', but only to the extend that they require 1 additional parameter per zone which can then be just hFloor=0.

[Mathadon]

It could indeed be a good idea to not add a default value for hFloor.. If we make the parameter conditional then this should not introduce an error even. This might however make it tricky to use the parameter since using conditional variables in non-equations is not allowed.

[Mathadon]

A quick idea. At component level we can check the following: If an internal wall component is horizontal you would expect that the connecting hFloor values are not equal. This could prompt a warning to check the hFloor input.

That's also a good idea!

[Mathadon]

The way I see it, there only arise problems when zones have an inconsistent hFloor, and it can only cause problem between zones , hence I think we only need to add checks in InternalWalls. Can't we just add an assert that for walls both hZone must be equal and for ceilings/floors, the difference between hZones must be the average zone height?

[kldjonge]

It is more robust to assert only for ceiling/floors. In buildings with split levels or spaces that are double-heighted two neighbouring spaces can easily have different absolute floor heights.

[Mathadon]

But are the equations also correct in this case? Note also that I changed the implementation yesterday in my pull request. So that may affect the answer to that question :p

What I mean is: we assumed that the window is at half the zone height. If zones have different heights, then the window is at different heights in both zones too. So that's not correct I think.

[kldjonge]

I will need to check the changed implementation then.

The default value was indeed to put it at half of the zone height but this was overridable I think. In most cases the default value is a 'most likely' parameter, placing the window in the middle of the zone is the assumption of minimum stack-effect.

Anyway, the window position will most likely be only dependent on the zone it is connected to? For a typical appartment or typical office floor , the hFloor and hZone will be equal. For special/untypical cases, the default value will be off a bit, but I think that is fine and up to the modeler to recognize when intervention to the default values are necessary.

[Mathadon]

For a window, yes, but for a cavity in an InternalWall, which has a high flow rate coefficient, even a small height difference of 1m causes 1.2 Pa of pressure difference and consequently a substantial flow rate? Perhaps not in all cases but in my opinion these equations should be 100% correct.

And the user probably doesn't know how to set hFloor and hZone to avoid this. Well, I don't know unless I think about it for a few minutes.. :p So that's asking for problems :)

[kldjonge]

Just to be sure, in which branch do I need to check? #1327?

[kldjonge]

Ok, I pinpointed the issue of the internal cavities and different heights in the current implementation. I'm figuring out a solution.

[kldjonge]

I propose to add two parameters similar to what we have in the window component that positions the bottom of the cavity (/doormodel) relative the the absolute floor height. -> href,cav,A and href,cav,B

With this new parameter all kinds of cavities can be modelled.

The proposed default (picture on the right) would then be that this cavity is a door starting at the lowest possible height. This is the either 0 or the difference between the absolute floor heights.

Practically after adding the new parameters. hA and hB of the door model need to become (hzoneA/2-href,cav,A) and (hzoneB/2-href,cav,B) respectively.

[kldjonge]

A check/assert could then be that: hfloorA+href,cav,A and hfloorB+href,cav,B should be the same.

[Mathadon]

Just to be sure, in which branch do I need to check? #1327?

This one Mathadon#2 :)