As I said on the other thread - I think the air side economiser is causing the mechanical ventilation to appear.
On the storage side of things, it’s a question I’m interested in learning more about. Looking at the code, the HB definition of “Storage” is just the remaining aspect of the energy balance to make it equal to 0 as a whole once all the other factors HB does factor in have been accounted for.
I feel like there might be potential with Storage being treated as a catch all by HB for aspects of the energy balance to be missed (a variable in E+ that isn’t being included in the other data?).
Up to now I’ve thought about Storage as thermal mass, generally where solar enters the room as a gain, but is mostly absorbed by surfaces rather than directly contributing to instantaneous air temperature increase in the space. I believe this is generally true, but always interested in learning more.
I asked a question on the topic here that Chris replied to
I agree, this looks like the airside economizer causing issues again. Personally, I think it makes sense to change the default behaviour of the Ideal Air System to NoEconomizer rather than DifferentialDryBulb. There are diminishing returns from economizers for hotter climates, and small buildings served by modest HVAC systems. For example, Ashrae 90.1’s prescriptive path doesn’t require the economizer for climate zones 0 to 1, and for the rest (climate zones 2 - 8) it’s only required if the cooling capacity is greater than 4.5 tons (~16 kW), which excludes many residential buildings. The LBT users who are modeling more complex buildings with >4.5 tons of cooling capacity are more likely to check and implement their economizer correctly, and so it makes sense to put the onus on them to activate the economizer, and align the default economizer behaviour with the conventions of small buildings, and the expectations of less-experienced LBT users.
Interesting, so why do you think this works? It does look like the reduction of natural ventilation with the 20C ventilation minimum doesn’t align with the thermal storage reduction. So the storage term appears to be nonlinearly correlated to the natural ventilation, (i.e. rate of increase is higher at lower temperatures, maybe also higher RHs).
It could be some missing term, for sure. I have some suspicion that it may have to do with the latent loads from humid outdoor air, reducing cooling energy load, but not increasing the Natural Ventilation load equivalently due to the inherent nonlinearity of psychrometrics, and/or the way EP doesn’t do any mass air balances.
Having tried building this type of report myself in a spreadsheet I know that it is combining output from at least 2 very different EnergyPlus reports. I can see how this accounting of typical flows might not in some circumstances account for all the energy flows in a model. Specifically, I note very big “storage” values can be made to appear when I manipulate the window opening temperature control setpoints. I have very deliberately pointed out to my students that this so-called storage term in the otherwise extremely useful Load Balance graph is an error term which if small could be presumed to be energy stored in the fabric of the building - but that if it is genuinely ‘storage’ then one might expect it to be randomly positive or negative depending on the season. If it is large and systematically gains or losses, then it is more likely an indication that there is something in their model they do not understand. Not wrong, but possibly an indication of behaviour they do not quite understand in the model.
Thanks for the heads up about the air-side economiser I will investigate.
Thank you so much for engaging in this conversation.
It is clear that the storage term is a catchall label for the difference on a monthly basis between energy gains and energy losses. There is no more complex calculation than this.
I would note that LBT tools has a warning pop up when the openable windows option is selected that advises making the calculation interval for EnergyPlus higher than the minimum - a positive reflection that window opening for bigger temperature differences between inside and outside may not need the window to be open for the whole hour of the base calculation (from the weather file hour interval).
@charlie.brooker As I said on the other thread - I think the air side economiser is causing the mechanical ventilation to appear.
I have tried using an ideal loads definition and set the option to no economiser, and there is no real change. I am assuming that it is not the Economiser that is the issue. I would have assumed it was not because the Economiser is only supposed to kick in when things get hot enough that outside air brought in by fan is cold enough to provide effective cooling.
The “Mechanical Ventilation” term in the load balance stays very large:
The version where I reduced the mechanical ventilation contribution to 0 the fresh air rates and all other mechanical ventilation rates were set to zero.
I believe what you say is correct. In your example above my interpretation is that the external air is cooler than internal, and so when it is supplied to the space it is categorised as a Mechanical Ventilation loss. Heating is then required to balance this and maintain the space set point.
During cooling season your mechanical ventilation rates are likely high enough to provide that cooling without frequently triggering the air side economiser (ie boosting the mech vent rates above your design rates to provide additional cooling when external conditions allow).
It sounds like you guys are thinking of fan-controlled ventilation that blows fresh outdoor air directly into the zone. Mechanical ventilation here refers to the conditioning of the fresh air portion of the supply air (to supply air conditions), before entering the zone. It’s thus calculated in HB as the difference between the zone demand and zone supply energy.
So you need to set the vent_per_floor_, vent_per_person_ and vent_ach inputs to 0 in your ApplyLoadValues component and also turn off the economizer to get mechanical ventilation to zero,
Just to check @SaeranVasanthakumar, in Michael’s example the mechanical ventilation is showing as a loss in the load balance. For example, during July (heating season), mechanical ventilation is a loss because the external air is cold, and the heating term is the energy required to bring it up to supply temperature?
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.