AFN Infiltration and ventilation questions

grasshopper honeybee
1

Hi all,

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

cc @LanceMonfort

3 Likes
2

Hi @RafaelA ,

Thanks for digging into this.

  1. 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.

  1. The opening factors correspond to the _fract_area_oper_ of the windows:
    image
    image732Ɨ355 18.3 KB

    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.
3

@chris, @RafaelA

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:

        flow_cof = flow_cof_area * (ext_face.area - opening_area)

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:

image
image686Ɨ512 69.8 KB

4

@chris, @RafaelA

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.

p.s @chris can we get a LaTeX plugin for the forums, itā€™ll make these discussion a little bit more legible i.e https://meta.discourse.org/t/discourse-math-plugin/65770 ?

5

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.

Rafael

6

Thank you both, @SaeranVasanthakumar and @RafaelA ,

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.

7

@chris, @RafaelA

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!

Agreed, good point.

1 Like
8

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

9

Hey @SaeranVasanthakumar ,

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.

Look at this beautiful formula!

Qva * d = Cqa * dP^n
1 Like
10

Thanks @chris!

q_{cond}= -k \frac{dT}{dx}

Works perfectly!

11

@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:

  1. 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})

  2. 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}

  3. 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.

12

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.

13

The delta_pressure has now been exposed on the latest component in the LBT Grasshopper development version:

image
image1075Ɨ431 49.6 KB

Thanks again for all of the work here, @SaeranVasanthakumar !

1 Like
14

Hi @SaeranVasanthakumar

I am trying to use your formula in order to find the reference pressure but I donā€™t know how to get Qafn from my initial AFN simulation. The only output I found is the hourly zone infiltration air change rate which is in ACH and I donā€™t know if it is convertible to the infiltration flow rate per exterior area.

15

Hi @Shadab_mdr

Lately, Iā€™ve been working with the AFN component to achieve a specific value of infiltration rate in accordance with the regulatory requirements Iā€™m following.

To calculate Qafn from the initial simulation, you can extract the variable AFN Zone Infiltration Air Change Rate or AFN Zone Infiltration Volume and convert their values to match the unit of measurement of the reference Qifrea using the geometric dimensions of the zone. In my case, where Qifrea = 0.0003 m3/(m2 s), I can either divide the air volume (in m3/hour) by exposed area* 3600 or multiply the air change rate (in 1/hour) by the zoneā€™s volume and then divide it by exposed area*3600.

To obtain a unique reference pressure, Iā€™ve noticed that using the annual average of the hourly Qafn values and then dividing it by Qifrea yields better results compared to averaging the hourly values of Qafn,h/Qifrea ratios.

In my case, the situation is further complicated because the model consists of multiple zones, and still, the resulting reference pressure must be unique for the entire model. Simulating with different formulas, I found that the formula which yielded the best correspondence between Qifrea and the annual average of Qafn across all zones was as follows:

image
image975Ɨ91 2.89 KB

Regrettably, when testing the same method on different models, I havenā€™t obtained comparable results, and thus, I couldnā€™t validate the use of one formula rather than another.

However, the employment of this comprehensive method introduces a significant problem that I noticed when analyzing the buildingā€™s heating demand: although the resulting reference pressure ensures the desired annual average infiltration, its annual trend is highly variable, characterized by pronounced peaks during the winter months. These peaks result in a heating demand that is twice as high as that of a scenario without AFN.

image
image1004Ɨ451 143 KB

This makes me think that the annual average infiltration cannot be compared with the regulation or code targets, as they probably do not account for such periodic peaks. Consequently, despite the hourly infiltration trends appearing more realistic, I am hesitant to rely on the results I obtained.

In conclusion, I havenā€™t delved further into the approach discussed so far, as I discovered the existence of the ā€œAirflowNetwork: MultiZone: SpecifiedFlowRateā€ object, implemented in EnergyPlus version 9.6.0. This idf object allows me to assign a constant airflow to each external surface, calculated simply as Qifrea for the area of the considered surface. By adopting this method, I achieve a constant infiltration rate that aligns with the regulatory requirements without renouncing the advantages of using the AFN.

Hope all of this helps you,

Matteo

P.S. It would be cool to write the formulas like @SaeranVasanthakumar did above, but I havenā€™t quite figured out how to do it yet.

1 Like
16

Hello @MatteoMerli
Firstly, Iā€™d like to express my appreciation for your comprehensive responseā€”it was incredibly helpful. Iā€™ve made progress in converting the hourly infiltration air change rate (ACH) to Qafn based on their units. But I also have multiple zones so I will try to use the new formula that you proposed.

However, I also realized that this method does not fix the issue entirely. Iā€™m still facing some challenges as I continue to encounter discrepancies in hourly operative temperatures and relative humidity values for a specific zone when modeled through the AFN compared to a default simple model (using Qifrea). Iā€™ve actually initiated a new forum topic to delve deeper into this issue. HB AFN model results not consistent with the default simple simulation

To ensure clarity, I have a few questions:

In your formula, when you mention ā€œn,ā€ I assume itā€™s the same ā€œnā€ as before, correct? (A constant value equal to 0.65).

I also have a query regarding the EnergyPlus object you introduced. As Iā€™m primarily investigating the impact of natural ventilation, should I incorporate the airflow rate through the opened windows as an input for this object, or does it mainly pertain to the infiltration rate, primarily related to opaque surfaces?

Many thanks,
Shadab

17

Regarding the discrepancies between models with and without AFN, I suspect itā€™s inherently linked to the amount of air entering through infiltration. To better assess the impact of it, you can check for both models the hourly air inflow and the relative T and RH.

The formula I wrote was suitable in my case because the initial AFN simulation underestimated the annual average infiltration rate, and I needed to increase it. Using the other formula, where you raise it to a negative exponent, it results in Ī”P greater than Ī”Pref and consequently leads to even lower airflow rates.
Yes, the value of n remains equal to 0.65.

Since you are investigating natural ventilation, what you probably want is a defined and constant infiltration that doesnā€™t significantly influence your analysis. Therefore, I would recommend replacing the ā€˜AirflowNetwork: MultiZone: Surface: Crackā€™ objects for all external opaque surfaces with ā€˜AirflowNetwork: MultiZone: SpecifiedFlowRateā€™ objects. You can identify the Crack objects for external surfaces if they have an ā€˜Air Mass Flow Exponentā€™ equal to 0.65. To streamline this process, when you create the Specified Flow Rate objects, you can keep the original name as the Crack objects (e.g. ā€˜Airflow Network Crack 5ā€™) that you are replacing. The ā€˜Air Flow Valueā€™ (volumetric) is simply calculated as the product of the surface area in question and the Qifrea (in m3/s m2) that you aim to achieve. To completely eliminate variability in infiltration, you also need to lower the value of ā€˜Air Mass Flow Coefficient When Opening is Closedā€™ for all external openings (e.g. to 1e-09 kg/(s m) as for the internal openings).

When it comes to exporting airflow rates, it appears that the airflow resulting from the Specified Flow Rate objects is included within the output variable ā€œAFN Zone Ventilation Volumeā€. However, if you donā€™t have operable windows in your baseline, this variable should include for now only the infiltration flows.

3 Likes
18

Thank you so much for your help @MatteoMerli !

1 Like