All building simulation programs employ some means of
representing local climatic conditions relative to the
building models. For example, Radiance (Ward 1996) needs a
description of sky conditions and illuminance values to
calculate solar distribution through a window and within a
space. Three of the widely used energy simulation programs in
the UK and US, ESP-r (ESRU 1999), BLAST (UI 1998), and DOE-2
(Winkelmann et al. 1993) also use weather conditions to
simulate the response of a building. But even after 30 years
of significant development advances in simulation
capabilities, these programs use the same climate
representations as in the past-a simple set of hourly
temperature, humidity, wind speed and direction, and
atmospheric pressure and solar radiation or cloud cover data.
These data are often ‘typical’ data derived from hourly
observations at a specific location by the national weather
service or meteorological office. Examples of these typical
data include TMY2 (NREL 1995) and WYEC2 (ASHRAE 1997) in the
United States and Canada and TRY (CEC 1985) in Europe. The
TMY2 and WYEC2 typical weather years contain more solar
radiation and illumination data than older formats such as TMY
(NCDC 1983), WYEC (ASHRAE 1985), and TRY (NCDC 1981) in the
U.S. Crawley (1998) demonstrated that the methods used to
select data for the US TMY2 and European TRY data sets better
fits the long-term climate patterns.
Radiation and illumination data are becoming increasingly
necessary in simulation programs. Anyone who has ever
attempted to measure daylight factors will be familiar with
the fluctuations in lighting levels under partly cloudy
conditions. The expansion and contraction of lightweight
building components also shares sensitivity to rapid
fluctuations in solar radiation. Single-sided ventilation is
dependant on wind pressure fluctuations and pedestrians in
many cities are acquainted with the disarming tendency of the
wind to guest and change direction. It is increasingly the
case that design questions touch on such issues.
In a research context, the advent of tools such as LabVIEW
(National Instruments Corporation 1999) have made it possible
for increasing numbers of researchers to acquire and process
test-cell data. The increasing use of building energy
management systems (BEMS) has also provided high frequency
information from which simulation could be used as a
predictive tool for future control strategies. Other issues of
control, particularly of advanced daylighting control require
sub-hourly illumination data to ensure that possible control
regimes are tested under realistic conditions. Janak (1997)
observed that the differences between 5 minute and hourly
illumination data could result in prediction variations
approaching 40%.
Thus far, projects that mix empirical and simulation-based
work have had to store and access such data via temporal
database facilities (ESRU 1999). As the number of high quality
datasets increases so does the need to encapsulate such
information in a form that can be broadly distributed. The
simulation community must also consider the uncertainty in
high frequency performance predictions that are based on
boundary conditions that have been sampled at one or two
magnitudes less temporal resolution.
The simulation community must also consider practitioner
demands and issues of quality assurance. Someone who is not a
native of Copenhagen may not know that there are three or four
recognizable patterns of winter weather that should be
included in detailed assessments. A data set that lacks
documentation or is dependent on separately held lists of
assumptions can be effectively useless.
In the absence of data within the weather data format, the
simulation programs must calculate these data often with older
calculation methods. As the simulation programs have become
more capable, data at hourly resolution is no longer
enough-interpolating between hourly observations does not
accurately represent weather conditions that change much more
frequently such as illumination.
We have developed a generalized weather data format for use
by energy simulation programs has been developed and adopted
by both ESP-r (in the UK) and EnergyPlus (in the US).
Anticipating the need for data at time steps less than one
hour, the format includes a minute field to facilitate the use
of sub hourly data. The data include basic location
identifiers such as location name, data source, latitude,
longitude, time zone, elevation, peak design conditions,
holidays, daylight saving period, typical and extreme periods,
ground temperatures, period(s) covered by the data and space
for descriptive comments. The time step data include dry bulb
and dew point temperature, relative humidity, station
pressure, solar radiation (global, extraterrestrial,
horizontal infrared, direct, and diffuse), illuminance, wind
direction and speed, sky cover, and current weather.
Background[LINK]
All building simulation programs employ some means of representing local climatic conditions relative to the building models. For example, Radiance (Ward 1996) needs a description of sky conditions and illuminance values to calculate solar distribution through a window and within a space. Three of the widely used energy simulation programs in the UK and US, ESP-r (ESRU 1999), BLAST (UI 1998), and DOE-2 (Winkelmann et al. 1993) also use weather conditions to simulate the response of a building. But even after 30 years of significant development advances in simulation capabilities, these programs use the same climate representations as in the past-a simple set of hourly temperature, humidity, wind speed and direction, and atmospheric pressure and solar radiation or cloud cover data. These data are often ‘typical’ data derived from hourly observations at a specific location by the national weather service or meteorological office. Examples of these typical data include TMY2 (NREL 1995) and WYEC2 (ASHRAE 1997) in the United States and Canada and TRY (CEC 1985) in Europe. The TMY2 and WYEC2 typical weather years contain more solar radiation and illumination data than older formats such as TMY (NCDC 1983), WYEC (ASHRAE 1985), and TRY (NCDC 1981) in the U.S. Crawley (1998) demonstrated that the methods used to select data for the US TMY2 and European TRY data sets better fits the long-term climate patterns.
Radiation and illumination data are becoming increasingly necessary in simulation programs. Anyone who has ever attempted to measure daylight factors will be familiar with the fluctuations in lighting levels under partly cloudy conditions. The expansion and contraction of lightweight building components also shares sensitivity to rapid fluctuations in solar radiation. Single-sided ventilation is dependant on wind pressure fluctuations and pedestrians in many cities are acquainted with the disarming tendency of the wind to guest and change direction. It is increasingly the case that design questions touch on such issues.
In a research context, the advent of tools such as LabVIEW (National Instruments Corporation 1999) have made it possible for increasing numbers of researchers to acquire and process test-cell data. The increasing use of building energy management systems (BEMS) has also provided high frequency information from which simulation could be used as a predictive tool for future control strategies. Other issues of control, particularly of advanced daylighting control require sub-hourly illumination data to ensure that possible control regimes are tested under realistic conditions. Janak (1997) observed that the differences between 5 minute and hourly illumination data could result in prediction variations approaching 40%.
Thus far, projects that mix empirical and simulation-based work have had to store and access such data via temporal database facilities (ESRU 1999). As the number of high quality datasets increases so does the need to encapsulate such information in a form that can be broadly distributed. The simulation community must also consider the uncertainty in high frequency performance predictions that are based on boundary conditions that have been sampled at one or two magnitudes less temporal resolution.
The simulation community must also consider practitioner demands and issues of quality assurance. Someone who is not a native of Copenhagen may not know that there are three or four recognizable patterns of winter weather that should be included in detailed assessments. A data set that lacks documentation or is dependent on separately held lists of assumptions can be effectively useless.
In the absence of data within the weather data format, the simulation programs must calculate these data often with older calculation methods. As the simulation programs have become more capable, data at hourly resolution is no longer enough-interpolating between hourly observations does not accurately represent weather conditions that change much more frequently such as illumination.
We have developed a generalized weather data format for use by energy simulation programs has been developed and adopted by both ESP-r (in the UK) and EnergyPlus (in the US). Anticipating the need for data at time steps less than one hour, the format includes a minute field to facilitate the use of sub hourly data. The data include basic location identifiers such as location name, data source, latitude, longitude, time zone, elevation, peak design conditions, holidays, daylight saving period, typical and extreme periods, ground temperatures, period(s) covered by the data and space for descriptive comments. The time step data include dry bulb and dew point temperature, relative humidity, station pressure, solar radiation (global, extraterrestrial, horizontal infrared, direct, and diffuse), illuminance, wind direction and speed, sky cover, and current weather.
Documentation content copyright © 1996-2026 The Board of Trustees of the University of Illinois and the Regents of the University of California through the Ernest Orlando Lawrence Berkeley National Laboratory. All rights reserved. EnergyPlus is a trademark of the US Department of Energy.
This documentation is made available under the EnergyPlus Open Source License v1.0.