[Equest-users] Weather Normalizing an eQuest Model

[Joe Huang]

Jacob,

I admire you for giving it the old college try, but there are many reasons why the 
procedure you described did not work having to do with both data format and, more 
critically, data content.

My first comment is that you will need much more than just the temperature, i.e., you also 
need at a minimum some indicator of humidity, wind speed and direction, and both global 
horizontal and direct normal solar radiation.  Otherwise, your new weather file would be 
unusable.

The file from the NCDC site contains raw weather data as reported by weather stations 
around the world, which means it has subhourly and missing records, standard pressure 
rather than station pressure, etc., and most important, will have no solar radiation data.

When you run txt2bin, it calls fmtwth2, which is one of two small Fortran programs (the 
other being wthfmt2) originally written to convert  between *.BIN binary and *.FMT  text 
files, so that DOE-2 weather files could be ported across different operating systems.
These programs were never meant for converting raw weather data, for which there's another 
much better program called doewth (more on that later).  The *.FMT format is very 
DOE-2-specific, containing several elements not found in standard weather reports, e.g., 
wetbulb, humidity ratio, enthalpy, and is also in IP units.  So, if you're using fmtwth2 
to create a *.BIN file, you need to first convert your *.txt file to *.FMT,  which is way 
too much work and not worth the effort, because in addition to calculating the missing 
climate elements , including the solar (!) and converting them to IP , you also need to 
fill in any missing and skip the subhourly data.

Are there other ways to do this?  Sure, but the effort might still strike you as excessive.

1. DOE-2's weather processor program is called doewth and was written specifically to do 
what you want, i.e., convert a raw weather file to *.BIN, but since it's about 25 years 
old, it won't recognize the format of your *.txt file, so, you'd have to write a
Fortran subroutine to specify the contents and format of your *.txt file and then 
recompile doewth.  Fortran anyone ?  :-)

2.  You could conceivably use the WeatherConverter program in EnergyPlus, which allows you 
to get your *.txt file to an *.EPW, and from there you can use eQ_WthProc that comes with 
eQUEST to then the *.EPW  to *.BIN.  I've never tried to do that,  so I can't say how 
smoothly that would work.

What I do know is that neither doewth nor WeatherConverter do a good job in filling 
missing data, and their solar algorithms are either extremely old (>25 years) or fairly 
old (>10 years).

Before you throw up your hands, there is another path, which is to find a commercial 
vendor who can get you the historical file that you need.

Joe

Joe Huang
White Box Technologies, Inc.
346 Rheem Blvd., Suite 108D
Moraga CA 94556
yjhuang at whiteboxtechnologies.com
http://weather.whiteboxtechnologies.com for simulation-ready weather data
(o) (925)388-0265
(c) (510)928-2683
"building energy simulations at your fingertips"


On 6/14/2014 10:08 AM, Jacob Goodman wrote:
> Dear List,
>
> After much googleing I found some close answers, but not exact. My task this weekend is 
> to take an eQuest model and "Weather normalize" it. To do this I need to create a .bin 
> weather file for San Diego for the full year 2013 and then run the model using that 
> weather. My approach so far is to download a .txt file from:
>
> https://gis.ncdc.noaa.gov/map/viewer/#app=cdo&cfg=cdo&theme=hourly&layers=1
>
> Then selecting only "Air Temperature Observations" (do I want other variables?) and 
> generating the output sent to me as:
>
> http://www1.ncdc.noaa.gov/pub/orders/3303657117758dat.txt
>
> Then I tried to convert "SanDiegoTemp.txt" to a .bin file using the PKAFT command to 
> call the TXT2BIN application from the DOE2 website. I edited the PKAFT batch file to 
> change the directory path from "C:/doe22" (that was the default) to point to my weather 
> directory that containd the .txt file that I got from NOAA. I then typed "PKAFT 
> SandDiego" hit enter got a message:
>
>
> /This shell file packs an unpacked DOE-2 weather file.//
> //The file was unpacked wth wthfmt2 and has an .ft extension//
> //(which is not included in the call to this procedure.)//
> //Param 1 is file name.  Param 2 is S or NS for solar or nonsolar.//
> //S for TMY, WYEC; NS for TRY.//
> //If Param 2 is not specified the type found on the .ft file will be used.//
> //A WTH stat run is also made on the file and all output//
> // is moved into the INPUT directory./
>
> Then hit continue and got the error:
>
> /ERROR:missing input data file - c:\Users....the path...\weather\SanDiegotemp.ft
>
> /No .bin file was produced and it looks to me like the program is looking for a .ft file 
> not a .txt file. Any advice? Is there an easier way to get a 2013 San Diego .bin file?
>
> Thanks much and hope everyone is having a great weekend,
> Jacob
>
>
>
> _______________________________________________
> Equest-users mailing list
> http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org
> To unsubscribe from this mailing list send  a blank message to EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20140614/bb2461e0/attachment.htm>