[Met_help] [rt.rap.ucar.edu #47329] History for PointStat problem
RAL HelpDesk {for Paul Oldenburg}
met_help at ucar.edu
Tue Jun 7 09:22:20 MDT 2011
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I'd like to compare my WRF model run with surface meteorological measurements. I got the measurements in the prepbufr format from dss.ucar.edu ds337.0 database, and converted it to the nc filea with pb2nc (see the .nc file attached). The .nc file looks fine, there are the sites that I need (Central Europe) and messages (ADPSFC and ADPUPA). But when I use these .nc files with PointStat tool (config file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0 pairs. Is there anything wrong with config file or .nc data (height/level?). I can work with ADPUPA messsages, using pressure levels e.g. TMP/P1000-500.
I will be greatful for any hints and suggestions.
Best regards,
Maciek Kryza
--
#############################################################
Department of Climatology and Atmosphere Protection
Wroclaw University
ul. Kosiby 6/8
51-670 Poland
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Paul Oldenburg
Time: Mon Jun 06 10:18:35 2011
Maciek,
Can you please send me a sample model data file that you are using? I
would like to reproduce the problem you are
having. If the file is too large to send by email, please upload it
to our FTP site using the following instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
$ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
0, 11, 20, 25389.44, 196.25,
0, 11, 14, -9999, 196.25,
240, 11, 20, 25309.47, 197.45,
240, 11, 16, -9999, 197.65,
240, 11, 10, 29397.77, 206.05,
242, 11, 20, 25030.66, 192.85,
244, 11, 20, 25241.41, 196.65,
244, 11, 10, 29236.89, 201.85,
To see the accompanying message type, I use commands like this (ADPUPA
= upper air, ADPSFC = surface):
$ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
"ADPUPA", # 0
"ADPUPA", # 1
"ADPUPA", # 2
"ADPUPA", # 3
"ADPUPA", # 4
$ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
...
"ADPSFC", # 237
"ADPSFC", # 238
"ADPSFC", # 239
"ADPUPA", # 240
"ADPUPA", # 241
"ADPUPA", # 242
"ADPUPA", # 243
"ADPUPA", # 244
I also tried another approach to looking at surface TMP observations
in the NetCDF, using the plot_point_obs tool that
is included with METv3.0 and above. If you did not build this tool,
edit your MET Makefile to compile the tools:
DISABLE_TOOLS = 0
Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
$ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
Paul
On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
> Queue: met_help
> Subject: PointStat problem
> Owner: Nobody
> Requestors: maciej.kryza at uni.wroc.pl
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
>
> Hi,
> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
> I will be greatful for any hints and suggestions.
> Best regards,
> Maciek Kryza
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Maciej Kryza
Time: Mon Jun 06 11:34:22 2011
Paul,
Thank you very much for quick reply. I've just started uploading the
WRF file to the ftp server.
I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP measurements at 2m). However, it seems that most of
them have obs_arr:hgt value at -9999. Is it ok when maching Z2 values?
I forgot to add - I use MET 3.0
Best wishes,
Maciek
----- Oryginalna wiadomość -----
Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
Maciek,
Can you please send me a sample model data file that you are using? I
would like to reproduce the problem you are
having. If the file is too large to send by email, please upload it
to our FTP site using the following instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
$ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
0, 11, 20, 25389.44, 196.25,
0, 11, 14, -9999, 196.25,
240, 11, 20, 25309.47, 197.45,
240, 11, 16, -9999, 197.65,
240, 11, 10, 29397.77, 206.05,
242, 11, 20, 25030.66, 192.85,
244, 11, 20, 25241.41, 196.65,
244, 11, 10, 29236.89, 201.85,
To see the accompanying message type, I use commands like this (ADPUPA
= upper air, ADPSFC = surface):
$ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
"ADPUPA", # 0
"ADPUPA", # 1
"ADPUPA", # 2
"ADPUPA", # 3
"ADPUPA", # 4
$ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
...
"ADPSFC", # 237
"ADPSFC", # 238
"ADPSFC", # 239
"ADPUPA", # 240
"ADPUPA", # 241
"ADPUPA", # 242
"ADPUPA", # 243
"ADPUPA", # 244
I also tried another approach to looking at surface TMP observations
in the NetCDF, using the plot_point_obs tool that
is included with METv3.0 and above. If you did not build this tool,
edit your MET Makefile to compile the tools:
DISABLE_TOOLS = 0
Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
$ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
Paul
On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
> Queue: met_help
> Subject: PointStat problem
> Owner: Nobody
> Requestors: maciej.kryza at uni.wroc.pl
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
>
> Hi,
> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
> I will be greatful for any hints and suggestions.
> Best regards,
> Maciek Kryza
>
>
--
#############################################################
Department of Climatology and Atmosphere Protection
Wroclaw University
ul. Kosiby 6/8
51-670 Poland
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Paul Oldenburg
Time: Mon Jun 06 12:53:04 2011
Maciek,
I am not able to read the data in the zipped file you sent,
wrfout_d03_2010-01-24_00:00:00. Does it contain GRIB data
which is the output of the WRF post processor, WPP? If not, what
format is it in? If so, can you try to gzip the file
instead? Perhaps we have different verions of zip and that is causing
corruption.
Regarding your point_stat config file, PointStat_configWIOS2010, one
possible problem that I notice is the following
setting:
beg_ds = 0;
end_ds = 0;
The observation file that you sent me contains data for a wide range
of times, from 20100123_223000 to 20100124_193000.
I would suggest opening your time window to this to see if you get a
match in point_stat:
beg_ds = -5400;
end_ds = 70200;
This will match all valid times in the observation file.
Another suggestion that I have is to use the following option with
point_stat: -v 3. This will set the verbosity level
so that point_stat prints out a report of reasons why it rejected obs
points based on criteria. You can often find
problems this way. Please let me know if you have any questions.
Paul
On 06/06/2011 11:34 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
> Paul,
> Thank you very much for quick reply. I've just started uploading the
WRF file to the ftp server.
> I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP measurements at 2m). However, it seems that most of
them have obs_arr:hgt value at -9999. Is it ok when maching Z2 values?
> I forgot to add - I use MET 3.0
> Best wishes,
> Maciek
>
>
> ----- Oryginalna wiadomość -----
> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
> Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>
> Maciek,
>
> Can you please send me a sample model data file that you are using?
I would like to reproduce the problem you are
> having. If the file is too large to send by email, please upload it
to our FTP site using the following instructions:
>
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
> recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
>
> $ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
> 0, 11, 20, 25389.44, 196.25,
> 0, 11, 14, -9999, 196.25,
> 240, 11, 20, 25309.47, 197.45,
> 240, 11, 16, -9999, 197.65,
> 240, 11, 10, 29397.77, 206.05,
> 242, 11, 20, 25030.66, 192.85,
> 244, 11, 20, 25241.41, 196.65,
> 244, 11, 10, 29236.89, 201.85,
>
> To see the accompanying message type, I use commands like this
(ADPUPA = upper air, ADPSFC = surface):
>
> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
> "ADPUPA", # 0
> "ADPUPA", # 1
> "ADPUPA", # 2
> "ADPUPA", # 3
> "ADPUPA", # 4
>
> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
> ...
> "ADPSFC", # 237
> "ADPSFC", # 238
> "ADPSFC", # 239
> "ADPUPA", # 240
> "ADPUPA", # 241
> "ADPUPA", # 242
> "ADPUPA", # 243
> "ADPUPA", # 244
>
> I also tried another approach to looking at surface TMP observations
in the NetCDF, using the plot_point_obs tool that
> is included with METv3.0 and above. If you did not build this tool,
edit your MET Makefile to compile the tools:
>
> DISABLE_TOOLS = 0
>
> Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
> done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
>
> $ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
>
> Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
> to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
>
> Paul
>
>
>
> On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>
>> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
>> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
>> Queue: met_help
>> Subject: PointStat problem
>> Owner: Nobody
>> Requestors: maciej.kryza at uni.wroc.pl
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>
>>
>> Hi,
>> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
>> I will be greatful for any hints and suggestions.
>> Best regards,
>> Maciek Kryza
>>
>>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Maciej Kryza
Time: Mon Jun 06 13:39:20 2011
Paul,
Thank you very much for all suggestions. The .gz file should be on the
server in a minute. This is regural wrf output file in netcdf format,
that should go through wpp postprocessor.
I use -v 3 (some time ago I recieved this tip fro you or someone else
from met_help), the output is:
wpp file: wpp_post/wpp_d03_2010-01-24_00:00:00
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=18446744073523752013
Forecast File: wpp_post/wpp_d03_2010-01-24_00:00:00
Climatology File: none
Configuration File: PointStat_configWIOS2010
Observation File:
/opt/macierz/wrfdata/wrf_verif/pb2nc_test/PLncdf_2010/PLsyn_20100124.nc
--------------------------------------------------------------------------------
Reading records for TMP/Z2.
GRIB Record 247: Init = 20100120_000000, Valid = 20100124_000000,
Accum = 000000, Min = 250.589, Max = 268.968
For TMP/Z2 found 1 forecast levels and 0 climatology levels.
--------------------------------------------------------------------------------
Searching 2048 observations from 488 PrepBufr messages.
--------------------------------------------------------------------------------
Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC, over
region FULL, for interpolation method UW_MEAN(1), using 0 pairs.
Number of matched pairs = 0
Observations processed = 2048
Rejected: GRIB code = 1784
Rejected: valid time = 130
Rejected: bad obs value = 0
Rejected: off the grid = 89
Rejected: level mismatch = 45
Rejected: message type = 0
Rejected: masking region = 0
Rejected: bad fcst value = 0
I can understand all reasons for rejections except the level mismatch.
As I said, these are all surface measurements gathered at 2m or 10m
(for wind), except for ADPUPA, but above I asked for ADPSFC messages.
Best wishes,
Maciek
----- Oryginalna wiadomość -----
Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
Wysłane: poniedziałek, 6 czerwiec 2011 20:53:05
Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
Maciek,
I am not able to read the data in the zipped file you sent,
wrfout_d03_2010-01-24_00:00:00. Does it contain GRIB data
which is the output of the WRF post processor, WPP? If not, what
format is it in? If so, can you try to gzip the file
instead? Perhaps we have different verions of zip and that is causing
corruption.
Regarding your point_stat config file, PointStat_configWIOS2010, one
possible problem that I notice is the following
setting:
beg_ds = 0;
end_ds = 0;
The observation file that you sent me contains data for a wide range
of times, from 20100123_223000 to 20100124_193000.
I would suggest opening your time window to this to see if you get a
match in point_stat:
beg_ds = -5400;
end_ds = 70200;
This will match all valid times in the observation file.
Another suggestion that I have is to use the following option with
point_stat: -v 3. This will set the verbosity level
so that point_stat prints out a report of reasons why it rejected obs
points based on criteria. You can often find
problems this way. Please let me know if you have any questions.
Paul
On 06/06/2011 11:34 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
> Paul,
> Thank you very much for quick reply. I've just started uploading the
WRF file to the ftp server.
> I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP measurements at 2m). However, it seems that most of
them have obs_arr:hgt value at -9999. Is it ok when maching Z2 values?
> I forgot to add - I use MET 3.0
> Best wishes,
> Maciek
>
>
> ----- Oryginalna wiadomość -----
> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
> Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>
> Maciek,
>
> Can you please send me a sample model data file that you are using?
I would like to reproduce the problem you are
> having. If the file is too large to send by email, please upload it
to our FTP site using the following instructions:
>
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
> recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
>
> $ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
> 0, 11, 20, 25389.44, 196.25,
> 0, 11, 14, -9999, 196.25,
> 240, 11, 20, 25309.47, 197.45,
> 240, 11, 16, -9999, 197.65,
> 240, 11, 10, 29397.77, 206.05,
> 242, 11, 20, 25030.66, 192.85,
> 244, 11, 20, 25241.41, 196.65,
> 244, 11, 10, 29236.89, 201.85,
>
> To see the accompanying message type, I use commands like this
(ADPUPA = upper air, ADPSFC = surface):
>
> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
> "ADPUPA", # 0
> "ADPUPA", # 1
> "ADPUPA", # 2
> "ADPUPA", # 3
> "ADPUPA", # 4
>
> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
> ...
> "ADPSFC", # 237
> "ADPSFC", # 238
> "ADPSFC", # 239
> "ADPUPA", # 240
> "ADPUPA", # 241
> "ADPUPA", # 242
> "ADPUPA", # 243
> "ADPUPA", # 244
>
> I also tried another approach to looking at surface TMP observations
in the NetCDF, using the plot_point_obs tool that
> is included with METv3.0 and above. If you did not build this tool,
edit your MET Makefile to compile the tools:
>
> DISABLE_TOOLS = 0
>
> Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
> done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
>
> $ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
>
> Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
> to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
>
> Paul
>
>
>
> On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>
>> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
>> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
>> Queue: met_help
>> Subject: PointStat problem
>> Owner: Nobody
>> Requestors: maciej.kryza at uni.wroc.pl
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>
>>
>> Hi,
>> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
>> I will be greatful for any hints and suggestions.
>> Best regards,
>> Maciek Kryza
>>
>>
>
>
>
--
#############################################################
Department of Climatology and Atmosphere Protection
Wroclaw University
ul. Kosiby 6/8
51-670 Poland
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Paul Oldenburg
Time: Mon Jun 06 13:56:02 2011
Maciek,
I get the following error when I try to unzip your latest data file:
$ gunzip wrfdata.gz
gzip: wrfdata.gz: unexpected end of file
I like to use the following command to tar and gzip files like this:
$ tar czvf wrfdata.tar.gz wpp_d03_2010-01-24_00:00:00
Maybe try to do that and then upload to the FTP site. Sorry for the
trouble.
Thanks,
Paul
On 06/06/2011 01:39 PM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
> Paul,
> Thank you very much for all suggestions. The .gz file should be on
the server in a minute. This is regural wrf output file in netcdf
format, that should go through wpp postprocessor.
> I use -v 3 (some time ago I recieved this tip fro you or someone
else from met_help), the output is:
> wpp file: wpp_post/wpp_d03_2010-01-24_00:00:00
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=18446744073523752013
> Forecast File: wpp_post/wpp_d03_2010-01-24_00:00:00
> Climatology File: none
> Configuration File: PointStat_configWIOS2010
> Observation File:
/opt/macierz/wrfdata/wrf_verif/pb2nc_test/PLncdf_2010/PLsyn_20100124.nc
>
>
--------------------------------------------------------------------------------
>
> Reading records for TMP/Z2.
> GRIB Record 247: Init = 20100120_000000, Valid = 20100124_000000,
Accum = 000000, Min = 250.589, Max = 268.968
> For TMP/Z2 found 1 forecast levels and 0 climatology levels.
>
>
--------------------------------------------------------------------------------
>
> Searching 2048 observations from 488 PrepBufr messages.
>
>
--------------------------------------------------------------------------------
>
> Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC, over
region FULL, for interpolation method UW_MEAN(1), using 0 pairs.
> Number of matched pairs = 0
> Observations processed = 2048
> Rejected: GRIB code = 1784
> Rejected: valid time = 130
> Rejected: bad obs value = 0
> Rejected: off the grid = 89
> Rejected: level mismatch = 45
> Rejected: message type = 0
> Rejected: masking region = 0
> Rejected: bad fcst value = 0
>
> I can understand all reasons for rejections except the level
mismatch. As I said, these are all surface measurements gathered at 2m
or 10m (for wind), except for ADPUPA, but above I asked for ADPSFC
messages.
> Best wishes,
> Maciek
>
> ----- Oryginalna wiadomość -----
> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
> Wysłane: poniedziałek, 6 czerwiec 2011 20:53:05
> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>
> Maciek,
>
> I am not able to read the data in the zipped file you sent,
wrfout_d03_2010-01-24_00:00:00. Does it contain GRIB data
> which is the output of the WRF post processor, WPP? If not, what
format is it in? If so, can you try to gzip the file
> instead? Perhaps we have different verions of zip and that is
causing corruption.
>
> Regarding your point_stat config file, PointStat_configWIOS2010, one
possible problem that I notice is the following
> setting:
>
> beg_ds = 0;
> end_ds = 0;
>
> The observation file that you sent me contains data for a wide range
of times, from 20100123_223000 to 20100124_193000.
> I would suggest opening your time window to this to see if you get
a match in point_stat:
>
> beg_ds = -5400;
> end_ds = 70200;
>
> This will match all valid times in the observation file.
>
> Another suggestion that I have is to use the following option with
point_stat: -v 3. This will set the verbosity level
> so that point_stat prints out a report of reasons why it rejected
obs points based on criteria. You can often find
> problems this way. Please let me know if you have any questions.
>
> Paul
>
>
> On 06/06/2011 11:34 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>
>> Paul,
>> Thank you very much for quick reply. I've just started uploading
the WRF file to the ftp server.
>> I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP measurements at 2m). However, it seems that most of
them have obs_arr:hgt value at -9999. Is it ok when maching Z2 values?
>> I forgot to add - I use MET 3.0
>> Best wishes,
>> Maciek
>>
>>
>> ----- Oryginalna wiadomość -----
>> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
>> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
>> Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
>> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>>
>> Maciek,
>>
>> Can you please send me a sample model data file that you are using?
I would like to reproduce the problem you are
>> having. If the file is too large to send by email, please upload
it to our FTP site using the following instructions:
>>
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
>> recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
>>
>> $ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
>> 0, 11, 20, 25389.44, 196.25,
>> 0, 11, 14, -9999, 196.25,
>> 240, 11, 20, 25309.47, 197.45,
>> 240, 11, 16, -9999, 197.65,
>> 240, 11, 10, 29397.77, 206.05,
>> 242, 11, 20, 25030.66, 192.85,
>> 244, 11, 20, 25241.41, 196.65,
>> 244, 11, 10, 29236.89, 201.85,
>>
>> To see the accompanying message type, I use commands like this
(ADPUPA = upper air, ADPSFC = surface):
>>
>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
>> "ADPUPA", # 0
>> "ADPUPA", # 1
>> "ADPUPA", # 2
>> "ADPUPA", # 3
>> "ADPUPA", # 4
>>
>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
>> ...
>> "ADPSFC", # 237
>> "ADPSFC", # 238
>> "ADPSFC", # 239
>> "ADPUPA", # 240
>> "ADPUPA", # 241
>> "ADPUPA", # 242
>> "ADPUPA", # 243
>> "ADPUPA", # 244
>>
>> I also tried another approach to looking at surface TMP
observations in the NetCDF, using the plot_point_obs tool that
>> is included with METv3.0 and above. If you did not build this
tool, edit your MET Makefile to compile the tools:
>>
>> DISABLE_TOOLS = 0
>>
>> Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
>> done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
>>
>> $ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
>>
>> Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
>> to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
>>
>> Paul
>>
>>
>>
>> On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>>
>>> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
>>> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
>>> Queue: met_help
>>> Subject: PointStat problem
>>> Owner: Nobody
>>> Requestors: maciej.kryza at uni.wroc.pl
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>>
>>>
>>> Hi,
>>> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
>>> I will be greatful for any hints and suggestions.
>>> Best regards,
>>> Maciek Kryza
>>>
>>>
>>
>>
>>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Maciej Kryza
Time: Mon Jun 06 23:40:14 2011
Paul,
I did tar czvf for the wpp file - it should be ready now at the ftp
server.
I changed the time window - it doesn't help.
Best wishes,
Maciek
----- Oryginalna wiadomość -----
Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
Wysłane: poniedziałek, 6 czerwiec 2011 21:56:03
Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
Maciek,
I get the following error when I try to unzip your latest data file:
$ gunzip wrfdata.gz
gzip: wrfdata.gz: unexpected end of file
I like to use the following command to tar and gzip files like this:
$ tar czvf wrfdata.tar.gz wpp_d03_2010-01-24_00:00:00
Maybe try to do that and then upload to the FTP site. Sorry for the
trouble.
Thanks,
Paul
On 06/06/2011 01:39 PM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
> Paul,
> Thank you very much for all suggestions. The .gz file should be on
the server in a minute. This is regural wrf output file in netcdf
format, that should go through wpp postprocessor.
> I use -v 3 (some time ago I recieved this tip fro you or someone
else from met_help), the output is:
> wpp file: wpp_post/wpp_d03_2010-01-24_00:00:00
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=18446744073523752013
> Forecast File: wpp_post/wpp_d03_2010-01-24_00:00:00
> Climatology File: none
> Configuration File: PointStat_configWIOS2010
> Observation File:
/opt/macierz/wrfdata/wrf_verif/pb2nc_test/PLncdf_2010/PLsyn_20100124.nc
>
>
--------------------------------------------------------------------------------
>
> Reading records for TMP/Z2.
> GRIB Record 247: Init = 20100120_000000, Valid = 20100124_000000,
Accum = 000000, Min = 250.589, Max = 268.968
> For TMP/Z2 found 1 forecast levels and 0 climatology levels.
>
>
--------------------------------------------------------------------------------
>
> Searching 2048 observations from 488 PrepBufr messages.
>
>
--------------------------------------------------------------------------------
>
> Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC, over
region FULL, for interpolation method UW_MEAN(1), using 0 pairs.
> Number of matched pairs = 0
> Observations processed = 2048
> Rejected: GRIB code = 1784
> Rejected: valid time = 130
> Rejected: bad obs value = 0
> Rejected: off the grid = 89
> Rejected: level mismatch = 45
> Rejected: message type = 0
> Rejected: masking region = 0
> Rejected: bad fcst value = 0
>
> I can understand all reasons for rejections except the level
mismatch. As I said, these are all surface measurements gathered at 2m
or 10m (for wind), except for ADPUPA, but above I asked for ADPSFC
messages.
> Best wishes,
> Maciek
>
> ----- Oryginalna wiadomość -----
> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
> Wysłane: poniedziałek, 6 czerwiec 2011 20:53:05
> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>
> Maciek,
>
> I am not able to read the data in the zipped file you sent,
wrfout_d03_2010-01-24_00:00:00. Does it contain GRIB data
> which is the output of the WRF post processor, WPP? If not, what
format is it in? If so, can you try to gzip the file
> instead? Perhaps we have different verions of zip and that is
causing corruption.
>
> Regarding your point_stat config file, PointStat_configWIOS2010, one
possible problem that I notice is the following
> setting:
>
> beg_ds = 0;
> end_ds = 0;
>
> The observation file that you sent me contains data for a wide range
of times, from 20100123_223000 to 20100124_193000.
> I would suggest opening your time window to this to see if you get
a match in point_stat:
>
> beg_ds = -5400;
> end_ds = 70200;
>
> This will match all valid times in the observation file.
>
> Another suggestion that I have is to use the following option with
point_stat: -v 3. This will set the verbosity level
> so that point_stat prints out a report of reasons why it rejected
obs points based on criteria. You can often find
> problems this way. Please let me know if you have any questions.
>
> Paul
>
>
> On 06/06/2011 11:34 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>
>> Paul,
>> Thank you very much for quick reply. I've just started uploading
the WRF file to the ftp server.
>> I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP measurements at 2m). However, it seems that most of
them have obs_arr:hgt value at -9999. Is it ok when maching Z2 values?
>> I forgot to add - I use MET 3.0
>> Best wishes,
>> Maciek
>>
>>
>> ----- Oryginalna wiadomość -----
>> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
>> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
>> Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
>> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>>
>> Maciek,
>>
>> Can you please send me a sample model data file that you are using?
I would like to reproduce the problem you are
>> having. If the file is too large to send by email, please upload
it to our FTP site using the following instructions:
>>
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
>> recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
>>
>> $ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
>> 0, 11, 20, 25389.44, 196.25,
>> 0, 11, 14, -9999, 196.25,
>> 240, 11, 20, 25309.47, 197.45,
>> 240, 11, 16, -9999, 197.65,
>> 240, 11, 10, 29397.77, 206.05,
>> 242, 11, 20, 25030.66, 192.85,
>> 244, 11, 20, 25241.41, 196.65,
>> 244, 11, 10, 29236.89, 201.85,
>>
>> To see the accompanying message type, I use commands like this
(ADPUPA = upper air, ADPSFC = surface):
>>
>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
>> "ADPUPA", # 0
>> "ADPUPA", # 1
>> "ADPUPA", # 2
>> "ADPUPA", # 3
>> "ADPUPA", # 4
>>
>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
>> ...
>> "ADPSFC", # 237
>> "ADPSFC", # 238
>> "ADPSFC", # 239
>> "ADPUPA", # 240
>> "ADPUPA", # 241
>> "ADPUPA", # 242
>> "ADPUPA", # 243
>> "ADPUPA", # 244
>>
>> I also tried another approach to looking at surface TMP
observations in the NetCDF, using the plot_point_obs tool that
>> is included with METv3.0 and above. If you did not build this
tool, edit your MET Makefile to compile the tools:
>>
>> DISABLE_TOOLS = 0
>>
>> Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
>> done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
>>
>> $ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
>>
>> Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
>> to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
>>
>> Paul
>>
>>
>>
>> On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>>
>>> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
>>> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
>>> Queue: met_help
>>> Subject: PointStat problem
>>> Owner: Nobody
>>> Requestors: maciej.kryza at uni.wroc.pl
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>>
>>>
>>> Hi,
>>> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
>>> I will be greatful for any hints and suggestions.
>>> Best regards,
>>> Maciek Kryza
>>>
>>>
>>
>>
>>
>
>
>
--
#############################################################
Department of Climatology and Atmosphere Protection
Wroclaw University
ul. Kosiby 6/8
51-670 Poland
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Maciej Kryza
Time: Tue Jun 07 03:28:30 2011
Paul,
It seems that the "problem" is solved now - default
quality_mark_thresh=2 for pb2nc was too much for these stations. I'm
sorry for these, I should be more cerful with the data before taking
your time.
Thanks for help,
Maciek
----- Oryginalna wiadomość -----
Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
Wysłane: poniedziałek, 6 czerwiec 2011 21:56:03
Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
Maciek,
I get the following error when I try to unzip your latest data file:
$ gunzip wrfdata.gz
gzip: wrfdata.gz: unexpected end of file
I like to use the following command to tar and gzip files like this:
$ tar czvf wrfdata.tar.gz wpp_d03_2010-01-24_00:00:00
Maybe try to do that and then upload to the FTP site. Sorry for the
trouble.
Thanks,
Paul
On 06/06/2011 01:39 PM, RAL HelpDesk {for Maciej Kryza} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
> Paul,
> Thank you very much for all suggestions. The .gz file should be on
the server in a minute. This is regural wrf output file in netcdf
format, that should go through wpp postprocessor.
> I use -v 3 (some time ago I recieved this tip fro you or someone
else from met_help), the output is:
> wpp file: wpp_post/wpp_d03_2010-01-24_00:00:00
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=18446744073523752013
> Forecast File: wpp_post/wpp_d03_2010-01-24_00:00:00
> Climatology File: none
> Configuration File: PointStat_configWIOS2010
> Observation File:
/opt/macierz/wrfdata/wrf_verif/pb2nc_test/PLncdf_2010/PLsyn_20100124.nc
>
>
--------------------------------------------------------------------------------
>
> Reading records for TMP/Z2.
> GRIB Record 247: Init = 20100120_000000, Valid = 20100124_000000,
Accum = 000000, Min = 250.589, Max = 268.968
> For TMP/Z2 found 1 forecast levels and 0 climatology levels.
>
>
--------------------------------------------------------------------------------
>
> Searching 2048 observations from 488 PrepBufr messages.
>
>
--------------------------------------------------------------------------------
>
> Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC, over
region FULL, for interpolation method UW_MEAN(1), using 0 pairs.
> Number of matched pairs = 0
> Observations processed = 2048
> Rejected: GRIB code = 1784
> Rejected: valid time = 130
> Rejected: bad obs value = 0
> Rejected: off the grid = 89
> Rejected: level mismatch = 45
> Rejected: message type = 0
> Rejected: masking region = 0
> Rejected: bad fcst value = 0
>
> I can understand all reasons for rejections except the level
mismatch. As I said, these are all surface measurements gathered at 2m
or 10m (for wind), except for ADPUPA, but above I asked for ADPSFC
messages.
> Best wishes,
> Maciek
>
> ----- Oryginalna wiadomość -----
> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
> Wysłane: poniedziałek, 6 czerwiec 2011 20:53:05
> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>
> Maciek,
>
> I am not able to read the data in the zipped file you sent,
wrfout_d03_2010-01-24_00:00:00. Does it contain GRIB data
> which is the output of the WRF post processor, WPP? If not, what
format is it in? If so, can you try to gzip the file
> instead? Perhaps we have different verions of zip and that is
causing corruption.
>
> Regarding your point_stat config file, PointStat_configWIOS2010, one
possible problem that I notice is the following
> setting:
>
> beg_ds = 0;
> end_ds = 0;
>
> The observation file that you sent me contains data for a wide range
of times, from 20100123_223000 to 20100124_193000.
> I would suggest opening your time window to this to see if you get
a match in point_stat:
>
> beg_ds = -5400;
> end_ds = 70200;
>
> This will match all valid times in the observation file.
>
> Another suggestion that I have is to use the following option with
point_stat: -v 3. This will set the verbosity level
> so that point_stat prints out a report of reasons why it rejected
obs points based on criteria. You can often find
> problems this way. Please let me know if you have any questions.
>
> Paul
>
>
> On 06/06/2011 11:34 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>
>> Paul,
>> Thank you very much for quick reply. I've just started uploading
the WRF file to the ftp server.
>> I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP measurements at 2m). However, it seems that most of
them have obs_arr:hgt value at -9999. Is it ok when maching Z2 values?
>> I forgot to add - I use MET 3.0
>> Best wishes,
>> Maciek
>>
>>
>> ----- Oryginalna wiadomość -----
>> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
>> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
>> Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
>> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>>
>> Maciek,
>>
>> Can you please send me a sample model data file that you are using?
I would like to reproduce the problem you are
>> having. If the file is too large to send by email, please upload
it to our FTP site using the following instructions:
>>
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have access to this utility, I
>> recommend that you establish it on your system. I think that there
may not be many surface TMP observations:
>>
>> $ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
>> 0, 11, 20, 25389.44, 196.25,
>> 0, 11, 14, -9999, 196.25,
>> 240, 11, 20, 25309.47, 197.45,
>> 240, 11, 16, -9999, 197.65,
>> 240, 11, 10, 29397.77, 206.05,
>> 242, 11, 20, 25030.66, 192.85,
>> 244, 11, 20, 25241.41, 196.65,
>> 244, 11, 10, 29236.89, 201.85,
>>
>> To see the accompanying message type, I use commands like this
(ADPUPA = upper air, ADPSFC = surface):
>>
>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
>> "ADPUPA", # 0
>> "ADPUPA", # 1
>> "ADPUPA", # 2
>> "ADPUPA", # 3
>> "ADPUPA", # 4
>>
>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
>> ...
>> "ADPSFC", # 237
>> "ADPSFC", # 238
>> "ADPSFC", # 239
>> "ADPUPA", # 240
>> "ADPUPA", # 241
>> "ADPUPA", # 242
>> "ADPUPA", # 243
>> "ADPUPA", # 244
>>
>> I also tried another approach to looking at surface TMP
observations in the NetCDF, using the plot_point_obs tool that
>> is included with METv3.0 and above. If you did not build this
tool, edit your MET Makefile to compile the tools:
>>
>> DISABLE_TOOLS = 0
>>
>> Then, run make from the top-level MET folder and it should make the
plot_point_obs tool, among others. When this is
>> done, you can use this tool like this to plot all the surface TMP
observations in the input NetCDF file:
>>
>> $ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11 -msg_typ
ADPSFC
>>
>> Using this approach, I see that there is a single TMP surface
observation. When I get your model data, I will attempt
>> to match this point in point_obs and let you know how it was done.
Please let me know if you have any questions.
>>
>> Paul
>>
>>
>>
>> On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>>
>>> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
>>> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
>>> Queue: met_help
>>> Subject: PointStat problem
>>> Owner: Nobody
>>> Requestors: maciej.kryza at uni.wroc.pl
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>>
>>>
>>> Hi,
>>> I'd like to compare my WRF model run with surface meteorological
measurements. I got the measurements in the prepbufr format from
dss.ucar.edu ds337.0 database, and converted it to the nc filea with
pb2nc (see the .nc file attached). The .nc file looks fine, there are
the sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc files with PointStat tool (config
file attached) for TMP/Z2, WIND/Z10 or any other surface data, I get 0
pairs. Is there anything wrong with config file or .nc data
(height/level?). I can work with ADPUPA messsages, using pressure
levels e.g. TMP/P1000-500.
>>> I will be greatful for any hints and suggestions.
>>> Best regards,
>>> Maciek Kryza
>>>
>>>
>>
>>
>>
>
>
>
--
#############################################################
Department of Climatology and Atmosphere Protection
Wroclaw University
ul. Kosiby 6/8
51-670 Poland
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #47329] PointStat problem
From: Paul Oldenburg
Time: Tue Jun 07 06:37:54 2011
Maciek,
I should have thought of the quality_mark_thresh for pb2nc earlier,
although I did see that there
was one TMP point that was present in the output you originally sent.
I was puzzled why that 1
point would not match. I'm glad to hear you solved the problem.
Paul
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>
> Paul,
> It seems that the "problem" is solved now - default
quality_mark_thresh=2 for pb2nc was too much
> for these stations. I'm sorry for these, I should be more cerful
with the data before taking your
> time.
> Thanks for help,
> Maciek
>
> ----- Oryginalna wiadomość -----
> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
> Wysłane: poniedziałek, 6 czerwiec 2011 21:56:03
> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>
> Maciek,
>
> I get the following error when I try to unzip your latest data file:
>
> $ gunzip wrfdata.gz
>
> gzip: wrfdata.gz: unexpected end of file
>
> I like to use the following command to tar and gzip files like this:
>
> $ tar czvf wrfdata.tar.gz wpp_d03_2010-01-24_00:00:00
>
> Maybe try to do that and then upload to the FTP site. Sorry for the
trouble.
>
> Thanks,
>
> Paul
>
>
>
> On 06/06/2011 01:39 PM, RAL HelpDesk {for Maciej Kryza} wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>
>> Paul,
>> Thank you very much for all suggestions. The .gz file should be on
the server in a minute. This
>> is regural wrf output file in netcdf format, that should go through
wpp postprocessor.
>> I use -v 3 (some time ago I recieved this tip fro you or someone
else from met_help), the output
>> is:
>> wpp file: wpp_post/wpp_d03_2010-01-24_00:00:00
>> GSL_RNG_TYPE=mt19937
>> GSL_RNG_SEED=18446744073523752013
>> Forecast File: wpp_post/wpp_d03_2010-01-24_00:00:00
>> Climatology File: none
>> Configuration File: PointStat_configWIOS2010
>> Observation File:
/opt/macierz/wrfdata/wrf_verif/pb2nc_test/PLncdf_2010/PLsyn_20100124.nc
>>
>>
--------------------------------------------------------------------------------
>>
>> Reading records for TMP/Z2.
>> GRIB Record 247: Init = 20100120_000000, Valid = 20100124_000000,
Accum = 000000, Min = 250.589,
>> Max = 268.968
>> For TMP/Z2 found 1 forecast levels and 0 climatology levels.
>>
>>
--------------------------------------------------------------------------------
>>
>> Searching 2048 observations from 488 PrepBufr messages.
>>
>>
--------------------------------------------------------------------------------
>>
>> Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC, over
region FULL, for
>> interpolation method UW_MEAN(1), using 0 pairs.
>> Number of matched pairs = 0
>> Observations processed = 2048
>> Rejected: GRIB code = 1784
>> Rejected: valid time = 130
>> Rejected: bad obs value = 0
>> Rejected: off the grid = 89
>> Rejected: level mismatch = 45
>> Rejected: message type = 0
>> Rejected: masking region = 0
>> Rejected: bad fcst value = 0
>>
>> I can understand all reasons for rejections except the level
mismatch. As I said, these are all
>> surface measurements gathered at 2m or 10m (for wind), except for
ADPUPA, but above I asked for
>> ADPSFC messages.
>> Best wishes,
>> Maciek
>>
>> ----- Oryginalna wiadomość -----
>> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
>> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
>> Wysłane: poniedziałek, 6 czerwiec 2011 20:53:05
>> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>>
>> Maciek,
>>
>> I am not able to read the data in the zipped file you sent,
wrfout_d03_2010-01-24_00:00:00.
>> Does it contain GRIB data
>> which is the output of the WRF post processor, WPP? If not, what
format is it in? If so, can
>> you try to gzip the file
>> instead? Perhaps we have different verions of zip and that is
causing corruption.
>>
>> Regarding your point_stat config file, PointStat_configWIOS2010,
one possible problem that I
>> notice is the following
>> setting:
>>
>> beg_ds = 0;
>> end_ds = 0;
>>
>> The observation file that you sent me contains data for a wide
range of times, from
>> 20100123_223000 to 20100124_193000.
>> I would suggest opening your time window to this to see if you get
a match in point_stat:
>>
>> beg_ds = -5400;
>> end_ds = 70200;
>>
>> This will match all valid times in the observation file.
>>
>> Another suggestion that I have is to use the following option with
point_stat: -v 3. This will
>> set the verbosity level
>> so that point_stat prints out a report of reasons why it rejected
obs points based on criteria.
>> You can often find
>> problems this way. Please let me know if you have any questions.
>>
>> Paul
>>
>>
>> On 06/06/2011 11:34 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>>
>>> Paul,
>>> Thank you very much for quick reply. I've just started uploading
the WRF file to the ftp
>>> server.
>>> I'm quite sure that there are ADPSFC messages (SYNOP - synoptical
stations, with TMP
>>> measurements at 2m). However, it seems that most of them have
obs_arr:hgt value at -9999. Is it
>>> ok when maching Z2 values?
>>> I forgot to add - I use MET 3.0
>>> Best wishes,
>>> Maciek
>>>
>>>
>>> ----- Oryginalna wiadomość -----
>>> Od: "RAL HelpDesk {for Paul Oldenburg}" <met_help at ucar.edu>
>>> Do: "maciej kryza" <maciej.kryza at uni.wroc.pl>
>>> Wysłane: poniedziałek, 6 czerwiec 2011 18:18:35
>>> Temat: Re: [rt.rap.ucar.edu #47329] PointStat problem
>>>
>>> Maciek,
>>>
>>> Can you please send me a sample model data file that you are
using? I would like to reproduce
>>> the problem you are
>>> having. If the file is too large to send by email, please upload
it to our FTP site using the
>>> following instructions:
>>>
>>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>
>>> I looked at your TMP (GRIB code 11) observations using the ncdump
utility. If you do not have
>>> access to this utility, I
>>> recommend that you establish it on your system. I think that
there may not be many surface TMP
>>> observations:
>>>
>>> $ ncdump -v obs_arr PLsyn_20100124.nc | egrep '^[ ]+[0-9]+, 11,[
]+[12][0-9],'
>>> 0, 11, 20, 25389.44, 196.25,
>>> 0, 11, 14, -9999, 196.25,
>>> 240, 11, 20, 25309.47, 197.45,
>>> 240, 11, 16, -9999, 197.65,
>>> 240, 11, 10, 29397.77, 206.05,
>>> 242, 11, 20, 25030.66, 192.85,
>>> 244, 11, 20, 25241.41, 196.65,
>>> 244, 11, 10, 29236.89, 201.85,
>>>
>>> To see the accompanying message type, I use commands like this
(ADPUPA = upper air, ADPSFC =
>>> surface):
>>>
>>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -5
>>> "ADPUPA", # 0
>>> "ADPUPA", # 1
>>> "ADPUPA", # 2
>>> "ADPUPA", # 3
>>> "ADPUPA", # 4
>>>
>>> $ ncdump -v hdr_typ PLsyn_20100124.nc | egrep '^ "' | head -245
>>> ...
>>> "ADPSFC", # 237
>>> "ADPSFC", # 238
>>> "ADPSFC", # 239
>>> "ADPUPA", # 240
>>> "ADPUPA", # 241
>>> "ADPUPA", # 242
>>> "ADPUPA", # 243
>>> "ADPUPA", # 244
>>>
>>> I also tried another approach to looking at surface TMP
observations in the NetCDF, using the
>>> plot_point_obs tool that
>>> is included with METv3.0 and above. If you did not build this
tool, edit your MET Makefile to
>>> compile the tools:
>>>
>>> DISABLE_TOOLS = 0
>>>
>>> Then, run make from the top-level MET folder and it should make
the plot_point_obs tool, among
>>> others. When this is
>>> done, you can use this tool like this to plot all the surface TMP
observations in the input
>>> NetCDF file:
>>>
>>> $ plot_point_obs PLsyn_20100124.nc kryza_tmp_sfc.ps -gc 11
-msg_typ ADPSFC
>>>
>>> Using this approach, I see that there is a single TMP surface
observation. When I get your
>>> model data, I will attempt
>>> to match this point in point_obs and let you know how it was done.
Please let me know if you
>>> have any questions.
>>>
>>> Paul
>>>
>>>
>>>
>>> On 06/06/2011 09:16 AM, RAL HelpDesk {for Maciej Kryza} wrote:
>>>>
>>>> Mon Jun 06 09:16:32 2011: Request 47329 was acted upon.
>>>> Transaction: Ticket created by maciej.kryza at uni.wroc.pl
>>>> Queue: met_help
>>>> Subject: PointStat problem
>>>> Owner: Nobody
>>>> Requestors: maciej.kryza at uni.wroc.pl
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=47329 >
>>>>
>>>>
>>>> Hi,
>>>> I'd like to compare my WRF model run with surface meteorological
measurements. I got the
>>>> measurements in the prepbufr format from dss.ucar.edu ds337.0
database, and converted it to
>>>> the nc filea with pb2nc (see the .nc file attached). The .nc file
looks fine, there are the
>>>> sites that I need (Central Europe) and messages (ADPSFC and
ADPUPA). But when I use these .nc
>>>> files with PointStat tool (config file attached) for TMP/Z2,
WIND/Z10 or any other surface
>>>> data, I get 0 pairs. Is there anything wrong with config file or
.nc data (height/level?). I
>>>> can work with ADPUPA messsages, using pressure levels e.g.
TMP/P1000-500.
>>>> I will be greatful for any hints and suggestions.
>>>> Best regards,
>>>> Maciek Kryza
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> #############################################################
> Department of Climatology and Atmosphere Protection
> Wroclaw University
> ul. Kosiby 6/8
> 51-670 Poland
>
------------------------------------------------
More information about the Met_help
mailing list