Stack effect airflow - Project itz fixes

[Mathadon]

@jelgerjansen this includes some changes but still requires a master merge

[Mathadon]

The problem seems to be that we are externally applying a stack instead of letting the door model handle it. This would have been fine if the model equations were consistent, but they are not: the external pressure column uses hVertical instead of the door height hOpe.

The cleanest approach would be to refactor the model such that we used the internal stack computation again.

[Mathadon]

I have pushed some changes and tested them on ZoneExample but OM cannot run TwinHouse. Can you have another look whether the results for the model have improved?

E.g. the mass flow rate for W1 on this figure:

[jelgerjansen]

@Mathadon the results seem to be better (solid line represents the results of PR #1322, dashed line the results of this PR)

When zooming in, both results show exactly the same trend, but there is still a minor offset of about (2e-5 for W1[1], 8e-5 for W7[1], 2e-4 for W10, and 1e-7 for W37). The latter might be due to the change CVal/COpe?

[kldjonge]

The problem seems to be that we are externally applying a stack instead of letting the door model handle it. This would have been fine if the model equations were consistent, but they are not: the external pressure column uses hVertical instead of the door height hOpe.

The cleanest approach would be to refactor the model such that we used the internal stack computation again.

Isn't the external column their is a door/opening doesn't start on the floor level? (e.g. a large opening between a living room and a kitchen that only starts above the cabinets..). I'm not familiar with the specific changes you made when combining/optimizing the models, but that was the approach before I believe. If I recall correctly, the door model assumes the pressure in the connecor to be the reference at the bottom of the door, so their should be some kind of correction based on the room heights (and preferably the 'starting height' of the door for e.g. modelling a 2-storey hallway with as 1-zone).

[Mathadon]

@kldjonge to be clear, the problem that I described is a problem that I created by modifying your implementation. As far as I know, the equations are now again consistent with the old implementation.

The way I see it, the external column is now integrated into the door model but I did not look into the model equations in full detail to verify their correctness. Since the implementation is the same as before, it should be equally correct as before and the validation should point out whether or not that the results match contam and thus whether the implementation is correct.

[Mathadon]

@jelgerjansen the CVal/COpe should be correct since commit aad7465.

Perhaps the remaining differences are because the new implementation effectively disables the cracks when a door is open. In the old implementation both equations would be present at the same time. The underlying assumption was that the crack flow rate is negligible to the flow rate of an open door. Looking at the values of CClo=5e-5 and COpe=0.388 this should indeed be the case. The differences seem larger than that. So probably it's something else.

@jelgerjansen would it be possible to send me those two .mat files such that I can compare further?

[Mathadon]

At least part of the reason seems to be that the q50 values are not the same. E.g. for W1 q50=0.910208 vs q50=0.883414. This is the same ratio as the mass flow rate mismatch.

The cause of this change is probably:

+    setArea(A=A*nWin),
-    setArea(A=A_glass*nWin),

in the Window model, for which the new implementation is the more accurate computation as far as I am concerned.

So I think we can accept these changes and move ahead..! @kldjonge @jelgerjansen do you agree?

[jelgerjansen]

Is the difference in ratio A/A_glass the same as the ratio of both q50 values? But probably this does not have to be like this because the q50 value is a combination of all wall components connected to that zone?
Before moving on, I would like to merge this PR and redo all unit tests to make sure that nothing else broke while fixing the issue of the TwinHouses example.

[Mathadon]

@jelgerjansen Indeed, the results are affected by all surfaces so the q50 value does not scale proportionally.

[Mathadon]

I would propose to update the reference results of the current PR and then run unit tests again for Mathadon#2 to look for new changes.

[jelgerjansen]

@Mathadon I'll update the reference results of the current PR, but I'll compare them to those of the stack airflow branch (#1322) to do one last check of this PR.

[jelgerjansen]

I've included an overview of the reference results that show significant changes compared to those of commit . The reference results are those from #1322.

IDEAS.Buildings.Components


There is a large change in U_default, which is caused by a higher heat flow. Not sure if this can be attributed to the changes made in the last couple of commits.

IDEAS.Examples.TwinHouses
IDEAS.Examples.TwinHouses.BuildingO5_Exp1_1Port still shows a relatively high difference between W40[1]/W37[1] and W40[1]_ref/W37[1]_ref (so compared to the reference results of #1322). Maybe this should be looked into before continuing.

IDEAS.Examples.TwinHouses.BuildingO5_Exp1_2Port now has the same reference results as #1322, which seems good. However, we must not forget to include the airflow throug wall W40 once the validation data of the 2-port configuration using CONTAM is availabe @kldjonge.

[Mathadon]

@jelgerjansen commit 07c74e4 fixes a parameter bug that is a possible cause for the remaining changes. I pushed it on branch project_itz_fixes_v2.

[jelgerjansen]

@Mathadon I ran the branch project_itz_fixes_v2, but I ran into an error which I solved in commit 33e525c (see branch origin/project_itz_fixes_v2).
Unfortunately, I get the same 'problems': a large deviation of U_default for IDEAS.Buildings.Components.Validations.WindowEN673 and comparison_w40[1] for IDEAS.Examples.TwinHouses.BuildingO5_Exp1_1Port

[jelgerjansen]

The deviation of U_default in IDEAS.Buildings.Components.Validations.WindowEN673 is due to a change of the window fraction (and therefore A_glass): the default value of 0.15 for the component window was used previously, but is now changed to 0. This new value seems more appropriate since it is also used in the other window component windowEN673.
Therefore, the updated the reference results (commit 69d307e) are the 'correct' ones.

[Mathadon]

For clarity, we still have to cover the comments here: Mathadon#2