Unexpected temperature flattening with AirBoundaries

MatteoMerli · July 28, 2025, 12:26pm

I’m running into some unexpected behaviour when using AirBoundaries in Honeybee models.

When setting an Air Boundary, Honeybee automatically adds ZoneMixing objects between the connected zones, assuming an air speed of 0.1 m/s.

In my tests with two identical, unconditioned zones and no internal loads, I found that once the wall is set as an AirBoundary, the temperature profiles of the two rooms become somewhat flattened. If I manually remove the ZoneMixing object from the IDF, the temperature profiles start to make more sense, representing an average of the two zones’ conditions before they were connected, and the results also match those of a merged single-zone model. With zone mixing assigned, I would have expected just a faster averaging between the zones, not such a dampening of their peaks.

What seems like an incorrect balancing in the airflows when using ZoneMixing may actually be more of an EnergyPlus issue than a Honeybee one, that’s why I first posted about it here on Unmet Hours.
However, since AirBoundaries are commonly used in Honeybee, and since ZoneMixing is automatically assigned to them, I thought I’d ask here in case others have noticed similar results.

This also reminds me of another issue I looked into a while ago involving CO₂ dilution with ZoneMixing. There too, the exchanged air appeared to distort the mass balance showing strange results in terms of CO₂ concentration. That post is here.

Would love to hear your thoughts.

MatteoMerli · August 28, 2025, 4:28pm

Hi @chris

I was hoping you could take a look at this since it feels like a pretty significant issue, as air boundaries are such a common object in Honeybee and they’re particularly important for some projects I’m working on.

Another user has already done some testing and reported it on the EnergyPlus GitHub (post), so your input there would probably carry a lot of weight too.

chris · February 23, 2026, 8:58pm

HI @MatteoMerli ,

Sorry for not seeing this when you first posted and for it taking so long for me to respond.

You sparked quite a good discussion on Unmethours and congratulations on reporting an issue that has resulted in an EnergyPlus GitHub issue. I am pasting it here for reference if others want to follow whether anything comes of it:

github.com/NatLabRockies/EnergyPlus

Interzonal air transfer appears to increase the thermal mass of a model

opened 05:13AM - 13 Aug 25 UTC

sullivj1

UnconfirmedDefect Triage

### Issue overview This issue was originally posted on UnmetHours [here](https:…//unmethours.com/question/102288/how-should-air-boundary-simple-zone-mixing-work/), but after sufficient testing and discussion with others we're fairly confident this is an error in EnergyPlus so I'm reporting it here. In brief, EnergyPlus does not appear to be modelling heat transfer from interzonal air exchange properly, resulting in zone mixing changing the air temperatures as if it was adding significant thermal mass to the model. These results are difficult to explain, and are at odds with the predictions of at least one other simulation tool (CSIRO's AccuRate) or what we get if we just merge the zones into one. If significant two-way mixing is applied between zones the effects on both temperature and energy use (particularly cooling) can be substantial. It also appears to be broader and more fundamental than just an issue with the simple ZoneMixing objects (ZoneMixing, ZoneCrossMixing, Construction:AirBoundary). The same kind of effect also appears to occur with the AirflowNetwork, and I also got the same effects when I instead supplied outdoor air via the HVAC system and changed the outdoor air node temperature to that of the other zone using the EMS. **Tests** The first thing I did was grab an old two-zone test model I had and try to replicate the results reported on UnmetHours, which I did. In my case, my model had a large main zone with windows, and a much smaller zone attached to it. In this case we would expect that putting a large opening between the two zones would result in the air temperatures converging to that of the main zone. Running a high degree of air exchange (3 m3/s) between the two zones results in the model acting as if it has much higher thermal mass, with a lower shifted peak and higher temperatures overnight. We get the same results from both ZoneCrossMixing, and using two ZoneMixing objects. Merging the zones into one, however, does not do this and just produces temperatures almost identical to that of the larger main zone as we would expect. High air mixing should produce a similar result but it doesn’t. <img width="669" height="417" alt="Image" src="https://github.com/user-attachments/assets/bf230f28-f174-4294-88b6-7b8201643a95" /> One directional air exchange using a single ZoneMixing object just results in the temperatures in the target zone being pulled towards that of the source zone, as we would expect. This may also apply when using the AirflowNetwork as well. It’s harder to test, since I can’t easily force air exchange between the zones, but just setting up a 27m2 permanent opening between the zones and some leakage produced results similar to what we get if we use cross-mixing to exchange a similar amount of air (here ~0.75 m3/s roughly lined up with what was happening in the AFN): <img width="664" height="456" alt="Image" src="https://github.com/user-attachments/assets/7f2562af-f150-4762-b4ab-fa3cceb4c6ff" /> As a follow-up, I then looked at what would happen with two identical zones. Theoretically, this should provide a very clean test since if the zones are identical then exchanging air between them shouldn’t do anything since they have the same temperature and loads. Again, however, we see EnergyPlus produce this bizarre result. Indeed, rather than mixing the two zones we can even have one zone cross-mix with itself, which should definitely have no effect. Again though we see it act as if it has more mass. <img width="707" height="347" alt="Image" src="https://github.com/user-attachments/assets/83804b64-e8d9-470c-a216-319dc97e693a" /> These temperature changes also affect energy use - adding cross-mixing to the identical zones here reduced heating use by 10% and cooling by 28% in a quick test (18 and 25C setpoints). It should also be noted that this still appears to be an issue with one directional ZoneMixing, even if it is far less apparent than when you have recursive two-way mixing. While adding ZoneMixing (here transferring air from the identical Zone 2 to Zone 1) does not appear to have an obvious impact when looking at overall temperatures, if we zoom in on how the zone temperatures have changed the impact is more apparent. Zone 2, of course, has had no change in temperature because removing air does nothing to the loads. Zone 1 however shows a distinct daily temperature shift, being cooler in the day and warmer overnight: <img width="637" height="337" alt="Image" src="https://github.com/user-attachments/assets/9dade153-6c8d-429a-aea3-074cdd638518" /> Finally, to check whether or not this is an issue with EnergyPlus specifically, I re-ran these tests with AccuRateNZ using CSIRO’s Chenath engine. <img width="666" height="355" alt="Image" src="https://github.com/user-attachments/assets/5c90c21c-db48-4f82-825f-04080e4d8d06" /> AccuRate does not agree with EnergyPlus, and instead produces the results we would expect. With a big zone and a small zone, adding a large opening between them results in the temperatures converging to that of the big zone (and a small reduction in mass because we’ve removed most of the internal wall). When we connect to identical zones to each other, it results in no change in temperature as we would expect. I've attached a couple of my duplicate zone models, and I can share others if it would be helpful. [testcell_2zone_magicmixing.idf.txt](https://github.com/user-attachments/files/21747389/testcell_2zone_magicmixing.idf.txt) [testcell_2zone_magicmixing_nomix.idf.txt](https://github.com/user-attachments/files/21747390/testcell_2zone_magicmixing_nomix.idf.txt) ### Operating System (Multiple choices) Windows ### Operating System Version 11 ### Version of EnergyPlus 22.1.0 ### Unmethours link or helpdesk ticket number https://unmethours.com/question/102288/how-should-air-boundary-simple-zone-mixing-work/ ### Defect file _No response_

It would seem that this is a situation that can happen when you have AirBoundary adjacencies between two rooms where the surface area of the AirBoundary is particularly high in relation to the volume of the rooms (like your screenshot). This results in the room mixing over more air in a timestep than it actually has in its total volume.

I think we would all agree that E+ should at least be giving a severe warning in this case if not providing a better auto-correction for this effect. So I hope that E+ GitHub issue eventually gets a response.

Did you try the suggestion given at the bottom of the unmethours post of just increasing the timestep? You can use the _timestep_ input of the HB Simulation Parameters component to boost the timestep all of the way up to 60 and then see if you still notice the effect.

The other option for working around this is to change the air_mixing_per_area input on the AirBoundary Construction used by Honeybee. It’s not exposed on any component but you can see here in the Honeybee SDK that the AirBoundary Construction has a property for this, which you can change from the default value of 0.1 m3/s-m2. So you would just have to create that construction inside of a GHPython component and assign it to all of the faces in your Honeybee Model that have an air boundary.

I’m not quite at the point that I would change the air mixing of the default AirBoundary construction in Honeybee if only because these cases of very high AirBoundary-area-to-Zone-volume ratio tend to be rare in models of real buildings. So I wouldn’t want the real-world cases to suffer because some of the more abstract test cases we have come up with are inaccurate. Also, for those needing really accurate simulations, upping the timestep is always a good suggestion, which seems to eliminate this effect as far as we can tell. Let me know if you feel strongly otherwise, @MatteoMerli .

MatteoMerli · February 24, 2026, 7:13pm

Hi @chris,

Thanks a lot for following up on this!

Yes, I have tested increasing the timestep to mitigate this damping effect and, depending on the model, it either makes it disappear or just reduces it, confirming that the issue is tied to how much air is exchanged within a timestep.

What helped me clarify things was identifying the relationship between the three involved variables: u = air speed across the AirBoundary (m/s), t = timesteps per hour, and V/A = ratio between the smaller zone’s volume and the AirBoundary surface area.

This is then used to compare the air volume exchanged during one timestep and the volume of the smaller zone. Therefore:

If > 1 → more than 100% of the zone air is exchanged within a single timestep → inaccurate results.
If < 1 → the exchanged volume is smaller than the zone’s volume → physically consistent results.

I plotted this air-mixing-flow/room-volume ratio for different V/A values and for each possible EP timestep t, using Honeybee’s default air mixing speed u = 0.1 m/s. This allows to see which combinations of V/A and timestep lead to physically consistent conditions. Note that if changing the air speed, the graph curves shift and the allowable V/A scales proportionally (half of the air speed → double the allowable V/A).

For example, from the graph, considering the default timestep of 6, all models with V/A ratio < 60 would give inaccurate results, and based on my experience they are not that uncommon. Many models I have seen have V/A ratios between 5 and 30 (whenever one of the room sides is set as an AirWall). In those cases, only timesteps > 15 would give accurate results (and for the lower ratios, even t = 60 would not be enough). These simplified and more abstract test cases were only meant to isolate issues I noticed in more complex models that I unfortunately couldn’t share in the forums.

Since I found this issue, I have tried avoiding AirBoundaries as much as possible. When I cannot avoid them, I use that equation to evaluate how much I need to increase the timestep and/or reduce the air speed (which may also be more realistic in some cases).

That said, this is currently limiting some of our studies (e.g., large atriums or big spaces that cannot be modelled as single zones), so it would be great to see it addressed by the EP developers, and in the meantime get a waning implemented to inform of this current limitation.

chris · February 24, 2026, 7:29pm

Thanks, @MatteoMerli .

In this case, why not use the workaround that I listed here?

You can make a custom GHPython component that takes the model you are about to simulate and replaces all of the air boundary constructions with ones that use no flow rate or a smaller flow rate.

MatteoMerli · February 25, 2026, 10:40am

Thanks @chris. Yes, that’s a valid workaround, but only up to a certain extent. For large spaces where one or more sides are modelled as AirBoundaries, the V/A ratio becomes small requiring either a very high timestep or a near-zero flow rate.

Also, increasing the timestep up to 60 in complex models significantly increases simulation time and for example limits studies that involve multiple iterations. It also limits the possibility of simulating forced air mixing between rooms at higher air speeds, that is what I was investigating before my CO2 post.

Just to clarify, I don’t think there is much that can be done on the HB side, except maybe making users aware of this limitation and inform about the tuning options. It seems to be a structural limitation in EP related to the stability of the air mass balance equation, which I consider quite serious, so I’ll follow up on GitHub!