Project itz fixes v2

[Mathadon]

@kldjonge I have made some revisions to your models:

• revised some variable names so make more clear what they mean
• I move part of the stack computation to the outsideAir component. This seemed more logical since you expect this component to give the correct pressure since it already has a variable Habs.
• This means that I have removed Habs (or it's equivalent) from the stack height computations for walls/windows. As far as I understand this is more correct than the current implementation since right now, assuming you have a zone at height 100m, we'd compute a stack 100m downwards with density a and then a stack 100m upwards with density b, which is now what happens in practice of course.
• I have add a missing pressure column for the trickle vent (It was missing because I thought It was included in the OutsideAir already.)
• I have removed the parameter Hpres since I found it too confusing with all the different heights and relative heights already.
• If I understand correctly, the old implementation also reported the zone pressure incorrectly. It would add, then subtract the relative height of the zone. So a zone at a height of 100m would still be reported as at atmospheric pressure.

Can you verify whether you agree with this logic and whether you agree with the implementation?

@jelgerjansen fyi

[kldjonge]

I suggest to not get rid of Hpres like you did. Now you assume that it is always measured at ground level, which is just not always the case. In meteo-stations it is often done 1m above the ground but I would suggest to make it a parameter for when case studies are modelled and e.g. the pressure is measured on the roof of the building.

So we did not model 100m and then 100m back up. If Hpres was at 1m, we modelled 1m down and then 100m up with the same density. This workaround was nececarry because density colmuns could not have a negative heights and otherwise Hpres could not be higher then the zones. It had the additional benefit that the reference pressure (either port a or port b) could be fixed.

So suggested changes
In: IDEAS.BoundaryConditions.Interfaces.PartialSimInfoManager
add:
parameter Modelica.Units.SI.Length Hpres=1 "Height above ground of meteorological atmospheric pressure measurement" annotation (Dialog(group="Wind"));

In: IDEAS.Fluid.Sources.OutsideAir
change:
Modelica.Blocks.Sources.RealExpression dpStack(y=-(Habs-sim.Hpres)*Modelica.Constants.g_n*rho);

With regards to using the IDEAS.Airflow.Multizone.CrackOrOperableDoor model. Care must be taken for correct implementation of the stack-effect heights. Specifically the IDEAS.Airflow.Multizone.DoorDiscretizedOperable model asks for the position to the reference pressure at the bottom of the cavity because that is how the implementation of this specific model was done. Which is different from the 1/4th-3/4th heights of the cracks.

The cavity stack heights are not correctly implemented now. For each model in which a cavity can be moddelled the correct column heights need to be implemented (hA and hB). This goes back to our discussion here: open-ideas#1338 for internal walls, but the same parameters need to be changed in the window component as it not just the average of the other columns heights.

So in general, I agree with the alternative logic of your implementation but the stack-effect of the open-cavities is not correct due to the convention difference now.

[Mathadon]

@kldjonge I added HPres again in 3f9a5ac :)

Regarding the Door model. I had another look at the equations. It seems that the model does not distinguish between the pressure of the top and bottom ports. The model assumes that both are equal to 'the zone pressure', abstracting the hight within the zone away. This seems consistent with the current use within CrackOrOperableDoor: both ports are directly connected to the outsideAir or the zone.

Then there are the equations within the model, and the parameters of the model. The way I see it, the internally computed 'stack offset' should be zero at the bottom of the door, since you chose the zone pressure to be defined at the floor level (I think?).

So based on:

    pA[i] = port_a1.p + rho_a1_inflow*hAg[i];

  parameter Real hAg[nCom](each unit="m2/s2")=
    {Modelica.Constants.g_n*(hA - (i - 0.5)*dh) for i in 1:nCom}

hAg should be zero for the largest value of pA[i] (i.e. at the bottom of the door). The largest value corresponds to port_a1.p + rho_a1_inflow*Modelica.Constants.g_n*(hA - (1 - 0.5)*dh) (or in fact 0.5 segments below that) and hAg=0=Modelica.Constants.g_n*(hA - (1 - 0.5-0.5)*dh), which results in hA=0. I think that the same reasoning can be used for hB=0. Do you agree wit this analysis? The new can just set hA=hB=0 in the door model?

[kldjonge]

What you say is correct. The door model only computes stack-effect within the model. So the new implementation is also correct with regards to not having 'external' density columns when a cavity is present.

But I always assumed that the zone-pressure is in the middle of the zone (as this is the assumption of for temperature as well and it seems unlogical to have it at different positions), hence the need to substract half the zone height to position the door at the floor height.

[Mathadon]

Okay, so hA=hB=-hZone/2?

[kldjonge]

I commented this in the other issue that proposes a solution:
open-ideas#1338 (comment)

If we don't see it necessary to check for equal absolute floor heights then hA and hB are hZoneA/2 and hZoneB/2 respecitvely for cavities in an internal wall.

[Mathadon]

Todo: verify whether we have to make updates for this:

some change in OuterWall

[kldjonge]

6454345 is not be a no-flow situation when simulated. Temperatures indoors do not evolve towards the intended steady-state stay of 10°C. Because of this temperature differences exists as well as airflow. I believe it has to do with the long-wave radiation (solBus.Tenv<10°C).

[jelgerjansen]

@kldjonge you are correct: the ambient temperature is set to 10°C, but the sky temperature (used for radiation) is calculated somewhere in the WeatherDataReader. This one has to be manually set equal to 10°C.

I sent the simulation results of that specific case (TSky set to 10°C) to Filip, but the changes in the model were not yet included in this branch.

[kldjonge]

Ok, good to know that has been fixed.

FYI, I'm testing/changing/spotting issues at the moment in this branch but can not actually make a branch on it to later generate a pull request (I need to Fork the repo of Mathadon for that, which is not possible because that would be a Fork of a Fork). I'm noting things for myself and will need to redo the changes in a branch that I can acces later.

[kldjonge]

The biggest issue I've encountered so far it that the door model fails to represent non-perfectly vertical openings. So a horizontal opening in the floor (e.g. staircase) is not modeled in a correct way. The model should be able to differentiate between the "height" that is used to calculate the surface area of each compartment and the vertically projected height.

When an opening is horizontal, the flows of all compartments should be exactly the same.

UPDATE It can be fixed by changing the base classes slightly.

[kldjonge]

Apart from things I managed to fix (I will provide an overview next week, mostly stack-heights) something is still wrong with the Lclo calculations. I understand that the Lclo (USA) approach was chosen to be compatible with the existing operable-door component so let's keep that although I feel like you made it much harder then it should be and now it is confusing.

Anyway, there is something wrong. The flow coefficients (C) which are calculated now in m1_flow and m2_flow do not match the coefficient if you simply use the european units C=Vflow/(50^0.65) where Vflow= q50_internal*A.

I'll take a bit more time to check this but I will look into it. @Mathadon, but it would be nice if you could not change things before I manage to write-up the changes I have now locally. I would really like to avoid parallel things again for now. (especially since I will not be able to fetch updates and I need to track each change to keep the CONTAM model up-to-date manually)

CONTAM-MODELICA results are thus not in line at the moment. This makes sense offcourse since the inputs are different.

[flosfeld]

I have noticed this also. In DoorDiscretizedOperable the flow coefficient is C = CD * A * sqrt(2/rho) and the aperture area is A = CD/CDRat*L*dpRat^(0.5-m). The flow coefficient is also C = Q / dp^m = q50*A_q50/3600/50^m. Combining these formulas results in L = q50*A_q50/3600/50^m/CD^2*CDRat*sqrt(rho/2)*dpRat^(m - 0.5). This should be the Lclo for CrackOrOperableDoor.

Also in CrackOrOperableDoor, for point_m_flow1, I believe we should have mMea_flow_nominal = if openDoorOnePort and interZonalAirFlowType == IDEAS.BoundaryConditions.Types.InterZonalAirFlow.OnePort then wOpe*hOpe*1.2*CDOpe*(2*50/1.2)^m else (if interZonalAirFlowType == IDEAS.BoundaryConditions.Types.InterZonalAirFlow.TwoPorts then 1/2 else 1)* q50*A_q50*1.2/3600. For point_m_flow2, mMea_flow_nominal = 1/2*q50*A_q50*1.2/3600.

[kldjonge]

Just to inform you @flosfeld , I have been busy debugging these things in a different branch: open-ideas#1345, I hope to be done with the review this week.