Is this part of my previous post confusing you? It makes it sound like the mechanical ventilation term refers to the supplied energy, which is not the case.
So to clarify: in terms of the load balance, the mech_vent_load term represents the energy demand of the required fresh air conditioning, not the energy supplied to condition it. Therefore the cooling and heating terms represents the total energy supply for the zone (with magnitude equal to the sum of the zone energy and the mechanical ventilation demand), respectively for heating and cooling.
Yes, during the heating season (i.e. July) the cold outdoor air brought in for fresh air is represented as heat loss. The heating term therefore represents the heating energy required to heat that portion of cold outdoor air, and the heat loss from conduction, and infiltration (that isn’t already met by solar, people etc).
I think in January (the warmer season), the cooling load still makes sense, since it looks like more heating energy is still required then cooling energy, probably due to cool evenings, and possibly reheating required after cooling the air for dehumidification. Since the mech_vent_load just shows the net difference, any portion of it that contributes to heat gain will be canceled out, and you’ll only see the heat loss during this period as well.
My goal is to try to model a building that has zero mechanical ventilation, relying only on openable windows.
I am setting the windows / apertures as “operable” and trialling various combinations of ventilation control:
Changing these vent_control values has HUGE impact on what I see as the “error” term in the Energy Balance report - the so-called “storage” term.
As I understand it, what I am looking at in this calculation is the “Mechanical Ventilation” load is the heat energy required to bring the fresh air per person “ventilation” up to the desired room temperature.
Switching off the cooling:
And setting the ventilation control to be consistent with this (no open windows below Heating set point):
Sorry, could you clarify your comments here? Are you saying you already had set the fresh air ventilation requirements to 0, and disabled the economizer, and still the mechanical ventilation term was not zero? Or do you mean you tried the suggestion and it worked?
If its the former, then you may have a bug in your workflow, I just tested it myself on the attached script from your first post and I’m seeing zero mechanical ventilation as expected. I can take a look at your latest model if you need (with geometries internalized, they were missing in the first script).
I still don’t know the exact mechanics of why the storage is there, but it’s at least partially reflecting the latent load from humid outdoor air. Here’s the hourly plots of Wellington’s drybulb and dewpoint temperatures, filtered to when drybulb is >= 18C (minimum opening setpoint) and the drybulb and dewpoint are within 5C of eachother.
The outdoor air is humid enough that it’s at risk of naturally condensing in the 18C-19C drybulb range. So your 18C drybulb threshold benefits alot from latent cooling, in addition to the sensible cooling. When the temperature minimum setpoint increases to 20, I think the seemingly disproportional reduction of the storage term is because that latent benefit is thus disproportionally filtered out.
Of course, the heat balance represents the latent loads of its terms too, so I don’t know why it’s not incorporated into the natural ventilation term. Thus, this explaination is lacking something, but I think latent loads at least starts to explain why you get the weird nonlinearity of the storage term for linear increments of the setpoint ranges.
This is a long thread but I’ll just respond to a few things discussed here that affect the development roadmap:
Yep, as you have all figured out, that’s exactly how it is used right now. It’s just the remainder after the addition of the other terms. Technically, E+ enables us to compute the heat stored in the mass of the constructions by means of the same output that we use to get envelope conduction (we just analyze the interior constructions instead of the exterior ones). I have had it on my development agenda to add support for this “Construction Storage” so that we can separate it from the rest of the current “storage”.
But I don’t think there’s any easy way to get the heat stored in the mass of the Room air and I think it’s this that’s causing @MichaelDonn 's odd results. When you set the natural ventilation setpoint and thermostat setpoint equal to one another, EnergyPlus does this weird thing of opening windows one timestep and then shutting them at the next one and turning on the heating/cooling system. All of this creates a set of unrealistic controls that messes with the air heat balance calculation.
If you have any strong opinions about what to call the “storage” term after “Construction Storage” is removed from it, I’d be interested in feedback here. We could just call it “Air Storage” or we could call it “Error” since it usually only gets big when there’s something wrong with the air heat balance.
This is a tough call that is almost certainly going to be biased by the types of buildings that individual people work on. Way back in early versions of Legacy, we had it as you suggested (with a default of NoEconomizer) but then I had to field a ton of questions on the forum about why people are getting lots of cooling for their office shoe box in the middle of winter.
As evidenced by this issue and others, I obviously still get questions about “the mechanical ventilation term” so I’ve just resigned myself to the fact that there’s no perfect default value. But I can say that I definitely get fewer questions about “the mechanical ventilation term” than I did about “wintertime cooling.” So that’s why I have settled on the current setup.
If it’s any consolation, all of the detailed HVAC systems use a “NoEconomizer” option by default and, if you ask me, this is the place where the “ASHRAE 90.1 assumptions” that you cite matter the most. After all, Ideal Air Systems aren’t mentioned in 90.1 at all but you can find all of the “All-Air” HVAC system templates mentioned there.
the bottom half of the script (in image below) is basically a library of New Zealand materials (e.g. Simple “Window” definitions are based on NZ Standard Window and calculated within LBNL Window Program)
the top half of the script has a single model build linked to four possible analyses.
I have circled the key model inputs for this issue as I see them.
What I am trying to achieve is providing students with a Shipping container as a coffee cart in an urban context where they can work on 1) placement of the container in the urban park, 2) window size, 3) orientation, 4) external insulation thickness, 5) shading options, in response to the messages about where the energy flows are happening from the excellent Load Balance data. Following that they can optimise the daylight indoors. I am thinking of making 4 separate analysis files to simplify the appearance of the script, but in development mode I have all four analyses in the one file.
For one of the warmest climates in New Zealand (Kaitaia), I have tried a bunch of ventilation settings in regards to the heating and cooling operation mostly as a desire just to figure out what is the “mechanical ventilation” term. However, what I was finding with the vent_ctrl was ‘behaviour’ that did not seem reflective of real buildings. With a Heating Setpoint of 18C and a Cooling set point of 27C, I had expected that the following would represent what people might see as a reasonable set of ventilation controls:
But this produces some very large “Error” terms (and in answer to @chris - in future terming this monthly input/output difference, would usefully be labelled something like “Delta”, so long as it is associated with the usual excellent LBT explanation. I say this because I suspect that to label it an ‘error’ term, or even margin of error, would be as misinterpreted in the same way storage is interpreted by my students).
Changing the set point for the minimum outdoor temperature when the windows are opened
Gets rid of some of the error term (notably in Spring, not summer):
Changing the indoor temperature when the windows are opened to be 2C more than the outdoor temperature when the windows are opened (to be consistent with the 2C Delta between indoor temperature and outdoor temperature for cooling )
Thanks for the input on what to call the “error” term. “Delta” isn’t a bad suggestion but maybe just calling it “remainder” as we have been doing here is actually the most elegant way to describe it. I’ll revisit this when I finally get the chance to implement a “construction storage” term.
FYI, what I was trying to explain above is that you should have at least 1C difference between your indoor cooling setpoint (27 C) and the max_in_temp_ (aka. the indoor temperature at which windows open). Otherwise, you’ll have both the cooling system on and the windows open within the same timestep, which is what’s causing your air heat balance equation to be all wacky.
I do like Remainder. It implies what is happening to derive the graphics.
And thanks for the reminder about precision of set points. You have revealed a blind spot where I was focusing on the same sort of decision making at the bottom end of the decision range, but not the top!
Kia ora korua
I apologise, I cannot yet understand what is happening when I try to set the combination of set points for Heating/Cooling/Opening windows (partly because I am worried about what the Remainder term in the energy balance graph is telling me.
Setting the mechanical ventilation term to Zero (I thought):
Gives the pattern of behaviour below, the issue seems more complex than just too close a match between the point at which we are opening or closing the windows and turning on the heating or the cooling. I wish I could tabulate these graphs in this interface so I apologise in advance for the length of this post.
For example: when I get the operation with a 20C heating set point rather than my preferred 18C setpoint, the mechanical ventilation term in the energy balance is clearly climate dependent - larger in summer than winter.
Mostly, I cannot see the pattern here.
==============================================================
Do you have an idea on why this isn’t captured in the cooling, heating or natural ventilation energy terms? If the cooling/heating system is running while windows are open, or they’re cycling on and off sequentially, shouldn’t the air heat balance still reflect this in the various demand/supply energy quantities?
We have two sources of thermal energy that violate the steady-state assumption of the monthly energy balance and result in a non-zero storage term to correct the imbalance. The thermal energy stored in construction, and the thermal energy stored in the air. You should be able to eliminate the former by using constructions without mass, and I expect the latter to be marginal, given that the air heat capacity is extremely low. And even if it is high, shouldn’t any energy stored in the air be reflected in the zone state variables (i.e. increased temperature), and then naturally cancel out as the air is conditioned back to setpoint conditions?
I apologise @SaeranVasanthakumar. I find the topic tantalising - I feel I ought to be able to pick the patterns of variation, but cannot.
I can accept that with the various places that @chris has extracted the energy flows to identify the major energy flows, and that for completeness he has identified that in principle the heat flows in should equal the heat flow out of a building on a monthly basis - an energy balance. If not, then the building would slowly heat up or cool down. “Thermal mass” = high heat capacity materials do not radically alter this monthly balance. To do so, would require the mass of a cave buried deep in the ground where the heat gains or losses last month, affect this month’s temperatures. For this extreme case we can see a couple of months “storage” term. In normal circumstances (even for example the Anasazi Indian Adobe dwellings) the effect is at the scale of the day not the month.
In these circumstances, the term Remainder (the unaccounted for difference between heat flow in and out) makes more sense to me than “Storage”.
In regards to the importance of high heat capacity materials: there was a very interesting experimental case study here in New Zealand a few decades ago where two single rooms were built, with identical equator facing windows. One was comprised of concrete walls and floor, the other was a lightweight timber framed structure. The experimenters worked to ensure the R-values of the various building elements were identical (Insulation around the outside of the concrete). The heating was intermittent (off overnight). The high mass building had a much lower range of temperatures than the lighter weight building. But, the actual energy use was very similar for both.
You would think that heating up the lightweight building from a colder start point would require more input energy. However, the air in this noticeably colder lightweight building heated up quickly. The air in the high “thermal mass” building heated up more slowly as the heat capacity of the concrete absorbed some of the heat energy. This heat was released back into the building overnight, contributing to the building remaining overall at a warmer temperature. However, overall, the two test buildings consumed roughly the same amount of energy.
On this logic, I am happy to accept that on a monthly basis in an energy balance if the remainder is large, there is something unaccounted for happening in how my model is working. As noted, my frustration is not understanding the pattern of the connection between vent control and this Remainder term.
@MichaelDonn, before getting into the weirdness of the storage term, we need to clarify whats going on with your mech. ventilation settings. The way you are using mech. ventilation in your analysis of the storage response to the natural ventilation settings doesn’t make sense, and is preventing a clear representation of the storage issue.
I suspect the underlying cause here is some misunderstanding about the mech. ventilation term, but your responses on the topic are vague or missing, and I unable to pin it down. I do appreciate the extra context you provided in your response to my previous posts, but you somehow missed the only question that I asked:
All we need to know is what is the mechanical ventilation term when the the ventilation requirements are set to zero in ApplyLoadValues; AND the _economizer_ input is set to NoEconomizer in HB IdealAir. You’ve shown both inputs set to zero and NoEconomizer as we reccommended, but for some reason don’t mention its effect on the mech. ventilation - the question we were trying to answer!
I’ve tested both your scripts, and the mech. ventilation goes to zero, as expected, when the inputs are set as reccommended, so as far as I can tell, it should work. However, if it does work, why is your mech. ventilation output still non-zero in your latest post? As far as I can tell, your mech. ventilation term seems to reflect a setting of DifferentialDryBulb for the economizer, which as I mentioned previously, is a flawed setup.
In order to understand why it’s flawed, it’s important to understand what the mech. ventilation term represents in the load balance, so (bear with me) I’ll summarize the description from the earlier posts again. The mech. ventilation energy represents two things:
The thermal energy associated with conditioning the portion of the outdoor air that is brought in through the HVAC air system to satisfy the zone fresh air requirements. This is represented as a zone energy demand, just like lighting, or electric equipment. This is controlled by the ventilation requirements in the ApplyLoadValues component.
The thermal energy associated with unconditioned air, also brought in through the HVAC air system, when the outdoor conditions permit passive cooling. This is controlled by the _economizer_ in HB IdealAir component.
Modifying only the ventilation requirements does not guarantee zero mech. ventilation energy, if you also don’t disable your economizer. For a variety of reasons, I’m assuming you’re using the DifferentialDryBulb for the economizer in this analysis. Running the economizer alongside natural ventilation means the economizer is attempting to supplying passive cooling at the same time you’re natural ventilation is attempting to achieve the exact same thing. All you’re doing by adding the economizer is reducing natural ventilation potential, and vice-versa. Since you have an extremely small building with operable windows, with moderate internal loads, you can achieve your passive cooling with just the natural ventilation. Which means, you need to zero out your mech. ventilation term.
This brings us back to why it’s important to resolve whats going on with your mech. ventilation settings, before getting into the weirdness of the storage term.
You can see that some of your previous confusions, are easily explained as the economizer logic working as intended:
The mechanical ventilation quantity changing based on outdoor conditions is exactly the behaviour you would expect from the mechanical ventilation when there are zero fresh air requirements and an economizer set to DifferentialDryBulb. When the zone temperature can be passively cooled by cooler outdoor air, the economizer is bringing in that air, and the mechanical ventilation term reflects the varying amount of thermal energy associated with the varying temperature difference.
The mech. ventilation isn’t directly related to the ventilation setpoints, so trying to understand mech. ventilation by changing them won’t be that helpful. Specifically, the ventilation setpoints only effects the amount of passive cooling from natural ventilation, and has no direct effect on the economizer-driven mechanical ventilation. But, due to conservation of energy, changing the amount of natural ventilation cooling, will also change the amount of cooling from the mechanical ventilation, in response to some fixed heat energy gain.
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…
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:
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.
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.
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.
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.
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:
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:
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.
