How should Air Boundary + Simple Zone Mixing work?

asked 2025-07-22 04:53:59 -0500

MatteoMerli
246 ●2 ●5

updated 2025-08-05 08:56:38 -0500

14460 ●91 ●25 http://bigladdersoftware.com/

I’m running a simple test case with two identical zones (Office and Reception), empty and unconditioned, to reproduce a behavior I can’t explain that I’ve noticed in my project model.

image description

I’m comparing three runs:

00-noairwall: Zones share a generic interior wall.
01-airwall-noflow: Zones separated by an AirBoundary, but no air mixing defined.
02-airwall: Same AirBoundary, plus two ZoneMixing objects (Office → Reception and Reception → Office) at an equal constant flow rate of 3 m³/s (0.1 m/s over the wall area).

image description

The results of 00-noairwall make sense: Reception heats up in the morning (east-facing windows), and Office heats up later (west‑facing windows).
In 01-airwall-noflow, the two zone temperature curves converge toward each other, roughly averaging the two spaces.
In 02-airwall, after adding the air mixing, both spaces' temperatures flatten and no longer reach the nighttime lows or daytime highs, with also a lag of a few hours. I probably would expect just a faster averaging between the zones, not such a dampening of their peaks.

Note that for mixing I also tried setting the "Air Exchange Method = SimpleMixing" in the "Construction:AirBoundary", instead of the ZoneMixing objects, but it gave identical results.

Am I missing any basic concepts of how interzone air mixing works?

edit retag flag offensive close merge delete

Comments

Huh, that is odd yes. Have you tried making a single zone version of the model? Theoretically sufficient air mixing of the zones should result in them converging to something close to that after all...

Jamie Sullivan ( 2025-07-22 17:03:18 -0500 )edit

I just tried it and it gives the same results as case 01. Thanks for the suggestion

MatteoMerli ( 2025-07-23 04:42:59 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2025-08-04 21:23:40 -0500

Jamie Sullivan
456 ●13 ●5

Alright. I’ve poked things a bit and ran a bunch of tests and talked to people and I think the answer is that EnergyPlus is not modelling heat transfer from interzonal air exchange properly, and you are right to be concerned. This appears to particularly be an issue when you have two-way exchange between zones.

The first thing I did was grab an old two-zone test model I had to make sure I could replicate your results, 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 the temperatures converging to that of the main zone.

As you found, 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, 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.
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.

image description

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): image description

I then looked at what happens 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. image description

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. 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. image description

So at this ... (more)

edit flag offensive delete link

Comments

Hi guys! It's my very first post here.

Did I understand you correctly that this problem even appears if you use AirFlowNetwork?

Is it possible that these odd observations can be caused by the setting inside the ZoneInfiltration:DesignFlowRate object? E+ is using just one coefficient (all others are set to zero).

Could you please share your IDF, please? I would like to reproduce your results.

Kind regards

aleca ( 2025-09-04 06:23:44 -0500 )edit

I have tried something but I would need you IDF to try it. The way E+ handles air mixing as said in the documentation is by "not computing the air leaving the source zone". In other words, it does not check what happens to the zone until the next timestep in terms of air balance.

As you both stated this issue appears at high airflows, have you tried changing the timestep to a smaller one? If 3m3/s are being removed from a zone without being computed until 15 minutes later then it could be that "More air than it is in the zone has" is being mixed. This could converge on the errors you graphed

PmP ( 2025-09-04 06:31:39 -0500 )edit

I reported the issue on E+'s github page here, and I attached a couple of idfs if you want to play with them.

And yes, it does appear to apply broadly and not just to any one object. The AFN is harder to set up, but its results do appear consistent with the issues applying to it as well. I've also attempted other workarounds like using mechanical ventilation to deliver air to a zone and then using the EMS to change the outdoor air node's temperature to that of the other zone, and that has the same effect as mixing.

Jamie Sullivan ( 2025-09-04 18:44:49 -0500 )edit

With regards to the air balance question, my understanding is that it's more that E+ doesn't bother considering the air balance with the simple objects unless you go to a lot of effort to manually do it?

e.g. when you remove air from a room, in real life that would result in a pressure difference that would draw other air in which could result in a temperature change. That won't happen in E+. Similarly, when you "transfer" that air to another zone it doesn't change the air volume or move it around. It just applies a sensible/latent heat load to that zone. I could be wrong there though.

Jamie Sullivan ( 2025-09-04 18:52:28 -0500 )edit

add a comment

answered 2025-09-08 02:46:16 -0500

PmP

415 ●7 ●7

Using the IDFs on your E+ issue I tried changing the timestep from 6 to 60 and to 1 hour and got this results:

image description

As it an can be seen in the image, by changing the timestep to 1 per minute the air balance of the zones resembles that of the no-mixing scenario for zone 1, while zone 2 is brought up to zone 1 temperatures. This is the expected effect of mixing air between a zone significantly bigger than other with high air mixing values. I also simulated with a bigger timestep (1 per hour) and the result was even "worse" zone 1 and 2 temperatures, with less peaks than they should have.

I might be wrong, but my original idea is reflected there: With very high air mixing values, the small zone is transmitting more heat than what it has if the timestep is not small enough, as the air balance for the SOURCE zone is done in timestep t+1 while the receiving zone is done on timsetep t. Another way of understanding it is that if the timestep is too big, air at a certain temperature is being created on the small zones. This creates the "stabilizing" effect that is seen with big timesteps, as it is like giving it much higher thermal mass each timestep for GIVING heat, but not for receiving it.

Thus, it does not seem like a bug, rather an oversight that no part of the software checks if "more air is being mixed out of a zone than that of the zone itself in each timestep".

edit flag offensive delete link

Comments

@PmP FYI, I suggested to @MatteoMerli last year in this post that the mixed air volume in a time step should not exceed the volume of the Zone itself.

I don't use ZoneMixing due to its nature: it does not consider energy balance. See this post for reference.

If what you observed also happens with ZoneCrossMixing, I think it is considered a bug and should be addressed by the developpers.

Keigo ( 2025-09-08 03:56:49 -0500 )edit

This indeed seems to be a post of the same nature and your response of the same kind as mine, applied to CO2 instead of heat balance. I agree with you in that at least it should be addressed by a check and warning or even severe error, as it is unreasonable to asume of the user that they understand such particular nuances of ZoneMixing or ZoneCrossMixing.

PmP ( 2025-09-08 05:16:53 -0500 )edit

Thanks @PmP , I also tried changing the timestep to 60 in the same model and got the same results in cases 02 and 01. As @Keigo noted, lower timestep values may still not be enough, since the rooms are 300 m3 and the airflow is 3 m3/s. The same happened in the CO2 simulations, where high flow rates with "low" timesteps gave unrealistic profiles. I don’t really understand how doing the air balance at timestep + 1 can “create” air with such an off temperature (or CO2), but it does feel like a bug that should be fixed, allowing large mixing rates regardless of the timestep used.

MatteoMerli ( 2025-09-08 07:32:00 -0500 )edit

Thanks @Keigo for highlighting the difference between ZoneMixing and ZoneCrossMixing. In this kind of case with a continuous flow, do you think it would be more appropriate to model it using two cross mixing objects (A to B and B to A)?

MatteoMerli ( 2025-09-08 07:34:19 -0500 )edit

@MatteoMerli Only one ZoneCrossMixing object should be used between Zone A and Zone B. Zone A is a source zone, and Zone B is a receiving zone. Or Zone B is a cource zone, and Zone A is a receiving zone.

Keigo ( 2025-09-08 10:28:01 -0500 )edit

see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

How should Air Boundary + Simple Zone Mixing work?

Comments

2 Answers

Comments

Comments

Your Answer

Training Workshops

Question Tools

Stats

How should Air Boundary + Simple Zone Mixing work? edit

Comments

2 Answers

Comments

Comments

Your Answer

Training Workshops

Question Tools

Stats

How should Air Boundary + Simple Zone Mixing work?