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
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"