<div dir="ltr"><div><div><div><div><div><div><div>Joe,<br><br></div>Thanks for sharing these. The other day I went looking for the MKAFT and PKAFT, but realized I could only find them as a windows exe so I gave up on this (I could have installed them on linux using WineHQ but I didn't care enough).<br></div><div>I was able to quickly compile these as a Unix exe using gfortan, and I can at least run them.<br></div><div><br></div>I tried out of the curiosity to see how I could port this to python, but this isn't going to happen for me (at least not without someone explaining very simply what the code does): I generally dislike Fortan syntax <u>very much </u>so I never got into it, and while I can generally follow scientific fortran about fine, the I/O stuff is really incomprehensible to me. <br>So far I was just able to figure out how to unpack the IWID and IWYR, after 30 minutes of scratcthing my head, the rest I get numbers but they don't match (I'm trying to read 4 bytes as an int for WLAT, WLONG, etc)<br>I also have never really dealt with packed binary files (seems to me like it's completely unnecessary nowadays that we have gigabytes of RAM and plently of disk space). At least I learned some new vocabulary, such as Hollerith strings (which I found out later, the fortran compiler itself told me it's deprecated)<br><br></div>I don't understand this in wthfm2Mleapyr.f:<br><br>DO 100 IM1=1,12<br> READ (10) (IWDID(I),I=1,5),IWYR,WLAT,WLONG,IWTZN,LRECX,NUMDAY,<br> _ CLN(IM1),GT(IM1),IWSOL<br> READ (10) IDUM<br></div>100 CONTINUE<br><br><br></div>Is the format expected in the binary file 20 chars followed by 6 integers (IWYR,WLAT,WLONG,IWTZN,LRECX,NUMDAY,) + 12 integers (CLN) + 12 integers (GT) + 1 integer (IWSOL) + 1 integer (IDUM)?<br><br></div>I've tried this in python:<br><br>import struct<br>with open('AK_BARROW-W-POST-W-ROGERS-AP_700260_12.BINM', 'rb') as f:<br> bindata = f.read()<br>fmt = '20s6i12i12iii'<br>start_pos = 4 # Apparently I have to skip the first 4 bytes.<br>end_pos = start_pos + struct.calcsize(fmt)<br>struct.unpack(fmt, bindata[start_pos:end_pos])<br><br><br></div>Which give me this, and it doesn't seem to match the WEATHER.FMTM file generated by the fortran utility:<br><br><pre>(b'BARROW-W-POST700260 ',
2012,
1116639068,
1125960909,
9,
1,
31,
1063675494,
1139180158,
5,
9849418,
328,
200,
98569,
9849418,
583,
200,
98567,
9915211,
648,
327,
100618,
9850960,
648,
326,
106761,
9851217,
9,
326,
106764,
9851475,
649,
454)</pre><div><div><br><br><div><div><div><div>Cheers,</div><div>Julien<br></div><div><br><br><br></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>--<br>Julien Marrec, EBCP, BPI MFBA<br>Owner at <a href="http://www.effibem.com" target="_blank">EffiBEM</a><br>T: +33 6 95 14 42 13<br><span style="color:rgb(0,0,0)"><br></span><span style="color:rgb(0,0,0)">LinkedIn (<a href="https://www.linkedin.com/in/julienmarrec" target="_blank">en</a>)<span style="color:rgb(0,0,0)"> <i>| </i></span>(<a href="https://fr.linkedin.com/in/julienmarrec/fr" target="_blank">fr</a>) : </span><br><span style="color:rgb(0,0,0)"><a href="http://www.linkedin.com/in/julienmarrec" target="_blank"></a></span></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2017-12-09 4:23 GMT+01:00 Joe Huang <span dir="ltr"><<a href="mailto:yjhuang@whiteboxtechnologies.com" target="_blank">yjhuang@whiteboxtechnologies.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Julien,</p>
<p>When I first read your post, I had the wrong impression that the
python script was disassembling (unpacking) the binary *.BINM
file, which would be quite an achievement since I hadn't
documented yet the packing procedure for the extra precision, nor
have the original packing been explained anywhere but in the
actual Fortran source code.</p>
<p>After looking at the python script, I then realized it was
reading the ASCII dump of the weather file, which I've said had a
embarrassing glitch in my unpacking :-)</p>
<p>The original packing/unpacking can be seen in the Fortran code of
the fmtwth2.f and wthfmt2.f programs that are part of the DOE-2
release package. In DOE-2.2, the same two programs have been
renamed as MKAFT and PKAFT. My additions can be seen in the
Fortran code of the fmtwth2M.f and wthfmt2mleapyr.f but please be
warned that I need to figure out the mysterious extra line I found
that was throwing off the solar radiation in November and
December. The source code for all 4 programs are attached, in
case anyone wants to port them to python<br>
</p><span class="">
<p>Joe<br>
</p>
<pre class="m_-8754494293076800014moz-signature" cols="90">Joe Huang
White Box Technologies, Inc.
346 Rheem Blvd., Suite 205A
Moraga CA 94556
<a class="m_-8754494293076800014moz-txt-link-abbreviated" href="mailto:yjhuang@whiteboxtechnologies.com" target="_blank">yjhuang@whiteboxtechnologies.<wbr>com</a>
<a class="m_-8754494293076800014moz-txt-link-freetext" href="http://weather.whiteboxtechnologies.com" target="_blank">http://weather.<wbr>whiteboxtechnologies.com</a> for simulation-ready weather data
(o) (925)388-0265
(c) (510)928-2683
"building energy simulations at your fingertips"
</pre>
</span><div><div class="h5"><div class="m_-8754494293076800014moz-cite-prefix">On 12/8/2017 6:24 AM, Jones,
Christopher wrote:<br>
</div>
<blockquote type="cite">
<div class="m_-8754494293076800014WordSection1">
<p class="MsoNormal"><span>Thank you Sir!</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><b><span> </span></b></p>
<p class="MsoNormal"><b><span lang="EN-GB">Christopher R. Jones</span></b><span lang="EN-GB">, P.Eng.</span></p>
<p class="MsoNormal"><span lang="EN-GB">Technical Specialist</span></p>
<p class="MsoNormal"><span lang="EN-GB">Sustainability &
Energy</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><img id="m_-8754494293076800014Picture_x0020_15" src="cid:part1.568184D1.0D8BAA1F@whiteboxtechnologies.com" width="78" height="37"></span><span></span></p>
<p class="MsoNormal"><span>T <a href="tel:+1%20416-644-0252" value="+14166440252" target="_blank">+1 416-644-0252</a></span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>2300 Yonge Street, Suite 2300</span></p>
<p class="MsoNormal"><span>Toronto, ON M4P 1E4 Canada</span><span lang="EN-GB"><br>
<br>
</span><span></span></p>
<p class="MsoNormal"><span><a><span>wsp.com</span></a></span></p>
<p class="MsoNormal"><u><span lang="EN-CA"><span> </span></span></u></p>
<p class="MsoNormal"><b><span> </span></b></p>
<p class="MsoNormal"><i><span>Please consider the environment
before printing...</span></i></p>
<p class="MsoNormal"><span lang="EN-CA"> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><b><span>From:</span></b><span> Julien
Marrec [<a class="m_-8754494293076800014moz-txt-link-freetext" href="mailto:julien.marrec@gmail.com" target="_blank">mailto:julien.marrec@gmail.<wbr>com</a>]
<br>
<b>Sent:</b> Friday, December 08, 2017 9:22 AM<br>
<b>To:</b> Jones, Christopher
<a class="m_-8754494293076800014moz-txt-link-rfc2396E" href="mailto:Christopher.r.Jones@wsp.com" target="_blank"><Christopher.r.Jones@wsp.com></a><br>
<b>Cc:</b> Joe Huang
<a class="m_-8754494293076800014moz-txt-link-rfc2396E" href="mailto:yjhuang@whiteboxtechnologies.com" target="_blank"><yjhuang@whiteboxtechnologies.<wbr>com></a>; EnergyPlus_Support
<a class="m_-8754494293076800014moz-txt-link-rfc2396E" href="mailto:EnergyPlus_Support@yahoogroups.com" target="_blank"><EnergyPlus_Support@<wbr>yahoogroups.com></a>; Javed Iqbal
<a class="m_-8754494293076800014moz-txt-link-rfc2396E" href="mailto:eee.javed@gmail.com" target="_blank"><eee.javed@gmail.com></a>; <a class="m_-8754494293076800014moz-txt-link-abbreviated" href="mailto:eQUEST-users@onebuilding.org" target="_blank">eQUEST-users@onebuilding.org</a><br>
<b>Subject:</b> Re: [Bldg-sim] Answers Re: Test your
knowledge of simulation weather file formats Part 1: the
DOE-2 *.BIN/*.BINM format</span></p>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Christopher,</p>
</div>
<p class="MsoNormal">This is a jupyter notebook. See <a href="http://jupyter.org/" target="_blank">
http://jupyter.org/</a>.</p>
</div>
<p class="MsoNormal">You can do "pip install jupyter"
then start a server with "jupyter notebook" in a
terminal, navigate to the location of the ipynb file
and open it up. Then you can just run it there, cell
by cell interactively (CTRL+ENTER to run a cell).</p>
</div>
<div>
<p class="MsoNormal">This is **hugely** helpful in
anything that has to do with data analysis, because it
allows for interactive exploring. I strongly suggest
you try it out.</p>
</div>
<div>
<p class="MsoNormal">Note that if you have installed a
scientific python distro such as Anaconda, you should
already have it installed.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">You can also download this as a
python file from the notebook, which I've done out of
convenience for you (see attached).</p>
</div>
<p class="MsoNormal">Best,</p>
</div>
<p class="MsoNormal">Julien</p>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><br>
</p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">--<br>
Julien Marrec, EBCP, BPI MFBA<br>
Owner at <a href="http://www.effibem.com" target="_blank">EffiBEM</a><br>
T: <a href="tel:06%2095%2014%2042%2013" value="+33695144213" target="_blank">+33 6 95 14 42 13</a><br>
<span><br>
LinkedIn (<a href="https://www.linkedin.com/in/julienmarrec" target="_blank">en</a>)
<i>| </i>(<a href="https://fr.linkedin.com/in/julienmarrec/fr" target="_blank">fr</a>)
:
</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">2017-12-08 14:26 GMT+01:00 Jones,
Christopher <<a href="mailto:Christopher.r.Jones@wsp.com" target="_blank">Christopher.r.Jones@wsp.com</a>>:</p>
<blockquote>
<div>
<div>
<p class="MsoNormal"><span>Julien,</span></p>
<p class="MsoNormal"><span>Thank you for the Python
code. One question – how do you download just the
code without the .png data in the file?</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><b><span> </span></b></p>
<p class="MsoNormal"><b><span lang="EN-GB">Christopher
R. Jones</span></b><span lang="EN-GB">, P.Eng.</span></p>
<p class="MsoNormal"><span lang="EN-GB">Technical
Specialist</span></p>
<p class="MsoNormal"><span lang="EN-GB">Sustainability
& Energy</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><img id="m_-8754494293076800014m_-2085549477788428701Picture_x0020_15" src="cid:part1.568184D1.0D8BAA1F@whiteboxtechnologies.com" width="78" height="37"></span></p>
<p class="MsoNormal"><span>T
<a href="tel:+1%20416-644-0252" target="_blank">+1 416-644-0252</a></span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><a href="https://maps.google.com/?q=2300+Yonge+Street,+Suite+2300%0D+Toronto,+ON+M4P+1E4+Canada&entry=gmail&source=g" target="_blank">2300 Yonge Street, Suite
2300</a></span></p>
<p class="MsoNormal"><span><a href="https://maps.google.com/?q=2300+Yonge+Street,+Suite+2300%0D+Toronto,+ON+M4P+1E4+Canada&entry=gmail&source=g" target="_blank">Toronto, ON M4P 1E4
Canada</a></span></p>
<p class="MsoNormal"><span><a href="http://wsp.com" target="_blank"><span>wsp.com</span></a></span></p>
<p class="MsoNormal"><span lang="EN-CA"> </span></p>
<p class="MsoNormal">
<b><span> </span></b></p>
<p class="MsoNormal">
<i><span>Please consider the environment before
printing...</span></i></p>
<p class="MsoNormal"><span lang="EN-CA"> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><b><span>From:</span></b><span>
Bldg-sim [mailto:<a href="mailto:bldg-sim-bounces@lists.onebuilding.org" target="_blank">bldg-sim-bounces@<wbr>lists.onebuilding.org</a>]
<b>On Behalf Of </b>Julien Marrec via Bldg-sim<br>
<b>Sent:</b> Thursday, December 07, 2017 7:02 AM<br>
<b>To:</b> Joe Huang <<a href="mailto:yjhuang@whiteboxtechnologies.com" target="_blank">yjhuang@whiteboxtechnologies.<wbr>com</a>><br>
<b>Cc:</b> EnergyPlus_Support <<a href="mailto:EnergyPlus_Support@yahoogroups.com" target="_blank">EnergyPlus_Support@<wbr>yahoogroups.com</a>>;
Javed Iqbal <<a href="mailto:eee.javed@gmail.com" target="_blank">eee.javed@gmail.com</a>>;
<a href="mailto:eQUEST-users@onebuilding.org" target="_blank">eQUEST-users@onebuilding.org</a>;
BLDG-SIM <<a href="mailto:bldg-sim@lists.onebuilding.org" target="_blank">bldg-sim@lists.onebuilding.<wbr>org</a>><br>
<b>Subject:</b> Re: [Bldg-sim] Answers Re: Test
your knowledge of simulation weather file formats
Part 1: the DOE-2 *.BIN/*.BINM format</span></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Joe,</p>
</div>
<p class="MsoNormal">This was fun, thanks
for putting it together, I'm looking
forward to the next one.
</p>
<div>
<p class="MsoNormal">I have to say that
I'm impressed by Aaron's knowledge and
level of detail, and it's not the
first time.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal">I've used Python to
parse your hourly dump and visualize it,
as well as comparing with the Barrow EPW
(converting your hourly dump to SI Units).
I've posted that on Github, where you can
already look at the code + graphs since
it's in a jupyter notebook, but you could
also download it and run it on your
machine. My hope is that I'll convert one
or two members of this list to coding :)
</p>
</div>
<div>
<p class="MsoNormal">For the record, the
actual parsing of the hourly dump into a
usable format (pandas.DataFrame) took me
about 5 minutes and 16 lines of code (it
was a very simple one though).<br>
<a href="https://github.com/jmarrec/BINM_Challenge/blob/master/Analyse_BINM.ipynb" target="_blank">https://github.com/jmarrec/<wbr>BINM_Challenge/blob/master/<wbr>Analyse_BINM.ipynb</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Cheers,</p>
</div>
<p class="MsoNormal">Julien</p>
</div>
<div>
<p class="MsoNormal"><br>
</p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">--<br>
Julien Marrec, EBCP, BPI MFBA<br>
Owner at <a href="http://www.effibem.com" target="_blank">EffiBEM</a><br>
T: <a href="tel:06%2095%2014%2042%2013" target="_blank">+33 6
95 14 42 13</a><br>
<span><br>
LinkedIn (<a href="https://www.linkedin.com/in/julienmarrec" target="_blank">en</a>)
<i>| </i>(<a href="https://fr.linkedin.com/in/julienmarrec/fr" target="_blank">fr</a>)
:
</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">2017-12-07 10:40
GMT+01:00 Joe Huang <<a href="mailto:yjhuang@whiteboxtechnologies.com" target="_blank">yjhuang@whiteboxtechnologies.<wbr>com</a>>:</p>
<blockquote>
<div>
<p class="MsoNormal">I got a total of five
responses, all of which are attached at
the end of this e-mail. Although I was
focusing on the FORMAT of the *.BIN
weather file, most of the respondents
focused on the data instead, and to my
chagrin more intensely than I have, esp.
Julien who pointed out an anomaly in the
direct normal radiation that made me
gasp and go back into my file and
processing procedures. Kudos to Julien
for spotting that, but I'll explain what
happened there following his e-mail
attached below.</p>
<div>
<p>The three answers I was seeking are:</p>
<p>(1) <b>The weather file is for a
location above the Arctic Circle</b>,
which would make DOE-2.1E crash due to
a bug in the shading calculation but
not in DOE-2.2 which fixed this bug in
2004. The point here is that this is
a problem in DOE-2.1E but NOT in the
*.BIN format, except it might seem
that way because the DOE-2 weather
packer also crashes because it uses
the same shading routine to generate
the weather statistics.</p>
<p>(2) <b>The weather file is for a
leap year with the output file
showing Feb. 29th</b>. I've heard
many people say that DOE-2 weather
files contain only 365 days, but
that's absolutely not true. The *.BIN
format stores data for 12 months of 32
days each, or 384 days! The reason
that Feb. 29th never shows up in a
DOE-2 run is that the developers never
bothered to reset the February day
count to 29 on leap years, even though
DOE-2 calculates when that's the
case. Now that more people are
running DOE-2 with actual historical
years, it's well past time for this
little fix to be implemented.
</p>
<p>(3) <b>The weather file reports
shows the weather parameters to an
additional decimal of precision</b>,
i.e., temperatures are to the 0.1F,
pressures to 0.01 inches of mercury,
solar radiation to 0.1 Btu/sqft, and
wind speeds to 0.1 mph. This required
a modest change to the BIN format that
I implemented as the *.BINM (M for
Modified) starting in 2011. This
leads to what I think is the most
fascinating part about the DOE-2 *.BIN
format that was developed in the early
1980's when computer memory was very
limited. Members of the original
development team (Ender Erdem and
maybe Fred Buhl) came up with the
strategy of "packing" the data by
converting all data to integers, pack
four integers into one big integer,
and then store them in the file in
binary form. By so doing the *.BIN
files are only 146K (70-80KB zipped),
whereas other formats can be well over
1MB (200+KB zipped). DOE-2 also uses
the *.BIN format to improve execution
speed by not reading the data an hour
at a time or 8760 ASCII reads, but by
reading 16 day chunks at a time or 24
binary reads for the entire year
(which also explains why the *.BIN
format contains 24x16 or 384 days).
</p>
<p>So now let's look at how did our
contestants do, listed in order of
when I received their answers:</p>
<p>Parag - 0 out of 3 (he looked
almost entirely on the data, not on
the format)</p>
<p>Julien - 1 out of 3 (he noticed the
leap day, but also focused his
attention on the data and pointed out
two problems that I will address
following his e-mail below)</p>
<p>Aaron - 2 out of 3 (I was impressed
that he knew about the packing and
unpacking process, but did not notice
the leap year)</p>
<p>Javed - 0 out of 3 (but had a good
question on why DNI (Direct Normal) is
larger than GHI (Global Horizontal)
that I will answer following his
e-mail below)</p>
<p>Nathan - 1 out of 3 (he also noticed
the leap day, and had other questions
that I will answer following his
e-mail below).</p>
<p>So, nobody noticed all three answers,
but since it's the holiday season, I
will make them all winners and provide
a historical year weather file of
their choosing. Just e-mail me if
you're interested and tell me which
one you want.</p>
<p>This has been an interesting and
insightful experience for me. I hope
others also found it entertaining and
useful, as well. I've learned that
(1) think twice before coming out with
a flawed contest rule, (2) look over
more times whatever I put out on the
Web.</p>
<p>(please be sure to read the
contestant's submittals and my
responses below)</p>
<p>Joe</p>
<pre>Joe Huang</pre>
<pre>White Box Technologies, Inc.</pre>
<pre><a href="https://maps.google.com/?q=346+Rheem+Blvd.,+Suite+205A%0D+Moraga+CA+94556&entry=gmail&source=g" target="_blank">346 Rheem Blvd., Suite 205A</a></pre>
<pre><a href="https://maps.google.com/?q=346+Rheem+Blvd.,+Suite+205A%0D+Moraga+CA+94556&entry=gmail&source=g" target="_blank">Moraga CA 94556</a></pre>
<pre><a href="mailto:yjhuang@whiteboxtechnologies.com" target="_blank">yjhuang@whiteboxtechnologies.<wbr>com</a></pre>
<pre><a href="http://weather.whiteboxtechnologies.com" target="_blank">http://weather.<wbr>whiteboxtechnologies.com</a> for simulation-ready weather data</pre>
<pre>(o) (925)388-0265</pre>
<pre>(c) (510)928-2683</pre>
<pre>"building energy simulations at your fingertips"</pre>
<p>Attached e-mails follow in the same
order (only final e-mails shown)
------------------------------<wbr>-----------------------------</p>
<div>
<p class="MsoNormal">On 12/5/2017
11:24 PM, Parag Rastogi wrote:</p>
</div>
<blockquote>
<pre>Hi Joe,</pre>
<pre> </pre>
<pre>Don't know anything about the DOE-2 platform, but here's my take on the meteorological "oddities". Thanks for organising this challenge - it's really cool!</pre>
<pre> </pre>
<pre>1. A large part of the year has zero sun while the other part has sun for 24 hours.</pre>
<pre>2. The humidity is _really_ high - the WBT and DBT are mostly within a degree of each other. Don’t know if DOE-2 has a problem with that?</pre>
<pre>3. In the summer months, the direct normal is sometimes larger than global solar. That is really odd!</pre>
<pre>4. I would not live here - Glasgow winters are bad enough.</pre>
<pre> </pre>
<pre>Parag</pre>
</blockquote>
<p class="MsoNormal">YJH answer: Yes,
I picked Barrow on purpose to show
that the *.BIN format still works for
places above the Arctic Circle or
below the Antarctic Circle. RH is
generally very high in frigid climates
because the cold air cannot hold much
moisture (that's why there's always
frost in your refrigerators!). The
DNI can often be greater than the GHI
at low sun angles, since the DNI is
calculated normal to the sun, while
the GHI is calculated for a flat
horizontal plane. Yes, stay in
Glasgow or at least don't go to Barrow
in place of Glasgow.<br>
<br>
On 12/6/2017 6:35 AM, Julien Marrec
wrote:</p>
<blockquote>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi
Joe,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Replying
off the mailing list,
since it would kinda
beat the point of "first
5 to find the error"
otherwise.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">1.
There is a 29th of
February, but 1912 was
indeed a leap year, so
I'm not sure whether
that qualifies for a bug
(can't remember how
eQuest/DOE deal with
leap year weather
files).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">2.
There is an unsual peak
of Global Solar
radiation mid November
(11 to 18th) while the
Direct Normal stays at
zero. The peak has
values at 400
BTU-HR/SQFT while the
max is 250 for the rest
of the year. 400 means
1250 Wh/m2, which is
just short of what the
Extraterrestrial Direct
Normal Solar Radiation
is.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">In IP
units:</p>
</div>
<div>
<p class="MsoNormal"><img id="m_-8754494293076800014m_-2085549477788428701_x005f_x0000_i1025" src="cid:part29.01520EE9.B42077A6@whiteboxtechnologies.com" alt="Images intégrées
1" width="936" height="513"></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">I don't
see any problem with the
Atmospheric pressure, not
the relative humidity I
computed with Db, Wb and
Atm. Wetbulb and drybulb are
where I expect them for this
location (checked against
the EPW file for the same
location too).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">So I'm
not sure what's the 3rd
problem, I'd say that it's
probably not a good idea to
live there unless you
<b>really</b> like cold
weather?</p>
</div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Best,</p>
</div>
<p class="MsoNormal">Julien</p>
</div>
<div>
<p class="MsoNormal">--</p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Julien
Marrec, EBCP, BPI
MFBA<br>
Owner at <a href="http://www.effibem.com" target="_blank">EffiBEM</a><br>
T: <a href="tel:06%2095%2014%2042%2013" target="_blank">+33 6 95 14 42 13</a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal">YJH answer: I was
embarrassed that you noticed the input
echo has 1912 instead of 2012, which
was because DOE-2.1E was not Y2K
compliant, so I had to set the year to
1912 in order for DOE-2.1E to run. I
was further more astonished to see the
wierd spike of GHI in November, which
wasn't there in the actual weather
file (see below).
<br>
<img id="m_-8754494293076800014m_-2085549477788428701_x005f_x0000_i1026" src="cid:part32.058DAE38.4D6FF30F@whiteboxtechnologies.com" width="486" height="291"><img id="m_-8754494293076800014m_-2085549477788428701_x005f_x0000_i1027" src="cid:part33.C68143FA.E303FCC4@whiteboxtechnologies.com" width="486" height="291"><br>
<br>
Since DOE-2.1E can't run with this
weather file, I used a version that I
modified that took care of the high
latitude problem as well as adding the
extra precision. When I checked the
Fortran source code, I found this
extra line (<<<) that I have
no memory of ever inserting nor why I
did so (sound like a politician, don't
I ? :-) ). <br>
DO 500 I=1,14<br>
CALC(I) =
FLOAT(IWTH(I))*XMASK(I,2) + XMASK(I,1)<br>
IF (I.LE.2)
CALC(I)=CALC(I)+IWTH2(I)/10.<br>
IF (I.EQ.11.OR.I.EQ.12)
CALC(I)=CALC(I)+IWTH2(I-8)/10.<wbr>
<<< ???<br>
500 CONTINUE<br>
So, if you believe my story, this
spike in GHI was the result of my
unpacking routine and not in the
weather file itself. A curious thing
with the solar in such Arctic
locations is that the GHI is above 0
for all hours over two months (see
central bottom of the left plot),
indicating the proverbial midnight
sun during the summer.</p>
<div>
<p class="MsoNormal">On 12/6/2017 9:05
AM, Aaron Powers wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Hey Joe,
</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Here's what I
could find. It's really 2
things since the first 2 and
last 2 are related.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">1. Normal
DOE2 binary weather files are
made up of 24 records of 6208
bytes each. So each file is
roughly 145 kB. Your file is
182 kB, so each of the 24
records is 7744 bytes in
length. I'm not sure what you
have in the extra bytes, but the
first 6208 bytes of each record
is exactly as you would expect
in a DOE2 packed file. So I am
able to read the .bin file by
just ignoring the bytes after
6208 of each record.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">2. You have
more precision for each data
point. I'm guessing this must
be tied up to the extra bytes in
each record. For example, the
drybulb, wetbulb, and pressure
are usually packed into a single
integer value. The first and
last 4 bits of the integer are
junk due to the way Fortran
writes binary data. The
atmospheric pressure takes up 15
bits and the drybulb and wetbulb
take up 8 bits each. After
encryption, this allows the
drybulb and wetbulb to be stored
with 0 decimal places and the
pressure with 1 decimal place.
Similarly, the direct normal and
global horizontal are usually
stored with 0 decimal places.
Your output file shows a higher
precision for each of these data
points. Again, I'm guessing
that this extra precision is in
the extra bytes in each record.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">3. Since
Barrow is above the Arctic
Circle, it gets the midnight sun
and polar night. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">4. Related to
previous, in the peak of summer,
radiation has very little
diffuse component and during
winter is almost all diffuse
(when it exists).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Aaron</p>
</div>
</div>
</blockquote>
<p class="MsoNormal">YJH answer: You're
completely correct in all your
suppositions, Sherlock Holmes ! What
I've done is to add another array of
384, each containing the extra
precision for the two temperatures,
pressure, wind speed, and the two
solar irradiances. It was my former
colleague at LBNL Ender Erdem who
assured me that in a binary read, this
extra integer would be ignored,
thereby guaranteeing compatibility
between the *.BIN and *.BINM formats.
However, once the extra read is added,
there has to be a flag telling DOE-2
NOT to do that for the older *.BIN
format. That's the main reason why I
haven't pushed very hard on this.</p>
<div>
<p class="MsoNormal">On 12/6/2017 9:18
AM, Javed Iqbal wrote:</p>
</div>
<blockquote>
<div>
<div>
<p class="MsoNormal"><span>Dear
Sir Joe,</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span>I am
able to find something though
NOT all which looks to me
unusual and hence reporting
here.</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span>1) The
following screenshot for
<b><u>22nd April</u></b> shows
that Direct Normal is greater
than the Global solar. As per
my limited knowledge in this
direction, usually Direct
Normal Solar can be greater
than Global solar
(Direct+diffuse) or GHI during
certain periods such as
morning or afternoon hours.
Whereas, the hourly report
shows Direct Normal Solar is
always higher (~8-10 times)
than the Global Solar. If this
is one of the acceptable
discrepancy than there are
many such instances could be
found in in the hourly weather
file. </span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span><img id="m_-8754494293076800014m_-2085549477788428701_x005f_x0000_i1028" src="cid:part34.89A5005F.684C15D9@whiteboxtechnologies.com" alt="Inline
image 1" width="407" height="515"></span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Let me
know your thought on this.</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Sorry I
could do this much only out of
my busy schedule.</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Thanks,</span></p>
</div>
</div>
</blockquote>
<p class="MsoNormal">YJH answer: The
DNI can be larger than the GHI
frequently in the Arctic locations
because of persistently low sun
angles. However, the numbers that
you've highlighted above have DNI/GHI
ratios that do seem excessive. All
these solar irradiances are calculated
using several empirical and analytical
models and so could always be wrong.
However, the formulation of the direct
solar model calculates the DNI as a
sigmoid function of the ratio between
the GHI and the extraterrestrial
global horizontal radiation, so it
would seem difficult to produce a DNI
that would violate physical reality,
i.e., GHI = DNI*sin(solarZ) + DHI.
Time permitting, I may look more into
this.</p>
<div>
<p class="MsoNormal">On 12/6/2017 2:01
PM, Nathan Brown wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Ok, so here’s
my revised list:</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">1. Hour index
is 1, not zero (not different from
.epw, but still annoying to deal
with while post processing)<br>
2. Solar noon is not aligned to
the noon timestamp. Does this mean
permanent DST?<br>
3. This file contains data for
2/29</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<p class="MsoNormal"><span>Nathan
Brown, BEMP, LEED AP</span><span>
~ Associate </span></p>
</div>
<div>
<p class="MsoNormal"><b><span>LOISOS
</span></b><span>+<b>
UBBELOHDE
</b></span></p>
</div>
<div>
<p class="MsoNormal"><span>-
- - - - - - - - - - - -
- - - - - - - - - - - -
- -
</span></p>
</div>
<p class="MsoNormal"><span><a href="http://www.coolshadow.com/" target="_blank"><span>www.coolshadow.com</span></a></span></p>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<p class="MsoNormal">YJH answer: 1 is
not a correct answer since, as you
note, the convention is the same for
both *.BIN and *.BINM, as well as
*.epw files. The annoyance you feel
msy be due to the mixed use of
cardinal and ordinal numbers in the
weather files. The standard
convention on simulation weather files
is the formal, i.e., Hour 1, Hour 2,
etc., whereas the convention on
weather station reports is the latter,
Hour 00:00, Hour 01:00, etc. In my
opinion there is an inconsistency on
simulation weather files where most of
the measurements (temperatures, etc.)
are reported by the timestamp, i.e.,
00:00, but incorporated as Hour 1,
etc., while others, notably solar and
rainfall, are both measured and
reported cardinally as Hour 1, etc.
I'll talk more about this in the next
contest on the epw file format.<br>
<br>
How are you deducing that solar noon
is not aligned to the noon timestamp?
As for DST, I feel that weather files
should NEVER incorporate any such
human-made artifacts. There are
several factors you should consider
when comparing solar noon to local
standard noon: (1) difference in
longitude between the standard
meridian and the location (Barrow); in
this case, they are 150.00 West and
156.782 West respectively, or a 27
minute effect, (2) the solar
irradiance is given over the past
hour, so the average solar position
for Hour 12 is at 11:30 AM local time
rather than 12:00 PM, another 30
minute effect, and (3) "Equation of
time" that makes local time faster or
slower than solar time by +- 15
minutes at the most. I don't know if
these effects combined accounts for
the difference between solar and local
noon that you see.</p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div class="MsoNormal">
<hr width="100%">
</div>
<p class="MsoNormal"><span><br>
<br>
NOTICE: This communication and any attachments
("this message") may contain information which is
privileged, confidential, proprietary or otherwise
subject to restricted disclosure under applicable
law. This message is for the sole use of the
intended recipient(s). Any unauthorized use,
disclosure, viewing, copying, alteration,
dissemination or distribution of, or reliance on,
this message is strictly prohibited. If you have
received this message in error, or you are not an
authorized or intended recipient, please notify the
sender immediately by replying to this message,
delete this message and all copies from your e-mail
system and destroy any printed copies. You are
receiving this communication because you are listed
as a current WSP contact. Should you have any
questions regarding WSP's electronic communications
policy, please consult our Anti-Spam Commitment at
<a href="http://www.wsp.com/casl" target="_blank">www.wsp.com/casl</a>. For
any concern or if you believe you should not be
receiving this message, please forward this message
to
<a href="mailto:caslcompliance@wsp.com" target="_blank">caslcompliance@wsp.com</a>
so that we can promptly address your request. Note
that not all messages sent by WSP qualify as
commercial electronic messages.
<br>
<br>
AVIS : Ce message, incluant tout fichier
l'accompagnant (« le message »), peut contenir des
renseignements ou de l'information privilégiés,
confidentiels, propriétaires ou à divulgation
restreinte en vertu de la loi. Ce message est
destiné à l'usage exclusif du/des destinataire(s)
voulu(s). Toute utilisation non permise,
divulgation, lecture, reproduction, modification,
diffusion ou distribution est interdite. Si vous
avez reçu ce message par erreur, ou que vous n'êtes
pas un destinataire autorisé ou voulu, veuillez en
aviser l'expéditeur immédiatement et détruire le
message et toute copie électronique ou imprimée.
Vous recevez cette communication car vous faites
partie des contacts de WSP. Si vous avez des
questions concernant la politique de communications
électroniques de WSP, veuillez consulter notre
Engagement anti-pourriel au <a href="http://www.wsp.com/lcap" target="_blank">
www.wsp.com/lcap</a>. Pour toute question ou si
vous croyez que vous ne devriez pas recevoir ce
message, prière de le transférer au
<a href="mailto:conformitelcap@wsp.com" target="_blank">conformitelcap@wsp.com</a>
afin que nous puissions rapidement traiter votre
demande. Notez que ce ne sont pas tous les messages
transmis par WSP qui constituent des messages
electroniques commerciaux.
<br>
</span><br>
<span><br>
<br>
-LAEmHhHzdJzBlTWfa4Hgs7pbKl </span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>