It is fantastic to see Honeybee support the Airflow Network, I really appreciate the amount of effort that has gone into this feature - big thanks @SaeranVasanthakumar and @chris for this.
As I am looking to replace/upgrade our current workflows, I have a couple of questions to make sure we use it correctly.
1.) Infiltration modelling: I have seen HB creates an AFN Surface and Surface crack object for each external surface, and that the crack properties are reverse-engineered following this to meet the infiltration value specified with HB Loads (assuming no leakage template is selected).
I have made a couple of tests, and the results of AFN Zone Infiltration Air Change rate doesnāt seem to align with the input in HB Loads. Is there something Iām missing?
This would help a long way when we model for code/standard compliance where the infiltration value is specified. Currently, we have to iterate over Air mass flow coefficient values, until the average infiltration over a certain period of time matches the Code requirements - which is time consuming.
2.) Opening factors for windows: I have noticed that window opening is controlled with the EMS, while all the settings in the AFN are left as NoVent. The EMS sets the opening factors to 0.5 when indoor temperature is above the setpoint.
Is there any specific reason for this not to be Opening factor 1?
It would be great to understand the logic behind, just to make sure we donāt misuse the AFN.
Rafael
I have also generally found that the air flow rates that I get with the AFN tend to be significantly lower than that with the simple ventilation/infiltration objects but, until now, I assumed this was largely because my models were usually of a small section of a building and so I wasnāt really capturing the buoyancy-driven pressure differences that I would see with a multi-story full-building model. If you are also getting low air flow rates with large models, maybe there are some inaccuracies with the assumptions that we make in order to map between the simple objects and the AFN. In particular, we assume that the constant infiltration flow rates are meant to be āat a typical building pressure of 4 Paā. You can see this assumption in this part of the code:
Maybe this assumption was too high and ātypicalā building pressure differences are actually lower like 2 Pa. If you edit the assumed pressure difference going into that function there and you find that you get results from EnergyPlus that are closer to the constant infiltration objects, I think we are open to editing this default assumption. As you can imagine, this assumption is a really tough one to make since the ātypicalā pressure differences experienced by a building are a function of things like wind speed, the height of the building, the indoor/outdoor temperature difference, and other properties.
Because ātypicalā pressures can vary so much, maybe we should also just expose it as an input on the AFN component.
The opening factors correspond to the _fract_area_oper_ of the windows:
So, if you set that value to 1, that indicates the entire window surface can open (like a casement window that swings fully open) and you will see that you get opening factors of 1 accordingly.
I think this underestimation of air flow is somewhat expected. The derivation method weāre using underestimates air flow because of the limitations inherent in taking a representation of uniform infiltration flow rate per exterior area (IFREA) and separating it (non-uniformly) into perimeter/area leakages so that it can participate in the AFN.
But before I get into why this is happening, itās helpful to clarify that there are plenty of cases where we donāt intend or expect the resulting infiltration rate from the AFN to match an equivalent IFREA, even when the coefficients for the former are derived from the latter. The IFREA is making a lot of assumptions about building geometry, orientation and opening size/frequency in the building, which wonāt match your specific building exactly. The IFREA also doesnāt model negative pressure, whereas the AFN will produce negative air flow rates at times. Thus the difference between the two will get higher the more exotic your building massing, opening geometry and building pressure gradient is. In such cases, itās better to use the leakage templates as the IFREA is not a good representation of the infiltration occurring at your building[1].
That being said, as I mentioned, the method is underestimating air flow. Specifically, I believe the guilty culprit is actually this solve_norm_perimeter_flow_coefficient function. Youāll notice the documentation for this function acknowledges its limitations:
Since this value is derived from the infiltration flow rate per exterior area, which represents an average over many types of air leakage rates, this value is not intended to be representative of actual opening edges flow coefficients.
This comment is alluding to the fact that since IFREA is representing an average value for the entire building faƧade, there is no mathematical way to unpack that value to better figure out the proportion of that rate that is from edge versus areas, since we donāt have any information about IFREAās underlying assumptions about edges versus area leakage. In absence of that information, I basically assumed the air flow rate from the opening perimeter is equivalent to what the infiltration flow rate per exterior area would have been for the opening area. I.e the flow coefficients are weighted by the area of openings versus walls.
In theory the average of the total opening edge leakage rates plus the average surface infiltration will equal the IFREA rate, even though we are definitely overcounting one and undercounting the other.
When testing this, I found that our derived mass flow coefficients for such openings were consistently lower than what other references suggested (i.e DesignBuilder), and was consequently contributing to the biggest difference in the air flow rates between the AFN from leakage template and our derived equivalent. At the time, I reasoned that this simplification was necessary to keep the total IFREA value equal to the theoretical average of the area/edge flow rates, but this discussion has made me rethink that rationale.
Iām not sure what the best solution is to fix it is, though. Reducing default pressure is one way, but I also wonder if we should include the area of openings in the derivation of the flow coefficient for the wall area. This would mean removing the opening_area variable in this formula from the IFREA derivation:
Itās basically removing the complexity of trying to separate the wall and opening leakages, and just assigning the entire IFREA to the walls, which might reflect the IFREA better.
S
[1] From the Honeybee Wiki article on infiltration that Iām working on:
Another idea about how we could bridge the IFREA flow rate with the AFN derived version is to calculate the default pressure manually, similar to how EP calculates it for non-AFN methods. That way weād be deriving the flow coefficient from, not only the same output flow rate (the IFREA), but also a similar pressure difference.
We could calculate delta P like this:
dP_stack = density_oa * g * H * |Tz - T_oa|/Tz
dP_wind = 0.5 * density_oa * (Sw * Vh)^2
dP ~ sum or square root of sum of squares of both dPs
Which is similar to how the wind and stack pressures are calculated in non-AFN air modeling. Itād be interesting to see how often this method would produce a lower dP then the 4 Pa assumption weāre making.
Thanks @chris for the clarification regarding the discharge coefficient - I somehow missed that.
The topic of infiltration is far less simple, as could be anticipated. Thanks @SaeranVasanthakumar for the detailed explanation. I have to say that until now, I only tested the AFN implementation in HB with an amended version of the AFN_apartment example file that comes with LBT. All my experience with AFN comes from editing files in E+, or via additional strings.
The IFREA vs AFN infiltration modelling has been one of my main headaches for quite a while, since we are forcing a more detailed method (AFN and crack factors) to match a simplified value (IFREA). Unfortunately, I donāt think we can escape the compliance point of view and it is necesarry to have the right volume of infiltration into the building, so that results can be compared with regulation or code targets.
Having said this, my line of thought is getting divided in two options - pretty much the current split in HB:
1.) One where the resulting infiltration from the AFN matches an IFREA value. I guess that we would look into an average value over time - until I saw that discussion in Unmet hours, I thought this could only be achieved by aproximating air mass flow coefficients iteratively. Even so, it might be unworkable since as you mention, pressure around the building affects infiltration every timestep.
Do you know how sensitive is the resulting infiltration through a crack to variations in pressure?
In some large models we ran, I found it varies around a target value over time in a similar order of magnitude (say Ā±30%). The same air mas flow applied on different orientations yielded similar infiltration volumes, which leads me to think that the incoming volume of air might not be that sensitive to variations in pressure.
With that in mind, it seems a matter of finding the right reference pressure when calculating air mass flow coefficients. I donāt have much knowledge on how to approach this, other than testing different Reference pressures than the default 4Pa, as @chris suggests. Looking at @SaeranVasanthakumar formula below, we could use the annual averages of those parameters to get an average dP as a reference - is this what you had in mind?
Tapping on the breakdown of infiltration via walls or windows, I share your reasoning to have the IFREA applied to the walls/opaque areas of the envelope, while ignoring window areas. Since IFREA values relate to the exposed envelope, it seems appropiate to leave the window breakdown out of this. This would leave windows with a minimal, almost zero infiltration via the perimeter cracks (even if this is tangential to the issue, I found that infiltration through windows dissapears when these open for ventilation - another reason why I would leave them out).
2.) A second option where infiltration is a result of more realistic crack factors. Instead of specifying a target infiltration value as an input, infiltration is a result based on the crack properties. I havenĀ“t looked into Designbuilder templates yet, but this seems an exciting path (on that note I recently found this paper with a good compilation of airflow values via cracks on different elements, in case it is useful). With a reliable source of inputs, this is a great option to have in my opinion.
It sounds like thereās a consensus that we should not be subtracting the opening_area from the ext_face.area and, from what I understand of the explanation, it makes sense to me. If itās true that we have a consensus, then we should make a change to the honeybee-energy code base. Iām happy to take care of it but, @SaeranVasanthakumar, if you want to put together the PR, then that will give me some time to look into the LaTeX plugin.
It sounds like we might also want to expose the delta_pressure on some of the higher-level methods but that might be a lower priority for now.
In any event, I share the headache of trying to map between IFREA vs AFN and I agree that there doesnāt seem to be a way that we can really avoid it. Itās not just for the compliance reasons that you cited, @RafaelA , but itās also the fact that the state of the art for measuring infiltration in buildings is still the blower door test. And all that we get from those tests is a flow rate at a given pressure (essentially an IFREA-type metric). So, until we get a more sophisticated way to measure infiltration, weāll need a method for taking these flow rates and converting them into the inputs of an AFN if we want them to inform our AFN-based simulations.
Along these lines, I donāt know if āSimulation Accuracyā is really the term that I would use to describe the differences between the models in the wiki docs you are working on , @SaeranVasanthakumar . A model can be very simple but still be āaccurateā in that itās close to a real-world observation. Conversely, using a crack data template can be a good representation of real-world physics but it can be very inaccurate if you choose the wrong template. So I think itās more the āFidelity to Physicsā that actually describes the differences between the models.
This makes a lot of sense, and is arguably contributing to a conceptual bug in our code. The AFN only models crack-like infiltration when the when windows are closed, But, as I understand it, that is not the behavior of IFREA which maintains a constant rate of infiltration per itās schedule, and thus produces more infiltration during those periods. Adding the opening area back into the area calcs will fix this too, so for all these reasons, I agree that is the best route. Also, now that Iāve had time to sleep on it, my suggestion for custom dP calculations wouldnāt work without adding a lot of additional complexity, and is not a good solution. Iāll see if I can put together a PR for the area addition.
Interesting, I didnāt have much luck finding resources for crack templates. Can you share the title/author - the link isnāt working for me.
Thanks, thatāll make math discussions a lot easier!
I am also realising now, that even if we are able to replicate an IFREA target with the AFN, it wonāt follow a schedule - it will always move around a 100% value. For a lot of cases this is not an issue, but I can see how it would be conflictual with the programme templates in HB libraries, which have variable infiltration schedules (if Iām not mistaken these relate to US standards). Here in Europe, it is not that common to have a schedule, and they only specify a IFREA value (ie. 1.0 m3/m2Ā·h).
Maybe just a warning on the AFN component when no DesignBuilder template is selected could clarify the situation for now.
Agreed. It seems to me that weād need to fine tune how to aproximate the AFN input values. For now, Iāll try to get some testing done with different deltaPressures to get a better picture.
Maybe this link to one of the authors Linkedin post works, the article is shared openly there. Otherwise, this is the full title: On the applicability of meta-analysis to evaluate airtightness performance of building components. Martin Prignona, Sergio Altomonte, Felipe Ossio, Arnaud Dawans, Geoffrey Van Moesekea. Building and Environment, Volume 194 May 2021, 107684
I just wanted to let you know that the Discourse Math plugin is now installed. I selected the MathJax render but let me know if you think you would prefer the KaTeX renderer.
@chris, @RafaelA sorry for delayed response here, Iām in the middle of multiple deadlines. But Iāve managed to slowly chip away and have two updates.
1. Reason for mismatch between AFN and target room infiltration
First off, I can confirm that @Chrisās initial speculation was correct, the envelope reference delta pressure is the source of most of the mismatch between the AFN infiltration rate and the target IFREA. My guess about moving the aperture edge air flow into the facade area air flow calculation ended up having only a marginal impact on AFN infiltration.
I did some tests on two test AFN models (multizone and single zone). With no changes, the IFREA target (0.000569 m3/s-m2) was an order of magnitude higher than the AFN infiltration rate (0.000085 m3/s-m2) (or ~15% of the target value). This roughly corresponds to the difference between the 4 Pa reference delta pressure and the āactualā simulated delta pressure, as reported in the āAFN Linkage Node 1 to Node 2 Pressure Differenceā EP output.
Accordingly, Iāve updated the code to expose a delta_pressure input that can be used to enter a custom reference delta pressure if thereās a need to match the AFN infiltration with the IFREA target.
2. How to calculate the reference delta pressure
While using an average of the output from the āAFN Linkage ā¦ā report will get the AFN room infiltration to the same order of magnitude as the IFREA, itās still fairly imprecise. This is because those output pressures are, in turn, a function of our coarsely approximated reference delta pressure of 4.
The good news is I found a way to calculate the reference delta pressure needed to hit the target IFREA with high accuracy. The bad news is that you need to run at least one simulation in order to capture the ratio that governs the relationship between the reference delta pressure and output pressures. I donāt think thereās any alternative to this, based on my understanding of the problem, so thereās no easy solution that I can include in the code to get AFN rates to match the IFREA automatically. But I can at least explain the formula to calculate it with at just one simulation, so thereās no need to iterate over parameters manually until results converge. The final formula is a little counterintuitive but the derivation is fairly straightforward:
Start with the power law function between any AFN-simulated infiltration \dot{Q}_{afn} and the AFN-derived delta pressure \Delta{P}_{afn}, and take the log of both sides to make our math simple: \dot{Q}_{afn} \cdot \rho = C \cdot \Delta{P}_{afn}^n log(\dot{Q}_{afn} \cdot \rho) = log(C) + n \cdot log(\Delta{P}_{afn})
Substituting the flow coefficient C with the formula used in the solve_norm_area_flow_coefficient function. This exposes \dot{Q}_{ifrea} the IFREA target value: \begin{align}
log(\dot{Q}_{afn} \cdot \rho) &= log(C) + n \cdot log(\Delta{P}_{afn}) \\
&= log(\dot{Q}_{ifrea} \cdot \rho) - n \cdot log(\Delta{P}_{ref=4}) + n \cdot log(\Delta{P}_{afn})
\end{align}
Finally, rearrange to solve for the AFN-simulated delta pressure and get rid of the log: log(\Delta{P}_{afn}) = -\frac{1}{n} \cdot log(\dot{Q}_{ifrea} \cdot \rho) + \frac{1}{n} \cdot log(\dot{Q}_{afn} \cdot \rho) + log(\Delta{P}_{ref=4}) \begin{align}\Delta{P}_{afn} &= exp(-\frac{1}{n} \cdot log(\dot{Q}_{ifrea} \cdot \rho) + \frac{1}{n} \cdot log(\dot{Q}_{afn} \cdot \rho) + log(\Delta{P}_{ref=4})) \\
&= \sqrt[n]{\frac{\dot{Q}_{afn}}{\dot{Q}_{ifrea}}} \cdot \Delta{P}_{ref=4}\end{align}
And thatās pretty much it. \Delta{P}_{afn} provides the reference delta pressure required for any target room infiltration rate \dot{Q}_{ifrea}. The initial AFN-simulated infiltration rate \dot{Q}_{afn} and assumptions for n, \rho and \Delta{P}_{ref=4} (0.65, 1.225 and 4), are constants in this formula, so only have to be calculated once for a given structure.
The only other thing Iāll add is that I found this worked well for simple AFN models (98% of the target), but got slightly less reliable as model complexity increased in my multizone setup (I guess the data gets noisier with more complex multizone flows). Luckily, the formula above tells us that the logs of \Delta{P}_{afn} and \Delta{P}_{ref=x} are linearly related, so the most accurate way to approximate true values is simply by fitting a straight line to the noise. Specifically, you can iterate through a couple of reference delta pressures, capture the output infiltration rates and plug the logs into a linear regression. In practice I found that my multizone model (the AFN apartment from the sample files) was able to get to 98%+ of the target with just two data points.
Thank you for all of this, @SaeranVasanthakumar . This is a huge help and you clearly put a lot of thought and testing into this. I merged your PR and Iāll expose the delta_pressure on the AFN Grasshopper component shortly and post back here.
