Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
6 months late. I found your question interesting, and so decided to take a deeper dive for my own sake. Not sure if this remains of any help to you at this stage.
Q1 : As stated in the UMH post you linked, a building model's surrounding grade/ground in EnergyPlus is always Z=0. This postulate is not only key for calculating atmospheric variations (e.g. based on the elevation of a wall, or that of an air node), but equally for solar calculations (e.g. ground plane/reflections), for instance. So the Z origin of typical mid-height spaces of a 22 storey building (e.g. 3m floor-to-floor height) should be ~33m. Lifting Z origins by a further 55m would make sense if instead modelling the 29th floor of some other 58-storey building. I'd initially argue that this is not a reasonable means to "account for the elevation difference" between weather station vs building location ... see below.
Q2 : "Best practice" can be broken down into multiple, in/dependent steps - depending on the circumstances. Let's start with most the basic EnergyPlus recommendation when one chooses to model a typical "middle floor" to represent many (e.g. 20 out of 22), inter alia:
Since exterior convection coefficients vary with elevation, locate the typical middle floor zones mid-height between the lowest and highest middle floors to be modeled.
Easy peasy. EnergyPlus adjusts zone, surface and air node temperatures at runtime based on their height (vs building ground elevation). As mentioned in the link you provided, the building ground elevation here is assumed to be that of the weather station, taken from the EPW file (not Site:Location elevation). EnergyPlus considers by default a standard WMO weather station temperature sensor height of 1.5m and a standard -0.0065 K/m temperature lapse rate (or what EnergyPlus calls an air temperature gradient coefficient). If the weather station temperature sensor were to read 15°C, then in theory the adjusted air temperature at the base of your building model should be 14.7°C, while dropping to 14.2°C near the roof. We're therefore looking at a 0.3K discrepancy.
Is such a discrepancy significant for natural ventilation assessments? Some may argue "yes". Then again, if outside air temperature acts as a control threshold ("close windows below X °C"), I'd argue that a 0.3K discrepancy could safely be ignored. A more relevant question IMHO is whether this 0.3K is in fact realistic. If the building is located in a suburban or urban setting, then one can easily anticipate warmer conditions (than the weather station) and reasonably ignore the 0.3K discrepancy altogether. So it depends ...
If you were adamant on correcting a 0.3K discrepancy, you have 3 options IMO:
Option 1 is certainly not unheard of (e.g. UHI effects, future climate), yet is considered heavy lifting.
Option 2 is fairly straightforward: adjust the rate so that the 0.3K discrepancy disappears for these mid-height spaces. This option would of course not work as well when simultaneously simulating the ground floor and/or top floor (may or may not be an issue in your case). An interesting case study.
Option 3 definitely requires adjusting the wind profile parameters to avoid overestimating wind speeds near these mid-height spaces - see next paragraph.
The entry-level input enabling EnergyPlus to adjust height-dependent wind speeds (from weather station to building zone, surface or air node) is Terrain. These wind speed adjustments, as well as the aforementioned height-dependent temperature adjustments, are explained in the Engineering Reference. I also found this insightful. With an AirflowNetwork, selecting the SurfaceAverageCalculation option (I'm assuming here a "HighRise" building type) enables wind pressure coefficients to be dynamically reset as well. So far so good.
In most cases, there is no need to correct wind speeds based on elevation differences (between building location and weather station). If the slope from the weather station to the building location (in your case, from 3.7m to 55m) is more or less gradual, then the atmospheric boundary layer will adjust to the terrain - it will maintain its profile and thickness, aside from changes in terrain roughness along the way. I'd argue that no corrections are needed if you're OK with the 0.3K discrepancy, or if you're retaining Options 1 or 2.
Exceptionally, selecting Option 3 would require tweaking both the building location wind speed profile coefficient and boundary layer thickness to avoid overestimating wind speeds near these mid-height spaces. Setting these will override Terrain settings. Doable, yet may take a few iterations to get it right.
A side note: As suggested in the UMH link you provided, there may be cases when weather data (e.g. used to generate a custom EPW) weren't measured at WMO standard conditions (e.g. urban rooftop) - conditions which should be adjusted via Site:WeatherStation.
| | 2 | No.2 Revision |
6 months late. I found your question interesting, and so decided to take a deeper dive for my own sake. Not sure if this remains of any help to you at this stage.
Q1 : As stated in the UMH post you linked, a building model's surrounding grade/ground in EnergyPlus is always Z=0. This postulate is not only key for calculating atmospheric variations (e.g. based on the elevation of a wall, or that of an air node), but equally for solar calculations (e.g. ground plane/reflections), for instance. So the Z origin of typical mid-height spaces of a 22 storey building (e.g. 3m floor-to-floor height) should be ~33m. Lifting Z origins by a further 55m would make sense if instead modelling the 29th floor of some other 58-storey building. I'd initially argue that this is not a reasonable means to "account for the elevation difference" between weather station vs building location ... see below.
Q2 : "Best practice" can be broken down into multiple, in/dependent steps - depending on the circumstances. Let's start with most the basic EnergyPlus recommendation when one chooses to model a typical "middle floor" to represent many (e.g. 20 out of 22), inter alia:
Since exterior convection coefficients vary with elevation, locate the typical middle floor zones mid-height between the lowest and highest middle floors to be modeled.
Easy peasy. EnergyPlus adjusts zone, surface and air node temperatures at runtime based on their height (vs building ground elevation). As mentioned in the link you provided, the building ground elevation here is assumed to be that of the weather station, taken from the EPW file (not Site:Location elevation). EnergyPlus considers by default a standard WMO weather station temperature sensor height of 1.5m and a standard -0.0065 K/m temperature lapse rate (or what EnergyPlus calls an air temperature gradient coefficient). If the weather station temperature sensor were to read 15°C, then in theory the adjusted air temperature at the base of your building model should be 14.7°C, while dropping to 14.2°C near the roof. We're therefore looking at a 0.3K discrepancy.
Is such a discrepancy significant for natural ventilation assessments? Some may argue "yes". Then again, if outside air temperature acts as a control threshold ("close windows below X °C"), I'd argue that a 0.3K discrepancy could safely be ignored. A more relevant question IMHO is whether this 0.3K is in fact realistic. If the building is located in a suburban or urban setting, then one can easily anticipate warmer conditions (than the weather station) and reasonably ignore the 0.3K discrepancy altogether. So it depends ...
If you were adamant on correcting a 0.3K discrepancy, you have 3 options IMO:
Option 1 is certainly not unheard of (e.g. UHI effects, future climate), yet is considered heavy lifting.
Option 2 is fairly straightforward: adjust the rate so that the 0.3K discrepancy disappears for these mid-height spaces. This option would of course not work as well when simultaneously simulating the ground floor and/or top floor (may or may not be an issue in your case). An interesting case study.
Option 3 definitely requires adjusting the wind profile parameters to avoid overestimating wind speeds near these mid-height spaces - see next paragraph.
The entry-level input enabling EnergyPlus to adjust height-dependent wind speeds (from weather station to building zone, surface or air node) is Terrain. These wind speed adjustments, as well as the aforementioned height-dependent temperature adjustments, are explained in the Engineering Reference. I also found this insightful. With an AirflowNetwork, selecting the SurfaceAverageCalculation option (I'm assuming here a "HighRise" building type) enables wind pressure coefficients to be dynamically reset as well. So far so good.
In most cases, there is no need to correct wind speeds based on elevation differences (between building location and weather station). If the slope from the weather station to the building location (in your case, from 3.7m to 55m) is more or less gradual, then the atmospheric boundary layer will adjust to the terrain - it will maintain its profile and thickness, aside from changes in terrain roughness along the way. I'd argue that no corrections are needed if you're OK with the 0.3K discrepancy, or if you're retaining Options 1 or 2.
Exceptionally, selecting Option 3 would require tweaking both the building location wind speed profile coefficient and boundary layer thickness to avoid overestimating wind speeds near these mid-height spaces. Setting these will override Terrain settings. Doable, yet may take a few iterations to get it right.
A side note: As suggested in the UMH link you provided, there may be cases when weather data (e.g. used to generate a custom EPW) weren't measured at WMO standard conditions (e.g. urban rooftop) - conditions which should be adjusted via Site:WeatherStation.
| | 3 | No.3 Revision |
6 months late. I found your question interesting, and so decided to take a deeper dive for my own sake. Not sure if this remains of any help to you at this stage.
Q1 : As stated in the UMH post you linked, a building model's surrounding grade/ground in EnergyPlus is always Z=0. This postulate is not only key for calculating atmospheric variations (e.g. based on the elevation of a wall, or that of an air node), but equally for solar calculations (e.g. ground plane/reflections), for instance. So the Z origin of typical mid-height spaces of a 22 storey building (e.g. 3m floor-to-floor height) should be ~33m. Lifting Z origins by a further 55m would make sense if instead modelling the 29th floor of some other 58-storey building. I'd initially argue that this is not a reasonable means to "account for the elevation difference" between weather station vs building location ... see below.
Q2 : "Best practice" can be broken down into multiple, in/dependent steps - depending on the circumstances. Let's start with most the basic EnergyPlus recommendation when one chooses to model a typical "middle floor" to represent many (e.g. 20 out of 22), inter alia:
Since exterior convection coefficients vary with elevation, locate the typical middle floor zones mid-height between the lowest and highest middle floors to be modeled.
Easy peasy. EnergyPlus adjusts zone, surface and air node temperatures at runtime based on their height (vs building ground elevation). As mentioned in the link you provided, the building ground elevation here is assumed to be that of the weather station, taken from the EPW file (not Site:Location elevation). EnergyPlus considers by default a standard WMO weather station temperature sensor height of 1.5m and a standard -0.0065 K/m temperature lapse rate (or what EnergyPlus calls an air temperature gradient coefficient). If the weather station temperature sensor were to read 15°C, then in theory the adjusted air temperature at the base of your building model should be 14.7°C, while dropping to 14.2°C near the roof. We're therefore looking at a 0.3K discrepancy.
Is such a discrepancy significant for natural ventilation assessments? Some may argue "yes". Then again, if outside air temperature acts as a control threshold ("close windows below X °C"), I'd argue that a 0.3K discrepancy could safely be ignored. A more relevant question IMHO is whether this 0.3K is in fact realistic. If the building is located in a suburban or urban setting, then one can easily anticipate warmer conditions (than the weather station) and reasonably ignore the 0.3K discrepancy altogether. So it depends ...
If you were adamant on correcting a 0.3K discrepancy, you have 3 options IMO:
Option 1 is certainly not unheard of (e.g. UHI effects, future climate), yet is considered heavy lifting.
Option 2 is fairly straightforward: adjust the rate so that the 0.3K discrepancy disappears for these mid-height spaces. This option would of course not work as well when simultaneously simulating the ground floor and/or top floor (may or may not be an issue in your case). An interesting case study.
Option 3 definitely requires adjusting the wind profile parameters to avoid overestimating wind speeds near these mid-height spaces - see next paragraph.
The entry-level input enabling EnergyPlus to adjust height-dependent wind speeds (from weather station to building zone, surface or air node) is Terrain. These wind speed adjustments, as well as the aforementioned height-dependent temperature adjustments, are explained in the Engineering Reference. I also found this insightful. With an AirflowNetwork, selecting the SurfaceAverageCalculation option (I'm assuming here a "HighRise" building type) enables wind pressure coefficients to be dynamically reset as well. So far so good.
In most cases, there is no need to correct wind speeds based on elevation differences (between building location and weather station). If the slope from the weather station to the building location (in your case, from 3.7m to 55m) is more or less gradual, then the atmospheric boundary layer will adjust to the terrain - it will maintain its profile and thickness, aside from changes in terrain roughness along the way. I'd argue that no corrections are needed if you're OK with the 0.3K discrepancy, or if you're retaining Options 1 or 2.
Exceptionally, selecting Option 3 would require tweaking both the building location wind speed profile coefficient and boundary layer thickness to avoid overestimating wind speeds near these mid-height spaces. Setting these will override Terrain settings. Doable, yet may take a few iterations to get it right.
A side noteSide notes: As suggested in the UMH link you provided, there may be cases when weather data (e.g. used to generate a custom EPW) weren't measured at WMO standard conditions (e.g. urban rooftop) - conditions which should be adjusted via Site:WeatherStation.
And in all cases, with sharper environmental differences than what you're describing (e.g. +500m in elevation between site and weather station, strong microclimatic effects, UHI effects), a modeller should reconsider which EPW file(s) to use.
