Intro IV - EnergyPlus Modeling Assumptions

Energy models are abstractions of reality. This section is meant as a guide for designers to understand how the geometry used for energy modeling is interpreted within the simulation engine. This is important for modeling an appropriate level of detail, and for ensuring that the simulation results are meaningful.

To achieve this, we will lift up Honeybee's hood to look at the EnergyPlus engine. Honeybee uses the EnergyPlus simulation engine, so energy models made in Honeybee rely upon methods of calculation available in EnergyPlus. All of these methods are simplifications for estimating the amount of heat moving in our out of a room during a given time-step. These simplifications are extremely context-specific, so it is important to understand how the engine arrives at an estimate of heat-transfer.

Historically, the fundamental calculation methods used by EnergyPlus were developed to size Heating, Ventilation and Air Conditioning (HVAC) equipment in the worst-case scenario. Energy efficiency was not initially the goal of EnergyPlus's predecessors, which were focused more narrowly on understanding how big of an air-conditioner would be necessary. As time progressed, the United States Department of Energy developed EnergyPlus with energy efficiency in mind. Further, as EnergyPlus developed over time our understanding of efficiency broadened from simply optimizing mechanical systems to modelling the thermal behavior of an entire building. Today, EnergyPlus is the collected work of thousands of PhDs contributing better and better methods for modelling energy use and thermal phenomena.

However, each method is very context-specific. For example, there is a different method for calculating the heat transfer for single-sided ventilation (when one windows are opened on one side of a room), versus cross-ventilation (when there are open windows on both sides of the room). You can read about these methods in much more detail on EnergyPlus's website: https://energyplus.net/.

To provide a path for Honeybee users to quickly understand some of the basics, here is an abbreviated list of the most important inherent assumptions in EnergyPlus.

• Think at the resolution of a room Historically, EnergyPlus was developed to figure out how much air conditioning each room required. Everything that is smaller than the scale of a room is reduced to its average impact on the room. For example, if you wanted to model the amount of conduction through a stud wall with insulation bats in between each stud. It would be represented by one number, the average insulation per unit area. If you are are looking for a simulation that can evaluate one window detail, against another, take a look at THERM, which can do two-dimensional conductive heat transfer.

  • Accurate sun movement, but reduced resolution The path of the sun is accurate for each hour of the day, but to reduce calculation time Honeybee uses the same sun for 30 days at a time.

  • One Zone, one temperature. As the simulation calculates through each time step, there is one value stored for the air temperature of each zone. This means that the entire zone is assumed to be the same temperature. If you have one zone with a boiling tea kettle at one end, and an overpowering pile of ice at the other, EnergyPlus will simply record the average, and indicate that the room is becoming colder.

  • One Surface, one temperature As the simulation calculates through each time step, it also records one value for the temperature of each surface of a zone. So, you will know that the east wall is hotter than the west wall in the morning, but you will only be able to tell which part of the East wall is hottest if you divide that wall into multiple sub-surfaces.

  • Airflow is a number EnergyPlus models for airflow are greatly simplified. You may have seen complex Computational Fluid Dynamics simulations with arrows dancing around in 3D showing every contour of an occupant's sneeze. This is not EnergyPlus. EnergyPlus deals with airflow quantitatively. It's a single number that is either positive for air flowing into a room or negative for air flowing out of a room.

  • Airflow does not account for wind direction Each form of ventilation works more like an on-off switch in EnergyPlus, where as "real" wind effects can be amplified or reduced by orientation, wind direction and surrounding context. This is particularly important to understand in relationship to cross-ventilation because EnergyPlus does not make adjustments for wind blocked by surrounding context, nor does it adjust the amount of ventilation based upon how directly a window faces the wind. Either there is cross-ventilation, or there isn't. It is possible to specify precise schedules of when there is and is not cross-ventilation though.

  • Thermal Bridging is one-dimensional EnergyPlus reduces the conduction of complex construction systems down to a single value for the entire wall. For instance, if you had a stud wall with insulation in between studs, you would just have one value for the entire wall, weighted by the insulation value and surface area of each element.

  • Air moves in one direction per time step EnergyPlus is good at modeling air-flow that travels in a single direction, like cross-ventilation through windows on opposite sides of a room. There are also great quantitative estimates for single-sided ventilation, with open windows on just one side of a room. EnergyPlus can also describe airflow driven by a buoyant chimney. However, the process for describing rooms with convective air currents are still quite coarse. For these situations, Computational Fluid Dynamics is necessary. To be clear, EnergyPlus is a state-of-the-art engine, and these limitations represent the limitations of the entire field of simulation, not limitations of Honeybee or Ladybug.

  • No complex lighting or shading effects EnergyPlus only returns tables of comma-separated values, so all effects of lighting are reduced to their quantitative impact on heat transfer. You should not model detailed louvers in EnergyPlus, but large shading elements like context geometry are suitable and appropriate. A shading device that is meant to block radiation at very particular times of year might actually be best modeled as a very simple shading device on a schedule of being active vs not. Then, when you actually design the geometry of the shading device, you just need to be certain that it performs the same as the schedule describing it.