readEPResult vs energyBalance vs Zone Ideal Loads Zone Total Cooling Energy

I’m digging into the outputs of the results components a bit more and just wanting to get some additional information for validation…

readEPResult…are the individual parameters of this component (electricLight, electricEquip, peopleGains, totalSolarGain, infiltrationEnergy) instantaneous HEAT GAINS/LOSSES or delayed LOADS? My assumption is Loads.

readEPSrfResult…are the individual parameters of this component (surfaceEnergyFlow, opaqueEnergyFlow, glazEnergyFlow) instantaneous HEAT GAINS/LOSSES or delayed LOADS? My assumption is Loads.

energyBalance…is the modelEnergyBalance output of this component instantaneous HEAT GAINS/LOSSES or delayed LOADS? My assumption is Heat Gains/losses.

if my assumptions are right, if I sum the annual values for the COOLING output of the readEPResult, how come this would not match the “Output:Variable,*,Zone Ideal Loads Zone Total Cooling Energy,hourly; !- HVAC Sum [J]” annual summation that I extract from the resultFileAddress report, assuming of course that my simulation is modeled as Ideal Air Loads.

any input is greatly appreciated!

@chris…any insight would be great…thanks!

@josh.greenfield ,

Sorry for the late response here. To answer your questions:

All of the results going into the energy balance (whether its readEPResult or readEPSrfResult) are for the timestep or hour that they are listed for. So this means that nearly all of the terms can be thought of as instantaneous HEAT GAINS/LOSSES for the whole zone. This is the case for solar, people, lights, equipment. The conduction terms out of the readEPSrfResult are netted over the construction for that timestep so they can also be thought of as instantaneous even though the amount of heat going into one side of the construction might not equal the amount of heat leaving the other side of the construction for that timestep (we are just tracking the net heat flow).

The only term that might not be considered perfectly instantaneous for the whole zone is the heating and cooling ideal air loads, which are equal to the amount of energy that must be added to or removed from the zone air to keep the air at the set point temperature. The air is only part of the mass of the whole zone (there’s obviously a lot of heat capacity in all of the surfaces and constructions). So it will take time for a term like instantaneous solar to show up in the cooling load since the solar energy often gets absorbed by the floor surface and then gradually convects to the zone air where it can get sucked up by an ideal air cooling system. I think this chart over the course of a cooling design day illustrates this point well. You can see that the cooling demand mirrors the sum of the instantaneous loads but there’s a time delay between the peaks of the two and the peak cooling load is ultimately smaller than the peak sum of the instant loads thanks to the thermal mass of the zone surfaces.

For the reason above, you will rarely find that the ideal air heating / cooling loads sum to zero when added with the other instantaneous terms for a given timestep or hour. However, over a long period of time like a week or a month, the sum of all of these terms will be relatively close to 0, which is how we can get monthly energy balance charts like this:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Energy_Balance&slide=1&scale=1&offset=0,0

For a clear view of what is happening on a day-by-day basis, you can connect the totalledDaily output of the component in the example above to the 3D chart here:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Energy_Balance&slide=0&scale=5.749089036464323&offset=-4167.368630808567,-1426.827226100129

I hope that helps explain what is going on.

thanks @chris!

is the variable " “ Output:Variable,*,Zone Ideal Loads Zone Total Cooling Energy,hourly; !- HVAC Sum [J]" ok to use for determining a customized daily cooling load profile in lieu of utilizing the preset cooling design day output?