[Met_help] [rt.rap.ucar.edu #38461] History for point_stat file names
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Mon Jun 21 09:44:01 MDT 2010
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I'm trying to compare the WRF-ARW results with synop data for the January
2008 (forecast & observations every three hours). It works fine for the
first 11 days, but for other days that point_stat overwrites the first
file. The last file named (I guess) correctly is:
point_stat_2550000L_200080111_150000V.stat
All other results are written to: point_stat_000000L_200080101_000000V.stat
Could you please help me with this?
Best wishes,
Maciek
**********************************************************
Maciek Kryza
Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
ul. Kosiby 6/8, 51-670 Wroclaw
email: kryzam at meteo.uni.wroc.pl
**********************************************************
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: point_stat file names
From: John Halley Gotway
Time: Thu Jun 10 12:18:44 2010
Maciek,
I think I have an idea of what's going on here. You've notice a
problem in the timestamps on day 11 of your 3-hourly output. 11 days
is the same as 264 hours. In the GRIB version 1 output of the WRF
PostProcessor (WPP), there are issues when the time value grows larger
than 255. GRIB version 1 only provides a single byte for each time
value it stores. Basically, when the time values exceed 255, WPP
overflows that one byte.
This is a known issue. I'm not sure what version of WPP you're
running, but here's a link to the problem description. This issue
should be fixed in the latest version, v3.2:
http://www.dtcenter.org/wrf-
nmm/users/model/graphics/WPP/fixes_v3.1.php
I also want to let you know about an option in Point-Stat for
customizing output file names. In the Point-Stat config file, look
for the "output_prefix" parameter. You can use this to specify a
string to come after the "point_stat_" in the output file names.
Also, be aware that you can specify the "output_prefix" using
environment variables. For example, suppose you set the environment
variable "FCST_LEAD = 006" and set:
output_prefx = "${FCST_LEAD}";
That will cause the Point-Stat output files to be named
"point_stat_006_...". You may find using the "output_prefix" option
helpful in customizing your output file names.
Let us know if you continue to experience problems.
Thanks,
John Halley Gotway
met_help at ucar.edu
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #38461] point_stat file names
From: kryzam
Time: Thu Jun 10 23:23:51 2010
Dear John,
Thank you for quick reply.
I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but the
problem
still exist. I also tried the solution with "output_prefix", adding
date
and hour to the output file name. It partly works - the files are not
overwritten, but the observation value for days >Jan 11 in the output
files is always for Jan 1st.
Is there any other way to compare model results with observations?
Best wishes,
Maciek
> Maciek,
>
> I think I have an idea of what's going on here. You've notice a
problem
> in the timestamps on day 11 of your 3-hourly output. 11 days is the
same
> as 264 hours. In the GRIB version 1 output of the WRF PostProcessor
> (WPP), there are issues when the time value grows larger than 255.
GRIB
> version 1 only provides a single byte for each time value it stores.
> Basically, when the time values exceed 255, WPP overflows that one
byte.
>
> This is a known issue. I'm not sure what version of WPP you're
running,
> but here's a link to the problem description. This issue should be
fixed
> in the latest version, v3.2:
> http://www.dtcenter.org/wrf-
nmm/users/model/graphics/WPP/fixes_v3.1.php
>
> I also want to let you know about an option in Point-Stat for
customizing
> output file names. In the Point-Stat config file, look for the
> "output_prefix" parameter. You can use this to specify a string to
come
> after the "point_stat_" in the output file names. Also, be aware
that you
> can specify the "output_prefix" using environment variables. For
example,
> suppose you set the environment variable "FCST_LEAD = 006" and set:
> output_prefx = "${FCST_LEAD}";
>
> That will cause the Point-Stat output files to be named
> "point_stat_006_...". You may find using the "output_prefix" option
> helpful in customizing your output file names.
>
> Let us know if you continue to experience problems.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
**********************************************************
Maciek Kryza
Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
ul. Kosiby 6/8, 51-670 Wroclaw
email: kryzam at meteo.uni.wroc.pl
**********************************************************
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #38461] point_stat file names
From: John Halley Gotway
Time: Fri Jun 11 12:18:35 2010
Maciek,
Alright, I'm going to have to do some more investigating on this
issue. It'd really help to have some of your output data to run with
and test here. Could you send me some data for 2 output times,
one before there are problems and one after you see problems? For
example, forecast lead times 240 hours and 270 hours.
I'd like to see the following data:
(1) WRFOUT NetCDF files for those lead times
(2) GRIB output from the WPP for those lead times
(3) The Point-Stat configuration file you're using.
(4) Point observation files you're using to verify that WPP output for
those two lead times.
(5) A description of what the output file names from Point-Stat are
for those two lead times.
That'll give me plenty of data to play around with and debug this
issue. You can post it to our anonymous ftp site as described below:
ftp ftp.rap.ucar.edu
username = anonymous
password = "your email address"
cd incoming/irap/met_help/kryza_data
put "your files"
bye
Please let me know when you've posted the data there, and I'll take a
look.
Thanks,
John
RAL HelpDesk {for kryzam} wrote:
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38461 >
>
> Dear John,
> Thank you for quick reply.
> I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but the
problem
> still exist. I also tried the solution with "output_prefix", adding
date
> and hour to the output file name. It partly works - the files are
not
> overwritten, but the observation value for days >Jan 11 in the
output
> files is always for Jan 1st.
> Is there any other way to compare model results with observations?
> Best wishes,
> Maciek
>
>
>> Maciek,
>>
>> I think I have an idea of what's going on here. You've notice a
problem
>> in the timestamps on day 11 of your 3-hourly output. 11 days is
the same
>> as 264 hours. In the GRIB version 1 output of the WRF
PostProcessor
>> (WPP), there are issues when the time value grows larger than 255.
GRIB
>> version 1 only provides a single byte for each time value it
stores.
>> Basically, when the time values exceed 255, WPP overflows that one
byte.
>>
>> This is a known issue. I'm not sure what version of WPP you're
running,
>> but here's a link to the problem description. This issue should be
fixed
>> in the latest version, v3.2:
>> http://www.dtcenter.org/wrf-
nmm/users/model/graphics/WPP/fixes_v3.1.php
>>
>> I also want to let you know about an option in Point-Stat for
customizing
>> output file names. In the Point-Stat config file, look for the
>> "output_prefix" parameter. You can use this to specify a string to
come
>> after the "point_stat_" in the output file names. Also, be aware
that you
>> can specify the "output_prefix" using environment variables. For
example,
>> suppose you set the environment variable "FCST_LEAD = 006" and set:
>> output_prefx = "${FCST_LEAD}";
>>
>> That will cause the Point-Stat output files to be named
>> "point_stat_006_...". You may find using the "output_prefix"
option
>> helpful in customizing your output file names.
>>
>> Let us know if you continue to experience problems.
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>>
>
>
> **********************************************************
> Maciek Kryza
>
> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
> ul. Kosiby 6/8, 51-670 Wroclaw
>
> email: kryzam at meteo.uni.wroc.pl
> **********************************************************
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #38461] point_stat file names
From: kryzam
Time: Fri Jun 11 12:57:06 2010
John,
Thank you very much for your help.
I'm uploading the help.zip file containing wrf model results (wrf*
files),
wpp output (wpp* files), point_stat config file (PointStat_config) and
observation data (EPWR_012008.nc). Please let me know if you can get
the
data.
Best wishes,
Maciek
> Maciek,
>
> Alright, I'm going to have to do some more investigating on this
issue.
> It'd really help to have some of your output data to run with and
test
> here. Could you send me some data for 2 output times,
> one before there are problems and one after you see problems? For
> example, forecast lead times 240 hours and 270 hours.
>
> I'd like to see the following data:
> (1) WRFOUT NetCDF files for those lead times
> (2) GRIB output from the WPP for those lead times
> (3) The Point-Stat configuration file you're using.
> (4) Point observation files you're using to verify that WPP output
for
> those two lead times.
> (5) A description of what the output file names from Point-Stat are
for
> those two lead times.
>
> That'll give me plenty of data to play around with and debug this
issue.
> You can post it to our anonymous ftp site as described below:
>
> ftp ftp.rap.ucar.edu
> username = anonymous
> password = "your email address"
> cd incoming/irap/met_help/kryza_data
> put "your files"
> bye
>
> Please let me know when you've posted the data there, and I'll take
a
> look.
>
> Thanks,
> John
>
> RAL HelpDesk {for kryzam} wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38461 >
>>
>> Dear John,
>> Thank you for quick reply.
>> I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but the
>> problem
>> still exist. I also tried the solution with "output_prefix", adding
date
>> and hour to the output file name. It partly works - the files are
not
>> overwritten, but the observation value for days >Jan 11 in the
output
>> files is always for Jan 1st.
>> Is there any other way to compare model results with observations?
>> Best wishes,
>> Maciek
>>
>>
>>> Maciek,
>>>
>>> I think I have an idea of what's going on here. You've notice a
>>> problem
>>> in the timestamps on day 11 of your 3-hourly output. 11 days is
the
>>> same
>>> as 264 hours. In the GRIB version 1 output of the WRF
PostProcessor
>>> (WPP), there are issues when the time value grows larger than 255.
>>> GRIB
>>> version 1 only provides a single byte for each time value it
stores.
>>> Basically, when the time values exceed 255, WPP overflows that one
>>> byte.
>>>
>>> This is a known issue. I'm not sure what version of WPP you're
>>> running,
>>> but here's a link to the problem description. This issue should
be
>>> fixed
>>> in the latest version, v3.2:
>>> http://www.dtcenter.org/wrf-
nmm/users/model/graphics/WPP/fixes_v3.1.php
>>>
>>> I also want to let you know about an option in Point-Stat for
>>> customizing
>>> output file names. In the Point-Stat config file, look for the
>>> "output_prefix" parameter. You can use this to specify a string
to
>>> come
>>> after the "point_stat_" in the output file names. Also, be aware
that
>>> you
>>> can specify the "output_prefix" using environment variables. For
>>> example,
>>> suppose you set the environment variable "FCST_LEAD = 006" and
set:
>>> output_prefx = "${FCST_LEAD}";
>>>
>>> That will cause the Point-Stat output files to be named
>>> "point_stat_006_...". You may find using the "output_prefix"
option
>>> helpful in customizing your output file names.
>>>
>>> Let us know if you continue to experience problems.
>>>
>>> Thanks,
>>> John Halley Gotway
>>> met_help at ucar.edu
>>>
>>>
>>
>>
>> **********************************************************
>> Maciek Kryza
>>
>> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
>> ul. Kosiby 6/8, 51-670 Wroclaw
>>
>> email: kryzam at meteo.uni.wroc.pl
>> **********************************************************
>
>
**********************************************************
Maciek Kryza
Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
ul. Kosiby 6/8, 51-670 Wroclaw
email: kryzam at meteo.uni.wroc.pl
**********************************************************
------------------------------------------------
Subject: point_stat file names
From: John Halley Gotway
Time: Wed Jun 16 10:26:34 2010
Maciek,
OK, I'm working with the wrf-help support staff to try to figure out
the issues you're having. However, I'm having trouble replicating
exactly the behavior you're seeing.
I'm trying to run your wrfout files through WPP version 3.2. However,
when I compile WPP using the GNU gfortran compiler, I'm only getting
18 output GRIB records instead of the 318 you're getting. And when I
compile WPP using PGI, I'm getting a floating point exception for
dividing by zero.
So frankly, I'm surprised you were able to get WPP to run to complete
for your day 20 file! Can you tell me the environment you're using
for running WRF and WPP? What type of operating system and compilers
(with version numbers) are you using?
Thanks,
John
On Fri Jun 11 12:57:06 2010, kryzam at meteo.uni.wroc.pl wrote:
> John,
> Thank you very much for your help.
> I'm uploading the help.zip file containing wrf model results (wrf*
> files),
> wpp output (wpp* files), point_stat config file (PointStat_config)
and
> observation data (EPWR_012008.nc). Please let me know if you can get
> the
> data.
> Best wishes,
> Maciek
>
> > Maciek,
> >
> > Alright, I'm going to have to do some more investigating on this
> issue.
> > It'd really help to have some of your output data to run with and
> test
> > here. Could you send me some data for 2 output times,
> > one before there are problems and one after you see problems? For
> > example, forecast lead times 240 hours and 270 hours.
> >
> > I'd like to see the following data:
> > (1) WRFOUT NetCDF files for those lead times
> > (2) GRIB output from the WPP for those lead times
> > (3) The Point-Stat configuration file you're using.
> > (4) Point observation files you're using to verify that WPP output
> for
> > those two lead times.
> > (5) A description of what the output file names from Point-Stat
are
> for
> > those two lead times.
> >
> > That'll give me plenty of data to play around with and debug this
> issue.
> > You can post it to our anonymous ftp site as described below:
> >
> > ftp ftp.rap.ucar.edu
> > username = anonymous
> > password = "your email address"
> > cd incoming/irap/met_help/kryza_data
> > put "your files"
> > bye
> >
> > Please let me know when you've posted the data there, and I'll
take
> a
> > look.
> >
> > Thanks,
> > John
> >
> > RAL HelpDesk {for kryzam} wrote:
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38461 >
> >>
> >> Dear John,
> >> Thank you for quick reply.
> >> I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but the
> >> problem
> >> still exist. I also tried the solution with "output_prefix",
adding
> date
> >> and hour to the output file name. It partly works - the files are
> not
> >> overwritten, but the observation value for days >Jan 11 in the
> output
> >> files is always for Jan 1st.
> >> Is there any other way to compare model results with
observations?
> >> Best wishes,
> >> Maciek
> >>
> >>
> >>> Maciek,
> >>>
> >>> I think I have an idea of what's going on here. You've notice a
> >>> problem
> >>> in the timestamps on day 11 of your 3-hourly output. 11 days is
> the
> >>> same
> >>> as 264 hours. In the GRIB version 1 output of the WRF
> PostProcessor
> >>> (WPP), there are issues when the time value grows larger than
255.
> >>> GRIB
> >>> version 1 only provides a single byte for each time value it
> stores.
> >>> Basically, when the time values exceed 255, WPP overflows that
one
> >>> byte.
> >>>
> >>> This is a known issue. I'm not sure what version of WPP you're
> >>> running,
> >>> but here's a link to the problem description. This issue should
> be
> >>> fixed
> >>> in the latest version, v3.2:
> >>> http://www.dtcenter.org/wrf-
> nmm/users/model/graphics/WPP/fixes_v3.1.php
> >>>
> >>> I also want to let you know about an option in Point-Stat for
> >>> customizing
> >>> output file names. In the Point-Stat config file, look for the
> >>> "output_prefix" parameter. You can use this to specify a string
> to
> >>> come
> >>> after the "point_stat_" in the output file names. Also, be
aware
> that
> >>> you
> >>> can specify the "output_prefix" using environment variables.
For
> >>> example,
> >>> suppose you set the environment variable "FCST_LEAD = 006" and
> set:
> >>> output_prefx = "${FCST_LEAD}";
> >>>
> >>> That will cause the Point-Stat output files to be named
> >>> "point_stat_006_...". You may find using the "output_prefix"
> option
> >>> helpful in customizing your output file names.
> >>>
> >>> Let us know if you continue to experience problems.
> >>>
> >>> Thanks,
> >>> John Halley Gotway
> >>> met_help at ucar.edu
> >>>
> >>>
> >>
> >>
> >> **********************************************************
> >> Maciek Kryza
> >>
> >> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
> >> ul. Kosiby 6/8, 51-670 Wroclaw
> >>
> >> email: kryzam at meteo.uni.wroc.pl
> >> **********************************************************
> >
> >
>
>
> **********************************************************
> Maciek Kryza
>
> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
> ul. Kosiby 6/8, 51-670 Wroclaw
>
> email: kryzam at meteo.uni.wroc.pl
> **********************************************************
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #38461] point_stat file names
From: kryzam
Time: Wed Jun 16 13:01:09 2010
John,
Thank you very much for help.
We are using Linux Fedora 12 x-64 system and PGI 10.3 compilers. WPP
is
compiled for PGI - attached is configure.wpp file. Unfortunately, I
don't
have the WPP compile log file - if this can help somehow I can prepare
one.
Best wishes,
Maciek
> Maciek,
>
> OK, I'm working with the wrf-help support staff to try to figure out
the
> issues you're having. However, I'm having trouble replicating
exactly the
> behavior you're seeing.
>
> I'm trying to run your wrfout files through WPP version 3.2.
However,
> when I compile WPP using the GNU gfortran compiler, I'm only getting
18
> output GRIB records instead of the 318 you're getting. And when I
compile
> WPP using PGI, I'm getting a floating point exception for dividing
by
> zero.
>
> So frankly, I'm surprised you were able to get WPP to run to
complete for
> your day 20 file! Can you tell me the environment you're using for
> running WRF and WPP? What type of operating system and compilers
(with
> version numbers) are you using?
>
> Thanks,
> John
>
> On Fri Jun 11 12:57:06 2010, kryzam at meteo.uni.wroc.pl wrote:
>> John,
>> Thank you very much for your help.
>> I'm uploading the help.zip file containing wrf model results (wrf*
>> files),
>> wpp output (wpp* files), point_stat config file (PointStat_config)
and
>> observation data (EPWR_012008.nc). Please let me know if you can
get
>> the
>> data.
>> Best wishes,
>> Maciek
>>
>> > Maciek,
>> >
>> > Alright, I'm going to have to do some more investigating on this
>> issue.
>> > It'd really help to have some of your output data to run with and
>> test
>> > here. Could you send me some data for 2 output times,
>> > one before there are problems and one after you see problems?
For
>> > example, forecast lead times 240 hours and 270 hours.
>> >
>> > I'd like to see the following data:
>> > (1) WRFOUT NetCDF files for those lead times
>> > (2) GRIB output from the WPP for those lead times
>> > (3) The Point-Stat configuration file you're using.
>> > (4) Point observation files you're using to verify that WPP
output
>> for
>> > those two lead times.
>> > (5) A description of what the output file names from Point-Stat
are
>> for
>> > those two lead times.
>> >
>> > That'll give me plenty of data to play around with and debug this
>> issue.
>> > You can post it to our anonymous ftp site as described below:
>> >
>> > ftp ftp.rap.ucar.edu
>> > username = anonymous
>> > password = "your email address"
>> > cd incoming/irap/met_help/kryza_data
>> > put "your files"
>> > bye
>> >
>> > Please let me know when you've posted the data there, and I'll
take
>> a
>> > look.
>> >
>> > Thanks,
>> > John
>> >
>> > RAL HelpDesk {for kryzam} wrote:
>> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38461 >
>> >>
>> >> Dear John,
>> >> Thank you for quick reply.
>> >> I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but
the
>> >> problem
>> >> still exist. I also tried the solution with "output_prefix",
adding
>> date
>> >> and hour to the output file name. It partly works - the files
are
>> not
>> >> overwritten, but the observation value for days >Jan 11 in the
>> output
>> >> files is always for Jan 1st.
>> >> Is there any other way to compare model results with
observations?
>> >> Best wishes,
>> >> Maciek
>> >>
>> >>
>> >>> Maciek,
>> >>>
>> >>> I think I have an idea of what's going on here. You've notice
a
>> >>> problem
>> >>> in the timestamps on day 11 of your 3-hourly output. 11 days
is
>> the
>> >>> same
>> >>> as 264 hours. In the GRIB version 1 output of the WRF
>> PostProcessor
>> >>> (WPP), there are issues when the time value grows larger than
255.
>> >>> GRIB
>> >>> version 1 only provides a single byte for each time value it
>> stores.
>> >>> Basically, when the time values exceed 255, WPP overflows that
one
>> >>> byte.
>> >>>
>> >>> This is a known issue. I'm not sure what version of WPP you're
>> >>> running,
>> >>> but here's a link to the problem description. This issue
should
>> be
>> >>> fixed
>> >>> in the latest version, v3.2:
>> >>> http://www.dtcenter.org/wrf-
>> nmm/users/model/graphics/WPP/fixes_v3.1.php
>> >>>
>> >>> I also want to let you know about an option in Point-Stat for
>> >>> customizing
>> >>> output file names. In the Point-Stat config file, look for the
>> >>> "output_prefix" parameter. You can use this to specify a
string
>> to
>> >>> come
>> >>> after the "point_stat_" in the output file names. Also, be
aware
>> that
>> >>> you
>> >>> can specify the "output_prefix" using environment variables.
For
>> >>> example,
>> >>> suppose you set the environment variable "FCST_LEAD = 006" and
>> set:
>> >>> output_prefx = "${FCST_LEAD}";
>> >>>
>> >>> That will cause the Point-Stat output files to be named
>> >>> "point_stat_006_...". You may find using the "output_prefix"
>> option
>> >>> helpful in customizing your output file names.
>> >>>
>> >>> Let us know if you continue to experience problems.
>> >>>
>> >>> Thanks,
>> >>> John Halley Gotway
>> >>> met_help at ucar.edu
>> >>>
>> >>>
>> >>
>> >>
>> >> **********************************************************
>> >> Maciek Kryza
>> >>
>> >> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
>> >> ul. Kosiby 6/8, 51-670 Wroclaw
>> >>
>> >> email: kryzam at meteo.uni.wroc.pl
>> >> **********************************************************
>> >
>> >
>>
>>
>> **********************************************************
>> Maciek Kryza
>>
>> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
>> ul. Kosiby 6/8, 51-670 Wroclaw
>>
>> email: kryzam at meteo.uni.wroc.pl
>> **********************************************************
>
>
>
>
**********************************************************
Maciek Kryza
Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
ul. Kosiby 6/8, 51-670 Wroclaw
email: kryzam at meteo.uni.wroc.pl
**********************************************************
------------------------------------------------
Subject: point_stat file names
From: John Halley Gotway
Time: Fri Jun 18 15:49:42 2010
Maciek,
I believe I may have found the hole in the logic that's causing the
problem you're seeing. I've worked up a bug fix for WPP that I'm
hoping you can try out. Please place the attached version of GRIBIT.f
into WPPV3/sorc/wrfpost/GRIBIT.f, recompile WPP, and rerun.
Please let me know if that fixes the problem you're seeing. If so,
we'll add the bugfix to the WPP code base.
Thanks,
John
On Wed Jun 16 13:01:09 2010, kryzam at meteo.uni.wroc.pl wrote:
> John,
> Thank you very much for help.
> We are using Linux Fedora 12 x-64 system and PGI 10.3 compilers. WPP
is
> compiled for PGI - attached is configure.wpp file. Unfortunately, I
don't
> have the WPP compile log file - if this can help somehow I can
prepare
> one.
> Best wishes,
> Maciek
>
> > Maciek,
> >
> > OK, I'm working with the wrf-help support staff to try to figure
out the
> > issues you're having. However, I'm having trouble replicating
exactly the
> > behavior you're seeing.
> >
> > I'm trying to run your wrfout files through WPP version 3.2.
However,
> > when I compile WPP using the GNU gfortran compiler, I'm only
getting 18
> > output GRIB records instead of the 318 you're getting. And when I
compile
> > WPP using PGI, I'm getting a floating point exception for dividing
by
> > zero.
> >
> > So frankly, I'm surprised you were able to get WPP to run to
complete for
> > your day 20 file! Can you tell me the environment you're using
for
> > running WRF and WPP? What type of operating system and compilers
(with
> > version numbers) are you using?
> >
> > Thanks,
> > John
> >
> > On Fri Jun 11 12:57:06 2010, kryzam at meteo.uni.wroc.pl wrote:
> >> John,
> >> Thank you very much for your help.
> >> I'm uploading the help.zip file containing wrf model results
(wrf*
> >> files),
> >> wpp output (wpp* files), point_stat config file
(PointStat_config) and
> >> observation data (EPWR_012008.nc). Please let me know if you can
get
> >> the
> >> data.
> >> Best wishes,
> >> Maciek
> >>
> >> > Maciek,
> >> >
> >> > Alright, I'm going to have to do some more investigating on
this
> >> issue.
> >> > It'd really help to have some of your output data to run with
and
> >> test
> >> > here. Could you send me some data for 2 output times,
> >> > one before there are problems and one after you see problems?
For
> >> > example, forecast lead times 240 hours and 270 hours.
> >> >
> >> > I'd like to see the following data:
> >> > (1) WRFOUT NetCDF files for those lead times
> >> > (2) GRIB output from the WPP for those lead times
> >> > (3) The Point-Stat configuration file you're using.
> >> > (4) Point observation files you're using to verify that WPP
output
> >> for
> >> > those two lead times.
> >> > (5) A description of what the output file names from Point-Stat
are
> >> for
> >> > those two lead times.
> >> >
> >> > That'll give me plenty of data to play around with and debug
this
> >> issue.
> >> > You can post it to our anonymous ftp site as described below:
> >> >
> >> > ftp ftp.rap.ucar.edu
> >> > username = anonymous
> >> > password = "your email address"
> >> > cd incoming/irap/met_help/kryza_data
> >> > put "your files"
> >> > bye
> >> >
> >> > Please let me know when you've posted the data there, and I'll
take
> >> a
> >> > look.
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> > RAL HelpDesk {for kryzam} wrote:
> >> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38461
>
> >> >>
> >> >> Dear John,
> >> >> Thank you for quick reply.
> >> >> I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but
the
> >> >> problem
> >> >> still exist. I also tried the solution with "output_prefix",
adding
> >> date
> >> >> and hour to the output file name. It partly works - the files
are
> >> not
> >> >> overwritten, but the observation value for days >Jan 11 in the
> >> output
> >> >> files is always for Jan 1st.
> >> >> Is there any other way to compare model results with
observations?
> >> >> Best wishes,
> >> >> Maciek
> >> >>
> >> >>
> >> >>> Maciek,
> >> >>>
> >> >>> I think I have an idea of what's going on here. You've
notice a
> >> >>> problem
> >> >>> in the timestamps on day 11 of your 3-hourly output. 11 days
is
> >> the
> >> >>> same
> >> >>> as 264 hours. In the GRIB version 1 output of the WRF
> >> PostProcessor
> >> >>> (WPP), there are issues when the time value grows larger than
255.
> >> >>> GRIB
> >> >>> version 1 only provides a single byte for each time value it
> >> stores.
> >> >>> Basically, when the time values exceed 255, WPP overflows
that one
> >> >>> byte.
> >> >>>
> >> >>> This is a known issue. I'm not sure what version of WPP
you're
> >> >>> running,
> >> >>> but here's a link to the problem description. This issue
should
> >> be
> >> >>> fixed
> >> >>> in the latest version, v3.2:
> >> >>> http://www.dtcenter.org/wrf-
> >> nmm/users/model/graphics/WPP/fixes_v3.1.php
> >> >>>
> >> >>> I also want to let you know about an option in Point-Stat for
> >> >>> customizing
> >> >>> output file names. In the Point-Stat config file, look for
the
> >> >>> "output_prefix" parameter. You can use this to specify a
string
> >> to
> >> >>> come
> >> >>> after the "point_stat_" in the output file names. Also, be
aware
> >> that
> >> >>> you
> >> >>> can specify the "output_prefix" using environment variables.
For
> >> >>> example,
> >> >>> suppose you set the environment variable "FCST_LEAD = 006"
and
> >> set:
> >> >>> output_prefx = "${FCST_LEAD}";
> >> >>>
> >> >>> That will cause the Point-Stat output files to be named
> >> >>> "point_stat_006_...". You may find using the "output_prefix"
> >> option
> >> >>> helpful in customizing your output file names.
> >> >>>
> >> >>> Let us know if you continue to experience problems.
> >> >>>
> >> >>> Thanks,
> >> >>> John Halley Gotway
> >> >>> met_help at ucar.edu
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> **********************************************************
> >> >> Maciek Kryza
> >> >>
> >> >> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
> >> >> ul. Kosiby 6/8, 51-670 Wroclaw
> >> >>
> >> >> email: kryzam at meteo.uni.wroc.pl
> >> >> **********************************************************
> >> >
> >> >
> >>
> >>
> >> **********************************************************
> >> Maciek Kryza
> >>
> >> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
> >> ul. Kosiby 6/8, 51-670 Wroclaw
> >>
> >> email: kryzam at meteo.uni.wroc.pl
> >> **********************************************************
> >
> >
> >
> >
>
>
> **********************************************************
> Maciek Kryza
>
> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
> ul. Kosiby 6/8, 51-670 Wroclaw
>
> email: kryzam at meteo.uni.wroc.pl
> **********************************************************
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #38461] point_stat file names
From: kryzam
Time: Mon Jun 21 04:19:03 2010
John,
It works! Thank you very much for help!
Have a good day,
Maciek
> Maciek,
>
> I believe I may have found the hole in the logic that's causing the
> problem you're seeing. I've worked up a bug fix for WPP that I'm
hoping
> you can try out. Please place the attached version of GRIBIT.f into
> WPPV3/sorc/wrfpost/GRIBIT.f, recompile WPP, and rerun.
>
> Please let me know if that fixes the problem you're seeing. If so,
we'll
> add the bugfix to the WPP code base.
>
> Thanks,
> John
>
> On Wed Jun 16 13:01:09 2010, kryzam at meteo.uni.wroc.pl wrote:
>> John,
>> Thank you very much for help.
>> We are using Linux Fedora 12 x-64 system and PGI 10.3 compilers.
WPP is
>> compiled for PGI - attached is configure.wpp file. Unfortunately, I
>> don't
>> have the WPP compile log file - if this can help somehow I can
prepare
>> one.
>> Best wishes,
>> Maciek
>>
>> > Maciek,
>> >
>> > OK, I'm working with the wrf-help support staff to try to figure
out
>> the
>> > issues you're having. However, I'm having trouble replicating
exactly
>> the
>> > behavior you're seeing.
>> >
>> > I'm trying to run your wrfout files through WPP version 3.2.
However,
>> > when I compile WPP using the GNU gfortran compiler, I'm only
getting
>> 18
>> > output GRIB records instead of the 318 you're getting. And when
I
>> compile
>> > WPP using PGI, I'm getting a floating point exception for
dividing by
>> > zero.
>> >
>> > So frankly, I'm surprised you were able to get WPP to run to
complete
>> for
>> > your day 20 file! Can you tell me the environment you're using
for
>> > running WRF and WPP? What type of operating system and compilers
>> (with
>> > version numbers) are you using?
>> >
>> > Thanks,
>> > John
>> >
>> > On Fri Jun 11 12:57:06 2010, kryzam at meteo.uni.wroc.pl wrote:
>> >> John,
>> >> Thank you very much for your help.
>> >> I'm uploading the help.zip file containing wrf model results
(wrf*
>> >> files),
>> >> wpp output (wpp* files), point_stat config file
(PointStat_config)
>> and
>> >> observation data (EPWR_012008.nc). Please let me know if you can
get
>> >> the
>> >> data.
>> >> Best wishes,
>> >> Maciek
>> >>
>> >> > Maciek,
>> >> >
>> >> > Alright, I'm going to have to do some more investigating on
this
>> >> issue.
>> >> > It'd really help to have some of your output data to run with
and
>> >> test
>> >> > here. Could you send me some data for 2 output times,
>> >> > one before there are problems and one after you see problems?
For
>> >> > example, forecast lead times 240 hours and 270 hours.
>> >> >
>> >> > I'd like to see the following data:
>> >> > (1) WRFOUT NetCDF files for those lead times
>> >> > (2) GRIB output from the WPP for those lead times
>> >> > (3) The Point-Stat configuration file you're using.
>> >> > (4) Point observation files you're using to verify that WPP
output
>> >> for
>> >> > those two lead times.
>> >> > (5) A description of what the output file names from Point-
Stat are
>> >> for
>> >> > those two lead times.
>> >> >
>> >> > That'll give me plenty of data to play around with and debug
this
>> >> issue.
>> >> > You can post it to our anonymous ftp site as described below:
>> >> >
>> >> > ftp ftp.rap.ucar.edu
>> >> > username = anonymous
>> >> > password = "your email address"
>> >> > cd incoming/irap/met_help/kryza_data
>> >> > put "your files"
>> >> > bye
>> >> >
>> >> > Please let me know when you've posted the data there, and I'll
take
>> >> a
>> >> > look.
>> >> >
>> >> > Thanks,
>> >> > John
>> >> >
>> >> > RAL HelpDesk {for kryzam} wrote:
>> >> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=38461
>
>> >> >>
>> >> >> Dear John,
>> >> >> Thank you for quick reply.
>> >> >> I recompiled my WPP (v 3.2) with the downloaded GRIBIT.f, but
the
>> >> >> problem
>> >> >> still exist. I also tried the solution with "output_prefix",
>> adding
>> >> date
>> >> >> and hour to the output file name. It partly works - the files
are
>> >> not
>> >> >> overwritten, but the observation value for days >Jan 11 in
the
>> >> output
>> >> >> files is always for Jan 1st.
>> >> >> Is there any other way to compare model results with
observations?
>> >> >> Best wishes,
>> >> >> Maciek
>> >> >>
>> >> >>
>> >> >>> Maciek,
>> >> >>>
>> >> >>> I think I have an idea of what's going on here. You've
notice a
>> >> >>> problem
>> >> >>> in the timestamps on day 11 of your 3-hourly output. 11
days is
>> >> the
>> >> >>> same
>> >> >>> as 264 hours. In the GRIB version 1 output of the WRF
>> >> PostProcessor
>> >> >>> (WPP), there are issues when the time value grows larger
than
>> 255.
>> >> >>> GRIB
>> >> >>> version 1 only provides a single byte for each time value it
>> >> stores.
>> >> >>> Basically, when the time values exceed 255, WPP overflows
that
>> one
>> >> >>> byte.
>> >> >>>
>> >> >>> This is a known issue. I'm not sure what version of WPP
you're
>> >> >>> running,
>> >> >>> but here's a link to the problem description. This issue
should
>> >> be
>> >> >>> fixed
>> >> >>> in the latest version, v3.2:
>> >> >>> http://www.dtcenter.org/wrf-
>> >> nmm/users/model/graphics/WPP/fixes_v3.1.php
>> >> >>>
>> >> >>> I also want to let you know about an option in Point-Stat
for
>> >> >>> customizing
>> >> >>> output file names. In the Point-Stat config file, look for
the
>> >> >>> "output_prefix" parameter. You can use this to specify a
string
>> >> to
>> >> >>> come
>> >> >>> after the "point_stat_" in the output file names. Also, be
aware
>> >> that
>> >> >>> you
>> >> >>> can specify the "output_prefix" using environment variables.
For
>> >> >>> example,
>> >> >>> suppose you set the environment variable "FCST_LEAD = 006"
and
>> >> set:
>> >> >>> output_prefx = "${FCST_LEAD}";
>> >> >>>
>> >> >>> That will cause the Point-Stat output files to be named
>> >> >>> "point_stat_006_...". You may find using the
"output_prefix"
>> >> option
>> >> >>> helpful in customizing your output file names.
>> >> >>>
>> >> >>> Let us know if you continue to experience problems.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> John Halley Gotway
>> >> >>> met_help at ucar.edu
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> **********************************************************
>> >> >> Maciek Kryza
>> >> >>
>> >> >> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
>> >> >> ul. Kosiby 6/8, 51-670 Wroclaw
>> >> >>
>> >> >> email: kryzam at meteo.uni.wroc.pl
>> >> >> **********************************************************
>> >> >
>> >> >
>> >>
>> >>
>> >> **********************************************************
>> >> Maciek Kryza
>> >>
>> >> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
>> >> ul. Kosiby 6/8, 51-670 Wroclaw
>> >>
>> >> email: kryzam at meteo.uni.wroc.pl
>> >> **********************************************************
>> >
>> >
>> >
>> >
>>
>>
>> **********************************************************
>> Maciek Kryza
>>
>> Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
>> ul. Kosiby 6/8, 51-670 Wroclaw
>>
>> email: kryzam at meteo.uni.wroc.pl
>> **********************************************************
>
>
>
>
**********************************************************
Maciek Kryza
Zaklad Meteorologii i Klimatologii, Uniwersytet Wroclawski
ul. Kosiby 6/8, 51-670 Wroclaw
email: kryzam at meteo.uni.wroc.pl
**********************************************************
------------------------------------------------
More information about the Met_help
mailing list