Understanding the Load Balance Component Assumptions

Kia ora @SaeranVasanthakumar - Just to confirm: I did set the economiser according to your original recommendation thus:

On careful re-checking, I can see that the Value List I created was feeding “Null” into the Economiser input!

With this fixed the Mechanical Ventilation term disappears, as you suggested.

However, the Natural Ventilation term is disappointingly small with these settings.

Just changing the Minimum Outdoor Temperature at which the windows are opened from 21 to 19 makes this change in a warmish climate:


In a cooler climate the issue reduces:

But in all cases, having the ability to open the windows when the temperature indoors is over 21 and under 26 in relatively mild climates, does not seem to produce the anticipated Natural Ventilation Energy Flow…

Hey @MichaelDonn ,

Sorry that this thread just seemed to go in a bunch of different places and we got pretty far from the original concern.

I opened your sample model from the top of this post and you are absolutely right that there’s some kind of bug in EnerbyPlus or change in the behavior of the EnergyPlus output for Zone Ventilation Total Heat Loss Energy.

It’s very clearly under-reporting the ventilation losses and I know this because, if I switch to using the AirflowNetwork for natural ventilation and using those corresponding outputs, I can get a much more balanced chart:

Let me see if I can find a solution on our end but this may be a bug in the EnergyPlus output that we’ll ultimately have to report to NREL.

1 Like

So this seems to be an EnergyPlus bug that only affects the reporting of the ventilation gain/loss energy. The actual simulation of the ventilation seems to be happening correctly.

An interesting thing that I noticed is that the bug seems to get worse and worse the more windows that I add (aka. the more ZoneVentilation objects in EnergyPlus). When I have only one window, things seem to be (almost) correct:

I have looked through the EnergyPlus github to see if there have been any bug reports related to this but there were none that I could find.

To temporarily patch the situation, I may just add some methods that join the zone ventilation objects into one but, if anyone else has any ideas about what could be happening or a better way to fix this, please fee free to voice them.

@chris

I think I know where the problem is occuring, and a workaround solution, but frustratingly, can’t figure out the underlying cause of the problem.

Essentially, the problem seems to be that the total heat energy doesn’t equal the sensible/latent heat energy, in net. Specifically, the following relationship between EP’s ventilation energy outputs isn’t true:

\begin{align} &\small{\text{ Zone Ventilation Sensible Heat Gain Energy } - \text{ Zone Ventilation Sensible Heat Loss Energy}}\\ + &\small{\text{ Zone Ventilation Latent Heat Gain Energy } - \text{ Zone Ventilation Latent Heat Loss Energy}} \\ &\rule{16cm}{0.2pt} \\ &\small{\text{ Zone Ventilation Total Heat Gain Energy } - \text{ Zone Ventilation Total Heat Loss Energy}} \\ \end{align}

A subtle detail here is that the “Total” energy reported by EP reports a somewhat counterintuitive value, and should only be compared to the sensible/latent outputs in terms of net energy.

From the EP I/O Reference[1]:

Zone Ventilation Total Heat Gain Energy [J][LINK]

The total heat gain that occurs when the sum of Zone Ventilation Sensible Heat Gain Energy and Zone Ventilation Latent Heat Gain Energy > = the sum of Zone Ventilation Sensible Heat Loss Energy and Zone Ventilation Latent Heat Loss Energy.

Personally, I think this is a confusing use of the term “Total”. Anyway, this means the cumulative total heat gain over multiple timesteps won’t equal the sum of the cumulative sensible and latent gains. However, the difference between the gain and loss should always be equal, which is what I’m showing in the equation above, and also what HB uses, so this shouldn’t result in the error we’re seeing. To verify this, I’ve checked the detailed timestep, as well as the sub-timestep (i.e. HVAC) values for all of this in a pure EP model (no HB involved). Nothing adds up, so I agree, it definitely requires some clarification from the EP developers.

For a temporary solution to our original energy balance problem: you can simply sum up the sensible/latent gains/losses (the first part of the equation), and the energy balance should work as expected.

[1] Group – Airflow: Input Output Reference — EnergyPlus 22.1

1 Like

Fascinating. Thanks for taking the time @chris and for your continued input @SaeranVasanthakumar.

With 9 days to the student hand-in, I am reluctant to introduce the airflow network into consideration. I’d much rather spend the last sessions of the class on what is a Net Zero office in a busy urban area…

Some weekend thinking before Monday’s class is required.

Thanks for digging into this, @SaeranVasanthakumar . There’s definitely some truth to your explanation there since I just tried your suggestion here:

… and it gets rid of this issue that I am seeing where adding more and more windows (zone ventilation objects) causes the zone ventilation energy balance impact to be less and less.

So I’ll push a fix now that replaces the use of Total Gain/Loss with a more explicit Sensible + Latent Gain/Loss and this should ameliorate the issue. I’ll post back here once the fix is implemented.

I merged the fix into the code base:

You should be able to get it with the LB Versioner in an hour or so. Admittedly, it still doesn’t completely balance out your original sample file, @MichaelDonn , but it’s definitely a major improvement, especially when I make your room a little deeper and the windows a bit smaller so that it has more thermal lag and isn’t constantly opening and shutting the windows:


Test_annual_loads_CWM.gh (102.9 KB)

2 Likes

Fantastic news @chris

I will try to focus on my Saturday afternoon activity replacing 45year old decking timbers and post the news for students tonight.

Thank you for pursuing this.

Kia ora @chris

I managed yesterday to advise one of the online (Zoom) tutorial participants about this issue. They updated the version and this is what their Office Building Model performance now looks like:
Storage

Thank you - with 1 week to hand in, at least those who have taken the advice to build models simply to explore particular issues, will be reporting on performance and the potential of openable windows for cooling and comparing that to heat recovery mechanical ventilation becomes feasible.

1 Like

FYI, @MichaelDonn . I realized the reason why things weren’t perfectly balanced out in your and my latest examples.

When I made the change to account for the natural ventilation term correctly, I accidentally deleted some code that was needed to get the infiltration term to display correctly. So the “storage” term in both your and my recent example is actually supposed to be a missing infiltration term. I just pushed a fix for this and hopefully the lack of infiltration did no mess up your class too much:

3 Likes

Thanks for the heads up.

We will discuss in class. (Detail too much for the entry level students - just right for the 3rd year students).

Now they have submitted their reports they have to produce a poster summary.

Thank Chris for shedding light on a little history of this issue. I can’t remember how many times I struggled to understand the result and eventually found the default economizer the culprit. As you know, I work on tropical buildings, the default economizer is actually making the room hotter than the setpoint. Just yesterday I found out that I have to specify NoEconomizer to make the HB Adaptive Comfort module render reasonable result for me. Knowing your dilemma, I can’t complain now.

1 Like