[Bldg-sim] Answers re: Test your knowledge of simulation weather file formats Part 2: the EnergyPlus *.epw format

Joe Huang yjhuang at whiteboxtechnologies.com
Tue Dec 19 09:44:21 PST 2017


I only got two responses this time, which I attribute to either the close proximity of the 
holidays or perhaps reader fatigue about weather data
However,  the answers I did receive, especially the second one, were so much in line with 
what I saw on the weather file that it looks copied which I must  affirm was not the case 
(see the answers at the bottom of this post).

So, the three things I found unusual about this weather file are, in order of ascending 
importance:
   1. The year is given as 2005 throughout, but the comment says that it's a "typical 
year" file made from the time period 1970-2000.
   2.  Line 8 says that the first day of the weather file, i.e., Jan. 1, is set as a 
Sunday, but January 1 2005 was a Saturday.
   3. The solar radiation appears to be shifted a half-hour ahead, probably because the 
original file was created in Europe, which tends to report the solar around the time step, 
e.g., -0:30 to +0.30, whereas in North America it's reported for the preceding time step, 
i.e., -1:00 to 0:00.  Although that was the only criteria for why I chose this weather 
file (Legnica, Poland), I later found other more troubling aspects to the solar radiation 
that made me expand the discussion to  QC'ing the solar on weather files in general.

I first became aware of the different conventions of reporting solar back in 1993 when I 
was involved in an IEA project on Low-Energy Cooling where one of the first items of 
business was  to compare the climate conditions in the participant countries.  When I 
tried to work with weather data from European colleagues, I was getting impossibly large 
spikes of Direct Normal Irradiance (DNI) for many sunrise hours due to this difference in 
convention, since I was using a US simulation program that follows the US convention and 
calculates the sun position at the midpoint of the preceding time step.

Although it might seem hard to tell which convention is being used in a weather file, it's 
actually quite noticeable if one were to compare the hourly profiles to those calculated 
by a Clear Sky Model.  For example,  this plot shows July 1 - 4, where the forward 
shifting of the solar on the weather file can be seen, particularly if you look for the 
sunrise and sunset hours. What really surprised me, though, was that the Global Horizontal 
Irradiance (GHI) and DNI seem switched on the weather file. The GHI profile is generally 
more smooth and the DNI more spiky, but here it's the reverse.  Also, the GHI greatly 
exceeds the Clear Sky GHI on the morning of Day 3, which simply cannot happen.


The data for Jan. 1 -4 reveals more indications that the GHI and DNI on the weather file 
may be switched., with the GHI (?) again more spiky and on Jan. 2  almost three times as 
much as the Clear Sky GHI.  The 30-minute shift is less visible owing to the small values, 
but can still be detected by looking at the sunrise and sunset hours.


So what does this say about QC'ing weather data?  It seems that more emphasis has gone 
into QC'ing excursions in temperature than solar radiation. However, since the solar in 
almost all weather files is not measured but calculated, there should be all the more 
reason to regard it more carefully.  Luckily, there are several simple, if not 
simple-minded,  facts that can be used as reality checks, e.g., (1) the GHI should always 
be non-zero when the sun is above the horizon, making it possible to determine the hours 
of sunrise and sunset, (2)  the GHI and DNI could never be greater than their Clear Sky 
values (don't worry about ground reflectance or atmospheric phenomena like cloud lensing 
since we're only dealing with calculated  data),  and (3) the Direct Horizontal ( DHI = 
DNI * arcsin of the solar angle) cannot be greater than the GHI.

I hope this answer has provided some insight into the contents of weather files. As in the 
previous contest, both respondents, Samuel Letellier-Duchesne and Michael Kummert, are 
declared winners and entitled to one free weather file of their choice from the WBT 
archive.  Just let me know. (Full disclosure: Samuel appears to be Michael's graduate 
student :-))

Holiday greetings to all!

Joe
-------- Forwarded Message --------
Subject: 	Re: [Bldg-sim] Test your knowledge of simulation weather file formats Part 2: 
the EnergyPlus *.epw format
Date: 	Fri, 15 Dec 2017 13:02:00 -0500
From: 	Samuel Letellier-Duchesne <samuel.letellier-duchesne at polymtl.ca>
To: 	Joe Huang <yjhuang at whiteboxtechnologies.com>



Well, there is clearly something wrong with the sunup/sundown portion of the data as there 
is no systematically no transition for most days of the year. See image for comparison 
with us-based weather file. Will try to find more!


Polytechnique Montréal
Samuel Letellier-Duchesne
Ph.D. Candidate
Mechanical Engineering
2900 Edouard Montpetit Blvd,
Montreal, QC H3T 1J4 - Canada
samuel.letellier-duchesne at polymtl.ca <mailto:samuel.letellier-duchesne at polymtl.ca>
Tel. +1-514-813-0056

On 12/19/2017 4:27 AM, Michaël Kummert wrote:
>
> Joe,
>
> Here are my comments on the file that you asked us to examine.
>
> **
>
> *Small details:*
>
> The EPW file appears to be a typical meteorological year but the year 2005 is given for 
> all months, which is probably not correct. The file also has zeros in the minute field 
> (5th field), while many typical EPW files have 60. I haven’t found a clear explanation 
> of what that field is supposed to contain.
>
> *The main “problem”: solar radiation*
>
> Solar radiation data in this EPW file seems questionable:
>
>   * There is an apparent shift (roughly ½ h) in solar radiation reported in the file.
>     This is apparent when comparing radiation in the file to calculated clear sky radiation
>   * The yearly average beam normal radiation is much lower than in other data sources
>     (Meteonorm), but hourly values on some days are unrealistically high (in some cases
>     twice the clear sky radiation)
>   * Calculated values for normal extraterrestrial (12^th column) are not correct. That
>     column probably shows another variable. On the other hand, calculated values for
>     extraterrestrial horizontal seem correct
>
>   * This indicates a problem in the original data and/or in its interpretation and
>     processing. If I had to guess, I would propose the following explanation:
>       o Let’s assume only total horizontal is available (estimated or measured). The
>         shift in time causes total radiation in the morning to be very high. Some
>         correlation similar to Erbs is used to estimate the diffuse radiation, and that
>         correlation gives a small percentage of diffuse. Since the total radiation is
>         very high, the calculated normal radiation on the horizontal is large, and the
>         beam normal radiation is even larger.
>       o This could explain the large spikes in beam normal (mostly in the morning), but
>         it does not explain why the beam normal radiation is too low in average.
>
> *Other variables* (temperature, humidity, wind speed) seem to be usable. I didn’t check 
> humidity calculations, I assumed the variables would be consistent.
>
> I have put some graphs in a presentation which I may use one day in a class. I am 
> attaching it in case you want to take a look at some of the strange solar radiation 
> values vs clear sky radiation.
>
> Michaël
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20171219/46b98629/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dagnbecdofhjdhcn.png
Type: image/png
Size: 94009 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20171219/46b98629/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binbdpboohiikeej.png
Type: image/png
Size: 68288 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20171219/46b98629/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: illgbjjoleaifocn.png
Type: image/png
Size: 107650 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20171219/46b98629/attachment-0002.png>


More information about the Bldg-sim mailing list