[Met_help] [rt.rap.ucar.edu #69290] History for grid_stat Error
John Halley Gotway via RT
met_help at ucar.edu
Wed Oct 15 11:26:32 MDT 2014
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Dear WRF Help and MET Help
Grid_stat produced error message below and stopped:
[jyoo at yslogin4 analysis]$
/glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
/glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm -outdir
/glade/scratch/jyoo/domain/mean/analysis/gridstatout
DEBUG 1: Default Config File:
/glade/p/ral/jnt/MET/MET_releases/met-5.0/share/met/config/GridStatConfig_default
DEBUG 1: User Config File: GridStatConfig_ccsm
WARNING:
WARNING: NcCfFile::open() -> could not extract init time from file name
WARNING: Using init time of 0
WARNING:
ERROR :
ERROR : process_command_line() -> The forecast and observation grids do
not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
-0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection: Lat/Lon Nx: 288 Ny:
191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942 delta_lon: 1.250
ERROR :
Interestingly, it seems that my forecast file grid looks the same as the
observation file grid as below:
latlon: lat -89.529000 to 89.529000 by 0.942000 nxny 55008
long 0.625000 to 358.750000 by 1.250000, (288 x 191)
However, grid_stat reads long 0.625000 as lon_ll: -0.625, making error.
Can anyone explain why?
Thank you very much.
Regards,
Jinwoong Yoo
UNM
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Tue Oct 07 12:06:52 2014
Jinwoong,
I see that you're having problems comparing a GRIB1 file to a CF-
compliant
NetCDF file using the grid_stat tool.
I ran grid_stat and the plot_data_plane tools through the debugger and
found some issues.
First, I ran the following plot_data_plane command to plot the CPRAT
variable from the GRIB1 file:
met-5.0/bin/plot_data_plane \
WRFPRS_d01.00_2latlon \
WRFPRS_d01.00_2latlon_CPRAT.ps \
'name="CPRAT"; level="L0";'
Turns out that all the values are 0. This can also be seen via wgrib:
wgrib -V -d 277 WRFPRS_d01.00_2latlon
...
min/max data 0 0
Do you expect this or should there be some non-zero values?
Second, I looked at the PRECC variable using ncview and see that it
ranges
from 0 to 1.157e-06. Those values are so small that the MET tools
won't
really be able to distinguish between them.
Next, I tried running the NetCDF data through plot_data_plane, but got
this
error:
met-5.0/bin/plot_data_plane \
b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
'name="PRECC"; level="(0,*,*)";'
ERROR : NcCfFile::data(NcVar *, const LongArray &, DataPlane &) const
->
star found in bad slot
After running this through the debugger, I found that MET is getting
confused by the presence of the slat and slon variables. It's using
them
to define the grid rather than the lat and lon variables. And that
leads
to the difference in the grids. Also, MET stores longitude values
internally in degrees_west rather than the more common degrees_east.
When
you see -0.625 degrees longitude, that's degrees_west. Very
confusing, I
know!
I tweaked the NetCDF CF code to print warning messages when it
encounters
multiple variables for latitude and longitude, and to use the first
instance of them rather than the second.
Doing so enables me to run plot_data_plane. But when I run through
grid_stat, I get the following error:
ERROR : process_command_line() -> The forecast and observation grids
do
not match:
Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: -0.625
delta_lat: 0.942 delta_lon: 1.250 !=
Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll: -0.000
delta_lat: 0.942 delta_lon: 1.250
So we need to rerun copygb to put the GRIB1 data onto this grid:
copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942 64*"
WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
After doing that, I was finally able to run grid_stat to compare these
fields. But since the forecast contains all 0's and the observation
basically contains all 0's, I didn't get any meaningful statistics.
Seems like I need to get you that patch for reading the lat/lon
dimensions. You need to start using the copygb command listed above
for
regridding GRIB files. And you need to figure out why your data is
all 0's.
How does that all sound?
Thanks,
John Halley Gotway
met_help at ucar.edu
On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
> Transaction: Ticket created by jinwoong.yoo at gmail.com
> Queue: met_help
> Subject: grid_stat Error
> Owner: Nobody
> Requestors: jinwoong.yoo at gmail.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
>
> Dear WRF Help and MET Help
>
> Grid_stat produced error message below and stopped:
> [jyoo at yslogin4 analysis]$
> /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
>
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm -outdir
> /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> DEBUG 1: Default Config File:
>
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> DEBUG 1: User Config File: GridStatConfig_ccsm
> WARNING:
> WARNING: NcCfFile::open() -> could not extract init time from file
name
> WARNING: Using init time of 0
> WARNING:
> ERROR :
> ERROR : process_command_line() -> The forecast and observation
grids do
> not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection: Lat/Lon Nx:
288 Ny:
> 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942 delta_lon: 1.250
> ERROR :
>
>
> Interestingly, it seems that my forecast file grid looks the same as
the
> observation file grid as below:
> latlon: lat -89.529000 to 89.529000 by 0.942000 nxny 55008
> long 0.625000 to 358.750000 by 1.250000, (288 x 191)
>
> However, grid_stat reads long 0.625000 as lon_ll: -0.625, making
error.
>
> Can anyone explain why?
> Thank you very much.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Tue Oct 07 13:35:49 2014
Dear John
First of all, thank you for your efforts to figure out the issue with
Grid_stat of my case.
>>> Do you expect this or should there be some non-zero values?
This is a test case with precipitation variables from the WRF and
CCSM4 at
model initialization time 00. So, 0 is reasonable although I did not
consider carefully when I pick the variable for a test case.
>>>After running this through the debugger, I found that MET is
getting
confused by the presence of the slat and slon variables. It's using
them
to define the grid rather than the lat and lon variables. And that
leads
to the difference in the grids.
That's one thing that I mentioned in my previous email:
"However, there are something strange.
According to what Grid-Stat reads in for the CCSM4 file (Projection:
Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
delta_lon: 1.250), lat and lon information were flipped compared to
what I
get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ; slat = 191
;slon
= 288) and the Ny: 191 matches to slat(staggered latitude) not
latitude."
I'm glad you found a solution to the issue with NC file with two
different
pair of lat (lat and slat) and lon (lon and slon).
>>> So we need to rerun copygb to put the GRIB1 data onto this grid:
copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942 64*"
WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
Running copygb is not a big deal at all.
>>> After doing that, I was finally able to run grid_stat to compare
these
fields. But since the forecast contains all 0's and the observation
basically contains all 0's, I didn't get any meaningful statistics.
I can switch to a different variable than the precipitation at the
initialization time for a test.
Please send me the patch for reading the lat/lon dimensions via email
or
you can put the file(s) on the Yellowstone and let me know the path to
the
file(s), whatever suits you best.
Thank you very much.
Regards,
Jinwoong Yoo
UNM
On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I see that you're having problems comparing a GRIB1 file to a CF-
compliant
> NetCDF file using the grid_stat tool.
>
> I ran grid_stat and the plot_data_plane tools through the debugger
and
> found some issues.
>
> First, I ran the following plot_data_plane command to plot the CPRAT
> variable from the GRIB1 file:
> met-5.0/bin/plot_data_plane \
> WRFPRS_d01.00_2latlon \
> WRFPRS_d01.00_2latlon_CPRAT.ps \
> 'name="CPRAT"; level="L0";'
>
> Turns out that all the values are 0. This can also be seen via
wgrib:
> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> ...
> min/max data 0 0
>
> Do you expect this or should there be some non-zero values?
>
> Second, I looked at the PRECC variable using ncview and see that it
ranges
> from 0 to 1.157e-06. Those values are so small that the MET tools
won't
> really be able to distinguish between them.
>
> Next, I tried running the NetCDF data through plot_data_plane, but
got this
> error:
> met-5.0/bin/plot_data_plane \
> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> 'name="PRECC"; level="(0,*,*)";'
>
> ERROR : NcCfFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
> star found in bad slot
>
> After running this through the debugger, I found that MET is getting
> confused by the presence of the slat and slon variables. It's using
them
> to define the grid rather than the lat and lon variables. And that
leads
> to the difference in the grids. Also, MET stores longitude values
> internally in degrees_west rather than the more common degrees_east.
When
> you see -0.625 degrees longitude, that's degrees_west. Very
confusing, I
> know!
>
> I tweaked the NetCDF CF code to print warning messages when it
encounters
> multiple variables for latitude and longitude, and to use the first
> instance of them rather than the second.
>
> Doing so enables me to run plot_data_plane. But when I run through
> grid_stat, I get the following error:
>
> ERROR : process_command_line() -> The forecast and observation
grids do
> not match:
> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: -0.625
> delta_lat: 0.942 delta_lon: 1.250 !=
> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll: -0.000
> delta_lat: 0.942 delta_lon: 1.250
>
> So we need to rerun copygb to put the GRIB1 data onto this grid:
> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942
64*"
> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>
> After doing that, I was finally able to run grid_stat to compare
these
> fields. But since the forecast contains all 0's and the observation
> basically contains all 0's, I didn't get any meaningful statistics.
>
> Seems like I need to get you that patch for reading the lat/lon
> dimensions. You need to start using the copygb command listed above
for
> regridding GRIB files. And you need to figure out why your data is
all
> 0's.
>
> How does that all sound?
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
> > Transaction: Ticket created by jinwoong.yoo at gmail.com
> > Queue: met_help
> > Subject: grid_stat Error
> > Owner: Nobody
> > Requestors: jinwoong.yoo at gmail.com
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> >
> > Dear WRF Help and MET Help
> >
> > Grid_stat produced error message below and stopped:
> > [jyoo at yslogin4 analysis]$
> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm
-outdir
> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > DEBUG 1: Default Config File:
> >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > DEBUG 1: User Config File: GridStatConfig_ccsm
> > WARNING:
> > WARNING: NcCfFile::open() -> could not extract init time from file
name
> > WARNING: Using init time of 0
> > WARNING:
> > ERROR :
> > ERROR : process_command_line() -> The forecast and observation
grids do
> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection: Lat/Lon
Nx: 288
> Ny:
> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942 delta_lon:
1.250
> > ERROR :
> >
> >
> > Interestingly, it seems that my forecast file grid looks the same
as the
> > observation file grid as below:
> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny 55008
> > long 0.625000 to 358.750000 by 1.250000, (288 x 191)
> >
> > However, grid_stat reads long 0.625000 as lon_ll: -0.625, making
error.
> >
> > Can anyone explain why?
> > Thank you very much.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Tue Oct 07 14:23:05 2014
Dear John,
Since I'm using the MET that is available on the Yellowstone
at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
you can just let me know how I can use the patch for reading the
lat/lon
dimensions of the CCSM4 file in the Yellowstone.
Thank you.
Regards,
Jinwoong Yoo
UNM
On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Dear John
>
> First of all, thank you for your efforts to figure out the issue
with
> Grid_stat of my case.
>
> >>> Do you expect this or should there be some non-zero values?
>
> This is a test case with precipitation variables from the WRF and
CCSM4 at
> model initialization time 00. So, 0 is reasonable although I did not
> consider carefully when I pick the variable for a test case.
>
> >>>After running this through the debugger, I found that MET is
getting
> confused by the presence of the slat and slon variables. It's using
them
> to define the grid rather than the lat and lon variables. And that
leads
> to the difference in the grids.
>
> That's one thing that I mentioned in my previous email:
> "However, there are something strange.
> According to what Grid-Stat reads in for the CCSM4 file (Projection:
> Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat:
0.942
> delta_lon: 1.250), lat and lon information were flipped compared to
what I
> get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ; slat =
191 ;slon
> = 288) and the Ny: 191 matches to slat(staggered latitude) not
latitude."
> I'm glad you found a solution to the issue with NC file with two
different
> pair of lat (lat and slat) and lon (lon and slon).
>
>
> >>> So we need to rerun copygb to put the GRIB1 data onto this grid:
> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942
64*"
> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>
> Running copygb is not a big deal at all.
>
> >>> After doing that, I was finally able to run grid_stat to compare
these
> fields. But since the forecast contains all 0's and the observation
> basically contains all 0's, I didn't get any meaningful statistics.
>
>
> I can switch to a different variable than the precipitation at the
> initialization time for a test.
> Please send me the patch for reading the lat/lon dimensions via
email or
> you can put the file(s) on the Yellowstone and let me know the path
to the
> file(s), whatever suits you best.
>
> Thank you very much.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
>
> On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> I see that you're having problems comparing a GRIB1 file to a CF-
compliant
>> NetCDF file using the grid_stat tool.
>>
>> I ran grid_stat and the plot_data_plane tools through the debugger
and
>> found some issues.
>>
>> First, I ran the following plot_data_plane command to plot the
CPRAT
>> variable from the GRIB1 file:
>> met-5.0/bin/plot_data_plane \
>> WRFPRS_d01.00_2latlon \
>> WRFPRS_d01.00_2latlon_CPRAT.ps \
>> 'name="CPRAT"; level="L0";'
>>
>> Turns out that all the values are 0. This can also be seen via
wgrib:
>> wgrib -V -d 277 WRFPRS_d01.00_2latlon
>> ...
>> min/max data 0 0
>>
>> Do you expect this or should there be some non-zero values?
>>
>> Second, I looked at the PRECC variable using ncview and see that it
ranges
>> from 0 to 1.157e-06. Those values are so small that the MET tools
won't
>> really be able to distinguish between them.
>>
>> Next, I tried running the NetCDF data through plot_data_plane, but
got
>> this
>> error:
>> met-5.0/bin/plot_data_plane \
>> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
>> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
>> 'name="PRECC"; level="(0,*,*)";'
>>
>> ERROR : NcCfFile::data(NcVar *, const LongArray &, DataPlane &)
const ->
>> star found in bad slot
>>
>> After running this through the debugger, I found that MET is
getting
>> confused by the presence of the slat and slon variables. It's
using them
>> to define the grid rather than the lat and lon variables. And that
leads
>> to the difference in the grids. Also, MET stores longitude values
>> internally in degrees_west rather than the more common
degrees_east. When
>> you see -0.625 degrees longitude, that's degrees_west. Very
confusing, I
>> know!
>>
>> I tweaked the NetCDF CF code to print warning messages when it
encounters
>> multiple variables for latitude and longitude, and to use the first
>> instance of them rather than the second.
>>
>> Doing so enables me to run plot_data_plane. But when I run through
>> grid_stat, I get the following error:
>>
>> ERROR : process_command_line() -> The forecast and observation
grids do
>> not match:
>> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: -0.625
>> delta_lat: 0.942 delta_lon: 1.250 !=
>> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll: -0.000
>> delta_lat: 0.942 delta_lon: 1.250
>>
>> So we need to rerun copygb to put the GRIB1 data onto this grid:
>> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942
64*"
>> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>>
>> After doing that, I was finally able to run grid_stat to compare
these
>> fields. But since the forecast contains all 0's and the
observation
>> basically contains all 0's, I didn't get any meaningful statistics.
>>
>> Seems like I need to get you that patch for reading the lat/lon
>> dimensions. You need to start using the copygb command listed
above for
>> regridding GRIB files. And you need to figure out why your data is
all
>> 0's.
>>
>> How does that all sound?
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
>> > Transaction: Ticket created by jinwoong.yoo at gmail.com
>> > Queue: met_help
>> > Subject: grid_stat Error
>> > Owner: Nobody
>> > Requestors: jinwoong.yoo at gmail.com
>> > Status: new
>> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>> >
>> >
>> > Dear WRF Help and MET Help
>> >
>> > Grid_stat produced error message below and stopped:
>> > [jyoo at yslogin4 analysis]$
>> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
>> >
>> >
>>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
>> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
>> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm
-outdir
>> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
>> > DEBUG 1: Default Config File:
>> >
>> >
>> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
>> > DEBUG 1: User Config File: GridStatConfig_ccsm
>> > WARNING:
>> > WARNING: NcCfFile::open() -> could not extract init time from
file name
>> > WARNING: Using init time of 0
>> > WARNING:
>> > ERROR :
>> > ERROR : process_command_line() -> The forecast and observation
grids do
>> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
>> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection: Lat/Lon
Nx: 288
>> Ny:
>> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942 delta_lon:
1.250
>> > ERROR :
>> >
>> >
>> > Interestingly, it seems that my forecast file grid looks the same
as the
>> > observation file grid as below:
>> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny 55008
>> > long 0.625000 to 358.750000 by 1.250000, (288 x 191)
>> >
>> > However, grid_stat reads long 0.625000 as lon_ll: -0.625, making
error.
>> >
>> > Can anyone explain why?
>> > Thank you very much.
>> >
>> > Regards,
>> >
>> > Jinwoong Yoo
>> > UNM
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Tue Oct 07 16:13:18 2014
Jinwoong,
OK, I updated the build on yellowstone to include the latest set of
patches:
/glade/p/ral/jnt/MET/MET_releases/met-5.0
The original, as released, version of met-5.0 can still be found here:
/glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
Please give the updated version a shot and let me know how it goes.
Thanks,
John
On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
> Dear John,
>
> Since I'm using the MET that is available on the Yellowstone
> at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> you can just let me know how I can use the patch for reading the
lat/lon
> dimensions of the CCSM4 file in the Yellowstone.
>
> Thank you.
>
> Regards,
> Jinwoong Yoo
> UNM
>
> On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Dear John
> >
> > First of all, thank you for your efforts to figure out the issue
with
> > Grid_stat of my case.
> >
> > >>> Do you expect this or should there be some non-zero values?
> >
> > This is a test case with precipitation variables from the WRF and
CCSM4
> at
> > model initialization time 00. So, 0 is reasonable although I did
not
> > consider carefully when I pick the variable for a test case.
> >
> > >>>After running this through the debugger, I found that MET is
getting
> > confused by the presence of the slat and slon variables. It's
using them
> > to define the grid rather than the lat and lon variables. And
that leads
> > to the difference in the grids.
> >
> > That's one thing that I mentioned in my previous email:
> > "However, there are something strange.
> > According to what Grid-Stat reads in for the CCSM4 file
(Projection:
> > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat:
0.942
> > delta_lon: 1.250), lat and lon information were flipped compared
to what
> I
> > get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ; slat =
191
> ;slon
> > = 288) and the Ny: 191 matches to slat(staggered latitude) not
latitude."
> > I'm glad you found a solution to the issue with NC file with two
> different
> > pair of lat (lat and slat) and lon (lon and slon).
> >
> >
> > >>> So we need to rerun copygb to put the GRIB1 data onto this
grid:
> > copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942
64*"
> > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> >
> > Running copygb is not a big deal at all.
> >
> > >>> After doing that, I was finally able to run grid_stat to
compare
> these
> > fields. But since the forecast contains all 0's and the
observation
> > basically contains all 0's, I didn't get any meaningful
statistics.
> >
> >
> > I can switch to a different variable than the precipitation at the
> > initialization time for a test.
> > Please send me the patch for reading the lat/lon dimensions via
email or
> > you can put the file(s) on the Yellowstone and let me know the
path to
> the
> > file(s), whatever suits you best.
> >
> > Thank you very much.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> >
> > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> I see that you're having problems comparing a GRIB1 file to a
> CF-compliant
> >> NetCDF file using the grid_stat tool.
> >>
> >> I ran grid_stat and the plot_data_plane tools through the
debugger and
> >> found some issues.
> >>
> >> First, I ran the following plot_data_plane command to plot the
CPRAT
> >> variable from the GRIB1 file:
> >> met-5.0/bin/plot_data_plane \
> >> WRFPRS_d01.00_2latlon \
> >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> >> 'name="CPRAT"; level="L0";'
> >>
> >> Turns out that all the values are 0. This can also be seen via
wgrib:
> >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> >> ...
> >> min/max data 0 0
> >>
> >> Do you expect this or should there be some non-zero values?
> >>
> >> Second, I looked at the PRECC variable using ncview and see that
it
> ranges
> >> from 0 to 1.157e-06. Those values are so small that the MET
tools won't
> >> really be able to distinguish between them.
> >>
> >> Next, I tried running the NetCDF data through plot_data_plane,
but got
> >> this
> >> error:
> >> met-5.0/bin/plot_data_plane \
> >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> >> 'name="PRECC"; level="(0,*,*)";'
> >>
> >> ERROR : NcCfFile::data(NcVar *, const LongArray &, DataPlane &)
const
> ->
> >> star found in bad slot
> >>
> >> After running this through the debugger, I found that MET is
getting
> >> confused by the presence of the slat and slon variables. It's
using
> them
> >> to define the grid rather than the lat and lon variables. And
that
> leads
> >> to the difference in the grids. Also, MET stores longitude
values
> >> internally in degrees_west rather than the more common
degrees_east.
> When
> >> you see -0.625 degrees longitude, that's degrees_west. Very
confusing,
> I
> >> know!
> >>
> >> I tweaked the NetCDF CF code to print warning messages when it
> encounters
> >> multiple variables for latitude and longitude, and to use the
first
> >> instance of them rather than the second.
> >>
> >> Doing so enables me to run plot_data_plane. But when I run
through
> >> grid_stat, I get the following error:
> >>
> >> ERROR : process_command_line() -> The forecast and observation
grids do
> >> not match:
> >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
-0.625
> >> delta_lat: 0.942 delta_lon: 1.250 !=
> >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll:
-0.000
> >> delta_lat: 0.942 delta_lon: 1.250
> >>
> >> So we need to rerun copygb to put the GRIB1 data onto this grid:
> >> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250 942
64*"
> >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> >>
> >> After doing that, I was finally able to run grid_stat to compare
these
> >> fields. But since the forecast contains all 0's and the
observation
> >> basically contains all 0's, I didn't get any meaningful
statistics.
> >>
> >> Seems like I need to get you that patch for reading the lat/lon
> >> dimensions. You need to start using the copygb command listed
above for
> >> regridding GRIB files. And you need to figure out why your data
is all
> >> 0's.
> >>
> >> How does that all sound?
> >>
> >> Thanks,
> >> John Halley Gotway
> >> met_help at ucar.edu
> >>
> >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
> >> > Transaction: Ticket created by jinwoong.yoo at gmail.com
> >> > Queue: met_help
> >> > Subject: grid_stat Error
> >> > Owner: Nobody
> >> > Requestors: jinwoong.yoo at gmail.com
> >> > Status: new
> >> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> >
> >> >
> >> >
> >> > Dear WRF Help and MET Help
> >> >
> >> > Grid_stat produced error message below and stopped:
> >> > [jyoo at yslogin4 analysis]$
> >> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> >> >
> >> >
> >>
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> >> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm
-outdir
> >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> >> > DEBUG 1: Default Config File:
> >> >
> >> >
> >>
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> >> > WARNING:
> >> > WARNING: NcCfFile::open() -> could not extract init time from
file
> name
> >> > WARNING: Using init time of 0
> >> > WARNING:
> >> > ERROR :
> >> > ERROR : process_command_line() -> The forecast and observation
grids
> do
> >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection: Lat/Lon
Nx:
> 288
> >> Ny:
> >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942 delta_lon:
1.250
> >> > ERROR :
> >> >
> >> >
> >> > Interestingly, it seems that my forecast file grid looks the
same as
> the
> >> > observation file grid as below:
> >> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny 55008
> >> > long 0.625000 to 358.750000 by 1.250000, (288 x 191)
> >> >
> >> > However, grid_stat reads long 0.625000 as lon_ll: -0.625,
making
> error.
> >> >
> >> > Can anyone explain why?
> >> > Thank you very much.
> >> >
> >> > Regards,
> >> >
> >> > Jinwoong Yoo
> >> > UNM
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Tue Oct 07 17:36:35 2014
Dear John,
I switched variable to PRMSL (sea level pressure) for a Grid_stat
test.
Grid_stat seemed to run this time but produced files were empty.
However, when I produced a ps file for the variable, the output file
looks
ok (attached).
[jyoo at yslogin6 postprd]$
pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
[jyoo at yslogin6 postprd]$
/glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG/bin/plot_data_plane
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
Do I need to change other information for dictionary parts for the
variables being compared in the GridStatConfig_ccsm file (attached
also)?
Where can I find more detail information about the GridStatConfig than
in
the MET Users Guide V5.0, if available?
Thank you.
Regards,
Jinwoong Yoo
UNM
On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> OK, I updated the build on yellowstone to include the latest set of
> patches:
> /glade/p/ral/jnt/MET/MET_releases/met-5.0
>
> The original, as released, version of met-5.0 can still be found
here:
> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
>
> Please give the updated version a shot and let me know how it goes.
>
> Thanks,
> John
>
> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> > Dear John,
> >
> > Since I'm using the MET that is available on the Yellowstone
> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> > you can just let me know how I can use the patch for reading the
lat/lon
> > dimensions of the CCSM4 file in the Yellowstone.
> >
> > Thank you.
> >
> > Regards,
> > Jinwoong Yoo
> > UNM
> >
> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Dear John
> > >
> > > First of all, thank you for your efforts to figure out the issue
with
> > > Grid_stat of my case.
> > >
> > > >>> Do you expect this or should there be some non-zero values?
> > >
> > > This is a test case with precipitation variables from the WRF
and CCSM4
> > at
> > > model initialization time 00. So, 0 is reasonable although I did
not
> > > consider carefully when I pick the variable for a test case.
> > >
> > > >>>After running this through the debugger, I found that MET is
getting
> > > confused by the presence of the slat and slon variables. It's
using
> them
> > > to define the grid rather than the lat and lon variables. And
that
> leads
> > > to the difference in the grids.
> > >
> > > That's one thing that I mentioned in my previous email:
> > > "However, there are something strange.
> > > According to what Grid-Stat reads in for the CCSM4 file
(Projection:
> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat:
0.942
> > > delta_lon: 1.250), lat and lon information were flipped compared
to
> what
> > I
> > > get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ; slat
= 191
> > ;slon
> > > = 288) and the Ny: 191 matches to slat(staggered latitude) not
> latitude."
> > > I'm glad you found a solution to the issue with NC file with two
> > different
> > > pair of lat (lat and slat) and lon (lon and slon).
> > >
> > >
> > > >>> So we need to rerun copygb to put the GRIB1 data onto this
grid:
> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250
942 64*"
> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > >
> > > Running copygb is not a big deal at all.
> > >
> > > >>> After doing that, I was finally able to run grid_stat to
compare
> > these
> > > fields. But since the forecast contains all 0's and the
observation
> > > basically contains all 0's, I didn't get any meaningful
statistics.
> > >
> > >
> > > I can switch to a different variable than the precipitation at
the
> > > initialization time for a test.
> > > Please send me the patch for reading the lat/lon dimensions via
email
> or
> > > you can put the file(s) on the Yellowstone and let me know the
path to
> > the
> > > file(s), whatever suits you best.
> > >
> > > Thank you very much.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > > UNM
> > >
> > >
> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> I see that you're having problems comparing a GRIB1 file to a
> > CF-compliant
> > >> NetCDF file using the grid_stat tool.
> > >>
> > >> I ran grid_stat and the plot_data_plane tools through the
debugger and
> > >> found some issues.
> > >>
> > >> First, I ran the following plot_data_plane command to plot the
CPRAT
> > >> variable from the GRIB1 file:
> > >> met-5.0/bin/plot_data_plane \
> > >> WRFPRS_d01.00_2latlon \
> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > >> 'name="CPRAT"; level="L0";'
> > >>
> > >> Turns out that all the values are 0. This can also be seen via
wgrib:
> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > >> ...
> > >> min/max data 0 0
> > >>
> > >> Do you expect this or should there be some non-zero values?
> > >>
> > >> Second, I looked at the PRECC variable using ncview and see
that it
> > ranges
> > >> from 0 to 1.157e-06. Those values are so small that the MET
tools
> won't
> > >> really be able to distinguish between them.
> > >>
> > >> Next, I tried running the NetCDF data through plot_data_plane,
but got
> > >> this
> > >> error:
> > >> met-5.0/bin/plot_data_plane \
> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> > >> 'name="PRECC"; level="(0,*,*)";'
> > >>
> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &, DataPlane
&) const
> > ->
> > >> star found in bad slot
> > >>
> > >> After running this through the debugger, I found that MET is
getting
> > >> confused by the presence of the slat and slon variables. It's
using
> > them
> > >> to define the grid rather than the lat and lon variables. And
that
> > leads
> > >> to the difference in the grids. Also, MET stores longitude
values
> > >> internally in degrees_west rather than the more common
degrees_east.
> > When
> > >> you see -0.625 degrees longitude, that's degrees_west. Very
> confusing,
> > I
> > >> know!
> > >>
> > >> I tweaked the NetCDF CF code to print warning messages when it
> > encounters
> > >> multiple variables for latitude and longitude, and to use the
first
> > >> instance of them rather than the second.
> > >>
> > >> Doing so enables me to run plot_data_plane. But when I run
through
> > >> grid_stat, I get the following error:
> > >>
> > >> ERROR : process_command_line() -> The forecast and observation
grids
> do
> > >> not match:
> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
-0.625
> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll:
-0.000
> > >> delta_lat: 0.942 delta_lon: 1.250
> > >>
> > >> So we need to rerun copygb to put the GRIB1 data onto this
grid:
> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250
942 64*"
> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > >>
> > >> After doing that, I was finally able to run grid_stat to
compare these
> > >> fields. But since the forecast contains all 0's and the
observation
> > >> basically contains all 0's, I didn't get any meaningful
statistics.
> > >>
> > >> Seems like I need to get you that patch for reading the lat/lon
> > >> dimensions. You need to start using the copygb command listed
above
> for
> > >> regridding GRIB files. And you need to figure out why your
data is
> all
> > >> 0's.
> > >>
> > >> How does that all sound?
> > >>
> > >> Thanks,
> > >> John Halley Gotway
> > >> met_help at ucar.edu
> > >>
> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
> > >> > Transaction: Ticket created by jinwoong.yoo at gmail.com
> > >> > Queue: met_help
> > >> > Subject: grid_stat Error
> > >> > Owner: Nobody
> > >> > Requestors: jinwoong.yoo at gmail.com
> > >> > Status: new
> > >> > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > >
> > >> >
> > >> >
> > >> > Dear WRF Help and MET Help
> > >> >
> > >> > Grid_stat produced error message below and stopped:
> > >> > [jyoo at yslogin4 analysis]$
> > >> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > >> >
> > >> >
> > >>
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > >> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm
> -outdir
> > >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > >> > DEBUG 1: Default Config File:
> > >> >
> > >> >
> > >>
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> > >> > WARNING:
> > >> > WARNING: NcCfFile::open() -> could not extract init time from
file
> > name
> > >> > WARNING: Using init time of 0
> > >> > WARNING:
> > >> > ERROR :
> > >> > ERROR : process_command_line() -> The forecast and
observation
> grids
> > do
> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
> lon_ll:
> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection:
Lat/Lon Nx:
> > 288
> > >> Ny:
> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942 delta_lon:
1.250
> > >> > ERROR :
> > >> >
> > >> >
> > >> > Interestingly, it seems that my forecast file grid looks the
same as
> > the
> > >> > observation file grid as below:
> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny
55008
> > >> > long 0.625000 to 358.750000 by 1.250000, (288 x
191)
> > >> >
> > >> > However, grid_stat reads long 0.625000 as lon_ll: -0.625,
making
> > error.
> > >> >
> > >> > Can anyone explain why?
> > >> > Thank you very much.
> > >> >
> > >> > Regards,
> > >> >
> > >> > Jinwoong Yoo
> > >> > UNM
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Tue Oct 07 20:16:39 2014
Dear John,
Maybe should I use gen_poly_mask to define the area of my WRF model
domain
(which is a tropical channel) before I run grid_stat against the CCSM4
in
global domain?
Jinwoong Yoo
UNM
On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Dear John,
>
> I switched variable to PRMSL (sea level pressure) for a Grid_stat
test.
> Grid_stat seemed to run this time but produced files were empty.
>
> However, when I produced a ps file for the variable, the output file
looks
> ok (attached).
>
> [jyoo at yslogin6 postprd]$
> pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> [jyoo at yslogin6 postprd]$
> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG/bin/plot_data_plane
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
>
> Do I need to change other information for dictionary parts for the
> variables being compared in the GridStatConfig_ccsm file (attached
also)?
> Where can I find more detail information about the GridStatConfig
than in
> the MET Users Guide V5.0, if available?
>
> Thank you.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
> On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> OK, I updated the build on yellowstone to include the latest set of
>> patches:
>> /glade/p/ral/jnt/MET/MET_releases/met-5.0
>>
>> The original, as released, version of met-5.0 can still be found
here:
>> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
>>
>> Please give the updated version a shot and let me know how it goes.
>>
>> Thanks,
>> John
>>
>> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>> >
>> > Dear John,
>> >
>> > Since I'm using the MET that is available on the Yellowstone
>> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
>> > you can just let me know how I can use the patch for reading the
lat/lon
>> > dimensions of the CCSM4 file in the Yellowstone.
>> >
>> > Thank you.
>> >
>> > Regards,
>> > Jinwoong Yoo
>> > UNM
>> >
>> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
>> > wrote:
>> >
>> > > Dear John
>> > >
>> > > First of all, thank you for your efforts to figure out the
issue with
>> > > Grid_stat of my case.
>> > >
>> > > >>> Do you expect this or should there be some non-zero values?
>> > >
>> > > This is a test case with precipitation variables from the WRF
and
>> CCSM4
>> > at
>> > > model initialization time 00. So, 0 is reasonable although I
did not
>> > > consider carefully when I pick the variable for a test case.
>> > >
>> > > >>>After running this through the debugger, I found that MET is
>> getting
>> > > confused by the presence of the slat and slon variables. It's
using
>> them
>> > > to define the grid rather than the lat and lon variables. And
that
>> leads
>> > > to the difference in the grids.
>> > >
>> > > That's one thing that I mentioned in my previous email:
>> > > "However, there are something strange.
>> > > According to what Grid-Stat reads in for the CCSM4 file
(Projection:
>> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat: 0.942
>> > > delta_lon: 1.250), lat and lon information were flipped
compared to
>> what
>> > I
>> > > get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ; slat
= 191
>> > ;slon
>> > > = 288) and the Ny: 191 matches to slat(staggered latitude) not
>> latitude."
>> > > I'm glad you found a solution to the issue with NC file with
two
>> > different
>> > > pair of lat (lat and slat) and lon (lon and slon).
>> > >
>> > >
>> > > >>> So we need to rerun copygb to put the GRIB1 data onto this
grid:
>> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250
942 64*"
>> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>> > >
>> > > Running copygb is not a big deal at all.
>> > >
>> > > >>> After doing that, I was finally able to run grid_stat to
compare
>> > these
>> > > fields. But since the forecast contains all 0's and the
observation
>> > > basically contains all 0's, I didn't get any meaningful
statistics.
>> > >
>> > >
>> > > I can switch to a different variable than the precipitation at
the
>> > > initialization time for a test.
>> > > Please send me the patch for reading the lat/lon dimensions via
email
>> or
>> > > you can put the file(s) on the Yellowstone and let me know the
path to
>> > the
>> > > file(s), whatever suits you best.
>> > >
>> > > Thank you very much.
>> > >
>> > > Regards,
>> > >
>> > > Jinwoong Yoo
>> > > UNM
>> > >
>> > >
>> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT <
>> > > met_help at ucar.edu> wrote:
>> > >
>> > >> Jinwoong,
>> > >>
>> > >> I see that you're having problems comparing a GRIB1 file to a
>> > CF-compliant
>> > >> NetCDF file using the grid_stat tool.
>> > >>
>> > >> I ran grid_stat and the plot_data_plane tools through the
debugger
>> and
>> > >> found some issues.
>> > >>
>> > >> First, I ran the following plot_data_plane command to plot the
CPRAT
>> > >> variable from the GRIB1 file:
>> > >> met-5.0/bin/plot_data_plane \
>> > >> WRFPRS_d01.00_2latlon \
>> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
>> > >> 'name="CPRAT"; level="L0";'
>> > >>
>> > >> Turns out that all the values are 0. This can also be seen
via
>> wgrib:
>> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
>> > >> ...
>> > >> min/max data 0 0
>> > >>
>> > >> Do you expect this or should there be some non-zero values?
>> > >>
>> > >> Second, I looked at the PRECC variable using ncview and see
that it
>> > ranges
>> > >> from 0 to 1.157e-06. Those values are so small that the MET
tools
>> won't
>> > >> really be able to distinguish between them.
>> > >>
>> > >> Next, I tried running the NetCDF data through plot_data_plane,
but
>> got
>> > >> this
>> > >> error:
>> > >> met-5.0/bin/plot_data_plane \
>> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
>> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
>> > >> 'name="PRECC"; level="(0,*,*)";'
>> > >>
>> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &, DataPlane
&)
>> const
>> > ->
>> > >> star found in bad slot
>> > >>
>> > >> After running this through the debugger, I found that MET is
getting
>> > >> confused by the presence of the slat and slon variables. It's
using
>> > them
>> > >> to define the grid rather than the lat and lon variables. And
that
>> > leads
>> > >> to the difference in the grids. Also, MET stores longitude
values
>> > >> internally in degrees_west rather than the more common
degrees_east.
>> > When
>> > >> you see -0.625 degrees longitude, that's degrees_west. Very
>> confusing,
>> > I
>> > >> know!
>> > >>
>> > >> I tweaked the NetCDF CF code to print warning messages when it
>> > encounters
>> > >> multiple variables for latitude and longitude, and to use the
first
>> > >> instance of them rather than the second.
>> > >>
>> > >> Doing so enables me to run plot_data_plane. But when I run
through
>> > >> grid_stat, I get the following error:
>> > >>
>> > >> ERROR : process_command_line() -> The forecast and
observation
>> grids do
>> > >> not match:
>> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
-0.625
>> > >> delta_lat: 0.942 delta_lon: 1.250 !=
>> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll:
-0.000
>> > >> delta_lat: 0.942 delta_lon: 1.250
>> > >>
>> > >> So we need to rerun copygb to put the GRIB1 data onto this
grid:
>> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250
942
>> 64*"
>> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>> > >>
>> > >> After doing that, I was finally able to run grid_stat to
compare
>> these
>> > >> fields. But since the forecast contains all 0's and the
observation
>> > >> basically contains all 0's, I didn't get any meaningful
statistics.
>> > >>
>> > >> Seems like I need to get you that patch for reading the
lat/lon
>> > >> dimensions. You need to start using the copygb command listed
above
>> for
>> > >> regridding GRIB files. And you need to figure out why your
data is
>> all
>> > >> 0's.
>> > >>
>> > >> How does that all sound?
>> > >>
>> > >> Thanks,
>> > >> John Halley Gotway
>> > >> met_help at ucar.edu
>> > >>
>> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > >> wrote:
>> > >>
>> > >> >
>> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
>> > >> > Transaction: Ticket created by jinwoong.yoo at gmail.com
>> > >> > Queue: met_help
>> > >> > Subject: grid_stat Error
>> > >> > Owner: Nobody
>> > >> > Requestors: jinwoong.yoo at gmail.com
>> > >> > Status: new
>> > >> > Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>> > >
>> > >> >
>> > >> >
>> > >> > Dear WRF Help and MET Help
>> > >> >
>> > >> > Grid_stat produced error message below and stopped:
>> > >> > [jyoo at yslogin4 analysis]$
>> > >> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
>> > >> >
>> > >> >
>> > >>
>> >
>>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
>> > >> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
>> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc GridStatConfig_ccsm
>> -outdir
>> > >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
>> > >> > DEBUG 1: Default Config File:
>> > >> >
>> > >> >
>> > >>
>> >
>> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
>> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
>> > >> > WARNING:
>> > >> > WARNING: NcCfFile::open() -> could not extract init time
from file
>> > name
>> > >> > WARNING: Using init time of 0
>> > >> > WARNING:
>> > >> > ERROR :
>> > >> > ERROR : process_command_line() -> The forecast and
observation
>> grids
>> > do
>> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
>> lon_ll:
>> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection:
Lat/Lon Nx:
>> > 288
>> > >> Ny:
>> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
delta_lon: 1.250
>> > >> > ERROR :
>> > >> >
>> > >> >
>> > >> > Interestingly, it seems that my forecast file grid looks the
same
>> as
>> > the
>> > >> > observation file grid as below:
>> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny
55008
>> > >> > long 0.625000 to 358.750000 by 1.250000, (288 x
191)
>> > >> >
>> > >> > However, grid_stat reads long 0.625000 as lon_ll: -0.625,
making
>> > error.
>> > >> >
>> > >> > Can anyone explain why?
>> > >> > Thank you very much.
>> > >> >
>> > >> > Regards,
>> > >> >
>> > >> > Jinwoong Yoo
>> > >> > UNM
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Wed Oct 08 13:21:32 2014
Jinwoong,
Try editing your Grid-Stat config file by setting:
nc_pairs_flag = FALSE;
We're getting a weird error when Grid-Stat tries to write the NetCDF
output
file:
NetCDF: Numeric conversion not representable
That's causing you to see empty output files.
I'll look into the source of this error, but for now, just disable the
NetCDF matched pairs output.
Thanks,
John
On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
> Dear John,
>
> Maybe should I use gen_poly_mask to define the area of my WRF model
domain
> (which is a tropical channel) before I run grid_stat against the
CCSM4 in
> global domain?
>
> Jinwoong Yoo
> UNM
>
> On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Dear John,
> >
> > I switched variable to PRMSL (sea level pressure) for a Grid_stat
test.
> > Grid_stat seemed to run this time but produced files were empty.
> >
> > However, when I produced a ps file for the variable, the output
file
> looks
> > ok (attached).
> >
> > [jyoo at yslogin6 postprd]$
> > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > [jyoo at yslogin6 postprd]$
> > /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG/bin/plot_data_plane
> >
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
> >
> > Do I need to change other information for dictionary parts for the
> > variables being compared in the GridStatConfig_ccsm file (attached
also)?
> > Where can I find more detail information about the GridStatConfig
than in
> > the MET Users Guide V5.0, if available?
> >
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> OK, I updated the build on yellowstone to include the latest set
of
> >> patches:
> >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> >>
> >> The original, as released, version of met-5.0 can still be found
here:
> >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> >>
> >> Please give the updated version a shot and let me know how it
goes.
> >>
> >> Thanks,
> >> John
> >>
> >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >> >
> >> > Dear John,
> >> >
> >> > Since I'm using the MET that is available on the Yellowstone
> >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> >> > you can just let me know how I can use the patch for reading
the
> lat/lon
> >> > dimensions of the CCSM4 file in the Yellowstone.
> >> >
> >> > Thank you.
> >> >
> >> > Regards,
> >> > Jinwoong Yoo
> >> > UNM
> >> >
> >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> >> > wrote:
> >> >
> >> > > Dear John
> >> > >
> >> > > First of all, thank you for your efforts to figure out the
issue
> with
> >> > > Grid_stat of my case.
> >> > >
> >> > > >>> Do you expect this or should there be some non-zero
values?
> >> > >
> >> > > This is a test case with precipitation variables from the WRF
and
> >> CCSM4
> >> > at
> >> > > model initialization time 00. So, 0 is reasonable although I
did not
> >> > > consider carefully when I pick the variable for a test case.
> >> > >
> >> > > >>>After running this through the debugger, I found that MET
is
> >> getting
> >> > > confused by the presence of the slat and slon variables.
It's using
> >> them
> >> > > to define the grid rather than the lat and lon variables.
And that
> >> leads
> >> > > to the difference in the grids.
> >> > >
> >> > > That's one thing that I mentioned in my previous email:
> >> > > "However, there are something strange.
> >> > > According to what Grid-Stat reads in for the CCSM4 file
(Projection:
> >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat:
> 0.942
> >> > > delta_lon: 1.250), lat and lon information were flipped
compared to
> >> what
> >> > I
> >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ;
slat =
> 191
> >> > ;slon
> >> > > = 288) and the Ny: 191 matches to slat(staggered latitude)
not
> >> latitude."
> >> > > I'm glad you found a solution to the issue with NC file with
two
> >> > different
> >> > > pair of lat (lat and slat) and lon (lon and slon).
> >> > >
> >> > >
> >> > > >>> So we need to rerun copygb to put the GRIB1 data onto
this grid:
> >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750 1250
942
> 64*"
> >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> >> > >
> >> > > Running copygb is not a big deal at all.
> >> > >
> >> > > >>> After doing that, I was finally able to run grid_stat to
compare
> >> > these
> >> > > fields. But since the forecast contains all 0's and the
observation
> >> > > basically contains all 0's, I didn't get any meaningful
statistics.
> >> > >
> >> > >
> >> > > I can switch to a different variable than the precipitation
at the
> >> > > initialization time for a test.
> >> > > Please send me the patch for reading the lat/lon dimensions
via
> email
> >> or
> >> > > you can put the file(s) on the Yellowstone and let me know
the path
> to
> >> > the
> >> > > file(s), whatever suits you best.
> >> > >
> >> > > Thank you very much.
> >> > >
> >> > > Regards,
> >> > >
> >> > > Jinwoong Yoo
> >> > > UNM
> >> > >
> >> > >
> >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT <
> >> > > met_help at ucar.edu> wrote:
> >> > >
> >> > >> Jinwoong,
> >> > >>
> >> > >> I see that you're having problems comparing a GRIB1 file to
a
> >> > CF-compliant
> >> > >> NetCDF file using the grid_stat tool.
> >> > >>
> >> > >> I ran grid_stat and the plot_data_plane tools through the
debugger
> >> and
> >> > >> found some issues.
> >> > >>
> >> > >> First, I ran the following plot_data_plane command to plot
the
> CPRAT
> >> > >> variable from the GRIB1 file:
> >> > >> met-5.0/bin/plot_data_plane \
> >> > >> WRFPRS_d01.00_2latlon \
> >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> >> > >> 'name="CPRAT"; level="L0";'
> >> > >>
> >> > >> Turns out that all the values are 0. This can also be seen
via
> >> wgrib:
> >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> >> > >> ...
> >> > >> min/max data 0 0
> >> > >>
> >> > >> Do you expect this or should there be some non-zero values?
> >> > >>
> >> > >> Second, I looked at the PRECC variable using ncview and see
that it
> >> > ranges
> >> > >> from 0 to 1.157e-06. Those values are so small that the MET
tools
> >> won't
> >> > >> really be able to distinguish between them.
> >> > >>
> >> > >> Next, I tried running the NetCDF data through
plot_data_plane, but
> >> got
> >> > >> this
> >> > >> error:
> >> > >> met-5.0/bin/plot_data_plane \
> >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> >> > >> 'name="PRECC"; level="(0,*,*)";'
> >> > >>
> >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &,
DataPlane &)
> >> const
> >> > ->
> >> > >> star found in bad slot
> >> > >>
> >> > >> After running this through the debugger, I found that MET is
> getting
> >> > >> confused by the presence of the slat and slon variables.
It's
> using
> >> > them
> >> > >> to define the grid rather than the lat and lon variables.
And that
> >> > leads
> >> > >> to the difference in the grids. Also, MET stores longitude
values
> >> > >> internally in degrees_west rather than the more common
> degrees_east.
> >> > When
> >> > >> you see -0.625 degrees longitude, that's degrees_west. Very
> >> confusing,
> >> > I
> >> > >> know!
> >> > >>
> >> > >> I tweaked the NetCDF CF code to print warning messages when
it
> >> > encounters
> >> > >> multiple variables for latitude and longitude, and to use
the first
> >> > >> instance of them rather than the second.
> >> > >>
> >> > >> Doing so enables me to run plot_data_plane. But when I run
through
> >> > >> grid_stat, I get the following error:
> >> > >>
> >> > >> ERROR : process_command_line() -> The forecast and
observation
> >> grids do
> >> > >> not match:
> >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
-0.625
> >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000 lon_ll:
-0.000
> >> > >> delta_lat: 0.942 delta_lon: 1.250
> >> > >>
> >> > >> So we need to rerun copygb to put the GRIB1 data onto this
grid:
> >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750
1250 942
> >> 64*"
> >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> >> > >>
> >> > >> After doing that, I was finally able to run grid_stat to
compare
> >> these
> >> > >> fields. But since the forecast contains all 0's and the
> observation
> >> > >> basically contains all 0's, I didn't get any meaningful
statistics.
> >> > >>
> >> > >> Seems like I need to get you that patch for reading the
lat/lon
> >> > >> dimensions. You need to start using the copygb command
listed
> above
> >> for
> >> > >> regridding GRIB files. And you need to figure out why your
data is
> >> all
> >> > >> 0's.
> >> > >>
> >> > >> How does that all sound?
> >> > >>
> >> > >> Thanks,
> >> > >> John Halley Gotway
> >> > >> met_help at ucar.edu
> >> > >>
> >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
> >> met_help at ucar.edu>
> >> > >> wrote:
> >> > >>
> >> > >> >
> >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
> >> > >> > Transaction: Ticket created by jinwoong.yoo at gmail.com
> >> > >> > Queue: met_help
> >> > >> > Subject: grid_stat Error
> >> > >> > Owner: Nobody
> >> > >> > Requestors: jinwoong.yoo at gmail.com
> >> > >> > Status: new
> >> > >> > Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> >> > >
> >> > >> >
> >> > >> >
> >> > >> > Dear WRF Help and MET Help
> >> > >> >
> >> > >> > Grid_stat produced error message below and stopped:
> >> > >> > [jyoo at yslogin4 analysis]$
> >> > >> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> >> > >> >
> >> > >> >
> >> > >>
> >> >
> >>
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> >> > >> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
GridStatConfig_ccsm
> >> -outdir
> >> > >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> >> > >> > DEBUG 1: Default Config File:
> >> > >> >
> >> > >> >
> >> > >>
> >> >
> >>
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> >> > >> > WARNING:
> >> > >> > WARNING: NcCfFile::open() -> could not extract init time
from
> file
> >> > name
> >> > >> > WARNING: Using init time of 0
> >> > >> > WARNING:
> >> > >> > ERROR :
> >> > >> > ERROR : process_command_line() -> The forecast and
observation
> >> grids
> >> > do
> >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
> >> lon_ll:
> >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection:
Lat/Lon
> Nx:
> >> > 288
> >> > >> Ny:
> >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
delta_lon:
> 1.250
> >> > >> > ERROR :
> >> > >> >
> >> > >> >
> >> > >> > Interestingly, it seems that my forecast file grid looks
the same
> >> as
> >> > the
> >> > >> > observation file grid as below:
> >> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny
55008
> >> > >> > long 0.625000 to 358.750000 by 1.250000, (288 x
191)
> >> > >> >
> >> > >> > However, grid_stat reads long 0.625000 as lon_ll: -0.625,
making
> >> > error.
> >> > >> >
> >> > >> > Can anyone explain why?
> >> > >> > Thank you very much.
> >> > >> >
> >> > >> > Regards,
> >> > >> >
> >> > >> > Jinwoong Yoo
> >> > >> > UNM
> >> > >> >
> >> > >> >
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Wed Oct 08 13:47:02 2014
Dear John,
Yes. Disabling nc_pairs_flag did helped Grid_stat generating
statistics txt
files.
Then, I should run stat_analysis using the grid_stat outputs right?
Thank you.
Regards,
Jinwoong Yoo
UNM
On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> Try editing your Grid-Stat config file by setting:
> nc_pairs_flag = FALSE;
>
> We're getting a weird error when Grid-Stat tries to write the NetCDF
output
> file:
> NetCDF: Numeric conversion not representable
>
> That's causing you to see empty output files.
>
> I'll look into the source of this error, but for now, just disable
the
> NetCDF matched pairs output.
>
> Thanks,
> John
>
>
> On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> > Dear John,
> >
> > Maybe should I use gen_poly_mask to define the area of my WRF
model
> domain
> > (which is a tropical channel) before I run grid_stat against the
CCSM4 in
> > global domain?
> >
> > Jinwoong Yoo
> > UNM
> >
> > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Dear John,
> > >
> > > I switched variable to PRMSL (sea level pressure) for a
Grid_stat test.
> > > Grid_stat seemed to run this time but produced files were empty.
> > >
> > > However, when I produced a ps file for the variable, the output
file
> > looks
> > > ok (attached).
> > >
> > > [jyoo at yslogin6 postprd]$
> > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > [jyoo at yslogin6 postprd]$
> > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
> > >
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
> > >
> > > Do I need to change other information for dictionary parts for
the
> > > variables being compared in the GridStatConfig_ccsm file
(attached
> also)?
> > > Where can I find more detail information about the
GridStatConfig than
> in
> > > the MET Users Guide V5.0, if available?
> > >
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > > UNM
> > >
> > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> OK, I updated the build on yellowstone to include the latest
set of
> > >> patches:
> > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > >>
> > >> The original, as released, version of met-5.0 can still be
found here:
> > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> > >>
> > >> Please give the updated version a shot and let me know how it
goes.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>
> > >> >
> > >> > Dear John,
> > >> >
> > >> > Since I'm using the MET that is available on the Yellowstone
> > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> > >> > you can just let me know how I can use the patch for reading
the
> > lat/lon
> > >> > dimensions of the CCSM4 file in the Yellowstone.
> > >> >
> > >> > Thank you.
> > >> >
> > >> > Regards,
> > >> > Jinwoong Yoo
> > >> > UNM
> > >> >
> > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Dear John
> > >> > >
> > >> > > First of all, thank you for your efforts to figure out the
issue
> > with
> > >> > > Grid_stat of my case.
> > >> > >
> > >> > > >>> Do you expect this or should there be some non-zero
values?
> > >> > >
> > >> > > This is a test case with precipitation variables from the
WRF and
> > >> CCSM4
> > >> > at
> > >> > > model initialization time 00. So, 0 is reasonable although
I did
> not
> > >> > > consider carefully when I pick the variable for a test
case.
> > >> > >
> > >> > > >>>After running this through the debugger, I found that
MET is
> > >> getting
> > >> > > confused by the presence of the slat and slon variables.
It's
> using
> > >> them
> > >> > > to define the grid rather than the lat and lon variables.
And
> that
> > >> leads
> > >> > > to the difference in the grids.
> > >> > >
> > >> > > That's one thing that I mentioned in my previous email:
> > >> > > "However, there are something strange.
> > >> > > According to what Grid-Stat reads in for the CCSM4 file
> (Projection:
> > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat:
> > 0.942
> > >> > > delta_lon: 1.250), lat and lon information were flipped
compared
> to
> > >> what
> > >> > I
> > >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon = 288 ;
slat =
> > 191
> > >> > ;slon
> > >> > > = 288) and the Ny: 191 matches to slat(staggered latitude)
not
> > >> latitude."
> > >> > > I'm glad you found a solution to the issue with NC file
with two
> > >> > different
> > >> > > pair of lat (lat and slat) and lon (lon and slon).
> > >> > >
> > >> > >
> > >> > > >>> So we need to rerun copygb to put the GRIB1 data onto
this
> grid:
> > >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750
1250 942
> > 64*"
> > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > >> > >
> > >> > > Running copygb is not a big deal at all.
> > >> > >
> > >> > > >>> After doing that, I was finally able to run grid_stat
to
> compare
> > >> > these
> > >> > > fields. But since the forecast contains all 0's and the
> observation
> > >> > > basically contains all 0's, I didn't get any meaningful
> statistics.
> > >> > >
> > >> > >
> > >> > > I can switch to a different variable than the precipitation
at the
> > >> > > initialization time for a test.
> > >> > > Please send me the patch for reading the lat/lon dimensions
via
> > email
> > >> or
> > >> > > you can put the file(s) on the Yellowstone and let me know
the
> path
> > to
> > >> > the
> > >> > > file(s), whatever suits you best.
> > >> > >
> > >> > > Thank you very much.
> > >> > >
> > >> > > Regards,
> > >> > >
> > >> > > Jinwoong Yoo
> > >> > > UNM
> > >> > >
> > >> > >
> > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via RT
<
> > >> > > met_help at ucar.edu> wrote:
> > >> > >
> > >> > >> Jinwoong,
> > >> > >>
> > >> > >> I see that you're having problems comparing a GRIB1 file
to a
> > >> > CF-compliant
> > >> > >> NetCDF file using the grid_stat tool.
> > >> > >>
> > >> > >> I ran grid_stat and the plot_data_plane tools through the
> debugger
> > >> and
> > >> > >> found some issues.
> > >> > >>
> > >> > >> First, I ran the following plot_data_plane command to plot
the
> > CPRAT
> > >> > >> variable from the GRIB1 file:
> > >> > >> met-5.0/bin/plot_data_plane \
> > >> > >> WRFPRS_d01.00_2latlon \
> > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > >> > >> 'name="CPRAT"; level="L0";'
> > >> > >>
> > >> > >> Turns out that all the values are 0. This can also be
seen via
> > >> wgrib:
> > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > >> > >> ...
> > >> > >> min/max data 0 0
> > >> > >>
> > >> > >> Do you expect this or should there be some non-zero
values?
> > >> > >>
> > >> > >> Second, I looked at the PRECC variable using ncview and
see that
> it
> > >> > ranges
> > >> > >> from 0 to 1.157e-06. Those values are so small that the
MET
> tools
> > >> won't
> > >> > >> really be able to distinguish between them.
> > >> > >>
> > >> > >> Next, I tried running the NetCDF data through
plot_data_plane,
> but
> > >> got
> > >> > >> this
> > >> > >> error:
> > >> > >> met-5.0/bin/plot_data_plane \
> > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > >> > >>
> > >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &,
DataPlane &)
> > >> const
> > >> > ->
> > >> > >> star found in bad slot
> > >> > >>
> > >> > >> After running this through the debugger, I found that MET
is
> > getting
> > >> > >> confused by the presence of the slat and slon variables.
It's
> > using
> > >> > them
> > >> > >> to define the grid rather than the lat and lon variables.
And
> that
> > >> > leads
> > >> > >> to the difference in the grids. Also, MET stores
longitude
> values
> > >> > >> internally in degrees_west rather than the more common
> > degrees_east.
> > >> > When
> > >> > >> you see -0.625 degrees longitude, that's degrees_west.
Very
> > >> confusing,
> > >> > I
> > >> > >> know!
> > >> > >>
> > >> > >> I tweaked the NetCDF CF code to print warning messages
when it
> > >> > encounters
> > >> > >> multiple variables for latitude and longitude, and to use
the
> first
> > >> > >> instance of them rather than the second.
> > >> > >>
> > >> > >> Doing so enables me to run plot_data_plane. But when I
run
> through
> > >> > >> grid_stat, I get the following error:
> > >> > >>
> > >> > >> ERROR : process_command_line() -> The forecast and
observation
> > >> grids do
> > >> > >> not match:
> > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> -0.625
> > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000
lon_ll:
> -0.000
> > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > >> > >>
> > >> > >> So we need to rerun copygb to put the GRIB1 data onto this
grid:
> > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750
1250 942
> > >> 64*"
> > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > >> > >>
> > >> > >> After doing that, I was finally able to run grid_stat to
compare
> > >> these
> > >> > >> fields. But since the forecast contains all 0's and the
> > observation
> > >> > >> basically contains all 0's, I didn't get any meaningful
> statistics.
> > >> > >>
> > >> > >> Seems like I need to get you that patch for reading the
lat/lon
> > >> > >> dimensions. You need to start using the copygb command
listed
> > above
> > >> for
> > >> > >> regridding GRIB files. And you need to figure out why
your data
> is
> > >> all
> > >> > >> 0's.
> > >> > >>
> > >> > >> How does that all sound?
> > >> > >>
> > >> > >> Thanks,
> > >> > >> John Halley Gotway
> > >> > >> met_help at ucar.edu
> > >> > >>
> > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
> > >> met_help at ucar.edu>
> > >> > >> wrote:
> > >> > >>
> > >> > >> >
> > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted upon.
> > >> > >> > Transaction: Ticket created by jinwoong.yoo at gmail.com
> > >> > >> > Queue: met_help
> > >> > >> > Subject: grid_stat Error
> > >> > >> > Owner: Nobody
> > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > >> > >> > Status: new
> > >> > >> > Ticket <URL:
> > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > >> > >
> > >> > >> >
> > >> > >> >
> > >> > >> > Dear WRF Help and MET Help
> > >> > >> >
> > >> > >> > Grid_stat produced error message below and stopped:
> > >> > >> > [jyoo at yslogin4 analysis]$
> > >> > >> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > >> > >> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
GridStatConfig_ccsm
> > >> -outdir
> > >> > >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > >> > >> > DEBUG 1: Default Config File:
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> > >> > >> > WARNING:
> > >> > >> > WARNING: NcCfFile::open() -> could not extract init time
from
> > file
> > >> > name
> > >> > >> > WARNING: Using init time of 0
> > >> > >> > WARNING:
> > >> > >> > ERROR :
> > >> > >> > ERROR : process_command_line() -> The forecast and
observation
> > >> grids
> > >> > do
> > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
> > >> lon_ll:
> > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 != Projection:
Lat/Lon
> > Nx:
> > >> > 288
> > >> > >> Ny:
> > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
delta_lon:
> > 1.250
> > >> > >> > ERROR :
> > >> > >> >
> > >> > >> >
> > >> > >> > Interestingly, it seems that my forecast file grid looks
the
> same
> > >> as
> > >> > the
> > >> > >> > observation file grid as below:
> > >> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000 nxny
55008
> > >> > >> > long 0.625000 to 358.750000 by 1.250000, (288
x 191)
> > >> > >> >
> > >> > >> > However, grid_stat reads long 0.625000 as lon_ll:
-0.625,
> making
> > >> > error.
> > >> > >> >
> > >> > >> > Can anyone explain why?
> > >> > >> > Thank you very much.
> > >> > >> >
> > >> > >> > Regards,
> > >> > >> >
> > >> > >> > Jinwoong Yoo
> > >> > >> > UNM
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Wed Oct 08 14:25:50 2014
Jinwoong,
What you do with the statistical output that the MET tools generate
really
depends on what sort of question you're trying to answer. If you want
to
aggregate results across multiple runs of grid-stat, you can use
stat-analysis to do that. Alternatively, you could plot a time series
of
scores output from each run. It's really up to you to analyze and
make
sense of your statistical output.
Thanks,
John
On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
> Dear John,
>
> Yes. Disabling nc_pairs_flag did helped Grid_stat generating
statistics txt
> files.
> Then, I should run stat_analysis using the grid_stat outputs right?
>
> Thank you.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
>
>
> On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT <
> met_help at ucar.edu
> > wrote:
>
> > Jinwoong,
> >
> > Try editing your Grid-Stat config file by setting:
> > nc_pairs_flag = FALSE;
> >
> > We're getting a weird error when Grid-Stat tries to write the
NetCDF
> output
> > file:
> > NetCDF: Numeric conversion not representable
> >
> > That's causing you to see empty output files.
> >
> > I'll look into the source of this error, but for now, just disable
the
> > NetCDF matched pairs output.
> >
> > Thanks,
> > John
> >
> >
> > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > >
> > > Dear John,
> > >
> > > Maybe should I use gen_poly_mask to define the area of my WRF
model
> > domain
> > > (which is a tropical channel) before I run grid_stat against the
CCSM4
> in
> > > global domain?
> > >
> > > Jinwoong Yoo
> > > UNM
> > >
> > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > > > Dear John,
> > > >
> > > > I switched variable to PRMSL (sea level pressure) for a
Grid_stat
> test.
> > > > Grid_stat seemed to run this time but produced files were
empty.
> > > >
> > > > However, when I produced a ps file for the variable, the
output file
> > > looks
> > > > ok (attached).
> > > >
> > > > [jyoo at yslogin6 postprd]$
> > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > > [jyoo at yslogin6 postprd]$
> > > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
> > > >
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
> > > >
> > > > Do I need to change other information for dictionary parts for
the
> > > > variables being compared in the GridStatConfig_ccsm file
(attached
> > also)?
> > > > Where can I find more detail information about the
GridStatConfig
> than
> > in
> > > > the MET Users Guide V5.0, if available?
> > > >
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong Yoo
> > > > UNM
> > > >
> > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Jinwoong,
> > > >>
> > > >> OK, I updated the build on yellowstone to include the latest
set of
> > > >> patches:
> > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > > >>
> > > >> The original, as released, version of met-5.0 can still be
found
> here:
> > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> > > >>
> > > >> Please give the updated version a shot and let me know how it
goes.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu>
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > > >> >
> > > >> > Dear John,
> > > >> >
> > > >> > Since I'm using the MET that is available on the
Yellowstone
> > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> > > >> > you can just let me know how I can use the patch for
reading the
> > > lat/lon
> > > >> > dimensions of the CCSM4 file in the Yellowstone.
> > > >> >
> > > >> > Thank you.
> > > >> >
> > > >> > Regards,
> > > >> > Jinwoong Yoo
> > > >> > UNM
> > > >> >
> > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Dear John
> > > >> > >
> > > >> > > First of all, thank you for your efforts to figure out
the issue
> > > with
> > > >> > > Grid_stat of my case.
> > > >> > >
> > > >> > > >>> Do you expect this or should there be some non-zero
values?
> > > >> > >
> > > >> > > This is a test case with precipitation variables from the
WRF
> and
> > > >> CCSM4
> > > >> > at
> > > >> > > model initialization time 00. So, 0 is reasonable
although I did
> > not
> > > >> > > consider carefully when I pick the variable for a test
case.
> > > >> > >
> > > >> > > >>>After running this through the debugger, I found that
MET is
> > > >> getting
> > > >> > > confused by the presence of the slat and slon variables.
It's
> > using
> > > >> them
> > > >> > > to define the grid rather than the lat and lon variables.
And
> > that
> > > >> leads
> > > >> > > to the difference in the grids.
> > > >> > >
> > > >> > > That's one thing that I mentioned in my previous email:
> > > >> > > "However, there are something strange.
> > > >> > > According to what Grid-Stat reads in for the CCSM4 file
> > (Projection:
> > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat:
> > > 0.942
> > > >> > > delta_lon: 1.250), lat and lon information were flipped
compared
> > to
> > > >> what
> > > >> > I
> > > >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon = 288
; slat
> =
> > > 191
> > > >> > ;slon
> > > >> > > = 288) and the Ny: 191 matches to slat(staggered
latitude) not
> > > >> latitude."
> > > >> > > I'm glad you found a solution to the issue with NC file
with two
> > > >> > different
> > > >> > > pair of lat (lat and slat) and lon (lon and slon).
> > > >> > >
> > > >> > >
> > > >> > > >>> So we need to rerun copygb to put the GRIB1 data onto
this
> > grid:
> > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750
1250
> 942
> > > 64*"
> > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > >> > >
> > > >> > > Running copygb is not a big deal at all.
> > > >> > >
> > > >> > > >>> After doing that, I was finally able to run grid_stat
to
> > compare
> > > >> > these
> > > >> > > fields. But since the forecast contains all 0's and the
> > observation
> > > >> > > basically contains all 0's, I didn't get any meaningful
> > statistics.
> > > >> > >
> > > >> > >
> > > >> > > I can switch to a different variable than the
precipitation at
> the
> > > >> > > initialization time for a test.
> > > >> > > Please send me the patch for reading the lat/lon
dimensions via
> > > email
> > > >> or
> > > >> > > you can put the file(s) on the Yellowstone and let me
know the
> > path
> > > to
> > > >> > the
> > > >> > > file(s), whatever suits you best.
> > > >> > >
> > > >> > > Thank you very much.
> > > >> > >
> > > >> > > Regards,
> > > >> > >
> > > >> > > Jinwoong Yoo
> > > >> > > UNM
> > > >> > >
> > > >> > >
> > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via
RT <
> > > >> > > met_help at ucar.edu> wrote:
> > > >> > >
> > > >> > >> Jinwoong,
> > > >> > >>
> > > >> > >> I see that you're having problems comparing a GRIB1 file
to a
> > > >> > CF-compliant
> > > >> > >> NetCDF file using the grid_stat tool.
> > > >> > >>
> > > >> > >> I ran grid_stat and the plot_data_plane tools through
the
> > debugger
> > > >> and
> > > >> > >> found some issues.
> > > >> > >>
> > > >> > >> First, I ran the following plot_data_plane command to
plot the
> > > CPRAT
> > > >> > >> variable from the GRIB1 file:
> > > >> > >> met-5.0/bin/plot_data_plane \
> > > >> > >> WRFPRS_d01.00_2latlon \
> > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > > >> > >> 'name="CPRAT"; level="L0";'
> > > >> > >>
> > > >> > >> Turns out that all the values are 0. This can also be
seen via
> > > >> wgrib:
> > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > > >> > >> ...
> > > >> > >> min/max data 0 0
> > > >> > >>
> > > >> > >> Do you expect this or should there be some non-zero
values?
> > > >> > >>
> > > >> > >> Second, I looked at the PRECC variable using ncview and
see
> that
> > it
> > > >> > ranges
> > > >> > >> from 0 to 1.157e-06. Those values are so small that the
MET
> > tools
> > > >> won't
> > > >> > >> really be able to distinguish between them.
> > > >> > >>
> > > >> > >> Next, I tried running the NetCDF data through
plot_data_plane,
> > but
> > > >> got
> > > >> > >> this
> > > >> > >> error:
> > > >> > >> met-5.0/bin/plot_data_plane \
> > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > > >> > >>
> > > >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &,
DataPlane
> &)
> > > >> const
> > > >> > ->
> > > >> > >> star found in bad slot
> > > >> > >>
> > > >> > >> After running this through the debugger, I found that
MET is
> > > getting
> > > >> > >> confused by the presence of the slat and slon variables.
It's
> > > using
> > > >> > them
> > > >> > >> to define the grid rather than the lat and lon
variables. And
> > that
> > > >> > leads
> > > >> > >> to the difference in the grids. Also, MET stores
longitude
> > values
> > > >> > >> internally in degrees_west rather than the more common
> > > degrees_east.
> > > >> > When
> > > >> > >> you see -0.625 degrees longitude, that's degrees_west.
Very
> > > >> confusing,
> > > >> > I
> > > >> > >> know!
> > > >> > >>
> > > >> > >> I tweaked the NetCDF CF code to print warning messages
when it
> > > >> > encounters
> > > >> > >> multiple variables for latitude and longitude, and to
use the
> > first
> > > >> > >> instance of them rather than the second.
> > > >> > >>
> > > >> > >> Doing so enables me to run plot_data_plane. But when I
run
> > through
> > > >> > >> grid_stat, I get the following error:
> > > >> > >>
> > > >> > >> ERROR : process_command_line() -> The forecast and
observation
> > > >> grids do
> > > >> > >> not match:
> > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> > -0.625
> > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000
lon_ll:
> > -0.000
> > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > > >> > >>
> > > >> > >> So we need to rerun copygb to put the GRIB1 data onto
this
> grid:
> > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000 358750
1250
> 942
> > > >> 64*"
> > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > >> > >>
> > > >> > >> After doing that, I was finally able to run grid_stat to
> compare
> > > >> these
> > > >> > >> fields. But since the forecast contains all 0's and the
> > > observation
> > > >> > >> basically contains all 0's, I didn't get any meaningful
> > statistics.
> > > >> > >>
> > > >> > >> Seems like I need to get you that patch for reading the
lat/lon
> > > >> > >> dimensions. You need to start using the copygb command
listed
> > > above
> > > >> for
> > > >> > >> regridding GRIB files. And you need to figure out why
your
> data
> > is
> > > >> all
> > > >> > >> 0's.
> > > >> > >>
> > > >> > >> How does that all sound?
> > > >> > >>
> > > >> > >> Thanks,
> > > >> > >> John Halley Gotway
> > > >> > >> met_help at ucar.edu
> > > >> > >>
> > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
> > > >> met_help at ucar.edu>
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> >
> > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted
upon.
> > > >> > >> > Transaction: Ticket created by jinwoong.yoo at gmail.com
> > > >> > >> > Queue: met_help
> > > >> > >> > Subject: grid_stat Error
> > > >> > >> > Owner: Nobody
> > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > > >> > >> > Status: new
> > > >> > >> > Ticket <URL:
> > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > >> > >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > Dear WRF Help and MET Help
> > > >> > >> >
> > > >> > >> > Grid_stat produced error message below and stopped:
> > > >> > >> > [jyoo at yslogin4 analysis]$
> > > >> > >> > /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/grid_stat
> > > >> > >> >
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
GridStatConfig_ccsm
> > > >> -outdir
> > > >> > >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > > >> > >> > DEBUG 1: Default Config File:
> > > >> > >> >
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > > >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> > > >> > >> > WARNING:
> > > >> > >> > WARNING: NcCfFile::open() -> could not extract init
time from
> > > file
> > > >> > name
> > > >> > >> > WARNING: Using init time of 0
> > > >> > >> > WARNING:
> > > >> > >> > ERROR :
> > > >> > >> > ERROR : process_command_line() -> The forecast and
> observation
> > > >> grids
> > > >> > do
> > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
> -89.529
> > > >> lon_ll:
> > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
Projection:
> Lat/Lon
> > > Nx:
> > > >> > 288
> > > >> > >> Ny:
> > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
delta_lon:
> > > 1.250
> > > >> > >> > ERROR :
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > Interestingly, it seems that my forecast file grid
looks the
> > same
> > > >> as
> > > >> > the
> > > >> > >> > observation file grid as below:
> > > >> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000
nxny
> 55008
> > > >> > >> > long 0.625000 to 358.750000 by 1.250000,
(288 x
> 191)
> > > >> > >> >
> > > >> > >> > However, grid_stat reads long 0.625000 as lon_ll:
-0.625,
> > making
> > > >> > error.
> > > >> > >> >
> > > >> > >> > Can anyone explain why?
> > > >> > >> > Thank you very much.
> > > >> > >> >
> > > >> > >> > Regards,
> > > >> > >> >
> > > >> > >> > Jinwoong Yoo
> > > >> > >> > UNM
> > > >> > >> >
> > > >> > >> >
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Wed Oct 08 15:23:44 2014
Dear John,
At present, I just would like to get the general idea about using MET
through Grid_stat and eventually I'd like to run series-analysis so
that I
can evaluate the WRF simulation performance against the CCSM4 over the
10
years period of integral.
In other words, I would like to get the time series of scores for a
few
variables such as T2, PSL, soil moisture, precipitation, snowfall,
etc.
Then, what will be the next step for the most economic way?
Thank you.
Regards,
Jinwoong Yoo
UNM
On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> What you do with the statistical output that the MET tools generate
really
> depends on what sort of question you're trying to answer. If you
want to
> aggregate results across multiple runs of grid-stat, you can use
> stat-analysis to do that. Alternatively, you could plot a time
series of
> scores output from each run. It's really up to you to analyze and
make
> sense of your statistical output.
>
> Thanks,
> John
>
> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> > Dear John,
> >
> > Yes. Disabling nc_pairs_flag did helped Grid_stat generating
statistics
> txt
> > files.
> > Then, I should run stat_analysis using the grid_stat outputs
right?
> >
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> >
> >
> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > > Jinwoong,
> > >
> > > Try editing your Grid-Stat config file by setting:
> > > nc_pairs_flag = FALSE;
> > >
> > > We're getting a weird error when Grid-Stat tries to write the
NetCDF
> > output
> > > file:
> > > NetCDF: Numeric conversion not representable
> > >
> > > That's causing you to see empty output files.
> > >
> > > I'll look into the source of this error, but for now, just
disable the
> > > NetCDF matched pairs output.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>
> > > >
> > > > Dear John,
> > > >
> > > > Maybe should I use gen_poly_mask to define the area of my WRF
model
> > > domain
> > > > (which is a tropical channel) before I run grid_stat against
the
> CCSM4
> > in
> > > > global domain?
> > > >
> > > > Jinwoong Yoo
> > > > UNM
> > > >
> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> > > > wrote:
> > > >
> > > > > Dear John,
> > > > >
> > > > > I switched variable to PRMSL (sea level pressure) for a
Grid_stat
> > test.
> > > > > Grid_stat seemed to run this time but produced files were
empty.
> > > > >
> > > > > However, when I produced a ps file for the variable, the
output
> file
> > > > looks
> > > > > ok (attached).
> > > > >
> > > > > [jyoo at yslogin6 postprd]$
> > > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > > > [jyoo at yslogin6 postprd]$
> > > > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
> > > > >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
> > > > >
> > > > > Do I need to change other information for dictionary parts
for the
> > > > > variables being compared in the GridStatConfig_ccsm file
(attached
> > > also)?
> > > > > Where can I find more detail information about the
GridStatConfig
> > than
> > > in
> > > > > the MET Users Guide V5.0, if available?
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jinwoong Yoo
> > > > > UNM
> > > > >
> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Jinwoong,
> > > > >>
> > > > >> OK, I updated the build on yellowstone to include the
latest set
> of
> > > > >> patches:
> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > > > >>
> > > > >> The original, as released, version of met-5.0 can still be
found
> > here:
> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> > > > >>
> > > > >> Please give the updated version a shot and let me know how
it
> goes.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu>
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > > > >> >
> > > > >> > Dear John,
> > > > >> >
> > > > >> > Since I'm using the MET that is available on the
Yellowstone
> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> > > > >> > you can just let me know how I can use the patch for
reading the
> > > > lat/lon
> > > > >> > dimensions of the CCSM4 file in the Yellowstone.
> > > > >> >
> > > > >> > Thank you.
> > > > >> >
> > > > >> > Regards,
> > > > >> > Jinwoong Yoo
> > > > >> > UNM
> > > > >> >
> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Dear John
> > > > >> > >
> > > > >> > > First of all, thank you for your efforts to figure out
the
> issue
> > > > with
> > > > >> > > Grid_stat of my case.
> > > > >> > >
> > > > >> > > >>> Do you expect this or should there be some non-zero
> values?
> > > > >> > >
> > > > >> > > This is a test case with precipitation variables from
the WRF
> > and
> > > > >> CCSM4
> > > > >> > at
> > > > >> > > model initialization time 00. So, 0 is reasonable
although I
> did
> > > not
> > > > >> > > consider carefully when I pick the variable for a test
case.
> > > > >> > >
> > > > >> > > >>>After running this through the debugger, I found
that MET
> is
> > > > >> getting
> > > > >> > > confused by the presence of the slat and slon
variables. It's
> > > using
> > > > >> them
> > > > >> > > to define the grid rather than the lat and lon
variables. And
> > > that
> > > > >> leads
> > > > >> > > to the difference in the grids.
> > > > >> > >
> > > > >> > > That's one thing that I mentioned in my previous email:
> > > > >> > > "However, there are something strange.
> > > > >> > > According to what Grid-Stat reads in for the CCSM4 file
> > > (Projection:
> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625
> delta_lat:
> > > > 0.942
> > > > >> > > delta_lon: 1.250), lat and lon information were flipped
> compared
> > > to
> > > > >> what
> > > > >> > I
> > > > >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon =
288 ;
> slat
> > =
> > > > 191
> > > > >> > ;slon
> > > > >> > > = 288) and the Ny: 191 matches to slat(staggered
latitude) not
> > > > >> latitude."
> > > > >> > > I'm glad you found a solution to the issue with NC file
with
> two
> > > > >> > different
> > > > >> > > pair of lat (lat and slat) and lon (lon and slon).
> > > > >> > >
> > > > >> > >
> > > > >> > > >>> So we need to rerun copygb to put the GRIB1 data
onto this
> > > grid:
> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750 1250
> > 942
> > > > 64*"
> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > > >> > >
> > > > >> > > Running copygb is not a big deal at all.
> > > > >> > >
> > > > >> > > >>> After doing that, I was finally able to run
grid_stat to
> > > compare
> > > > >> > these
> > > > >> > > fields. But since the forecast contains all 0's and
the
> > > observation
> > > > >> > > basically contains all 0's, I didn't get any meaningful
> > > statistics.
> > > > >> > >
> > > > >> > >
> > > > >> > > I can switch to a different variable than the
precipitation at
> > the
> > > > >> > > initialization time for a test.
> > > > >> > > Please send me the patch for reading the lat/lon
dimensions
> via
> > > > email
> > > > >> or
> > > > >> > > you can put the file(s) on the Yellowstone and let me
know the
> > > path
> > > > to
> > > > >> > the
> > > > >> > > file(s), whatever suits you best.
> > > > >> > >
> > > > >> > > Thank you very much.
> > > > >> > >
> > > > >> > > Regards,
> > > > >> > >
> > > > >> > > Jinwoong Yoo
> > > > >> > > UNM
> > > > >> > >
> > > > >> > >
> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway via
RT <
> > > > >> > > met_help at ucar.edu> wrote:
> > > > >> > >
> > > > >> > >> Jinwoong,
> > > > >> > >>
> > > > >> > >> I see that you're having problems comparing a GRIB1
file to a
> > > > >> > CF-compliant
> > > > >> > >> NetCDF file using the grid_stat tool.
> > > > >> > >>
> > > > >> > >> I ran grid_stat and the plot_data_plane tools through
the
> > > debugger
> > > > >> and
> > > > >> > >> found some issues.
> > > > >> > >>
> > > > >> > >> First, I ran the following plot_data_plane command to
plot
> the
> > > > CPRAT
> > > > >> > >> variable from the GRIB1 file:
> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > >> > >> WRFPRS_d01.00_2latlon \
> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > > > >> > >> 'name="CPRAT"; level="L0";'
> > > > >> > >>
> > > > >> > >> Turns out that all the values are 0. This can also be
seen
> via
> > > > >> wgrib:
> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > > > >> > >> ...
> > > > >> > >> min/max data 0 0
> > > > >> > >>
> > > > >> > >> Do you expect this or should there be some non-zero
values?
> > > > >> > >>
> > > > >> > >> Second, I looked at the PRECC variable using ncview
and see
> > that
> > > it
> > > > >> > ranges
> > > > >> > >> from 0 to 1.157e-06. Those values are so small that
the MET
> > > tools
> > > > >> won't
> > > > >> > >> really be able to distinguish between them.
> > > > >> > >>
> > > > >> > >> Next, I tried running the NetCDF data through
> plot_data_plane,
> > > but
> > > > >> got
> > > > >> > >> this
> > > > >> > >> error:
> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > > > >> > >>
> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &,
DataPlane
> > &)
> > > > >> const
> > > > >> > ->
> > > > >> > >> star found in bad slot
> > > > >> > >>
> > > > >> > >> After running this through the debugger, I found that
MET is
> > > > getting
> > > > >> > >> confused by the presence of the slat and slon
variables.
> It's
> > > > using
> > > > >> > them
> > > > >> > >> to define the grid rather than the lat and lon
variables.
> And
> > > that
> > > > >> > leads
> > > > >> > >> to the difference in the grids. Also, MET stores
longitude
> > > values
> > > > >> > >> internally in degrees_west rather than the more common
> > > > degrees_east.
> > > > >> > When
> > > > >> > >> you see -0.625 degrees longitude, that's degrees_west.
Very
> > > > >> confusing,
> > > > >> > I
> > > > >> > >> know!
> > > > >> > >>
> > > > >> > >> I tweaked the NetCDF CF code to print warning messages
when
> it
> > > > >> > encounters
> > > > >> > >> multiple variables for latitude and longitude, and to
use the
> > > first
> > > > >> > >> instance of them rather than the second.
> > > > >> > >>
> > > > >> > >> Doing so enables me to run plot_data_plane. But when
I run
> > > through
> > > > >> > >> grid_stat, I get the following error:
> > > > >> > >>
> > > > >> > >> ERROR : process_command_line() -> The forecast and
> observation
> > > > >> grids do
> > > > >> > >> not match:
> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> > > -0.625
> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000
lon_ll:
> > > -0.000
> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > > > >> > >>
> > > > >> > >> So we need to rerun copygb to put the GRIB1 data onto
this
> > grid:
> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750 1250
> > 942
> > > > >> 64*"
> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > > >> > >>
> > > > >> > >> After doing that, I was finally able to run grid_stat
to
> > compare
> > > > >> these
> > > > >> > >> fields. But since the forecast contains all 0's and
the
> > > > observation
> > > > >> > >> basically contains all 0's, I didn't get any
meaningful
> > > statistics.
> > > > >> > >>
> > > > >> > >> Seems like I need to get you that patch for reading
the
> lat/lon
> > > > >> > >> dimensions. You need to start using the copygb
command
> listed
> > > > above
> > > > >> for
> > > > >> > >> regridding GRIB files. And you need to figure out why
your
> > data
> > > is
> > > > >> all
> > > > >> > >> 0's.
> > > > >> > >>
> > > > >> > >> How does that all sound?
> > > > >> > >>
> > > > >> > >> Thanks,
> > > > >> > >> John Halley Gotway
> > > > >> > >> met_help at ucar.edu
> > > > >> > >>
> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
> > > > >> met_help at ucar.edu>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> >
> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted
upon.
> > > > >> > >> > Transaction: Ticket created by
jinwoong.yoo at gmail.com
> > > > >> > >> > Queue: met_help
> > > > >> > >> > Subject: grid_stat Error
> > > > >> > >> > Owner: Nobody
> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > > > >> > >> > Status: new
> > > > >> > >> > Ticket <URL:
> > > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > >> > >
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >> > Dear WRF Help and MET Help
> > > > >> > >> >
> > > > >> > >> > Grid_stat produced error message below and stopped:
> > > > >> > >> > [jyoo at yslogin4 analysis]$
> > > > >> > >> > /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/grid_stat
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
> GridStatConfig_ccsm
> > > > >> -outdir
> > > > >> > >> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > > > >> > >> > DEBUG 1: Default Config File:
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> >
> > > > >>
> > > >
> > >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > > > >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> > > > >> > >> > WARNING:
> > > > >> > >> > WARNING: NcCfFile::open() -> could not extract init
time
> from
> > > > file
> > > > >> > name
> > > > >> > >> > WARNING: Using init time of 0
> > > > >> > >> > WARNING:
> > > > >> > >> > ERROR :
> > > > >> > >> > ERROR : process_command_line() -> The forecast and
> > observation
> > > > >> grids
> > > > >> > do
> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191
lat_ll:
> > -89.529
> > > > >> lon_ll:
> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
Projection:
> > Lat/Lon
> > > > Nx:
> > > > >> > 288
> > > > >> > >> Ny:
> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
> delta_lon:
> > > > 1.250
> > > > >> > >> > ERROR :
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >> > Interestingly, it seems that my forecast file grid
looks
> the
> > > same
> > > > >> as
> > > > >> > the
> > > > >> > >> > observation file grid as below:
> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000
nxny
> > 55008
> > > > >> > >> > long 0.625000 to 358.750000 by 1.250000,
(288 x
> > 191)
> > > > >> > >> >
> > > > >> > >> > However, grid_stat reads long 0.625000 as lon_ll:
-0.625,
> > > making
> > > > >> > error.
> > > > >> > >> >
> > > > >> > >> > Can anyone explain why?
> > > > >> > >> > Thank you very much.
> > > > >> > >> >
> > > > >> > >> > Regards,
> > > > >> > >> >
> > > > >> > >> > Jinwoong Yoo
> > > > >> > >> > UNM
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Wed Oct 08 15:23:44 2014
By the way,
Since I didn't get the nc file from Grid_stat by disabling the option,
It's
a bit hard to understand the output of grid_stat now.
Could you figure out what should be done to get the nc file from
grid_stat?
Thank you.
Regards,
Jinwoong Yoo
UNM
On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Dear John,
>
> At present, I just would like to get the general idea about using
MET
> through Grid_stat and eventually I'd like to run series-analysis so
that I
> can evaluate the WRF simulation performance against the CCSM4 over
the 10
> years period of integral.
>
> In other words, I would like to get the time series of scores for a
few
> variables such as T2, PSL, soil moisture, precipitation, snowfall,
etc.
>
> Then, what will be the next step for the most economic way?
> Thank you.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
> On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> What you do with the statistical output that the MET tools generate
really
>> depends on what sort of question you're trying to answer. If you
want to
>> aggregate results across multiple runs of grid-stat, you can use
>> stat-analysis to do that. Alternatively, you could plot a time
series of
>> scores output from each run. It's really up to you to analyze and
make
>> sense of your statistical output.
>>
>> Thanks,
>> John
>>
>> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>> >
>> > Dear John,
>> >
>> > Yes. Disabling nc_pairs_flag did helped Grid_stat generating
statistics
>> txt
>> > files.
>> > Then, I should run stat_analysis using the grid_stat outputs
right?
>> >
>> > Thank you.
>> >
>> > Regards,
>> >
>> > Jinwoong Yoo
>> > UNM
>> >
>> >
>> >
>> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu
>> > > wrote:
>> >
>> > > Jinwoong,
>> > >
>> > > Try editing your Grid-Stat config file by setting:
>> > > nc_pairs_flag = FALSE;
>> > >
>> > > We're getting a weird error when Grid-Stat tries to write the
NetCDF
>> > output
>> > > file:
>> > > NetCDF: Numeric conversion not representable
>> > >
>> > > That's causing you to see empty output files.
>> > >
>> > > I'll look into the source of this error, but for now, just
disable the
>> > > NetCDF matched pairs output.
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > >
>> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>
>> > > >
>> > > > Dear John,
>> > > >
>> > > > Maybe should I use gen_poly_mask to define the area of my WRF
model
>> > > domain
>> > > > (which is a tropical channel) before I run grid_stat against
the
>> CCSM4
>> > in
>> > > > global domain?
>> > > >
>> > > > Jinwoong Yoo
>> > > > UNM
>> > > >
>> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
>> jinwoong.yoo at gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Dear John,
>> > > > >
>> > > > > I switched variable to PRMSL (sea level pressure) for a
Grid_stat
>> > test.
>> > > > > Grid_stat seemed to run this time but produced files were
empty.
>> > > > >
>> > > > > However, when I produced a ps file for the variable, the
output
>> file
>> > > > looks
>> > > > > ok (attached).
>> > > > >
>> > > > > [jyoo at yslogin6 postprd]$
>> > > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
>> > > > > [jyoo at yslogin6 postprd]$
>> > > > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
>> > > > >
>>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
>> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL"; level="L0";'
>> > > > >
>> > > > > Do I need to change other information for dictionary parts
for the
>> > > > > variables being compared in the GridStatConfig_ccsm file
(attached
>> > > also)?
>> > > > > Where can I find more detail information about the
GridStatConfig
>> > than
>> > > in
>> > > > > the MET Users Guide V5.0, if available?
>> > > > >
>> > > > > Thank you.
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > Jinwoong Yoo
>> > > > > UNM
>> > > > >
>> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT <
>> > > > > met_help at ucar.edu> wrote:
>> > > > >
>> > > > >> Jinwoong,
>> > > > >>
>> > > > >> OK, I updated the build on yellowstone to include the
latest set
>> of
>> > > > >> patches:
>> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
>> > > > >>
>> > > > >> The original, as released, version of met-5.0 can still be
found
>> > here:
>> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
>> > > > >>
>> > > > >> Please give the updated version a shot and let me know how
it
>> goes.
>> > > > >>
>> > > > >> Thanks,
>> > > > >> John
>> > > > >>
>> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT <
>> > > met_help at ucar.edu>
>> > > > >> wrote:
>> > > > >>
>> > > > >> >
>> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>> >
>> > > > >> >
>> > > > >> > Dear John,
>> > > > >> >
>> > > > >> > Since I'm using the MET that is available on the
Yellowstone
>> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
>> > > > >> > you can just let me know how I can use the patch for
reading
>> the
>> > > > lat/lon
>> > > > >> > dimensions of the CCSM4 file in the Yellowstone.
>> > > > >> >
>> > > > >> > Thank you.
>> > > > >> >
>> > > > >> > Regards,
>> > > > >> > Jinwoong Yoo
>> > > > >> > UNM
>> > > > >> >
>> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
>> > > jinwoong.yoo at gmail.com>
>> > > > >> > wrote:
>> > > > >> >
>> > > > >> > > Dear John
>> > > > >> > >
>> > > > >> > > First of all, thank you for your efforts to figure out
the
>> issue
>> > > > with
>> > > > >> > > Grid_stat of my case.
>> > > > >> > >
>> > > > >> > > >>> Do you expect this or should there be some non-
zero
>> values?
>> > > > >> > >
>> > > > >> > > This is a test case with precipitation variables from
the WRF
>> > and
>> > > > >> CCSM4
>> > > > >> > at
>> > > > >> > > model initialization time 00. So, 0 is reasonable
although I
>> did
>> > > not
>> > > > >> > > consider carefully when I pick the variable for a test
case.
>> > > > >> > >
>> > > > >> > > >>>After running this through the debugger, I found
that MET
>> is
>> > > > >> getting
>> > > > >> > > confused by the presence of the slat and slon
variables.
>> It's
>> > > using
>> > > > >> them
>> > > > >> > > to define the grid rather than the lat and lon
variables.
>> And
>> > > that
>> > > > >> leads
>> > > > >> > > to the difference in the grids.
>> > > > >> > >
>> > > > >> > > That's one thing that I mentioned in my previous
email:
>> > > > >> > > "However, there are something strange.
>> > > > >> > > According to what Grid-Stat reads in for the CCSM4
file
>> > > (Projection:
>> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll: 0.625
>> delta_lat:
>> > > > 0.942
>> > > > >> > > delta_lon: 1.250), lat and lon information were
flipped
>> compared
>> > > to
>> > > > >> what
>> > > > >> > I
>> > > > >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon =
288 ;
>> slat
>> > =
>> > > > 191
>> > > > >> > ;slon
>> > > > >> > > = 288) and the Ny: 191 matches to slat(staggered
latitude)
>> not
>> > > > >> latitude."
>> > > > >> > > I'm glad you found a solution to the issue with NC
file with
>> two
>> > > > >> > different
>> > > > >> > > pair of lat (lat and slat) and lon (lon and slon).
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > >>> So we need to rerun copygb to put the GRIB1 data
onto
>> this
>> > > grid:
>> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750 1250
>> > 942
>> > > > 64*"
>> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>> > > > >> > >
>> > > > >> > > Running copygb is not a big deal at all.
>> > > > >> > >
>> > > > >> > > >>> After doing that, I was finally able to run
grid_stat to
>> > > compare
>> > > > >> > these
>> > > > >> > > fields. But since the forecast contains all 0's and
the
>> > > observation
>> > > > >> > > basically contains all 0's, I didn't get any
meaningful
>> > > statistics.
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > I can switch to a different variable than the
precipitation
>> at
>> > the
>> > > > >> > > initialization time for a test.
>> > > > >> > > Please send me the patch for reading the lat/lon
dimensions
>> via
>> > > > email
>> > > > >> or
>> > > > >> > > you can put the file(s) on the Yellowstone and let me
know
>> the
>> > > path
>> > > > to
>> > > > >> > the
>> > > > >> > > file(s), whatever suits you best.
>> > > > >> > >
>> > > > >> > > Thank you very much.
>> > > > >> > >
>> > > > >> > > Regards,
>> > > > >> > >
>> > > > >> > > Jinwoong Yoo
>> > > > >> > > UNM
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway
via RT <
>> > > > >> > > met_help at ucar.edu> wrote:
>> > > > >> > >
>> > > > >> > >> Jinwoong,
>> > > > >> > >>
>> > > > >> > >> I see that you're having problems comparing a GRIB1
file to
>> a
>> > > > >> > CF-compliant
>> > > > >> > >> NetCDF file using the grid_stat tool.
>> > > > >> > >>
>> > > > >> > >> I ran grid_stat and the plot_data_plane tools through
the
>> > > debugger
>> > > > >> and
>> > > > >> > >> found some issues.
>> > > > >> > >>
>> > > > >> > >> First, I ran the following plot_data_plane command to
plot
>> the
>> > > > CPRAT
>> > > > >> > >> variable from the GRIB1 file:
>> > > > >> > >> met-5.0/bin/plot_data_plane \
>> > > > >> > >> WRFPRS_d01.00_2latlon \
>> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
>> > > > >> > >> 'name="CPRAT"; level="L0";'
>> > > > >> > >>
>> > > > >> > >> Turns out that all the values are 0. This can also
be seen
>> via
>> > > > >> wgrib:
>> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
>> > > > >> > >> ...
>> > > > >> > >> min/max data 0 0
>> > > > >> > >>
>> > > > >> > >> Do you expect this or should there be some non-zero
values?
>> > > > >> > >>
>> > > > >> > >> Second, I looked at the PRECC variable using ncview
and see
>> > that
>> > > it
>> > > > >> > ranges
>> > > > >> > >> from 0 to 1.157e-06. Those values are so small that
the MET
>> > > tools
>> > > > >> won't
>> > > > >> > >> really be able to distinguish between them.
>> > > > >> > >>
>> > > > >> > >> Next, I tried running the NetCDF data through
>> plot_data_plane,
>> > > but
>> > > > >> got
>> > > > >> > >> this
>> > > > >> > >> error:
>> > > > >> > >> met-5.0/bin/plot_data_plane \
>> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
>> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
>> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
>> > > > >> > >>
>> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &,
>> DataPlane
>> > &)
>> > > > >> const
>> > > > >> > ->
>> > > > >> > >> star found in bad slot
>> > > > >> > >>
>> > > > >> > >> After running this through the debugger, I found that
MET is
>> > > > getting
>> > > > >> > >> confused by the presence of the slat and slon
variables.
>> It's
>> > > > using
>> > > > >> > them
>> > > > >> > >> to define the grid rather than the lat and lon
variables.
>> And
>> > > that
>> > > > >> > leads
>> > > > >> > >> to the difference in the grids. Also, MET stores
longitude
>> > > values
>> > > > >> > >> internally in degrees_west rather than the more
common
>> > > > degrees_east.
>> > > > >> > When
>> > > > >> > >> you see -0.625 degrees longitude, that's
degrees_west. Very
>> > > > >> confusing,
>> > > > >> > I
>> > > > >> > >> know!
>> > > > >> > >>
>> > > > >> > >> I tweaked the NetCDF CF code to print warning
messages when
>> it
>> > > > >> > encounters
>> > > > >> > >> multiple variables for latitude and longitude, and to
use
>> the
>> > > first
>> > > > >> > >> instance of them rather than the second.
>> > > > >> > >>
>> > > > >> > >> Doing so enables me to run plot_data_plane. But when
I run
>> > > through
>> > > > >> > >> grid_stat, I get the following error:
>> > > > >> > >>
>> > > > >> > >> ERROR : process_command_line() -> The forecast and
>> observation
>> > > > >> grids do
>> > > > >> > >> not match:
>> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
>> > > -0.625
>> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
>> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000
lon_ll:
>> > > -0.000
>> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
>> > > > >> > >>
>> > > > >> > >> So we need to rerun copygb to put the GRIB1 data onto
this
>> > grid:
>> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750
>> 1250
>> > 942
>> > > > >> 64*"
>> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
>> > > > >> > >>
>> > > > >> > >> After doing that, I was finally able to run grid_stat
to
>> > compare
>> > > > >> these
>> > > > >> > >> fields. But since the forecast contains all 0's and
the
>> > > > observation
>> > > > >> > >> basically contains all 0's, I didn't get any
meaningful
>> > > statistics.
>> > > > >> > >>
>> > > > >> > >> Seems like I need to get you that patch for reading
the
>> lat/lon
>> > > > >> > >> dimensions. You need to start using the copygb
command
>> listed
>> > > > above
>> > > > >> for
>> > > > >> > >> regridding GRIB files. And you need to figure out
why your
>> > data
>> > > is
>> > > > >> all
>> > > > >> > >> 0's.
>> > > > >> > >>
>> > > > >> > >> How does that all sound?
>> > > > >> > >>
>> > > > >> > >> Thanks,
>> > > > >> > >> John Halley Gotway
>> > > > >> > >> met_help at ucar.edu
>> > > > >> > >>
>> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT <
>> > > > >> met_help at ucar.edu>
>> > > > >> > >> wrote:
>> > > > >> > >>
>> > > > >> > >> >
>> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted
upon.
>> > > > >> > >> > Transaction: Ticket created by
jinwoong.yoo at gmail.com
>> > > > >> > >> > Queue: met_help
>> > > > >> > >> > Subject: grid_stat Error
>> > > > >> > >> > Owner: Nobody
>> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
>> > > > >> > >> > Status: new
>> > > > >> > >> > Ticket <URL:
>> > > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>> > > > >> > >
>> > > > >> > >> >
>> > > > >> > >> >
>> > > > >> > >> > Dear WRF Help and MET Help
>> > > > >> > >> >
>> > > > >> > >> > Grid_stat produced error message below and stopped:
>> > > > >> > >> > [jyoo at yslogin4 analysis]$
>> > > > >> > >> > /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/grid_stat
>> > > > >> > >> >
>> > > > >> > >> >
>> > > > >> > >>
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
>> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
>> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
>> GridStatConfig_ccsm
>> > > > >> -outdir
>> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/gridstatout
>> > > > >> > >> > DEBUG 1: Default Config File:
>> > > > >> > >> >
>> > > > >> > >> >
>> > > > >> > >>
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
>> > > > >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
>> > > > >> > >> > WARNING:
>> > > > >> > >> > WARNING: NcCfFile::open() -> could not extract init
time
>> from
>> > > > file
>> > > > >> > name
>> > > > >> > >> > WARNING: Using init time of 0
>> > > > >> > >> > WARNING:
>> > > > >> > >> > ERROR :
>> > > > >> > >> > ERROR : process_command_line() -> The forecast and
>> > observation
>> > > > >> grids
>> > > > >> > do
>> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191
lat_ll:
>> > -89.529
>> > > > >> lon_ll:
>> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
Projection:
>> > Lat/Lon
>> > > > Nx:
>> > > > >> > 288
>> > > > >> > >> Ny:
>> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat: 0.942
>> delta_lon:
>> > > > 1.250
>> > > > >> > >> > ERROR :
>> > > > >> > >> >
>> > > > >> > >> >
>> > > > >> > >> > Interestingly, it seems that my forecast file grid
looks
>> the
>> > > same
>> > > > >> as
>> > > > >> > the
>> > > > >> > >> > observation file grid as below:
>> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by 0.942000
nxny
>> > 55008
>> > > > >> > >> > long 0.625000 to 358.750000 by 1.250000,
(288 x
>> > 191)
>> > > > >> > >> >
>> > > > >> > >> > However, grid_stat reads long 0.625000 as lon_ll:
-0.625,
>> > > making
>> > > > >> > error.
>> > > > >> > >> >
>> > > > >> > >> > Can anyone explain why?
>> > > > >> > >> > Thank you very much.
>> > > > >> > >> >
>> > > > >> > >> > Regards,
>> > > > >> > >> >
>> > > > >> > >> > Jinwoong Yoo
>> > > > >> > >> > UNM
>> > > > >> > >> >
>> > > > >> > >> >
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >
>> > > > >> >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Tue Oct 14 14:56:48 2014
Jinwoong,
I apologize for the delay in providing a solution to this problem.
That
error is being caused by integer overflow when trying to write
unixtime
(seconds since Jan 1 1970) for the year 1870 as a variable attribute
to the
NetCDF output file. I just distributed a patch that checks for this
condition and, if overflow would happen, prints a warning and skips
writing
those values. Ultimately, we hope to come up with a better solution
in the
next release. But for now, this should get you past the error.
Please follow the instructions posted here to download and apply the
latest
set of patches for met-5.0:
http://www.dtcenter.org/met/users/support/known_issues/METv5.0/index.php
Please let me know if you continue to experience problems after
applying
these patches.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Wed, Oct 8, 2014 at 3:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
> By the way,
> Since I didn't get the nc file from Grid_stat by disabling the
option, It's
> a bit hard to understand the output of grid_stat now.
>
> Could you figure out what should be done to get the nc file from
grid_stat?
> Thank you.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
> On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Dear John,
> >
> > At present, I just would like to get the general idea about using
MET
> > through Grid_stat and eventually I'd like to run series-analysis
so that
> I
> > can evaluate the WRF simulation performance against the CCSM4 over
the 10
> > years period of integral.
> >
> > In other words, I would like to get the time series of scores for
a few
> > variables such as T2, PSL, soil moisture, precipitation, snowfall,
etc.
> >
> > Then, what will be the next step for the most economic way?
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> > On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> What you do with the statistical output that the MET tools
generate
> really
> >> depends on what sort of question you're trying to answer. If you
want
> to
> >> aggregate results across multiple runs of grid-stat, you can use
> >> stat-analysis to do that. Alternatively, you could plot a time
series
> of
> >> scores output from each run. It's really up to you to analyze
and make
> >> sense of your statistical output.
> >>
> >> Thanks,
> >> John
> >>
> >> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >> >
> >> > Dear John,
> >> >
> >> > Yes. Disabling nc_pairs_flag did helped Grid_stat generating
> statistics
> >> txt
> >> > files.
> >> > Then, I should run stat_analysis using the grid_stat outputs
right?
> >> >
> >> > Thank you.
> >> >
> >> > Regards,
> >> >
> >> > Jinwoong Yoo
> >> > UNM
> >> >
> >> >
> >> >
> >> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu
> >> > > wrote:
> >> >
> >> > > Jinwoong,
> >> > >
> >> > > Try editing your Grid-Stat config file by setting:
> >> > > nc_pairs_flag = FALSE;
> >> > >
> >> > > We're getting a weird error when Grid-Stat tries to write the
NetCDF
> >> > output
> >> > > file:
> >> > > NetCDF: Numeric conversion not representable
> >> > >
> >> > > That's causing you to see empty output files.
> >> > >
> >> > > I'll look into the source of this error, but for now, just
disable
> the
> >> > > NetCDF matched pairs output.
> >> > >
> >> > > Thanks,
> >> > > John
> >> > >
> >> > >
> >> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT <
> >> met_help at ucar.edu>
> >> > > wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >> > > >
> >> > > > Dear John,
> >> > > >
> >> > > > Maybe should I use gen_poly_mask to define the area of my
WRF
> model
> >> > > domain
> >> > > > (which is a tropical channel) before I run grid_stat
against the
> >> CCSM4
> >> > in
> >> > > > global domain?
> >> > > >
> >> > > > Jinwoong Yoo
> >> > > > UNM
> >> > > >
> >> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
> >> jinwoong.yoo at gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Dear John,
> >> > > > >
> >> > > > > I switched variable to PRMSL (sea level pressure) for a
> Grid_stat
> >> > test.
> >> > > > > Grid_stat seemed to run this time but produced files were
empty.
> >> > > > >
> >> > > > > However, when I produced a ps file for the variable, the
output
> >> file
> >> > > > looks
> >> > > > > ok (attached).
> >> > > > >
> >> > > > > [jyoo at yslogin6 postprd]$
> >> > > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> >> > > > > [jyoo at yslogin6 postprd]$
> >> > > > >
> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG/bin/plot_data_plane
> >> > > > >
> >>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> >> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL";
level="L0";'
> >> > > > >
> >> > > > > Do I need to change other information for dictionary
parts for
> the
> >> > > > > variables being compared in the GridStatConfig_ccsm file
> (attached
> >> > > also)?
> >> > > > > Where can I find more detail information about the
> GridStatConfig
> >> > than
> >> > > in
> >> > > > > the MET Users Guide V5.0, if available?
> >> > > > >
> >> > > > > Thank you.
> >> > > > >
> >> > > > > Regards,
> >> > > > >
> >> > > > > Jinwoong Yoo
> >> > > > > UNM
> >> > > > >
> >> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via RT
<
> >> > > > > met_help at ucar.edu> wrote:
> >> > > > >
> >> > > > >> Jinwoong,
> >> > > > >>
> >> > > > >> OK, I updated the build on yellowstone to include the
latest
> set
> >> of
> >> > > > >> patches:
> >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> >> > > > >>
> >> > > > >> The original, as released, version of met-5.0 can still
be
> found
> >> > here:
> >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> >> > > > >>
> >> > > > >> Please give the updated version a shot and let me know
how it
> >> goes.
> >> > > > >>
> >> > > > >> Thanks,
> >> > > > >> John
> >> > > > >>
> >> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT <
> >> > > met_help at ucar.edu>
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >> >
> >> > > > >> > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> >> >
> >> > > > >> >
> >> > > > >> > Dear John,
> >> > > > >> >
> >> > > > >> > Since I'm using the MET that is available on the
Yellowstone
> >> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> >> > > > >> > you can just let me know how I can use the patch for
reading
> >> the
> >> > > > lat/lon
> >> > > > >> > dimensions of the CCSM4 file in the Yellowstone.
> >> > > > >> >
> >> > > > >> > Thank you.
> >> > > > >> >
> >> > > > >> > Regards,
> >> > > > >> > Jinwoong Yoo
> >> > > > >> > UNM
> >> > > > >> >
> >> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> >> > > jinwoong.yoo at gmail.com>
> >> > > > >> > wrote:
> >> > > > >> >
> >> > > > >> > > Dear John
> >> > > > >> > >
> >> > > > >> > > First of all, thank you for your efforts to figure
out the
> >> issue
> >> > > > with
> >> > > > >> > > Grid_stat of my case.
> >> > > > >> > >
> >> > > > >> > > >>> Do you expect this or should there be some non-
zero
> >> values?
> >> > > > >> > >
> >> > > > >> > > This is a test case with precipitation variables
from the
> WRF
> >> > and
> >> > > > >> CCSM4
> >> > > > >> > at
> >> > > > >> > > model initialization time 00. So, 0 is reasonable
although
> I
> >> did
> >> > > not
> >> > > > >> > > consider carefully when I pick the variable for a
test
> case.
> >> > > > >> > >
> >> > > > >> > > >>>After running this through the debugger, I found
that
> MET
> >> is
> >> > > > >> getting
> >> > > > >> > > confused by the presence of the slat and slon
variables.
> >> It's
> >> > > using
> >> > > > >> them
> >> > > > >> > > to define the grid rather than the lat and lon
variables.
> >> And
> >> > > that
> >> > > > >> leads
> >> > > > >> > > to the difference in the grids.
> >> > > > >> > >
> >> > > > >> > > That's one thing that I mentioned in my previous
email:
> >> > > > >> > > "However, there are something strange.
> >> > > > >> > > According to what Grid-Stat reads in for the CCSM4
file
> >> > > (Projection:
> >> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
0.625
> >> delta_lat:
> >> > > > 0.942
> >> > > > >> > > delta_lon: 1.250), lat and lon information were
flipped
> >> compared
> >> > > to
> >> > > > >> what
> >> > > > >> > I
> >> > > > >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon =
288 ;
> >> slat
> >> > =
> >> > > > 191
> >> > > > >> > ;slon
> >> > > > >> > > = 288) and the Ny: 191 matches to slat(staggered
latitude)
> >> not
> >> > > > >> latitude."
> >> > > > >> > > I'm glad you found a solution to the issue with NC
file
> with
> >> two
> >> > > > >> > different
> >> > > > >> > > pair of lat (lat and slat) and lon (lon and slon).
> >> > > > >> > >
> >> > > > >> > >
> >> > > > >> > > >>> So we need to rerun copygb to put the GRIB1 data
onto
> >> this
> >> > > grid:
> >> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750
> 1250
> >> > 942
> >> > > > 64*"
> >> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> >> > > > >> > >
> >> > > > >> > > Running copygb is not a big deal at all.
> >> > > > >> > >
> >> > > > >> > > >>> After doing that, I was finally able to run
grid_stat
> to
> >> > > compare
> >> > > > >> > these
> >> > > > >> > > fields. But since the forecast contains all 0's and
the
> >> > > observation
> >> > > > >> > > basically contains all 0's, I didn't get any
meaningful
> >> > > statistics.
> >> > > > >> > >
> >> > > > >> > >
> >> > > > >> > > I can switch to a different variable than the
precipitation
> >> at
> >> > the
> >> > > > >> > > initialization time for a test.
> >> > > > >> > > Please send me the patch for reading the lat/lon
dimensions
> >> via
> >> > > > email
> >> > > > >> or
> >> > > > >> > > you can put the file(s) on the Yellowstone and let
me know
> >> the
> >> > > path
> >> > > > to
> >> > > > >> > the
> >> > > > >> > > file(s), whatever suits you best.
> >> > > > >> > >
> >> > > > >> > > Thank you very much.
> >> > > > >> > >
> >> > > > >> > > Regards,
> >> > > > >> > >
> >> > > > >> > > Jinwoong Yoo
> >> > > > >> > > UNM
> >> > > > >> > >
> >> > > > >> > >
> >> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley Gotway
via RT
> <
> >> > > > >> > > met_help at ucar.edu> wrote:
> >> > > > >> > >
> >> > > > >> > >> Jinwoong,
> >> > > > >> > >>
> >> > > > >> > >> I see that you're having problems comparing a GRIB1
file
> to
> >> a
> >> > > > >> > CF-compliant
> >> > > > >> > >> NetCDF file using the grid_stat tool.
> >> > > > >> > >>
> >> > > > >> > >> I ran grid_stat and the plot_data_plane tools
through the
> >> > > debugger
> >> > > > >> and
> >> > > > >> > >> found some issues.
> >> > > > >> > >>
> >> > > > >> > >> First, I ran the following plot_data_plane command
to plot
> >> the
> >> > > > CPRAT
> >> > > > >> > >> variable from the GRIB1 file:
> >> > > > >> > >> met-5.0/bin/plot_data_plane \
> >> > > > >> > >> WRFPRS_d01.00_2latlon \
> >> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> >> > > > >> > >> 'name="CPRAT"; level="L0";'
> >> > > > >> > >>
> >> > > > >> > >> Turns out that all the values are 0. This can also
be
> seen
> >> via
> >> > > > >> wgrib:
> >> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> >> > > > >> > >> ...
> >> > > > >> > >> min/max data 0 0
> >> > > > >> > >>
> >> > > > >> > >> Do you expect this or should there be some non-zero
> values?
> >> > > > >> > >>
> >> > > > >> > >> Second, I looked at the PRECC variable using ncview
and
> see
> >> > that
> >> > > it
> >> > > > >> > ranges
> >> > > > >> > >> from 0 to 1.157e-06. Those values are so small
that the
> MET
> >> > > tools
> >> > > > >> won't
> >> > > > >> > >> really be able to distinguish between them.
> >> > > > >> > >>
> >> > > > >> > >> Next, I tried running the NetCDF data through
> >> plot_data_plane,
> >> > > but
> >> > > > >> got
> >> > > > >> > >> this
> >> > > > >> > >> error:
> >> > > > >> > >> met-5.0/bin/plot_data_plane \
> >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps \
> >> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> >> > > > >> > >>
> >> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray &,
> >> DataPlane
> >> > &)
> >> > > > >> const
> >> > > > >> > ->
> >> > > > >> > >> star found in bad slot
> >> > > > >> > >>
> >> > > > >> > >> After running this through the debugger, I found
that MET
> is
> >> > > > getting
> >> > > > >> > >> confused by the presence of the slat and slon
variables.
> >> It's
> >> > > > using
> >> > > > >> > them
> >> > > > >> > >> to define the grid rather than the lat and lon
variables.
> >> And
> >> > > that
> >> > > > >> > leads
> >> > > > >> > >> to the difference in the grids. Also, MET stores
> longitude
> >> > > values
> >> > > > >> > >> internally in degrees_west rather than the more
common
> >> > > > degrees_east.
> >> > > > >> > When
> >> > > > >> > >> you see -0.625 degrees longitude, that's
degrees_west.
> Very
> >> > > > >> confusing,
> >> > > > >> > I
> >> > > > >> > >> know!
> >> > > > >> > >>
> >> > > > >> > >> I tweaked the NetCDF CF code to print warning
messages
> when
> >> it
> >> > > > >> > encounters
> >> > > > >> > >> multiple variables for latitude and longitude, and
to use
> >> the
> >> > > first
> >> > > > >> > >> instance of them rather than the second.
> >> > > > >> > >>
> >> > > > >> > >> Doing so enables me to run plot_data_plane. But
when I
> run
> >> > > through
> >> > > > >> > >> grid_stat, I get the following error:
> >> > > > >> > >>
> >> > > > >> > >> ERROR : process_command_line() -> The forecast and
> >> observation
> >> > > > >> grids do
> >> > > > >> > >> not match:
> >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
> lon_ll:
> >> > > -0.625
> >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll: -90.000
> lon_ll:
> >> > > -0.000
> >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> >> > > > >> > >>
> >> > > > >> > >> So we need to rerun copygb to put the GRIB1 data
onto this
> >> > grid:
> >> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750
> >> 1250
> >> > 942
> >> > > > >> 64*"
> >> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> >> > > > >> > >>
> >> > > > >> > >> After doing that, I was finally able to run
grid_stat to
> >> > compare
> >> > > > >> these
> >> > > > >> > >> fields. But since the forecast contains all 0's
and the
> >> > > > observation
> >> > > > >> > >> basically contains all 0's, I didn't get any
meaningful
> >> > > statistics.
> >> > > > >> > >>
> >> > > > >> > >> Seems like I need to get you that patch for reading
the
> >> lat/lon
> >> > > > >> > >> dimensions. You need to start using the copygb
command
> >> listed
> >> > > > above
> >> > > > >> for
> >> > > > >> > >> regridding GRIB files. And you need to figure out
why
> your
> >> > data
> >> > > is
> >> > > > >> all
> >> > > > >> > >> 0's.
> >> > > > >> > >>
> >> > > > >> > >> How does that all sound?
> >> > > > >> > >>
> >> > > > >> > >> Thanks,
> >> > > > >> > >> John Halley Gotway
> >> > > > >> > >> met_help at ucar.edu
> >> > > > >> > >>
> >> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via RT
<
> >> > > > >> met_help at ucar.edu>
> >> > > > >> > >> wrote:
> >> > > > >> > >>
> >> > > > >> > >> >
> >> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was acted
upon.
> >> > > > >> > >> > Transaction: Ticket created by
jinwoong.yoo at gmail.com
> >> > > > >> > >> > Queue: met_help
> >> > > > >> > >> > Subject: grid_stat Error
> >> > > > >> > >> > Owner: Nobody
> >> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> >> > > > >> > >> > Status: new
> >> > > > >> > >> > Ticket <URL:
> >> > > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> >> > > > >> > >
> >> > > > >> > >> >
> >> > > > >> > >> >
> >> > > > >> > >> > Dear WRF Help and MET Help
> >> > > > >> > >> >
> >> > > > >> > >> > Grid_stat produced error message below and
stopped:
> >> > > > >> > >> > [jyoo at yslogin4 analysis]$
> >> > > > >> > >> > /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/grid_stat
> >> > > > >> > >> >
> >> > > > >> > >> >
> >> > > > >> > >>
> >> > > > >> >
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> >> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> >> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
> >> GridStatConfig_ccsm
> >> > > > >> -outdir
> >> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/gridstatout
> >> > > > >> > >> > DEBUG 1: Default Config File:
> >> > > > >> > >> >
> >> > > > >> > >> >
> >> > > > >> > >>
> >> > > > >> >
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> >> > > > >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> >> > > > >> > >> > WARNING:
> >> > > > >> > >> > WARNING: NcCfFile::open() -> could not extract
init time
> >> from
> >> > > > file
> >> > > > >> > name
> >> > > > >> > >> > WARNING: Using init time of 0
> >> > > > >> > >> > WARNING:
> >> > > > >> > >> > ERROR :
> >> > > > >> > >> > ERROR : process_command_line() -> The forecast
and
> >> > observation
> >> > > > >> grids
> >> > > > >> > do
> >> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191
lat_ll:
> >> > -89.529
> >> > > > >> lon_ll:
> >> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
Projection:
> >> > Lat/Lon
> >> > > > Nx:
> >> > > > >> > 288
> >> > > > >> > >> Ny:
> >> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat:
0.942
> >> delta_lon:
> >> > > > 1.250
> >> > > > >> > >> > ERROR :
> >> > > > >> > >> >
> >> > > > >> > >> >
> >> > > > >> > >> > Interestingly, it seems that my forecast file
grid looks
> >> the
> >> > > same
> >> > > > >> as
> >> > > > >> > the
> >> > > > >> > >> > observation file grid as below:
> >> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by
0.942000 nxny
> >> > 55008
> >> > > > >> > >> > long 0.625000 to 358.750000 by
1.250000, (288
> x
> >> > 191)
> >> > > > >> > >> >
> >> > > > >> > >> > However, grid_stat reads long 0.625000 as
lon_ll:
> -0.625,
> >> > > making
> >> > > > >> > error.
> >> > > > >> > >> >
> >> > > > >> > >> > Can anyone explain why?
> >> > > > >> > >> > Thank you very much.
> >> > > > >> > >> >
> >> > > > >> > >> > Regards,
> >> > > > >> > >> >
> >> > > > >> > >> > Jinwoong Yoo
> >> > > > >> > >> > UNM
> >> > > > >> > >> >
> >> > > > >> > >> >
> >> > > > >> > >>
> >> > > > >> > >>
> >> > > > >> > >
> >> > > > >> >
> >> > > > >> >
> >> > > > >>
> >> > > > >>
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Tue Oct 14 16:44:59 2014
Dear John,
Thank you for your update.
Are these new updates applied to the build in the Yellowstone at
/glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/ ?
Please let me know.
By the way, John,
while I'm postrocessing WRF ARW output,
I'm getting error with run_unipost when the forecast hour is 1002.
Error did not occur until the fhr=1002.
I checked that input file is existing in the directory but it seems
that
WRFPRS1002.tm00 was not created for some reason.
I put the error message below.
Do you think this error is coming from the fhr number being too large
(>1000) as you mentioned previously or something else?
Thank you.
Regards,
Jinwoong Yoo
UNM
+ tmmark=tm00
+ export tmmark
+ MP_SHARED_MEMORY=yes
+ export MP_SHARED_MEMORY
+ MP_LABELIO=yes
+ export MP_LABELIO
+ NEWDATE=1870010100
+ export NEWDATE
+ [ 1002 -le 4320 ]
+ printf %02i 1002
+ fhr=1002
+ /glade/scratch/jyoo/UPPV2.2/bin/ndate.exe +1002 1870010100
+ NEWDATE=1870021118
+ echo 1870021118
+ cut -c1-4
+ YY=1870
+ cut -c5-6
+ echo 1870021118
+ MM=02
+ cut -c7-8
+ echo 1870021118
+ DD=11
+ echo 1870021118
+ cut -c9-10
+ HH=18
+ echo NEWDATE 1870021118
NEWDATE 1870021118
+ echo YY 1870
YY 1870
+ cat
+ 1> itag 0<< \EOF
../wrfprd/wrfout_d01_1870-02-11_18:00:00
netcdf
1870-02-11_18:00:00
NCAR
EOF
+ rm fort.110 fort.14
+ ln -sf wrf_cntrl.parm fort.14
+ /glade/scratch/jyoo/UPPV2.2/bin/unipost.exe
+ 1> unipost_d01.1002.out 2>& 1
+ cp WRFPRS1002.tm00 WRFPRS_d01.tm00.bk
cp: cannot stat `WRFPRS1002.tm00': No such file or directory
+ mv WRFPRS1002.tm00 WRFPRS_d01.1002
mv: cannot stat `WRFPRS1002.tm00': No such file or directory
+ ls -l WRFPRS_d01.1002
ls: cannot access WRFPRS_d01.1002: No such file or directory
+ err1=2
+ test 2 -ne 0
+ echo 'UNIPOST FAILED, EXITTING'
UNIPOST FAILED, EXITTING
+ exit
On Tue, Oct 14, 2014 at 2:56 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I apologize for the delay in providing a solution to this problem.
That
> error is being caused by integer overflow when trying to write
unixtime
> (seconds since Jan 1 1970) for the year 1870 as a variable attribute
to the
> NetCDF output file. I just distributed a patch that checks for this
> condition and, if overflow would happen, prints a warning and skips
writing
> those values. Ultimately, we hope to come up with a better solution
in the
> next release. But for now, this should get you past the error.
>
> Please follow the instructions posted here to download and apply the
latest
> set of patches for met-5.0:
>
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.0/index.php
>
> Please let me know if you continue to experience problems after
applying
> these patches.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On Wed, Oct 8, 2014 at 3:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> > By the way,
> > Since I didn't get the nc file from Grid_stat by disabling the
option,
> It's
> > a bit hard to understand the output of grid_stat now.
> >
> > Could you figure out what should be done to get the nc file from
> grid_stat?
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> > On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Dear John,
> > >
> > > At present, I just would like to get the general idea about
using MET
> > > through Grid_stat and eventually I'd like to run series-analysis
so
> that
> > I
> > > can evaluate the WRF simulation performance against the CCSM4
over the
> 10
> > > years period of integral.
> > >
> > > In other words, I would like to get the time series of scores
for a few
> > > variables such as T2, PSL, soil moisture, precipitation,
snowfall, etc.
> > >
> > > Then, what will be the next step for the most economic way?
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > > UNM
> > >
> > > On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> What you do with the statistical output that the MET tools
generate
> > really
> > >> depends on what sort of question you're trying to answer. If
you want
> > to
> > >> aggregate results across multiple runs of grid-stat, you can
use
> > >> stat-analysis to do that. Alternatively, you could plot a time
series
> > of
> > >> scores output from each run. It's really up to you to analyze
and
> make
> > >> sense of your statistical output.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>
> > >> >
> > >> > Dear John,
> > >> >
> > >> > Yes. Disabling nc_pairs_flag did helped Grid_stat generating
> > statistics
> > >> txt
> > >> > files.
> > >> > Then, I should run stat_analysis using the grid_stat outputs
right?
> > >> >
> > >> > Thank you.
> > >> >
> > >> > Regards,
> > >> >
> > >> > Jinwoong Yoo
> > >> > UNM
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT <
> > >> > met_help at ucar.edu
> > >> > > wrote:
> > >> >
> > >> > > Jinwoong,
> > >> > >
> > >> > > Try editing your Grid-Stat config file by setting:
> > >> > > nc_pairs_flag = FALSE;
> > >> > >
> > >> > > We're getting a weird error when Grid-Stat tries to write
the
> NetCDF
> > >> > output
> > >> > > file:
> > >> > > NetCDF: Numeric conversion not representable
> > >> > >
> > >> > > That's causing you to see empty output files.
> > >> > >
> > >> > > I'll look into the source of this error, but for now, just
disable
> > the
> > >> > > NetCDF matched pairs output.
> > >> > >
> > >> > > Thanks,
> > >> > > John
> > >> > >
> > >> > >
> > >> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT <
> > >> met_help at ucar.edu>
> > >> > > wrote:
> > >> > >
> > >> > > >
> > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > >> > > >
> > >> > > > Dear John,
> > >> > > >
> > >> > > > Maybe should I use gen_poly_mask to define the area of my
WRF
> > model
> > >> > > domain
> > >> > > > (which is a tropical channel) before I run grid_stat
against the
> > >> CCSM4
> > >> > in
> > >> > > > global domain?
> > >> > > >
> > >> > > > Jinwoong Yoo
> > >> > > > UNM
> > >> > > >
> > >> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
> > >> jinwoong.yoo at gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Dear John,
> > >> > > > >
> > >> > > > > I switched variable to PRMSL (sea level pressure) for a
> > Grid_stat
> > >> > test.
> > >> > > > > Grid_stat seemed to run this time but produced files
were
> empty.
> > >> > > > >
> > >> > > > > However, when I produced a ps file for the variable,
the
> output
> > >> file
> > >> > > > looks
> > >> > > > > ok (attached).
> > >> > > > >
> > >> > > > > [jyoo at yslogin6 postprd]$
> > >> > > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > >> > > > > [jyoo at yslogin6 postprd]$
> > >> > > > >
> > /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG/bin/plot_data_plane
> > >> > > > >
> > >>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > >> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL";
level="L0";'
> > >> > > > >
> > >> > > > > Do I need to change other information for dictionary
parts for
> > the
> > >> > > > > variables being compared in the GridStatConfig_ccsm
file
> > (attached
> > >> > > also)?
> > >> > > > > Where can I find more detail information about the
> > GridStatConfig
> > >> > than
> > >> > > in
> > >> > > > > the MET Users Guide V5.0, if available?
> > >> > > > >
> > >> > > > > Thank you.
> > >> > > > >
> > >> > > > > Regards,
> > >> > > > >
> > >> > > > > Jinwoong Yoo
> > >> > > > > UNM
> > >> > > > >
> > >> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway via
RT <
> > >> > > > > met_help at ucar.edu> wrote:
> > >> > > > >
> > >> > > > >> Jinwoong,
> > >> > > > >>
> > >> > > > >> OK, I updated the build on yellowstone to include the
latest
> > set
> > >> of
> > >> > > > >> patches:
> > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > >> > > > >>
> > >> > > > >> The original, as released, version of met-5.0 can
still be
> > found
> > >> > here:
> > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> > >> > > > >>
> > >> > > > >> Please give the updated version a shot and let me know
how it
> > >> goes.
> > >> > > > >>
> > >> > > > >> Thanks,
> > >> > > > >> John
> > >> > > > >>
> > >> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT <
> > >> > > met_help at ucar.edu>
> > >> > > > >> wrote:
> > >> > > > >>
> > >> > > > >> >
> > >> > > > >> > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > >> >
> > >> > > > >> >
> > >> > > > >> > Dear John,
> > >> > > > >> >
> > >> > > > >> > Since I'm using the MET that is available on the
> Yellowstone
> > >> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> > >> > > > >> > you can just let me know how I can use the patch for
> reading
> > >> the
> > >> > > > lat/lon
> > >> > > > >> > dimensions of the CCSM4 file in the Yellowstone.
> > >> > > > >> >
> > >> > > > >> > Thank you.
> > >> > > > >> >
> > >> > > > >> > Regards,
> > >> > > > >> > Jinwoong Yoo
> > >> > > > >> > UNM
> > >> > > > >> >
> > >> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> > >> > > jinwoong.yoo at gmail.com>
> > >> > > > >> > wrote:
> > >> > > > >> >
> > >> > > > >> > > Dear John
> > >> > > > >> > >
> > >> > > > >> > > First of all, thank you for your efforts to figure
out
> the
> > >> issue
> > >> > > > with
> > >> > > > >> > > Grid_stat of my case.
> > >> > > > >> > >
> > >> > > > >> > > >>> Do you expect this or should there be some
non-zero
> > >> values?
> > >> > > > >> > >
> > >> > > > >> > > This is a test case with precipitation variables
from the
> > WRF
> > >> > and
> > >> > > > >> CCSM4
> > >> > > > >> > at
> > >> > > > >> > > model initialization time 00. So, 0 is reasonable
> although
> > I
> > >> did
> > >> > > not
> > >> > > > >> > > consider carefully when I pick the variable for a
test
> > case.
> > >> > > > >> > >
> > >> > > > >> > > >>>After running this through the debugger, I
found that
> > MET
> > >> is
> > >> > > > >> getting
> > >> > > > >> > > confused by the presence of the slat and slon
variables.
> > >> It's
> > >> > > using
> > >> > > > >> them
> > >> > > > >> > > to define the grid rather than the lat and lon
variables.
> > >> And
> > >> > > that
> > >> > > > >> leads
> > >> > > > >> > > to the difference in the grids.
> > >> > > > >> > >
> > >> > > > >> > > That's one thing that I mentioned in my previous
email:
> > >> > > > >> > > "However, there are something strange.
> > >> > > > >> > > According to what Grid-Stat reads in for the CCSM4
file
> > >> > > (Projection:
> > >> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
0.625
> > >> delta_lat:
> > >> > > > 0.942
> > >> > > > >> > > delta_lon: 1.250), lat and lon information were
flipped
> > >> compared
> > >> > > to
> > >> > > > >> what
> > >> > > > >> > I
> > >> > > > >> > > get from ncdump of the CCSM4 file (lat = 192 ; lon
= 288
> ;
> > >> slat
> > >> > =
> > >> > > > 191
> > >> > > > >> > ;slon
> > >> > > > >> > > = 288) and the Ny: 191 matches to slat(staggered
> latitude)
> > >> not
> > >> > > > >> latitude."
> > >> > > > >> > > I'm glad you found a solution to the issue with NC
file
> > with
> > >> two
> > >> > > > >> > different
> > >> > > > >> > > pair of lat (lat and slat) and lon (lon and slon).
> > >> > > > >> > >
> > >> > > > >> > >
> > >> > > > >> > > >>> So we need to rerun copygb to put the GRIB1
data onto
> > >> this
> > >> > > grid:
> > >> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750
> > 1250
> > >> > 942
> > >> > > > 64*"
> > >> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > >> > > > >> > >
> > >> > > > >> > > Running copygb is not a big deal at all.
> > >> > > > >> > >
> > >> > > > >> > > >>> After doing that, I was finally able to run
grid_stat
> > to
> > >> > > compare
> > >> > > > >> > these
> > >> > > > >> > > fields. But since the forecast contains all 0's
and the
> > >> > > observation
> > >> > > > >> > > basically contains all 0's, I didn't get any
meaningful
> > >> > > statistics.
> > >> > > > >> > >
> > >> > > > >> > >
> > >> > > > >> > > I can switch to a different variable than the
> precipitation
> > >> at
> > >> > the
> > >> > > > >> > > initialization time for a test.
> > >> > > > >> > > Please send me the patch for reading the lat/lon
> dimensions
> > >> via
> > >> > > > email
> > >> > > > >> or
> > >> > > > >> > > you can put the file(s) on the Yellowstone and let
me
> know
> > >> the
> > >> > > path
> > >> > > > to
> > >> > > > >> > the
> > >> > > > >> > > file(s), whatever suits you best.
> > >> > > > >> > >
> > >> > > > >> > > Thank you very much.
> > >> > > > >> > >
> > >> > > > >> > > Regards,
> > >> > > > >> > >
> > >> > > > >> > > Jinwoong Yoo
> > >> > > > >> > > UNM
> > >> > > > >> > >
> > >> > > > >> > >
> > >> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley
Gotway via
> RT
> > <
> > >> > > > >> > > met_help at ucar.edu> wrote:
> > >> > > > >> > >
> > >> > > > >> > >> Jinwoong,
> > >> > > > >> > >>
> > >> > > > >> > >> I see that you're having problems comparing a
GRIB1 file
> > to
> > >> a
> > >> > > > >> > CF-compliant
> > >> > > > >> > >> NetCDF file using the grid_stat tool.
> > >> > > > >> > >>
> > >> > > > >> > >> I ran grid_stat and the plot_data_plane tools
through
> the
> > >> > > debugger
> > >> > > > >> and
> > >> > > > >> > >> found some issues.
> > >> > > > >> > >>
> > >> > > > >> > >> First, I ran the following plot_data_plane
command to
> plot
> > >> the
> > >> > > > CPRAT
> > >> > > > >> > >> variable from the GRIB1 file:
> > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > >> > > > >> > >> WRFPRS_d01.00_2latlon \
> > >> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > >> > > > >> > >> 'name="CPRAT"; level="L0";'
> > >> > > > >> > >>
> > >> > > > >> > >> Turns out that all the values are 0. This can
also be
> > seen
> > >> via
> > >> > > > >> wgrib:
> > >> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > >> > > > >> > >> ...
> > >> > > > >> > >> min/max data 0 0
> > >> > > > >> > >>
> > >> > > > >> > >> Do you expect this or should there be some non-
zero
> > values?
> > >> > > > >> > >>
> > >> > > > >> > >> Second, I looked at the PRECC variable using
ncview and
> > see
> > >> > that
> > >> > > it
> > >> > > > >> > ranges
> > >> > > > >> > >> from 0 to 1.157e-06. Those values are so small
that the
> > MET
> > >> > > tools
> > >> > > > >> won't
> > >> > > > >> > >> really be able to distinguish between them.
> > >> > > > >> > >>
> > >> > > > >> > >> Next, I tried running the NetCDF data through
> > >> plot_data_plane,
> > >> > > but
> > >> > > > >> got
> > >> > > > >> > >> this
> > >> > > > >> > >> error:
> > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps
\
> > >> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > >> > > > >> > >>
> > >> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const LongArray
&,
> > >> DataPlane
> > >> > &)
> > >> > > > >> const
> > >> > > > >> > ->
> > >> > > > >> > >> star found in bad slot
> > >> > > > >> > >>
> > >> > > > >> > >> After running this through the debugger, I found
that
> MET
> > is
> > >> > > > getting
> > >> > > > >> > >> confused by the presence of the slat and slon
variables.
> > >> It's
> > >> > > > using
> > >> > > > >> > them
> > >> > > > >> > >> to define the grid rather than the lat and lon
> variables.
> > >> And
> > >> > > that
> > >> > > > >> > leads
> > >> > > > >> > >> to the difference in the grids. Also, MET stores
> > longitude
> > >> > > values
> > >> > > > >> > >> internally in degrees_west rather than the more
common
> > >> > > > degrees_east.
> > >> > > > >> > When
> > >> > > > >> > >> you see -0.625 degrees longitude, that's
degrees_west.
> > Very
> > >> > > > >> confusing,
> > >> > > > >> > I
> > >> > > > >> > >> know!
> > >> > > > >> > >>
> > >> > > > >> > >> I tweaked the NetCDF CF code to print warning
messages
> > when
> > >> it
> > >> > > > >> > encounters
> > >> > > > >> > >> multiple variables for latitude and longitude,
and to
> use
> > >> the
> > >> > > first
> > >> > > > >> > >> instance of them rather than the second.
> > >> > > > >> > >>
> > >> > > > >> > >> Doing so enables me to run plot_data_plane. But
when I
> > run
> > >> > > through
> > >> > > > >> > >> grid_stat, I get the following error:
> > >> > > > >> > >>
> > >> > > > >> > >> ERROR : process_command_line() -> The forecast
and
> > >> observation
> > >> > > > >> grids do
> > >> > > > >> > >> not match:
> > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
> > lon_ll:
> > >> > > -0.625
> > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll:
-90.000
> > lon_ll:
> > >> > > -0.000
> > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > >> > > > >> > >>
> > >> > > > >> > >> So we need to rerun copygb to put the GRIB1 data
onto
> this
> > >> > grid:
> > >> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128 90000
358750
> > >> 1250
> > >> > 942
> > >> > > > >> 64*"
> > >> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > >> > > > >> > >>
> > >> > > > >> > >> After doing that, I was finally able to run
grid_stat to
> > >> > compare
> > >> > > > >> these
> > >> > > > >> > >> fields. But since the forecast contains all 0's
and the
> > >> > > > observation
> > >> > > > >> > >> basically contains all 0's, I didn't get any
meaningful
> > >> > > statistics.
> > >> > > > >> > >>
> > >> > > > >> > >> Seems like I need to get you that patch for
reading the
> > >> lat/lon
> > >> > > > >> > >> dimensions. You need to start using the copygb
command
> > >> listed
> > >> > > > above
> > >> > > > >> for
> > >> > > > >> > >> regridding GRIB files. And you need to figure
out why
> > your
> > >> > data
> > >> > > is
> > >> > > > >> all
> > >> > > > >> > >> 0's.
> > >> > > > >> > >>
> > >> > > > >> > >> How does that all sound?
> > >> > > > >> > >>
> > >> > > > >> > >> Thanks,
> > >> > > > >> > >> John Halley Gotway
> > >> > > > >> > >> met_help at ucar.edu
> > >> > > > >> > >>
> > >> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo via
RT <
> > >> > > > >> met_help at ucar.edu>
> > >> > > > >> > >> wrote:
> > >> > > > >> > >>
> > >> > > > >> > >> >
> > >> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was
acted
> upon.
> > >> > > > >> > >> > Transaction: Ticket created by
jinwoong.yoo at gmail.com
> > >> > > > >> > >> > Queue: met_help
> > >> > > > >> > >> > Subject: grid_stat Error
> > >> > > > >> > >> > Owner: Nobody
> > >> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > >> > > > >> > >> > Status: new
> > >> > > > >> > >> > Ticket <URL:
> > >> > > > >>
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > >> > > > >> > >
> > >> > > > >> > >> >
> > >> > > > >> > >> >
> > >> > > > >> > >> > Dear WRF Help and MET Help
> > >> > > > >> > >> >
> > >> > > > >> > >> > Grid_stat produced error message below and
stopped:
> > >> > > > >> > >> > [jyoo at yslogin4 analysis]$
> > >> > > > >> > >> >
> /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > >> > > > >> > >> >
> > >> > > > >> > >> >
> > >> > > > >> > >>
> > >> > > > >> >
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > >> > > > >> > >> >
> /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > >> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
> > >> GridStatConfig_ccsm
> > >> > > > >> -outdir
> > >> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > >> > > > >> > >> > DEBUG 1: Default Config File:
> > >> > > > >> > >> >
> > >> > > > >> > >> >
> > >> > > > >> > >>
> > >> > > > >> >
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > >> > > > >> > >> > DEBUG 1: User Config File: GridStatConfig_ccsm
> > >> > > > >> > >> > WARNING:
> > >> > > > >> > >> > WARNING: NcCfFile::open() -> could not extract
init
> time
> > >> from
> > >> > > > file
> > >> > > > >> > name
> > >> > > > >> > >> > WARNING: Using init time of 0
> > >> > > > >> > >> > WARNING:
> > >> > > > >> > >> > ERROR :
> > >> > > > >> > >> > ERROR : process_command_line() -> The forecast
and
> > >> > observation
> > >> > > > >> grids
> > >> > > > >> > do
> > >> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny: 191
lat_ll:
> > >> > -89.529
> > >> > > > >> lon_ll:
> > >> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
> Projection:
> > >> > Lat/Lon
> > >> > > > Nx:
> > >> > > > >> > 288
> > >> > > > >> > >> Ny:
> > >> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat:
0.942
> > >> delta_lon:
> > >> > > > 1.250
> > >> > > > >> > >> > ERROR :
> > >> > > > >> > >> >
> > >> > > > >> > >> >
> > >> > > > >> > >> > Interestingly, it seems that my forecast file
grid
> looks
> > >> the
> > >> > > same
> > >> > > > >> as
> > >> > > > >> > the
> > >> > > > >> > >> > observation file grid as below:
> > >> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by
0.942000
> nxny
> > >> > 55008
> > >> > > > >> > >> > long 0.625000 to 358.750000 by
1.250000,
> (288
> > x
> > >> > 191)
> > >> > > > >> > >> >
> > >> > > > >> > >> > However, grid_stat reads long 0.625000 as
lon_ll:
> > -0.625,
> > >> > > making
> > >> > > > >> > error.
> > >> > > > >> > >> >
> > >> > > > >> > >> > Can anyone explain why?
> > >> > > > >> > >> > Thank you very much.
> > >> > > > >> > >> >
> > >> > > > >> > >> > Regards,
> > >> > > > >> > >> >
> > >> > > > >> > >> > Jinwoong Yoo
> > >> > > > >> > >> > UNM
> > >> > > > >> > >> >
> > >> > > > >> > >> >
> > >> > > > >> > >>
> > >> > > > >> > >>
> > >> > > > >> > >
> > >> > > > >> >
> > >> > > > >> >
> > >> > > > >>
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Wed Oct 15 10:25:11 2014
Jinwoong,
I just finished updating the met-5.0 build on yellowstone:
/glade/p/ral/jnt/MET/MET_releases/met-5.0/bin
I took at look at the UPP output you sent but can't see an obvious
problem. Hopefully the folks at wrfhelp at ucar.edu will be able to help
you
out.
Thanks,
John
On Tue, Oct 14, 2014 at 4:44 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
> Dear John,
>
> Thank you for your update.
> Are these new updates applied to the build in the Yellowstone at
> /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/ ?
> Please let me know.
>
>
> By the way, John,
> while I'm postrocessing WRF ARW output,
> I'm getting error with run_unipost when the forecast hour is 1002.
> Error did not occur until the fhr=1002.
> I checked that input file is existing in the directory but it seems
that
> WRFPRS1002.tm00 was not created for some reason.
>
> I put the error message below.
> Do you think this error is coming from the fhr number being too
large
> (>1000) as you mentioned previously or something else?
>
> Thank you.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
>
>
>
>
> + tmmark=tm00
> + export tmmark
> + MP_SHARED_MEMORY=yes
> + export MP_SHARED_MEMORY
> + MP_LABELIO=yes
> + export MP_LABELIO
> + NEWDATE=1870010100
> + export NEWDATE
> + [ 1002 -le 4320 ]
> + printf %02i 1002
> + fhr=1002
> + /glade/scratch/jyoo/UPPV2.2/bin/ndate.exe +1002 1870010100
> + NEWDATE=1870021118
> + echo 1870021118
> + cut -c1-4
> + YY=1870
> + cut -c5-6
> + echo 1870021118
> + MM=02
> + cut -c7-8
> + echo 1870021118
> + DD=11
> + echo 1870021118
> + cut -c9-10
> + HH=18
> + echo NEWDATE 1870021118
> NEWDATE 1870021118
> + echo YY 1870
> YY 1870
> + cat
> + 1> itag 0<< \EOF
> ../wrfprd/wrfout_d01_1870-02-11_18:00:00
> netcdf
> 1870-02-11_18:00:00
> NCAR
> EOF
> + rm fort.110 fort.14
> + ln -sf wrf_cntrl.parm fort.14
> + /glade/scratch/jyoo/UPPV2.2/bin/unipost.exe
> + 1> unipost_d01.1002.out 2>& 1
> + cp WRFPRS1002.tm00 WRFPRS_d01.tm00.bk
> cp: cannot stat `WRFPRS1002.tm00': No such file or directory
> + mv WRFPRS1002.tm00 WRFPRS_d01.1002
> mv: cannot stat `WRFPRS1002.tm00': No such file or directory
> + ls -l WRFPRS_d01.1002
> ls: cannot access WRFPRS_d01.1002: No such file or directory
> + err1=2
> + test 2 -ne 0
> + echo 'UNIPOST FAILED, EXITTING'
> UNIPOST FAILED, EXITTING
> + exit
>
>
> On Tue, Oct 14, 2014 at 2:56 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jinwoong,
> >
> > I apologize for the delay in providing a solution to this problem.
That
> > error is being caused by integer overflow when trying to write
unixtime
> > (seconds since Jan 1 1970) for the year 1870 as a variable
attribute to
> the
> > NetCDF output file. I just distributed a patch that checks for
this
> > condition and, if overflow would happen, prints a warning and
skips
> writing
> > those values. Ultimately, we hope to come up with a better
solution in
> the
> > next release. But for now, this should get you past the error.
> >
> > Please follow the instructions posted here to download and apply
the
> latest
> > set of patches for met-5.0:
> >
> >
http://www.dtcenter.org/met/users/support/known_issues/METv5.0/index.php
> >
> > Please let me know if you continue to experience problems after
applying
> > these patches.
> >
> > Thanks,
> > John Halley Gotway
> > met_help at ucar.edu
> >
> > On Wed, Oct 8, 2014 at 3:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > >
> > > By the way,
> > > Since I didn't get the nc file from Grid_stat by disabling the
option,
> > It's
> > > a bit hard to understand the output of grid_stat now.
> > >
> > > Could you figure out what should be done to get the nc file from
> > grid_stat?
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > > UNM
> > >
> > > On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > > > Dear John,
> > > >
> > > > At present, I just would like to get the general idea about
using MET
> > > > through Grid_stat and eventually I'd like to run series-
analysis so
> > that
> > > I
> > > > can evaluate the WRF simulation performance against the CCSM4
over
> the
> > 10
> > > > years period of integral.
> > > >
> > > > In other words, I would like to get the time series of scores
for a
> few
> > > > variables such as T2, PSL, soil moisture, precipitation,
snowfall,
> etc.
> > > >
> > > > Then, what will be the next step for the most economic way?
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong Yoo
> > > > UNM
> > > >
> > > > On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Jinwoong,
> > > >>
> > > >> What you do with the statistical output that the MET tools
generate
> > > really
> > > >> depends on what sort of question you're trying to answer. If
you
> want
> > > to
> > > >> aggregate results across multiple runs of grid-stat, you can
use
> > > >> stat-analysis to do that. Alternatively, you could plot a
time
> series
> > > of
> > > >> scores output from each run. It's really up to you to
analyze and
> > make
> > > >> sense of your statistical output.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu>
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > > >> >
> > > >> > Dear John,
> > > >> >
> > > >> > Yes. Disabling nc_pairs_flag did helped Grid_stat
generating
> > > statistics
> > > >> txt
> > > >> > files.
> > > >> > Then, I should run stat_analysis using the grid_stat
outputs
> right?
> > > >> >
> > > >> > Thank you.
> > > >> >
> > > >> > Regards,
> > > >> >
> > > >> > Jinwoong Yoo
> > > >> > UNM
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT <
> > > >> > met_help at ucar.edu
> > > >> > > wrote:
> > > >> >
> > > >> > > Jinwoong,
> > > >> > >
> > > >> > > Try editing your Grid-Stat config file by setting:
> > > >> > > nc_pairs_flag = FALSE;
> > > >> > >
> > > >> > > We're getting a weird error when Grid-Stat tries to write
the
> > NetCDF
> > > >> > output
> > > >> > > file:
> > > >> > > NetCDF: Numeric conversion not representable
> > > >> > >
> > > >> > > That's causing you to see empty output files.
> > > >> > >
> > > >> > > I'll look into the source of this error, but for now,
just
> disable
> > > the
> > > >> > > NetCDF matched pairs output.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > John
> > > >> > >
> > > >> > >
> > > >> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT <
> > > >> met_help at ucar.edu>
> > > >> > > wrote:
> > > >> > >
> > > >> > > >
> > > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> >
> > > >> > > >
> > > >> > > > Dear John,
> > > >> > > >
> > > >> > > > Maybe should I use gen_poly_mask to define the area of
my WRF
> > > model
> > > >> > > domain
> > > >> > > > (which is a tropical channel) before I run grid_stat
against
> the
> > > >> CCSM4
> > > >> > in
> > > >> > > > global domain?
> > > >> > > >
> > > >> > > > Jinwoong Yoo
> > > >> > > > UNM
> > > >> > > >
> > > >> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
> > > >> jinwoong.yoo at gmail.com>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Dear John,
> > > >> > > > >
> > > >> > > > > I switched variable to PRMSL (sea level pressure) for
a
> > > Grid_stat
> > > >> > test.
> > > >> > > > > Grid_stat seemed to run this time but produced files
were
> > empty.
> > > >> > > > >
> > > >> > > > > However, when I produced a ps file for the variable,
the
> > output
> > > >> file
> > > >> > > > looks
> > > >> > > > > ok (attached).
> > > >> > > > >
> > > >> > > > > [jyoo at yslogin6 postprd]$
> > > >> > > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > >> > > > > [jyoo at yslogin6 postprd]$
> > > >> > > > >
> > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
> > > >> > > > >
> > > >>
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > >> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL";
level="L0";'
> > > >> > > > >
> > > >> > > > > Do I need to change other information for dictionary
parts
> for
> > > the
> > > >> > > > > variables being compared in the GridStatConfig_ccsm
file
> > > (attached
> > > >> > > also)?
> > > >> > > > > Where can I find more detail information about the
> > > GridStatConfig
> > > >> > than
> > > >> > > in
> > > >> > > > > the MET Users Guide V5.0, if available?
> > > >> > > > >
> > > >> > > > > Thank you.
> > > >> > > > >
> > > >> > > > > Regards,
> > > >> > > > >
> > > >> > > > > Jinwoong Yoo
> > > >> > > > > UNM
> > > >> > > > >
> > > >> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway
via RT <
> > > >> > > > > met_help at ucar.edu> wrote:
> > > >> > > > >
> > > >> > > > >> Jinwoong,
> > > >> > > > >>
> > > >> > > > >> OK, I updated the build on yellowstone to include
the
> latest
> > > set
> > > >> of
> > > >> > > > >> patches:
> > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > > >> > > > >>
> > > >> > > > >> The original, as released, version of met-5.0 can
still be
> > > found
> > > >> > here:
> > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> > > >> > > > >>
> > > >> > > > >> Please give the updated version a shot and let me
know how
> it
> > > >> goes.
> > > >> > > > >>
> > > >> > > > >> Thanks,
> > > >> > > > >> John
> > > >> > > > >>
> > > >> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via RT
<
> > > >> > > met_help at ucar.edu>
> > > >> > > > >> wrote:
> > > >> > > > >>
> > > >> > > > >> >
> > > >> > > > >> > <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > >> >
> > > >> > > > >> >
> > > >> > > > >> > Dear John,
> > > >> > > > >> >
> > > >> > > > >> > Since I'm using the MET that is available on the
> > Yellowstone
> > > >> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/,
> > > >> > > > >> > you can just let me know how I can use the patch
for
> > reading
> > > >> the
> > > >> > > > lat/lon
> > > >> > > > >> > dimensions of the CCSM4 file in the Yellowstone.
> > > >> > > > >> >
> > > >> > > > >> > Thank you.
> > > >> > > > >> >
> > > >> > > > >> > Regards,
> > > >> > > > >> > Jinwoong Yoo
> > > >> > > > >> > UNM
> > > >> > > > >> >
> > > >> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> > > >> > > jinwoong.yoo at gmail.com>
> > > >> > > > >> > wrote:
> > > >> > > > >> >
> > > >> > > > >> > > Dear John
> > > >> > > > >> > >
> > > >> > > > >> > > First of all, thank you for your efforts to
figure out
> > the
> > > >> issue
> > > >> > > > with
> > > >> > > > >> > > Grid_stat of my case.
> > > >> > > > >> > >
> > > >> > > > >> > > >>> Do you expect this or should there be some
non-zero
> > > >> values?
> > > >> > > > >> > >
> > > >> > > > >> > > This is a test case with precipitation variables
from
> the
> > > WRF
> > > >> > and
> > > >> > > > >> CCSM4
> > > >> > > > >> > at
> > > >> > > > >> > > model initialization time 00. So, 0 is
reasonable
> > although
> > > I
> > > >> did
> > > >> > > not
> > > >> > > > >> > > consider carefully when I pick the variable for
a test
> > > case.
> > > >> > > > >> > >
> > > >> > > > >> > > >>>After running this through the debugger, I
found
> that
> > > MET
> > > >> is
> > > >> > > > >> getting
> > > >> > > > >> > > confused by the presence of the slat and slon
> variables.
> > > >> It's
> > > >> > > using
> > > >> > > > >> them
> > > >> > > > >> > > to define the grid rather than the lat and lon
> variables.
> > > >> And
> > > >> > > that
> > > >> > > > >> leads
> > > >> > > > >> > > to the difference in the grids.
> > > >> > > > >> > >
> > > >> > > > >> > > That's one thing that I mentioned in my previous
email:
> > > >> > > > >> > > "However, there are something strange.
> > > >> > > > >> > > According to what Grid-Stat reads in for the
CCSM4 file
> > > >> > > (Projection:
> > > >> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529 lon_ll:
0.625
> > > >> delta_lat:
> > > >> > > > 0.942
> > > >> > > > >> > > delta_lon: 1.250), lat and lon information were
flipped
> > > >> compared
> > > >> > > to
> > > >> > > > >> what
> > > >> > > > >> > I
> > > >> > > > >> > > get from ncdump of the CCSM4 file (lat = 192 ;
lon =
> 288
> > ;
> > > >> slat
> > > >> > =
> > > >> > > > 191
> > > >> > > > >> > ;slon
> > > >> > > > >> > > = 288) and the Ny: 191 matches to slat(staggered
> > latitude)
> > > >> not
> > > >> > > > >> latitude."
> > > >> > > > >> > > I'm glad you found a solution to the issue with
NC file
> > > with
> > > >> two
> > > >> > > > >> > different
> > > >> > > > >> > > pair of lat (lat and slat) and lon (lon and
slon).
> > > >> > > > >> > >
> > > >> > > > >> > >
> > > >> > > > >> > > >>> So we need to rerun copygb to put the GRIB1
data
> onto
> > > >> this
> > > >> > > grid:
> > > >> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128
90000
> 358750
> > > 1250
> > > >> > 942
> > > >> > > > 64*"
> > > >> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > >> > > > >> > >
> > > >> > > > >> > > Running copygb is not a big deal at all.
> > > >> > > > >> > >
> > > >> > > > >> > > >>> After doing that, I was finally able to run
> grid_stat
> > > to
> > > >> > > compare
> > > >> > > > >> > these
> > > >> > > > >> > > fields. But since the forecast contains all 0's
and
> the
> > > >> > > observation
> > > >> > > > >> > > basically contains all 0's, I didn't get any
meaningful
> > > >> > > statistics.
> > > >> > > > >> > >
> > > >> > > > >> > >
> > > >> > > > >> > > I can switch to a different variable than the
> > precipitation
> > > >> at
> > > >> > the
> > > >> > > > >> > > initialization time for a test.
> > > >> > > > >> > > Please send me the patch for reading the lat/lon
> > dimensions
> > > >> via
> > > >> > > > email
> > > >> > > > >> or
> > > >> > > > >> > > you can put the file(s) on the Yellowstone and
let me
> > know
> > > >> the
> > > >> > > path
> > > >> > > > to
> > > >> > > > >> > the
> > > >> > > > >> > > file(s), whatever suits you best.
> > > >> > > > >> > >
> > > >> > > > >> > > Thank you very much.
> > > >> > > > >> > >
> > > >> > > > >> > > Regards,
> > > >> > > > >> > >
> > > >> > > > >> > > Jinwoong Yoo
> > > >> > > > >> > > UNM
> > > >> > > > >> > >
> > > >> > > > >> > >
> > > >> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley
Gotway via
> > RT
> > > <
> > > >> > > > >> > > met_help at ucar.edu> wrote:
> > > >> > > > >> > >
> > > >> > > > >> > >> Jinwoong,
> > > >> > > > >> > >>
> > > >> > > > >> > >> I see that you're having problems comparing a
GRIB1
> file
> > > to
> > > >> a
> > > >> > > > >> > CF-compliant
> > > >> > > > >> > >> NetCDF file using the grid_stat tool.
> > > >> > > > >> > >>
> > > >> > > > >> > >> I ran grid_stat and the plot_data_plane tools
through
> > the
> > > >> > > debugger
> > > >> > > > >> and
> > > >> > > > >> > >> found some issues.
> > > >> > > > >> > >>
> > > >> > > > >> > >> First, I ran the following plot_data_plane
command to
> > plot
> > > >> the
> > > >> > > > CPRAT
> > > >> > > > >> > >> variable from the GRIB1 file:
> > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > >> > > > >> > >> WRFPRS_d01.00_2latlon \
> > > >> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > > >> > > > >> > >> 'name="CPRAT"; level="L0";'
> > > >> > > > >> > >>
> > > >> > > > >> > >> Turns out that all the values are 0. This can
also be
> > > seen
> > > >> via
> > > >> > > > >> wgrib:
> > > >> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > > >> > > > >> > >> ...
> > > >> > > > >> > >> min/max data 0 0
> > > >> > > > >> > >>
> > > >> > > > >> > >> Do you expect this or should there be some non-
zero
> > > values?
> > > >> > > > >> > >>
> > > >> > > > >> > >> Second, I looked at the PRECC variable using
ncview
> and
> > > see
> > > >> > that
> > > >> > > it
> > > >> > > > >> > ranges
> > > >> > > > >> > >> from 0 to 1.157e-06. Those values are so small
that
> the
> > > MET
> > > >> > > tools
> > > >> > > > >> won't
> > > >> > > > >> > >> really be able to distinguish between them.
> > > >> > > > >> > >>
> > > >> > > > >> > >> Next, I tried running the NetCDF data through
> > > >> plot_data_plane,
> > > >> > > but
> > > >> > > > >> got
> > > >> > > > >> > >> this
> > > >> > > > >> > >> error:
> > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-
01_PRECC.ps \
> > > >> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > > >> > > > >> > >>
> > > >> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const
LongArray &,
> > > >> DataPlane
> > > >> > &)
> > > >> > > > >> const
> > > >> > > > >> > ->
> > > >> > > > >> > >> star found in bad slot
> > > >> > > > >> > >>
> > > >> > > > >> > >> After running this through the debugger, I
found that
> > MET
> > > is
> > > >> > > > getting
> > > >> > > > >> > >> confused by the presence of the slat and slon
> variables.
> > > >> It's
> > > >> > > > using
> > > >> > > > >> > them
> > > >> > > > >> > >> to define the grid rather than the lat and lon
> > variables.
> > > >> And
> > > >> > > that
> > > >> > > > >> > leads
> > > >> > > > >> > >> to the difference in the grids. Also, MET
stores
> > > longitude
> > > >> > > values
> > > >> > > > >> > >> internally in degrees_west rather than the more
common
> > > >> > > > degrees_east.
> > > >> > > > >> > When
> > > >> > > > >> > >> you see -0.625 degrees longitude, that's
degrees_west.
> > > Very
> > > >> > > > >> confusing,
> > > >> > > > >> > I
> > > >> > > > >> > >> know!
> > > >> > > > >> > >>
> > > >> > > > >> > >> I tweaked the NetCDF CF code to print warning
messages
> > > when
> > > >> it
> > > >> > > > >> > encounters
> > > >> > > > >> > >> multiple variables for latitude and longitude,
and to
> > use
> > > >> the
> > > >> > > first
> > > >> > > > >> > >> instance of them rather than the second.
> > > >> > > > >> > >>
> > > >> > > > >> > >> Doing so enables me to run plot_data_plane.
But when
> I
> > > run
> > > >> > > through
> > > >> > > > >> > >> grid_stat, I get the following error:
> > > >> > > > >> > >>
> > > >> > > > >> > >> ERROR : process_command_line() -> The forecast
and
> > > >> observation
> > > >> > > > >> grids do
> > > >> > > > >> > >> not match:
> > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
> > > lon_ll:
> > > >> > > -0.625
> > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll:
-90.000
> > > lon_ll:
> > > >> > > -0.000
> > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > > >> > > > >> > >>
> > > >> > > > >> > >> So we need to rerun copygb to put the GRIB1
data onto
> > this
> > > >> > grid:
> > > >> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128
90000
> 358750
> > > >> 1250
> > > >> > 942
> > > >> > > > >> 64*"
> > > >> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > >> > > > >> > >>
> > > >> > > > >> > >> After doing that, I was finally able to run
grid_stat
> to
> > > >> > compare
> > > >> > > > >> these
> > > >> > > > >> > >> fields. But since the forecast contains all
0's and
> the
> > > >> > > > observation
> > > >> > > > >> > >> basically contains all 0's, I didn't get any
> meaningful
> > > >> > > statistics.
> > > >> > > > >> > >>
> > > >> > > > >> > >> Seems like I need to get you that patch for
reading
> the
> > > >> lat/lon
> > > >> > > > >> > >> dimensions. You need to start using the copygb
> command
> > > >> listed
> > > >> > > > above
> > > >> > > > >> for
> > > >> > > > >> > >> regridding GRIB files. And you need to figure
out why
> > > your
> > > >> > data
> > > >> > > is
> > > >> > > > >> all
> > > >> > > > >> > >> 0's.
> > > >> > > > >> > >>
> > > >> > > > >> > >> How does that all sound?
> > > >> > > > >> > >>
> > > >> > > > >> > >> Thanks,
> > > >> > > > >> > >> John Halley Gotway
> > > >> > > > >> > >> met_help at ucar.edu
> > > >> > > > >> > >>
> > > >> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo
via RT <
> > > >> > > > >> met_help at ucar.edu>
> > > >> > > > >> > >> wrote:
> > > >> > > > >> > >>
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was
acted
> > upon.
> > > >> > > > >> > >> > Transaction: Ticket created by
> jinwoong.yoo at gmail.com
> > > >> > > > >> > >> > Queue: met_help
> > > >> > > > >> > >> > Subject: grid_stat Error
> > > >> > > > >> > >> > Owner: Nobody
> > > >> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > > >> > > > >> > >> > Status: new
> > > >> > > > >> > >> > Ticket <URL:
> > > >> > > > >>
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > >> > > > >> > >
> > > >> > > > >> > >> >
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Dear WRF Help and MET Help
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Grid_stat produced error message below and
stopped:
> > > >> > > > >> > >> > [jyoo at yslogin4 analysis]$
> > > >> > > > >> > >> >
> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > > >> > > > >> > >> >
> > > >> > > > >> > >> >
> > > >> > > > >> > >>
> > > >> > > > >> >
> > > >> > > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > > >> > > > >> > >> >
> > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > > >> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
> > > >> GridStatConfig_ccsm
> > > >> > > > >> -outdir
> > > >> > > > >> > >> >
/glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > > >> > > > >> > >> > DEBUG 1: Default Config File:
> > > >> > > > >> > >> >
> > > >> > > > >> > >> >
> > > >> > > > >> > >>
> > > >> > > > >> >
> > > >> > > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > > >> > > > >> > >> > DEBUG 1: User Config File:
GridStatConfig_ccsm
> > > >> > > > >> > >> > WARNING:
> > > >> > > > >> > >> > WARNING: NcCfFile::open() -> could not
extract init
> > time
> > > >> from
> > > >> > > > file
> > > >> > > > >> > name
> > > >> > > > >> > >> > WARNING: Using init time of 0
> > > >> > > > >> > >> > WARNING:
> > > >> > > > >> > >> > ERROR :
> > > >> > > > >> > >> > ERROR : process_command_line() -> The
forecast and
> > > >> > observation
> > > >> > > > >> grids
> > > >> > > > >> > do
> > > >> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny:
191
> lat_ll:
> > > >> > -89.529
> > > >> > > > >> lon_ll:
> > > >> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
> > Projection:
> > > >> > Lat/Lon
> > > >> > > > Nx:
> > > >> > > > >> > 288
> > > >> > > > >> > >> Ny:
> > > >> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625 delta_lat:
0.942
> > > >> delta_lon:
> > > >> > > > 1.250
> > > >> > > > >> > >> > ERROR :
> > > >> > > > >> > >> >
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Interestingly, it seems that my forecast file
grid
> > looks
> > > >> the
> > > >> > > same
> > > >> > > > >> as
> > > >> > > > >> > the
> > > >> > > > >> > >> > observation file grid as below:
> > > >> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by
0.942000
> > nxny
> > > >> > 55008
> > > >> > > > >> > >> > long 0.625000 to 358.750000 by
1.250000,
> > (288
> > > x
> > > >> > 191)
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > However, grid_stat reads long 0.625000 as
lon_ll:
> > > -0.625,
> > > >> > > making
> > > >> > > > >> > error.
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Can anyone explain why?
> > > >> > > > >> > >> > Thank you very much.
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Regards,
> > > >> > > > >> > >> >
> > > >> > > > >> > >> > Jinwoong Yoo
> > > >> > > > >> > >> > UNM
> > > >> > > > >> > >> >
> > > >> > > > >> > >> >
> > > >> > > > >> > >>
> > > >> > > > >> > >>
> > > >> > > > >> > >
> > > >> > > > >> >
> > > >> > > > >> >
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Wed Oct 15 10:59:18 2014
Dear John,
Thank you, John.
Yes, I ran a simple test with grid_stat on the Yellowstone and it
produced
statistics along with a nc file.
While waiting for reply from WRF Help folks, I'd like to run grid_stat
for
multiple times. However, my observation data of the CCSM4 netcdf files
come
in monthly data. So I have to specify the time in my config file as
"level
= [ "(0,*,*)" ];"
If I would want to run a script for multiple times, what would be my
option? I can make a script to loop through forecast times of
WRFPRS_d01.*
files, but how can I change the time in the config file for the CCSM4
monthly data file?
If you have an answer, please let me know.
Thank you.
Regards,
Jinwoong Yoo
UNM
On Wed, Oct 15, 2014 at 10:25 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I just finished updating the met-5.0 build on yellowstone:
> /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin
>
> I took at look at the UPP output you sent but can't see an obvious
> problem. Hopefully the folks at wrfhelp at ucar.edu will be able to
help you
> out.
>
> Thanks,
> John
>
> On Tue, Oct 14, 2014 at 4:44 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> > Dear John,
> >
> > Thank you for your update.
> > Are these new updates applied to the build in the Yellowstone at
> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/ ?
> > Please let me know.
> >
> >
> > By the way, John,
> > while I'm postrocessing WRF ARW output,
> > I'm getting error with run_unipost when the forecast hour is 1002.
> > Error did not occur until the fhr=1002.
> > I checked that input file is existing in the directory but it
seems that
> > WRFPRS1002.tm00 was not created for some reason.
> >
> > I put the error message below.
> > Do you think this error is coming from the fhr number being too
large
> > (>1000) as you mentioned previously or something else?
> >
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> >
> >
> >
> >
> > + tmmark=tm00
> > + export tmmark
> > + MP_SHARED_MEMORY=yes
> > + export MP_SHARED_MEMORY
> > + MP_LABELIO=yes
> > + export MP_LABELIO
> > + NEWDATE=1870010100
> > + export NEWDATE
> > + [ 1002 -le 4320 ]
> > + printf %02i 1002
> > + fhr=1002
> > + /glade/scratch/jyoo/UPPV2.2/bin/ndate.exe +1002 1870010100
> > + NEWDATE=1870021118
> > + echo 1870021118
> > + cut -c1-4
> > + YY=1870
> > + cut -c5-6
> > + echo 1870021118
> > + MM=02
> > + cut -c7-8
> > + echo 1870021118
> > + DD=11
> > + echo 1870021118
> > + cut -c9-10
> > + HH=18
> > + echo NEWDATE 1870021118
> > NEWDATE 1870021118
> > + echo YY 1870
> > YY 1870
> > + cat
> > + 1> itag 0<< \EOF
> > ../wrfprd/wrfout_d01_1870-02-11_18:00:00
> > netcdf
> > 1870-02-11_18:00:00
> > NCAR
> > EOF
> > + rm fort.110 fort.14
> > + ln -sf wrf_cntrl.parm fort.14
> > + /glade/scratch/jyoo/UPPV2.2/bin/unipost.exe
> > + 1> unipost_d01.1002.out 2>& 1
> > + cp WRFPRS1002.tm00 WRFPRS_d01.tm00.bk
> > cp: cannot stat `WRFPRS1002.tm00': No such file or directory
> > + mv WRFPRS1002.tm00 WRFPRS_d01.1002
> > mv: cannot stat `WRFPRS1002.tm00': No such file or directory
> > + ls -l WRFPRS_d01.1002
> > ls: cannot access WRFPRS_d01.1002: No such file or directory
> > + err1=2
> > + test 2 -ne 0
> > + echo 'UNIPOST FAILED, EXITTING'
> > UNIPOST FAILED, EXITTING
> > + exit
> >
> >
> > On Tue, Oct 14, 2014 at 2:56 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jinwoong,
> > >
> > > I apologize for the delay in providing a solution to this
problem.
> That
> > > error is being caused by integer overflow when trying to write
unixtime
> > > (seconds since Jan 1 1970) for the year 1870 as a variable
attribute to
> > the
> > > NetCDF output file. I just distributed a patch that checks for
this
> > > condition and, if overflow would happen, prints a warning and
skips
> > writing
> > > those values. Ultimately, we hope to come up with a better
solution in
> > the
> > > next release. But for now, this should get you past the error.
> > >
> > > Please follow the instructions posted here to download and apply
the
> > latest
> > > set of patches for met-5.0:
> > >
> > >
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.0/index.php
> > >
> > > Please let me know if you continue to experience problems after
> applying
> > > these patches.
> > >
> > > Thanks,
> > > John Halley Gotway
> > > met_help at ucar.edu
> > >
> > > On Wed, Oct 8, 2014 at 3:23 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>
> > > >
> > > > By the way,
> > > > Since I didn't get the nc file from Grid_stat by disabling the
> option,
> > > It's
> > > > a bit hard to understand the output of grid_stat now.
> > > >
> > > > Could you figure out what should be done to get the nc file
from
> > > grid_stat?
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong Yoo
> > > > UNM
> > > >
> > > > On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> > > > wrote:
> > > >
> > > > > Dear John,
> > > > >
> > > > > At present, I just would like to get the general idea about
using
> MET
> > > > > through Grid_stat and eventually I'd like to run series-
analysis so
> > > that
> > > > I
> > > > > can evaluate the WRF simulation performance against the
CCSM4 over
> > the
> > > 10
> > > > > years period of integral.
> > > > >
> > > > > In other words, I would like to get the time series of
scores for a
> > few
> > > > > variables such as T2, PSL, soil moisture, precipitation,
snowfall,
> > etc.
> > > > >
> > > > > Then, what will be the next step for the most economic way?
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jinwoong Yoo
> > > > > UNM
> > > > >
> > > > > On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Jinwoong,
> > > > >>
> > > > >> What you do with the statistical output that the MET tools
> generate
> > > > really
> > > > >> depends on what sort of question you're trying to answer.
If you
> > want
> > > > to
> > > > >> aggregate results across multiple runs of grid-stat, you
can use
> > > > >> stat-analysis to do that. Alternatively, you could plot a
time
> > series
> > > > of
> > > > >> scores output from each run. It's really up to you to
analyze and
> > > make
> > > > >> sense of your statistical output.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu>
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > > > >> >
> > > > >> > Dear John,
> > > > >> >
> > > > >> > Yes. Disabling nc_pairs_flag did helped Grid_stat
generating
> > > > statistics
> > > > >> txt
> > > > >> > files.
> > > > >> > Then, I should run stat_analysis using the grid_stat
outputs
> > right?
> > > > >> >
> > > > >> > Thank you.
> > > > >> >
> > > > >> > Regards,
> > > > >> >
> > > > >> > Jinwoong Yoo
> > > > >> > UNM
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via RT
<
> > > > >> > met_help at ucar.edu
> > > > >> > > wrote:
> > > > >> >
> > > > >> > > Jinwoong,
> > > > >> > >
> > > > >> > > Try editing your Grid-Stat config file by setting:
> > > > >> > > nc_pairs_flag = FALSE;
> > > > >> > >
> > > > >> > > We're getting a weird error when Grid-Stat tries to
write the
> > > NetCDF
> > > > >> > output
> > > > >> > > file:
> > > > >> > > NetCDF: Numeric conversion not representable
> > > > >> > >
> > > > >> > > That's causing you to see empty output files.
> > > > >> > >
> > > > >> > > I'll look into the source of this error, but for now,
just
> > disable
> > > > the
> > > > >> > > NetCDF matched pairs output.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > John
> > > > >> > >
> > > > >> > >
> > > > >> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT <
> > > > >> met_help at ucar.edu>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > >
> > > > >> > > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > >
> > > > >> > > >
> > > > >> > > > Dear John,
> > > > >> > > >
> > > > >> > > > Maybe should I use gen_poly_mask to define the area
of my
> WRF
> > > > model
> > > > >> > > domain
> > > > >> > > > (which is a tropical channel) before I run grid_stat
against
> > the
> > > > >> CCSM4
> > > > >> > in
> > > > >> > > > global domain?
> > > > >> > > >
> > > > >> > > > Jinwoong Yoo
> > > > >> > > > UNM
> > > > >> > > >
> > > > >> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
> > > > >> jinwoong.yoo at gmail.com>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > Dear John,
> > > > >> > > > >
> > > > >> > > > > I switched variable to PRMSL (sea level pressure)
for a
> > > > Grid_stat
> > > > >> > test.
> > > > >> > > > > Grid_stat seemed to run this time but produced
files were
> > > empty.
> > > > >> > > > >
> > > > >> > > > > However, when I produced a ps file for the
variable, the
> > > output
> > > > >> file
> > > > >> > > > looks
> > > > >> > > > > ok (attached).
> > > > >> > > > >
> > > > >> > > > > [jyoo at yslogin6 postprd]$
> > > > >> > > > > pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > > >> > > > > [jyoo at yslogin6 postprd]$
> > > > >> > > > >
> > > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
> > > > >> > > > >
> > > > >>
> >
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > > >> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL";
> level="L0";'
> > > > >> > > > >
> > > > >> > > > > Do I need to change other information for
dictionary parts
> > for
> > > > the
> > > > >> > > > > variables being compared in the GridStatConfig_ccsm
file
> > > > (attached
> > > > >> > > also)?
> > > > >> > > > > Where can I find more detail information about the
> > > > GridStatConfig
> > > > >> > than
> > > > >> > > in
> > > > >> > > > > the MET Users Guide V5.0, if available?
> > > > >> > > > >
> > > > >> > > > > Thank you.
> > > > >> > > > >
> > > > >> > > > > Regards,
> > > > >> > > > >
> > > > >> > > > > Jinwoong Yoo
> > > > >> > > > > UNM
> > > > >> > > > >
> > > > >> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley Gotway
via RT
> <
> > > > >> > > > > met_help at ucar.edu> wrote:
> > > > >> > > > >
> > > > >> > > > >> Jinwoong,
> > > > >> > > > >>
> > > > >> > > > >> OK, I updated the build on yellowstone to include
the
> > latest
> > > > set
> > > > >> of
> > > > >> > > > >> patches:
> > > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > > > >> > > > >>
> > > > >> > > > >> The original, as released, version of met-5.0 can
still
> be
> > > > found
> > > > >> > here:
> > > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG
> > > > >> > > > >>
> > > > >> > > > >> Please give the updated version a shot and let me
know
> how
> > it
> > > > >> goes.
> > > > >> > > > >>
> > > > >> > > > >> Thanks,
> > > > >> > > > >> John
> > > > >> > > > >>
> > > > >> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via
RT <
> > > > >> > > met_help at ucar.edu>
> > > > >> > > > >> wrote:
> > > > >> > > > >>
> > > > >> > > > >> >
> > > > >> > > > >> > <URL:
> > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > >> >
> > > > >> > > > >> >
> > > > >> > > > >> > Dear John,
> > > > >> > > > >> >
> > > > >> > > > >> > Since I'm using the MET that is available on the
> > > Yellowstone
> > > > >> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/,
> > > > >> > > > >> > you can just let me know how I can use the patch
for
> > > reading
> > > > >> the
> > > > >> > > > lat/lon
> > > > >> > > > >> > dimensions of the CCSM4 file in the Yellowstone.
> > > > >> > > > >> >
> > > > >> > > > >> > Thank you.
> > > > >> > > > >> >
> > > > >> > > > >> > Regards,
> > > > >> > > > >> > Jinwoong Yoo
> > > > >> > > > >> > UNM
> > > > >> > > > >> >
> > > > >> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> > > > >> > > jinwoong.yoo at gmail.com>
> > > > >> > > > >> > wrote:
> > > > >> > > > >> >
> > > > >> > > > >> > > Dear John
> > > > >> > > > >> > >
> > > > >> > > > >> > > First of all, thank you for your efforts to
figure
> out
> > > the
> > > > >> issue
> > > > >> > > > with
> > > > >> > > > >> > > Grid_stat of my case.
> > > > >> > > > >> > >
> > > > >> > > > >> > > >>> Do you expect this or should there be some
> non-zero
> > > > >> values?
> > > > >> > > > >> > >
> > > > >> > > > >> > > This is a test case with precipitation
variables from
> > the
> > > > WRF
> > > > >> > and
> > > > >> > > > >> CCSM4
> > > > >> > > > >> > at
> > > > >> > > > >> > > model initialization time 00. So, 0 is
reasonable
> > > although
> > > > I
> > > > >> did
> > > > >> > > not
> > > > >> > > > >> > > consider carefully when I pick the variable
for a
> test
> > > > case.
> > > > >> > > > >> > >
> > > > >> > > > >> > > >>>After running this through the debugger, I
found
> > that
> > > > MET
> > > > >> is
> > > > >> > > > >> getting
> > > > >> > > > >> > > confused by the presence of the slat and slon
> > variables.
> > > > >> It's
> > > > >> > > using
> > > > >> > > > >> them
> > > > >> > > > >> > > to define the grid rather than the lat and lon
> > variables.
> > > > >> And
> > > > >> > > that
> > > > >> > > > >> leads
> > > > >> > > > >> > > to the difference in the grids.
> > > > >> > > > >> > >
> > > > >> > > > >> > > That's one thing that I mentioned in my
previous
> email:
> > > > >> > > > >> > > "However, there are something strange.
> > > > >> > > > >> > > According to what Grid-Stat reads in for the
CCSM4
> file
> > > > >> > > (Projection:
> > > > >> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll: 0.625
> > > > >> delta_lat:
> > > > >> > > > 0.942
> > > > >> > > > >> > > delta_lon: 1.250), lat and lon information
were
> flipped
> > > > >> compared
> > > > >> > > to
> > > > >> > > > >> what
> > > > >> > > > >> > I
> > > > >> > > > >> > > get from ncdump of the CCSM4 file (lat = 192 ;
lon =
> > 288
> > > ;
> > > > >> slat
> > > > >> > =
> > > > >> > > > 191
> > > > >> > > > >> > ;slon
> > > > >> > > > >> > > = 288) and the Ny: 191 matches to
slat(staggered
> > > latitude)
> > > > >> not
> > > > >> > > > >> latitude."
> > > > >> > > > >> > > I'm glad you found a solution to the issue
with NC
> file
> > > > with
> > > > >> two
> > > > >> > > > >> > different
> > > > >> > > > >> > > pair of lat (lat and slat) and lon (lon and
slon).
> > > > >> > > > >> > >
> > > > >> > > > >> > >
> > > > >> > > > >> > > >>> So we need to rerun copygb to put the
GRIB1 data
> > onto
> > > > >> this
> > > > >> > > grid:
> > > > >> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128
90000
> > 358750
> > > > 1250
> > > > >> > 942
> > > > >> > > > 64*"
> > > > >> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > > >> > > > >> > >
> > > > >> > > > >> > > Running copygb is not a big deal at all.
> > > > >> > > > >> > >
> > > > >> > > > >> > > >>> After doing that, I was finally able to
run
> > grid_stat
> > > > to
> > > > >> > > compare
> > > > >> > > > >> > these
> > > > >> > > > >> > > fields. But since the forecast contains all
0's and
> > the
> > > > >> > > observation
> > > > >> > > > >> > > basically contains all 0's, I didn't get any
> meaningful
> > > > >> > > statistics.
> > > > >> > > > >> > >
> > > > >> > > > >> > >
> > > > >> > > > >> > > I can switch to a different variable than the
> > > precipitation
> > > > >> at
> > > > >> > the
> > > > >> > > > >> > > initialization time for a test.
> > > > >> > > > >> > > Please send me the patch for reading the
lat/lon
> > > dimensions
> > > > >> via
> > > > >> > > > email
> > > > >> > > > >> or
> > > > >> > > > >> > > you can put the file(s) on the Yellowstone and
let me
> > > know
> > > > >> the
> > > > >> > > path
> > > > >> > > > to
> > > > >> > > > >> > the
> > > > >> > > > >> > > file(s), whatever suits you best.
> > > > >> > > > >> > >
> > > > >> > > > >> > > Thank you very much.
> > > > >> > > > >> > >
> > > > >> > > > >> > > Regards,
> > > > >> > > > >> > >
> > > > >> > > > >> > > Jinwoong Yoo
> > > > >> > > > >> > > UNM
> > > > >> > > > >> > >
> > > > >> > > > >> > >
> > > > >> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley
Gotway
> via
> > > RT
> > > > <
> > > > >> > > > >> > > met_help at ucar.edu> wrote:
> > > > >> > > > >> > >
> > > > >> > > > >> > >> Jinwoong,
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> I see that you're having problems comparing a
GRIB1
> > file
> > > > to
> > > > >> a
> > > > >> > > > >> > CF-compliant
> > > > >> > > > >> > >> NetCDF file using the grid_stat tool.
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> I ran grid_stat and the plot_data_plane tools
> through
> > > the
> > > > >> > > debugger
> > > > >> > > > >> and
> > > > >> > > > >> > >> found some issues.
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> First, I ran the following plot_data_plane
command
> to
> > > plot
> > > > >> the
> > > > >> > > > CPRAT
> > > > >> > > > >> > >> variable from the GRIB1 file:
> > > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > >> > > > >> > >> WRFPRS_d01.00_2latlon \
> > > > >> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > > > >> > > > >> > >> 'name="CPRAT"; level="L0";'
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Turns out that all the values are 0. This
can also
> be
> > > > seen
> > > > >> via
> > > > >> > > > >> wgrib:
> > > > >> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > > > >> > > > >> > >> ...
> > > > >> > > > >> > >> min/max data 0 0
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Do you expect this or should there be some
non-zero
> > > > values?
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Second, I looked at the PRECC variable using
ncview
> > and
> > > > see
> > > > >> > that
> > > > >> > > it
> > > > >> > > > >> > ranges
> > > > >> > > > >> > >> from 0 to 1.157e-06. Those values are so
small that
> > the
> > > > MET
> > > > >> > > tools
> > > > >> > > > >> won't
> > > > >> > > > >> > >> really be able to distinguish between them.
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Next, I tried running the NetCDF data through
> > > > >> plot_data_plane,
> > > > >> > > but
> > > > >> > > > >> got
> > > > >> > > > >> > >> this
> > > > >> > > > >> > >> error:
> > > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc \
> > > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-
01_PRECC.ps \
> > > > >> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const
LongArray &,
> > > > >> DataPlane
> > > > >> > &)
> > > > >> > > > >> const
> > > > >> > > > >> > ->
> > > > >> > > > >> > >> star found in bad slot
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> After running this through the debugger, I
found
> that
> > > MET
> > > > is
> > > > >> > > > getting
> > > > >> > > > >> > >> confused by the presence of the slat and slon
> > variables.
> > > > >> It's
> > > > >> > > > using
> > > > >> > > > >> > them
> > > > >> > > > >> > >> to define the grid rather than the lat and
lon
> > > variables.
> > > > >> And
> > > > >> > > that
> > > > >> > > > >> > leads
> > > > >> > > > >> > >> to the difference in the grids. Also, MET
stores
> > > > longitude
> > > > >> > > values
> > > > >> > > > >> > >> internally in degrees_west rather than the
more
> common
> > > > >> > > > degrees_east.
> > > > >> > > > >> > When
> > > > >> > > > >> > >> you see -0.625 degrees longitude, that's
> degrees_west.
> > > > Very
> > > > >> > > > >> confusing,
> > > > >> > > > >> > I
> > > > >> > > > >> > >> know!
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> I tweaked the NetCDF CF code to print warning
> messages
> > > > when
> > > > >> it
> > > > >> > > > >> > encounters
> > > > >> > > > >> > >> multiple variables for latitude and
longitude, and
> to
> > > use
> > > > >> the
> > > > >> > > first
> > > > >> > > > >> > >> instance of them rather than the second.
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Doing so enables me to run plot_data_plane.
But
> when
> > I
> > > > run
> > > > >> > > through
> > > > >> > > > >> > >> grid_stat, I get the following error:
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> ERROR : process_command_line() -> The
forecast and
> > > > >> observation
> > > > >> > > > >> grids do
> > > > >> > > > >> > >> not match:
> > > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
-89.529
> > > > lon_ll:
> > > > >> > > -0.625
> > > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll:
-90.000
> > > > lon_ll:
> > > > >> > > -0.000
> > > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> So we need to rerun copygb to put the GRIB1
data
> onto
> > > this
> > > > >> > grid:
> > > > >> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128
90000
> > 358750
> > > > >> 1250
> > > > >> > 942
> > > > >> > > > >> 64*"
> > > > >> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> After doing that, I was finally able to run
> grid_stat
> > to
> > > > >> > compare
> > > > >> > > > >> these
> > > > >> > > > >> > >> fields. But since the forecast contains all
0's and
> > the
> > > > >> > > > observation
> > > > >> > > > >> > >> basically contains all 0's, I didn't get any
> > meaningful
> > > > >> > > statistics.
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Seems like I need to get you that patch for
reading
> > the
> > > > >> lat/lon
> > > > >> > > > >> > >> dimensions. You need to start using the
copygb
> > command
> > > > >> listed
> > > > >> > > > above
> > > > >> > > > >> for
> > > > >> > > > >> > >> regridding GRIB files. And you need to
figure out
> why
> > > > your
> > > > >> > data
> > > > >> > > is
> > > > >> > > > >> all
> > > > >> > > > >> > >> 0's.
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> How does that all sound?
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> Thanks,
> > > > >> > > > >> > >> John Halley Gotway
> > > > >> > > > >> > >> met_help at ucar.edu
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong Yoo
via RT
> <
> > > > >> > > > >> met_help at ucar.edu>
> > > > >> > > > >> > >> wrote:
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290 was
acted
> > > upon.
> > > > >> > > > >> > >> > Transaction: Ticket created by
> > jinwoong.yoo at gmail.com
> > > > >> > > > >> > >> > Queue: met_help
> > > > >> > > > >> > >> > Subject: grid_stat Error
> > > > >> > > > >> > >> > Owner: Nobody
> > > > >> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > > > >> > > > >> > >> > Status: new
> > > > >> > > > >> > >> > Ticket <URL:
> > > > >> > > > >>
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > >> > > > >> > >
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Dear WRF Help and MET Help
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Grid_stat produced error message below and
> stopped:
> > > > >> > > > >> > >> > [jyoo at yslogin4 analysis]$
> > > > >> > > > >> > >> >
> > > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >>
> > > > >> > > > >> >
> > > > >> > > > >>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > > > >> > > > >> > >> >
> > > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > > > >> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
> > > > >> GridStatConfig_ccsm
> > > > >> > > > >> -outdir
> > > > >> > > > >> > >> >
> /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > > > >> > > > >> > >> > DEBUG 1: Default Config File:
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >>
> > > > >> > > > >> >
> > > > >> > > > >>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > > > >> > > > >> > >> > DEBUG 1: User Config File:
GridStatConfig_ccsm
> > > > >> > > > >> > >> > WARNING:
> > > > >> > > > >> > >> > WARNING: NcCfFile::open() -> could not
extract
> init
> > > time
> > > > >> from
> > > > >> > > > file
> > > > >> > > > >> > name
> > > > >> > > > >> > >> > WARNING: Using init time of 0
> > > > >> > > > >> > >> > WARNING:
> > > > >> > > > >> > >> > ERROR :
> > > > >> > > > >> > >> > ERROR : process_command_line() -> The
forecast
> and
> > > > >> > observation
> > > > >> > > > >> grids
> > > > >> > > > >> > do
> > > > >> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288 Ny:
191
> > lat_ll:
> > > > >> > -89.529
> > > > >> > > > >> lon_ll:
> > > > >> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250 !=
> > > Projection:
> > > > >> > Lat/Lon
> > > > >> > > > Nx:
> > > > >> > > > >> > 288
> > > > >> > > > >> > >> Ny:
> > > > >> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat: 0.942
> > > > >> delta_lon:
> > > > >> > > > 1.250
> > > > >> > > > >> > >> > ERROR :
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Interestingly, it seems that my forecast
file grid
> > > looks
> > > > >> the
> > > > >> > > same
> > > > >> > > > >> as
> > > > >> > > > >> > the
> > > > >> > > > >> > >> > observation file grid as below:
> > > > >> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by
0.942000
> > > nxny
> > > > >> > 55008
> > > > >> > > > >> > >> > long 0.625000 to 358.750000 by
1.250000,
> > > (288
> > > > x
> > > > >> > 191)
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > However, grid_stat reads long 0.625000 as
lon_ll:
> > > > -0.625,
> > > > >> > > making
> > > > >> > > > >> > error.
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Can anyone explain why?
> > > > >> > > > >> > >> > Thank you very much.
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Regards,
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> > Jinwoong Yoo
> > > > >> > > > >> > >> > UNM
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >> >
> > > > >> > > > >> > >>
> > > > >> > > > >> > >>
> > > > >> > > > >> > >
> > > > >> > > > >> >
> > > > >> > > > >> >
> > > > >> > > > >>
> > > > >> > > > >>
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: John Halley Gotway
Time: Wed Oct 15 11:15:50 2014
Jinwoong,
If you're running Grid-Stat multiple times via a script, I suggest
using an
environment variable in your Grid-Stat configuration file. For
example...
setenv CUR_LVL 0
And in your Grid-Stat config file, use:
= [ "(${CUR_LVL},*,*)" ];
Just set that variable in your script that calls Grid-Stat and the MET
code
will substitute in the value. Supporting environment variables in the
config files makes scripting up calls to the MET tools much easier.
Thanks,
John
On Wed, Oct 15, 2014 at 10:59 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
>
> Dear John,
>
> Thank you, John.
> Yes, I ran a simple test with grid_stat on the Yellowstone and it
produced
> statistics along with a nc file.
>
> While waiting for reply from WRF Help folks, I'd like to run
grid_stat for
> multiple times. However, my observation data of the CCSM4 netcdf
files come
> in monthly data. So I have to specify the time in my config file as
"level
> = [ "(0,*,*)" ];"
> If I would want to run a script for multiple times, what would be my
> option? I can make a script to loop through forecast times of
WRFPRS_d01.*
> files, but how can I change the time in the config file for the
CCSM4
> monthly data file?
>
> If you have an answer, please let me know.
> Thank you.
>
> Regards,
>
> Jinwoong Yoo
> UNM
>
> On Wed, Oct 15, 2014 at 10:25 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jinwoong,
> >
> > I just finished updating the met-5.0 build on yellowstone:
> > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin
> >
> > I took at look at the UPP output you sent but can't see an obvious
> > problem. Hopefully the folks at wrfhelp at ucar.edu will be able to
help
> you
> > out.
> >
> > Thanks,
> > John
> >
> > On Tue, Oct 14, 2014 at 4:44 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > >
> > > Dear John,
> > >
> > > Thank you for your update.
> > > Are these new updates applied to the build in the Yellowstone at
> > > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/ ?
> > > Please let me know.
> > >
> > >
> > > By the way, John,
> > > while I'm postrocessing WRF ARW output,
> > > I'm getting error with run_unipost when the forecast hour is
1002.
> > > Error did not occur until the fhr=1002.
> > > I checked that input file is existing in the directory but it
seems
> that
> > > WRFPRS1002.tm00 was not created for some reason.
> > >
> > > I put the error message below.
> > > Do you think this error is coming from the fhr number being too
large
> > > (>1000) as you mentioned previously or something else?
> > >
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > > UNM
> > >
> > >
> > >
> > >
> > >
> > > + tmmark=tm00
> > > + export tmmark
> > > + MP_SHARED_MEMORY=yes
> > > + export MP_SHARED_MEMORY
> > > + MP_LABELIO=yes
> > > + export MP_LABELIO
> > > + NEWDATE=1870010100
> > > + export NEWDATE
> > > + [ 1002 -le 4320 ]
> > > + printf %02i 1002
> > > + fhr=1002
> > > + /glade/scratch/jyoo/UPPV2.2/bin/ndate.exe +1002 1870010100
> > > + NEWDATE=1870021118
> > > + echo 1870021118
> > > + cut -c1-4
> > > + YY=1870
> > > + cut -c5-6
> > > + echo 1870021118
> > > + MM=02
> > > + cut -c7-8
> > > + echo 1870021118
> > > + DD=11
> > > + echo 1870021118
> > > + cut -c9-10
> > > + HH=18
> > > + echo NEWDATE 1870021118
> > > NEWDATE 1870021118
> > > + echo YY 1870
> > > YY 1870
> > > + cat
> > > + 1> itag 0<< \EOF
> > > ../wrfprd/wrfout_d01_1870-02-11_18:00:00
> > > netcdf
> > > 1870-02-11_18:00:00
> > > NCAR
> > > EOF
> > > + rm fort.110 fort.14
> > > + ln -sf wrf_cntrl.parm fort.14
> > > + /glade/scratch/jyoo/UPPV2.2/bin/unipost.exe
> > > + 1> unipost_d01.1002.out 2>& 1
> > > + cp WRFPRS1002.tm00 WRFPRS_d01.tm00.bk
> > > cp: cannot stat `WRFPRS1002.tm00': No such file or directory
> > > + mv WRFPRS1002.tm00 WRFPRS_d01.1002
> > > mv: cannot stat `WRFPRS1002.tm00': No such file or directory
> > > + ls -l WRFPRS_d01.1002
> > > ls: cannot access WRFPRS_d01.1002: No such file or directory
> > > + err1=2
> > > + test 2 -ne 0
> > > + echo 'UNIPOST FAILED, EXITTING'
> > > UNIPOST FAILED, EXITTING
> > > + exit
> > >
> > >
> > > On Tue, Oct 14, 2014 at 2:56 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jinwoong,
> > > >
> > > > I apologize for the delay in providing a solution to this
problem.
> > That
> > > > error is being caused by integer overflow when trying to write
> unixtime
> > > > (seconds since Jan 1 1970) for the year 1870 as a variable
attribute
> to
> > > the
> > > > NetCDF output file. I just distributed a patch that checks
for this
> > > > condition and, if overflow would happen, prints a warning and
skips
> > > writing
> > > > those values. Ultimately, we hope to come up with a better
solution
> in
> > > the
> > > > next release. But for now, this should get you past the
error.
> > > >
> > > > Please follow the instructions posted here to download and
apply the
> > > latest
> > > > set of patches for met-5.0:
> > > >
> > > >
> >
http://www.dtcenter.org/met/users/support/known_issues/METv5.0/index.php
> > > >
> > > > Please let me know if you continue to experience problems
after
> > applying
> > > > these patches.
> > > >
> > > > Thanks,
> > > > John Halley Gotway
> > > > met_help at ucar.edu
> > > >
> > > > On Wed, Oct 8, 2014 at 3:23 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > > > >
> > > > > By the way,
> > > > > Since I didn't get the nc file from Grid_stat by disabling
the
> > option,
> > > > It's
> > > > > a bit hard to understand the output of grid_stat now.
> > > > >
> > > > > Could you figure out what should be done to get the nc file
from
> > > > grid_stat?
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jinwoong Yoo
> > > > > UNM
> > > > >
> > > > > On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Dear John,
> > > > > >
> > > > > > At present, I just would like to get the general idea
about using
> > MET
> > > > > > through Grid_stat and eventually I'd like to run series-
analysis
> so
> > > > that
> > > > > I
> > > > > > can evaluate the WRF simulation performance against the
CCSM4
> over
> > > the
> > > > 10
> > > > > > years period of integral.
> > > > > >
> > > > > > In other words, I would like to get the time series of
scores
> for a
> > > few
> > > > > > variables such as T2, PSL, soil moisture, precipitation,
> snowfall,
> > > etc.
> > > > > >
> > > > > > Then, what will be the next step for the most economic
way?
> > > > > > Thank you.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Jinwoong Yoo
> > > > > > UNM
> > > > > >
> > > > > > On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > >> Jinwoong,
> > > > > >>
> > > > > >> What you do with the statistical output that the MET
tools
> > generate
> > > > > really
> > > > > >> depends on what sort of question you're trying to answer.
If
> you
> > > want
> > > > > to
> > > > > >> aggregate results across multiple runs of grid-stat, you
can use
> > > > > >> stat-analysis to do that. Alternatively, you could plot
a time
> > > series
> > > > > of
> > > > > >> scores output from each run. It's really up to you to
analyze
> and
> > > > make
> > > > > >> sense of your statistical output.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> John
> > > > > >>
> > > > > >> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT <
> > > > met_help at ucar.edu>
> > > > > >> wrote:
> > > > > >>
> > > > > >> >
> > > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> >
> > > > > >> >
> > > > > >> > Dear John,
> > > > > >> >
> > > > > >> > Yes. Disabling nc_pairs_flag did helped Grid_stat
generating
> > > > > statistics
> > > > > >> txt
> > > > > >> > files.
> > > > > >> > Then, I should run stat_analysis using the grid_stat
outputs
> > > right?
> > > > > >> >
> > > > > >> > Thank you.
> > > > > >> >
> > > > > >> > Regards,
> > > > > >> >
> > > > > >> > Jinwoong Yoo
> > > > > >> > UNM
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway via
RT <
> > > > > >> > met_help at ucar.edu
> > > > > >> > > wrote:
> > > > > >> >
> > > > > >> > > Jinwoong,
> > > > > >> > >
> > > > > >> > > Try editing your Grid-Stat config file by setting:
> > > > > >> > > nc_pairs_flag = FALSE;
> > > > > >> > >
> > > > > >> > > We're getting a weird error when Grid-Stat tries to
write
> the
> > > > NetCDF
> > > > > >> > output
> > > > > >> > > file:
> > > > > >> > > NetCDF: Numeric conversion not representable
> > > > > >> > >
> > > > > >> > > That's causing you to see empty output files.
> > > > > >> > >
> > > > > >> > > I'll look into the source of this error, but for now,
just
> > > disable
> > > > > the
> > > > > >> > > NetCDF matched pairs output.
> > > > > >> > >
> > > > > >> > > Thanks,
> > > > > >> > > John
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT <
> > > > > >> met_help at ucar.edu>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > >
> > > > > >> > > > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > >
> > > > > >> > > >
> > > > > >> > > > Dear John,
> > > > > >> > > >
> > > > > >> > > > Maybe should I use gen_poly_mask to define the area
of my
> > WRF
> > > > > model
> > > > > >> > > domain
> > > > > >> > > > (which is a tropical channel) before I run
grid_stat
> against
> > > the
> > > > > >> CCSM4
> > > > > >> > in
> > > > > >> > > > global domain?
> > > > > >> > > >
> > > > > >> > > > Jinwoong Yoo
> > > > > >> > > > UNM
> > > > > >> > > >
> > > > > >> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
> > > > > >> jinwoong.yoo at gmail.com>
> > > > > >> > > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Dear John,
> > > > > >> > > > >
> > > > > >> > > > > I switched variable to PRMSL (sea level pressure)
for a
> > > > > Grid_stat
> > > > > >> > test.
> > > > > >> > > > > Grid_stat seemed to run this time but produced
files
> were
> > > > empty.
> > > > > >> > > > >
> > > > > >> > > > > However, when I produced a ps file for the
variable, the
> > > > output
> > > > > >> file
> > > > > >> > > > looks
> > > > > >> > > > > ok (attached).
> > > > > >> > > > >
> > > > > >> > > > > [jyoo at yslogin6 postprd]$
> > > > > >> > > > >
pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > > > >> > > > > [jyoo at yslogin6 postprd]$
> > > > > >> > > > >
> > > > > /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG/bin/plot_data_plane
> > > > > >> > > > >
> > > > > >>
> > >
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > > > >> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL";
> > level="L0";'
> > > > > >> > > > >
> > > > > >> > > > > Do I need to change other information for
dictionary
> parts
> > > for
> > > > > the
> > > > > >> > > > > variables being compared in the
GridStatConfig_ccsm file
> > > > > (attached
> > > > > >> > > also)?
> > > > > >> > > > > Where can I find more detail information about
the
> > > > > GridStatConfig
> > > > > >> > than
> > > > > >> > > in
> > > > > >> > > > > the MET Users Guide V5.0, if available?
> > > > > >> > > > >
> > > > > >> > > > > Thank you.
> > > > > >> > > > >
> > > > > >> > > > > Regards,
> > > > > >> > > > >
> > > > > >> > > > > Jinwoong Yoo
> > > > > >> > > > > UNM
> > > > > >> > > > >
> > > > > >> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley
Gotway via
> RT
> > <
> > > > > >> > > > > met_help at ucar.edu> wrote:
> > > > > >> > > > >
> > > > > >> > > > >> Jinwoong,
> > > > > >> > > > >>
> > > > > >> > > > >> OK, I updated the build on yellowstone to
include the
> > > latest
> > > > > set
> > > > > >> of
> > > > > >> > > > >> patches:
> > > > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > > > > >> > > > >>
> > > > > >> > > > >> The original, as released, version of met-5.0
can still
> > be
> > > > > found
> > > > > >> > here:
> > > > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG
> > > > > >> > > > >>
> > > > > >> > > > >> Please give the updated version a shot and let
me know
> > how
> > > it
> > > > > >> goes.
> > > > > >> > > > >>
> > > > > >> > > > >> Thanks,
> > > > > >> > > > >> John
> > > > > >> > > > >>
> > > > > >> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo via
RT <
> > > > > >> > > met_help at ucar.edu>
> > > > > >> > > > >> wrote:
> > > > > >> > > > >>
> > > > > >> > > > >> >
> > > > > >> > > > >> > <URL:
> > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > > >> >
> > > > > >> > > > >> >
> > > > > >> > > > >> > Dear John,
> > > > > >> > > > >> >
> > > > > >> > > > >> > Since I'm using the MET that is available on
the
> > > > Yellowstone
> > > > > >> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/,
> > > > > >> > > > >> > you can just let me know how I can use the
patch for
> > > > reading
> > > > > >> the
> > > > > >> > > > lat/lon
> > > > > >> > > > >> > dimensions of the CCSM4 file in the
Yellowstone.
> > > > > >> > > > >> >
> > > > > >> > > > >> > Thank you.
> > > > > >> > > > >> >
> > > > > >> > > > >> > Regards,
> > > > > >> > > > >> > Jinwoong Yoo
> > > > > >> > > > >> > UNM
> > > > > >> > > > >> >
> > > > > >> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo <
> > > > > >> > > jinwoong.yoo at gmail.com>
> > > > > >> > > > >> > wrote:
> > > > > >> > > > >> >
> > > > > >> > > > >> > > Dear John
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > First of all, thank you for your efforts to
figure
> > out
> > > > the
> > > > > >> issue
> > > > > >> > > > with
> > > > > >> > > > >> > > Grid_stat of my case.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > >>> Do you expect this or should there be
some
> > non-zero
> > > > > >> values?
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > This is a test case with precipitation
variables
> from
> > > the
> > > > > WRF
> > > > > >> > and
> > > > > >> > > > >> CCSM4
> > > > > >> > > > >> > at
> > > > > >> > > > >> > > model initialization time 00. So, 0 is
reasonable
> > > > although
> > > > > I
> > > > > >> did
> > > > > >> > > not
> > > > > >> > > > >> > > consider carefully when I pick the variable
for a
> > test
> > > > > case.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > >>>After running this through the debugger,
I found
> > > that
> > > > > MET
> > > > > >> is
> > > > > >> > > > >> getting
> > > > > >> > > > >> > > confused by the presence of the slat and
slon
> > > variables.
> > > > > >> It's
> > > > > >> > > using
> > > > > >> > > > >> them
> > > > > >> > > > >> > > to define the grid rather than the lat and
lon
> > > variables.
> > > > > >> And
> > > > > >> > > that
> > > > > >> > > > >> leads
> > > > > >> > > > >> > > to the difference in the grids.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > That's one thing that I mentioned in my
previous
> > email:
> > > > > >> > > > >> > > "However, there are something strange.
> > > > > >> > > > >> > > According to what Grid-Stat reads in for the
CCSM4
> > file
> > > > > >> > > (Projection:
> > > > > >> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> 0.625
> > > > > >> delta_lat:
> > > > > >> > > > 0.942
> > > > > >> > > > >> > > delta_lon: 1.250), lat and lon information
were
> > flipped
> > > > > >> compared
> > > > > >> > > to
> > > > > >> > > > >> what
> > > > > >> > > > >> > I
> > > > > >> > > > >> > > get from ncdump of the CCSM4 file (lat = 192
; lon
> =
> > > 288
> > > > ;
> > > > > >> slat
> > > > > >> > =
> > > > > >> > > > 191
> > > > > >> > > > >> > ;slon
> > > > > >> > > > >> > > = 288) and the Ny: 191 matches to
slat(staggered
> > > > latitude)
> > > > > >> not
> > > > > >> > > > >> latitude."
> > > > > >> > > > >> > > I'm glad you found a solution to the issue
with NC
> > file
> > > > > with
> > > > > >> two
> > > > > >> > > > >> > different
> > > > > >> > > > >> > > pair of lat (lat and slat) and lon (lon and
slon).
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > >>> So we need to rerun copygb to put the
GRIB1
> data
> > > onto
> > > > > >> this
> > > > > >> > > grid:
> > > > > >> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000 128
90000
> > > 358750
> > > > > 1250
> > > > > >> > 942
> > > > > >> > > > 64*"
> > > > > >> > > > >> > > WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > Running copygb is not a big deal at all.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > >>> After doing that, I was finally able to
run
> > > grid_stat
> > > > > to
> > > > > >> > > compare
> > > > > >> > > > >> > these
> > > > > >> > > > >> > > fields. But since the forecast contains all
0's
> and
> > > the
> > > > > >> > > observation
> > > > > >> > > > >> > > basically contains all 0's, I didn't get any
> > meaningful
> > > > > >> > > statistics.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > I can switch to a different variable than
the
> > > > precipitation
> > > > > >> at
> > > > > >> > the
> > > > > >> > > > >> > > initialization time for a test.
> > > > > >> > > > >> > > Please send me the patch for reading the
lat/lon
> > > > dimensions
> > > > > >> via
> > > > > >> > > > email
> > > > > >> > > > >> or
> > > > > >> > > > >> > > you can put the file(s) on the Yellowstone
and let
> me
> > > > know
> > > > > >> the
> > > > > >> > > path
> > > > > >> > > > to
> > > > > >> > > > >> > the
> > > > > >> > > > >> > > file(s), whatever suits you best.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > Thank you very much.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > Regards,
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > Jinwoong Yoo
> > > > > >> > > > >> > > UNM
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John Halley
Gotway
> > via
> > > > RT
> > > > > <
> > > > > >> > > > >> > > met_help at ucar.edu> wrote:
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >> Jinwoong,
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> I see that you're having problems comparing
a
> GRIB1
> > > file
> > > > > to
> > > > > >> a
> > > > > >> > > > >> > CF-compliant
> > > > > >> > > > >> > >> NetCDF file using the grid_stat tool.
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> I ran grid_stat and the plot_data_plane
tools
> > through
> > > > the
> > > > > >> > > debugger
> > > > > >> > > > >> and
> > > > > >> > > > >> > >> found some issues.
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> First, I ran the following plot_data_plane
command
> > to
> > > > plot
> > > > > >> the
> > > > > >> > > > CPRAT
> > > > > >> > > > >> > >> variable from the GRIB1 file:
> > > > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > > >> > > > >> > >> WRFPRS_d01.00_2latlon \
> > > > > >> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > > > > >> > > > >> > >> 'name="CPRAT"; level="L0";'
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Turns out that all the values are 0. This
can
> also
> > be
> > > > > seen
> > > > > >> via
> > > > > >> > > > >> wgrib:
> > > > > >> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > > > > >> > > > >> > >> ...
> > > > > >> > > > >> > >> min/max data 0 0
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Do you expect this or should there be some
> non-zero
> > > > > values?
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Second, I looked at the PRECC variable
using
> ncview
> > > and
> > > > > see
> > > > > >> > that
> > > > > >> > > it
> > > > > >> > > > >> > ranges
> > > > > >> > > > >> > >> from 0 to 1.157e-06. Those values are so
small
> that
> > > the
> > > > > MET
> > > > > >> > > tools
> > > > > >> > > > >> won't
> > > > > >> > > > >> > >> really be able to distinguish between them.
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Next, I tried running the NetCDF data
through
> > > > > >> plot_data_plane,
> > > > > >> > > but
> > > > > >> > > > >> got
> > > > > >> > > > >> > >> this
> > > > > >> > > > >> > >> error:
> > > > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
\
> > > > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-
01_PRECC.ps
> \
> > > > > >> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const
LongArray
> &,
> > > > > >> DataPlane
> > > > > >> > &)
> > > > > >> > > > >> const
> > > > > >> > > > >> > ->
> > > > > >> > > > >> > >> star found in bad slot
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> After running this through the debugger, I
found
> > that
> > > > MET
> > > > > is
> > > > > >> > > > getting
> > > > > >> > > > >> > >> confused by the presence of the slat and
slon
> > > variables.
> > > > > >> It's
> > > > > >> > > > using
> > > > > >> > > > >> > them
> > > > > >> > > > >> > >> to define the grid rather than the lat and
lon
> > > > variables.
> > > > > >> And
> > > > > >> > > that
> > > > > >> > > > >> > leads
> > > > > >> > > > >> > >> to the difference in the grids. Also, MET
stores
> > > > > longitude
> > > > > >> > > values
> > > > > >> > > > >> > >> internally in degrees_west rather than the
more
> > common
> > > > > >> > > > degrees_east.
> > > > > >> > > > >> > When
> > > > > >> > > > >> > >> you see -0.625 degrees longitude, that's
> > degrees_west.
> > > > > Very
> > > > > >> > > > >> confusing,
> > > > > >> > > > >> > I
> > > > > >> > > > >> > >> know!
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> I tweaked the NetCDF CF code to print
warning
> > messages
> > > > > when
> > > > > >> it
> > > > > >> > > > >> > encounters
> > > > > >> > > > >> > >> multiple variables for latitude and
longitude, and
> > to
> > > > use
> > > > > >> the
> > > > > >> > > first
> > > > > >> > > > >> > >> instance of them rather than the second.
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Doing so enables me to run plot_data_plane.
But
> > when
> > > I
> > > > > run
> > > > > >> > > through
> > > > > >> > > > >> > >> grid_stat, I get the following error:
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> ERROR : process_command_line() -> The
forecast
> and
> > > > > >> observation
> > > > > >> > > > >> grids do
> > > > > >> > > > >> > >> not match:
> > > > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191 lat_ll:
> -89.529
> > > > > lon_ll:
> > > > > >> > > -0.625
> > > > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > > > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192 lat_ll:
> -90.000
> > > > > lon_ll:
> > > > > >> > > -0.000
> > > > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> So we need to rerun copygb to put the GRIB1
data
> > onto
> > > > this
> > > > > >> > grid:
> > > > > >> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000 128
90000
> > > 358750
> > > > > >> 1250
> > > > > >> > 942
> > > > > >> > > > >> 64*"
> > > > > >> > > > >> > >> WRFPRS_d01.00_2latlon WRFPRS_d01.00_3latlon
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> After doing that, I was finally able to run
> > grid_stat
> > > to
> > > > > >> > compare
> > > > > >> > > > >> these
> > > > > >> > > > >> > >> fields. But since the forecast contains
all 0's
> and
> > > the
> > > > > >> > > > observation
> > > > > >> > > > >> > >> basically contains all 0's, I didn't get
any
> > > meaningful
> > > > > >> > > statistics.
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Seems like I need to get you that patch for
> reading
> > > the
> > > > > >> lat/lon
> > > > > >> > > > >> > >> dimensions. You need to start using the
copygb
> > > command
> > > > > >> listed
> > > > > >> > > > above
> > > > > >> > > > >> for
> > > > > >> > > > >> > >> regridding GRIB files. And you need to
figure out
> > why
> > > > > your
> > > > > >> > data
> > > > > >> > > is
> > > > > >> > > > >> all
> > > > > >> > > > >> > >> 0's.
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> How does that all sound?
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> Thanks,
> > > > > >> > > > >> > >> John Halley Gotway
> > > > > >> > > > >> > >> met_help at ucar.edu
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong
Yoo via
> RT
> > <
> > > > > >> > > > >> met_help at ucar.edu>
> > > > > >> > > > >> > >> wrote:
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290
was
> acted
> > > > upon.
> > > > > >> > > > >> > >> > Transaction: Ticket created by
> > > jinwoong.yoo at gmail.com
> > > > > >> > > > >> > >> > Queue: met_help
> > > > > >> > > > >> > >> > Subject: grid_stat Error
> > > > > >> > > > >> > >> > Owner: Nobody
> > > > > >> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > > > > >> > > > >> > >> > Status: new
> > > > > >> > > > >> > >> > Ticket <URL:
> > > > > >> > > > >>
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Dear WRF Help and MET Help
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Grid_stat produced error message below
and
> > stopped:
> > > > > >> > > > >> > >> > [jyoo at yslogin4 analysis]$
> > > > > >> > > > >> > >> >
> > > > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >>
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > > > > >> > > > >> > >> >
> > > > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > > > > >> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-01.nc
> > > > > >> GridStatConfig_ccsm
> > > > > >> > > > >> -outdir
> > > > > >> > > > >> > >> >
> > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > > > > >> > > > >> > >> > DEBUG 1: Default Config File:
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >>
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > > > > >> > > > >> > >> > DEBUG 1: User Config File:
GridStatConfig_ccsm
> > > > > >> > > > >> > >> > WARNING:
> > > > > >> > > > >> > >> > WARNING: NcCfFile::open() -> could not
extract
> > init
> > > > time
> > > > > >> from
> > > > > >> > > > file
> > > > > >> > > > >> > name
> > > > > >> > > > >> > >> > WARNING: Using init time of 0
> > > > > >> > > > >> > >> > WARNING:
> > > > > >> > > > >> > >> > ERROR :
> > > > > >> > > > >> > >> > ERROR : process_command_line() -> The
forecast
> > and
> > > > > >> > observation
> > > > > >> > > > >> grids
> > > > > >> > > > >> > do
> > > > > >> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288
Ny: 191
> > > lat_ll:
> > > > > >> > -89.529
> > > > > >> > > > >> lon_ll:
> > > > > >> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon: 1.250
!=
> > > > Projection:
> > > > > >> > Lat/Lon
> > > > > >> > > > Nx:
> > > > > >> > > > >> > 288
> > > > > >> > > > >> > >> Ny:
> > > > > >> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat:
> 0.942
> > > > > >> delta_lon:
> > > > > >> > > > 1.250
> > > > > >> > > > >> > >> > ERROR :
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Interestingly, it seems that my forecast
file
> grid
> > > > looks
> > > > > >> the
> > > > > >> > > same
> > > > > >> > > > >> as
> > > > > >> > > > >> > the
> > > > > >> > > > >> > >> > observation file grid as below:
> > > > > >> > > > >> > >> > latlon: lat -89.529000 to 89.529000 by
> 0.942000
> > > > nxny
> > > > > >> > 55008
> > > > > >> > > > >> > >> > long 0.625000 to 358.750000 by
> 1.250000,
> > > > (288
> > > > > x
> > > > > >> > 191)
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > However, grid_stat reads long 0.625000
as
> lon_ll:
> > > > > -0.625,
> > > > > >> > > making
> > > > > >> > > > >> > error.
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Can anyone explain why?
> > > > > >> > > > >> > >> > Thank you very much.
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Regards,
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> > Jinwoong Yoo
> > > > > >> > > > >> > >> > UNM
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >> >
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >
> > > > > >> > > > >> >
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > > >>
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: grid_stat Error
From: Jinwoong Yoo
Time: Wed Oct 15 11:18:39 2014
Dear John,
Thank you for your suggestion.
Let me try out this method.
Thank you very much.
Regards,
Jinwoong Yoo
UNM
On Wed, Oct 15, 2014 at 11:15 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> If you're running Grid-Stat multiple times via a script, I suggest
using an
> environment variable in your Grid-Stat configuration file. For
example...
>
> setenv CUR_LVL 0
>
> And in your Grid-Stat config file, use:
> = [ "(${CUR_LVL},*,*)" ];
>
> Just set that variable in your script that calls Grid-Stat and the
MET code
> will substitute in the value. Supporting environment variables in
the
> config files makes scripting up calls to the MET tools much easier.
>
> Thanks,
> John
>
> On Wed, Oct 15, 2014 at 10:59 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> >
> > Dear John,
> >
> > Thank you, John.
> > Yes, I ran a simple test with grid_stat on the Yellowstone and it
> produced
> > statistics along with a nc file.
> >
> > While waiting for reply from WRF Help folks, I'd like to run
grid_stat
> for
> > multiple times. However, my observation data of the CCSM4 netcdf
files
> come
> > in monthly data. So I have to specify the time in my config file
as
> "level
> > = [ "(0,*,*)" ];"
> > If I would want to run a script for multiple times, what would be
my
> > option? I can make a script to loop through forecast times of
> WRFPRS_d01.*
> > files, but how can I change the time in the config file for the
CCSM4
> > monthly data file?
> >
> > If you have an answer, please let me know.
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong Yoo
> > UNM
> >
> > On Wed, Oct 15, 2014 at 10:25 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jinwoong,
> > >
> > > I just finished updating the met-5.0 build on yellowstone:
> > > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin
> > >
> > > I took at look at the UPP output you sent but can't see an
obvious
> > > problem. Hopefully the folks at wrfhelp at ucar.edu will be able
to help
> > you
> > > out.
> > >
> > > Thanks,
> > > John
> > >
> > > On Tue, Oct 14, 2014 at 4:44 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
>
> > > >
> > > > Dear John,
> > > >
> > > > Thank you for your update.
> > > > Are these new updates applied to the build in the Yellowstone
at
> > > > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/ ?
> > > > Please let me know.
> > > >
> > > >
> > > > By the way, John,
> > > > while I'm postrocessing WRF ARW output,
> > > > I'm getting error with run_unipost when the forecast hour is
1002.
> > > > Error did not occur until the fhr=1002.
> > > > I checked that input file is existing in the directory but it
seems
> > that
> > > > WRFPRS1002.tm00 was not created for some reason.
> > > >
> > > > I put the error message below.
> > > > Do you think this error is coming from the fhr number being
too large
> > > > (>1000) as you mentioned previously or something else?
> > > >
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong Yoo
> > > > UNM
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > + tmmark=tm00
> > > > + export tmmark
> > > > + MP_SHARED_MEMORY=yes
> > > > + export MP_SHARED_MEMORY
> > > > + MP_LABELIO=yes
> > > > + export MP_LABELIO
> > > > + NEWDATE=1870010100
> > > > + export NEWDATE
> > > > + [ 1002 -le 4320 ]
> > > > + printf %02i 1002
> > > > + fhr=1002
> > > > + /glade/scratch/jyoo/UPPV2.2/bin/ndate.exe +1002 1870010100
> > > > + NEWDATE=1870021118
> > > > + echo 1870021118
> > > > + cut -c1-4
> > > > + YY=1870
> > > > + cut -c5-6
> > > > + echo 1870021118
> > > > + MM=02
> > > > + cut -c7-8
> > > > + echo 1870021118
> > > > + DD=11
> > > > + echo 1870021118
> > > > + cut -c9-10
> > > > + HH=18
> > > > + echo NEWDATE 1870021118
> > > > NEWDATE 1870021118
> > > > + echo YY 1870
> > > > YY 1870
> > > > + cat
> > > > + 1> itag 0<< \EOF
> > > > ../wrfprd/wrfout_d01_1870-02-11_18:00:00
> > > > netcdf
> > > > 1870-02-11_18:00:00
> > > > NCAR
> > > > EOF
> > > > + rm fort.110 fort.14
> > > > + ln -sf wrf_cntrl.parm fort.14
> > > > + /glade/scratch/jyoo/UPPV2.2/bin/unipost.exe
> > > > + 1> unipost_d01.1002.out 2>& 1
> > > > + cp WRFPRS1002.tm00 WRFPRS_d01.tm00.bk
> > > > cp: cannot stat `WRFPRS1002.tm00': No such file or directory
> > > > + mv WRFPRS1002.tm00 WRFPRS_d01.1002
> > > > mv: cannot stat `WRFPRS1002.tm00': No such file or directory
> > > > + ls -l WRFPRS_d01.1002
> > > > ls: cannot access WRFPRS_d01.1002: No such file or directory
> > > > + err1=2
> > > > + test 2 -ne 0
> > > > + echo 'UNIPOST FAILED, EXITTING'
> > > > UNIPOST FAILED, EXITTING
> > > > + exit
> > > >
> > > >
> > > > On Tue, Oct 14, 2014 at 2:56 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Jinwoong,
> > > > >
> > > > > I apologize for the delay in providing a solution to this
problem.
> > > That
> > > > > error is being caused by integer overflow when trying to
write
> > unixtime
> > > > > (seconds since Jan 1 1970) for the year 1870 as a variable
> attribute
> > to
> > > > the
> > > > > NetCDF output file. I just distributed a patch that checks
for
> this
> > > > > condition and, if overflow would happen, prints a warning
and skips
> > > > writing
> > > > > those values. Ultimately, we hope to come up with a better
> solution
> > in
> > > > the
> > > > > next release. But for now, this should get you past the
error.
> > > > >
> > > > > Please follow the instructions posted here to download and
apply
> the
> > > > latest
> > > > > set of patches for met-5.0:
> > > > >
> > > > >
> > >
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.0/index.php
> > > > >
> > > > > Please let me know if you continue to experience problems
after
> > > applying
> > > > > these patches.
> > > > >
> > > > > Thanks,
> > > > > John Halley Gotway
> > > > > met_help at ucar.edu
> > > > >
> > > > > On Wed, Oct 8, 2014 at 3:23 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290 >
> > > > > >
> > > > > > By the way,
> > > > > > Since I didn't get the nc file from Grid_stat by disabling
the
> > > option,
> > > > > It's
> > > > > > a bit hard to understand the output of grid_stat now.
> > > > > >
> > > > > > Could you figure out what should be done to get the nc
file from
> > > > > grid_stat?
> > > > > > Thank you.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Jinwoong Yoo
> > > > > > UNM
> > > > > >
> > > > > > On Wed, Oct 8, 2014 at 2:58 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Dear John,
> > > > > > >
> > > > > > > At present, I just would like to get the general idea
about
> using
> > > MET
> > > > > > > through Grid_stat and eventually I'd like to run
> series-analysis
> > so
> > > > > that
> > > > > > I
> > > > > > > can evaluate the WRF simulation performance against the
CCSM4
> > over
> > > > the
> > > > > 10
> > > > > > > years period of integral.
> > > > > > >
> > > > > > > In other words, I would like to get the time series of
scores
> > for a
> > > > few
> > > > > > > variables such as T2, PSL, soil moisture, precipitation,
> > snowfall,
> > > > etc.
> > > > > > >
> > > > > > > Then, what will be the next step for the most economic
way?
> > > > > > > Thank you.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Jinwoong Yoo
> > > > > > > UNM
> > > > > > >
> > > > > > > On Wed, Oct 8, 2014 at 2:25 PM, John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > >> Jinwoong,
> > > > > > >>
> > > > > > >> What you do with the statistical output that the MET
tools
> > > generate
> > > > > > really
> > > > > > >> depends on what sort of question you're trying to
answer. If
> > you
> > > > want
> > > > > > to
> > > > > > >> aggregate results across multiple runs of grid-stat,
you can
> use
> > > > > > >> stat-analysis to do that. Alternatively, you could
plot a
> time
> > > > series
> > > > > > of
> > > > > > >> scores output from each run. It's really up to you to
analyze
> > and
> > > > > make
> > > > > > >> sense of your statistical output.
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> John
> > > > > > >>
> > > > > > >> On Wed, Oct 8, 2014 at 1:47 PM, Jinwoong Yoo via RT <
> > > > > met_help at ucar.edu>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> >
> > > > > > >> > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > >
> > > > > > >> >
> > > > > > >> > Dear John,
> > > > > > >> >
> > > > > > >> > Yes. Disabling nc_pairs_flag did helped Grid_stat
generating
> > > > > > statistics
> > > > > > >> txt
> > > > > > >> > files.
> > > > > > >> > Then, I should run stat_analysis using the grid_stat
outputs
> > > > right?
> > > > > > >> >
> > > > > > >> > Thank you.
> > > > > > >> >
> > > > > > >> > Regards,
> > > > > > >> >
> > > > > > >> > Jinwoong Yoo
> > > > > > >> > UNM
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Wed, Oct 8, 2014 at 1:21 PM, John Halley Gotway
via RT <
> > > > > > >> > met_help at ucar.edu
> > > > > > >> > > wrote:
> > > > > > >> >
> > > > > > >> > > Jinwoong,
> > > > > > >> > >
> > > > > > >> > > Try editing your Grid-Stat config file by setting:
> > > > > > >> > > nc_pairs_flag = FALSE;
> > > > > > >> > >
> > > > > > >> > > We're getting a weird error when Grid-Stat tries to
write
> > the
> > > > > NetCDF
> > > > > > >> > output
> > > > > > >> > > file:
> > > > > > >> > > NetCDF: Numeric conversion not representable
> > > > > > >> > >
> > > > > > >> > > That's causing you to see empty output files.
> > > > > > >> > >
> > > > > > >> > > I'll look into the source of this error, but for
now, just
> > > > disable
> > > > > > the
> > > > > > >> > > NetCDF matched pairs output.
> > > > > > >> > >
> > > > > > >> > > Thanks,
> > > > > > >> > > John
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On Tue, Oct 7, 2014 at 8:16 PM, Jinwoong Yoo via RT
<
> > > > > > >> met_help at ucar.edu>
> > > > > > >> > > wrote:
> > > > > > >> > >
> > > > > > >> > > >
> > > > > > >> > > > <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > >
> > > > > > >> > > >
> > > > > > >> > > > Dear John,
> > > > > > >> > > >
> > > > > > >> > > > Maybe should I use gen_poly_mask to define the
area of
> my
> > > WRF
> > > > > > model
> > > > > > >> > > domain
> > > > > > >> > > > (which is a tropical channel) before I run
grid_stat
> > against
> > > > the
> > > > > > >> CCSM4
> > > > > > >> > in
> > > > > > >> > > > global domain?
> > > > > > >> > > >
> > > > > > >> > > > Jinwoong Yoo
> > > > > > >> > > > UNM
> > > > > > >> > > >
> > > > > > >> > > > On Tue, Oct 7, 2014 at 5:36 PM, Jinwoong Yoo <
> > > > > > >> jinwoong.yoo at gmail.com>
> > > > > > >> > > > wrote:
> > > > > > >> > > >
> > > > > > >> > > > > Dear John,
> > > > > > >> > > > >
> > > > > > >> > > > > I switched variable to PRMSL (sea level
pressure) for
> a
> > > > > > Grid_stat
> > > > > > >> > test.
> > > > > > >> > > > > Grid_stat seemed to run this time but produced
files
> > were
> > > > > empty.
> > > > > > >> > > > >
> > > > > > >> > > > > However, when I produced a ps file for the
variable,
> the
> > > > > output
> > > > > > >> file
> > > > > > >> > > > looks
> > > > > > >> > > > > ok (attached).
> > > > > > >> > > > >
> > > > > > >> > > > > [jyoo at yslogin6 postprd]$
> > > > > > >> > > > >
pwd/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd
> > > > > > >> > > > > [jyoo at yslogin6 postprd]$
> > > > > > >> > > > >
> > > > > >
> /glade/p/ral/jnt/MET/MET_releases/met-5.0_ORIG/bin/plot_data_plane
> > > > > > >> > > > >
> > > > > > >>
> > > >
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/WRFPRS_d01.00_2latlon
> > > > > > >> > > > > WRFPRS_d01.00_2latlon_PRMSL.ps 'name="PRMSL";
> > > level="L0";'
> > > > > > >> > > > >
> > > > > > >> > > > > Do I need to change other information for
dictionary
> > parts
> > > > for
> > > > > > the
> > > > > > >> > > > > variables being compared in the
GridStatConfig_ccsm
> file
> > > > > > (attached
> > > > > > >> > > also)?
> > > > > > >> > > > > Where can I find more detail information about
the
> > > > > > GridStatConfig
> > > > > > >> > than
> > > > > > >> > > in
> > > > > > >> > > > > the MET Users Guide V5.0, if available?
> > > > > > >> > > > >
> > > > > > >> > > > > Thank you.
> > > > > > >> > > > >
> > > > > > >> > > > > Regards,
> > > > > > >> > > > >
> > > > > > >> > > > > Jinwoong Yoo
> > > > > > >> > > > > UNM
> > > > > > >> > > > >
> > > > > > >> > > > > On Tue, Oct 7, 2014 at 4:13 PM, John Halley
Gotway via
> > RT
> > > <
> > > > > > >> > > > > met_help at ucar.edu> wrote:
> > > > > > >> > > > >
> > > > > > >> > > > >> Jinwoong,
> > > > > > >> > > > >>
> > > > > > >> > > > >> OK, I updated the build on yellowstone to
include the
> > > > latest
> > > > > > set
> > > > > > >> of
> > > > > > >> > > > >> patches:
> > > > > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-5.0
> > > > > > >> > > > >>
> > > > > > >> > > > >> The original, as released, version of met-5.0
can
> still
> > > be
> > > > > > found
> > > > > > >> > here:
> > > > > > >> > > > >> /glade/p/ral/jnt/MET/MET_releases/met-
5.0_ORIG
> > > > > > >> > > > >>
> > > > > > >> > > > >> Please give the updated version a shot and let
me
> know
> > > how
> > > > it
> > > > > > >> goes.
> > > > > > >> > > > >>
> > > > > > >> > > > >> Thanks,
> > > > > > >> > > > >> John
> > > > > > >> > > > >>
> > > > > > >> > > > >> On Tue, Oct 7, 2014 at 2:23 PM, Jinwoong Yoo
via RT <
> > > > > > >> > > met_help at ucar.edu>
> > > > > > >> > > > >> wrote:
> > > > > > >> > > > >>
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > <URL:
> > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > > > >> >
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > Dear John,
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > Since I'm using the MET that is available on
the
> > > > > Yellowstone
> > > > > > >> > > > >> > at /glade/p/ral/jnt/MET/MET_releases/met-
5.0/bin/,
> > > > > > >> > > > >> > you can just let me know how I can use the
patch
> for
> > > > > reading
> > > > > > >> the
> > > > > > >> > > > lat/lon
> > > > > > >> > > > >> > dimensions of the CCSM4 file in the
Yellowstone.
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > Thank you.
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > Regards,
> > > > > > >> > > > >> > Jinwoong Yoo
> > > > > > >> > > > >> > UNM
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > On Tue, Oct 7, 2014 at 1:35 PM, Jinwoong Yoo
<
> > > > > > >> > > jinwoong.yoo at gmail.com>
> > > > > > >> > > > >> > wrote:
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > > Dear John
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > First of all, thank you for your efforts
to
> figure
> > > out
> > > > > the
> > > > > > >> issue
> > > > > > >> > > > with
> > > > > > >> > > > >> > > Grid_stat of my case.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > >>> Do you expect this or should there be
some
> > > non-zero
> > > > > > >> values?
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > This is a test case with precipitation
variables
> > from
> > > > the
> > > > > > WRF
> > > > > > >> > and
> > > > > > >> > > > >> CCSM4
> > > > > > >> > > > >> > at
> > > > > > >> > > > >> > > model initialization time 00. So, 0 is
reasonable
> > > > > although
> > > > > > I
> > > > > > >> did
> > > > > > >> > > not
> > > > > > >> > > > >> > > consider carefully when I pick the
variable for a
> > > test
> > > > > > case.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > >>>After running this through the
debugger, I
> found
> > > > that
> > > > > > MET
> > > > > > >> is
> > > > > > >> > > > >> getting
> > > > > > >> > > > >> > > confused by the presence of the slat and
slon
> > > > variables.
> > > > > > >> It's
> > > > > > >> > > using
> > > > > > >> > > > >> them
> > > > > > >> > > > >> > > to define the grid rather than the lat and
lon
> > > > variables.
> > > > > > >> And
> > > > > > >> > > that
> > > > > > >> > > > >> leads
> > > > > > >> > > > >> > > to the difference in the grids.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > That's one thing that I mentioned in my
previous
> > > email:
> > > > > > >> > > > >> > > "However, there are something strange.
> > > > > > >> > > > >> > > According to what Grid-Stat reads in for
the
> CCSM4
> > > file
> > > > > > >> > > (Projection:
> > > > > > >> > > > >> > > Lat/Lon Nx: 288 Ny: 191 lat_ll: -89.529
lon_ll:
> > 0.625
> > > > > > >> delta_lat:
> > > > > > >> > > > 0.942
> > > > > > >> > > > >> > > delta_lon: 1.250), lat and lon information
were
> > > flipped
> > > > > > >> compared
> > > > > > >> > > to
> > > > > > >> > > > >> what
> > > > > > >> > > > >> > I
> > > > > > >> > > > >> > > get from ncdump of the CCSM4 file (lat =
192 ;
> lon
> > =
> > > > 288
> > > > > ;
> > > > > > >> slat
> > > > > > >> > =
> > > > > > >> > > > 191
> > > > > > >> > > > >> > ;slon
> > > > > > >> > > > >> > > = 288) and the Ny: 191 matches to
slat(staggered
> > > > > latitude)
> > > > > > >> not
> > > > > > >> > > > >> latitude."
> > > > > > >> > > > >> > > I'm glad you found a solution to the issue
with
> NC
> > > file
> > > > > > with
> > > > > > >> two
> > > > > > >> > > > >> > different
> > > > > > >> > > > >> > > pair of lat (lat and slat) and lon (lon
and
> slon).
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > >>> So we need to rerun copygb to put the
GRIB1
> > data
> > > > onto
> > > > > > >> this
> > > > > > >> > > grid:
> > > > > > >> > > > >> > > copygb -xg"*255 0 288 192 -90000 0000
128 90000
> > > > 358750
> > > > > > 1250
> > > > > > >> > 942
> > > > > > >> > > > 64*"
> > > > > > >> > > > >> > > WRFPRS_d01.00_2latlon
WRFPRS_d01.00_3latlon
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > Running copygb is not a big deal at all.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > >>> After doing that, I was finally able
to run
> > > > grid_stat
> > > > > > to
> > > > > > >> > > compare
> > > > > > >> > > > >> > these
> > > > > > >> > > > >> > > fields. But since the forecast contains
all 0's
> > and
> > > > the
> > > > > > >> > > observation
> > > > > > >> > > > >> > > basically contains all 0's, I didn't get
any
> > > meaningful
> > > > > > >> > > statistics.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > I can switch to a different variable than
the
> > > > > precipitation
> > > > > > >> at
> > > > > > >> > the
> > > > > > >> > > > >> > > initialization time for a test.
> > > > > > >> > > > >> > > Please send me the patch for reading the
lat/lon
> > > > > dimensions
> > > > > > >> via
> > > > > > >> > > > email
> > > > > > >> > > > >> or
> > > > > > >> > > > >> > > you can put the file(s) on the Yellowstone
and
> let
> > me
> > > > > know
> > > > > > >> the
> > > > > > >> > > path
> > > > > > >> > > > to
> > > > > > >> > > > >> > the
> > > > > > >> > > > >> > > file(s), whatever suits you best.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > Thank you very much.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > Regards,
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > Jinwoong Yoo
> > > > > > >> > > > >> > > UNM
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > On Tue, Oct 7, 2014 at 12:06 PM, John
Halley
> Gotway
> > > via
> > > > > RT
> > > > > > <
> > > > > > >> > > > >> > > met_help at ucar.edu> wrote:
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > >> Jinwoong,
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> I see that you're having problems
comparing a
> > GRIB1
> > > > file
> > > > > > to
> > > > > > >> a
> > > > > > >> > > > >> > CF-compliant
> > > > > > >> > > > >> > >> NetCDF file using the grid_stat tool.
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> I ran grid_stat and the plot_data_plane
tools
> > > through
> > > > > the
> > > > > > >> > > debugger
> > > > > > >> > > > >> and
> > > > > > >> > > > >> > >> found some issues.
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> First, I ran the following
plot_data_plane
> command
> > > to
> > > > > plot
> > > > > > >> the
> > > > > > >> > > > CPRAT
> > > > > > >> > > > >> > >> variable from the GRIB1 file:
> > > > > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > > > >> > > > >> > >> WRFPRS_d01.00_2latlon \
> > > > > > >> > > > >> > >> WRFPRS_d01.00_2latlon_CPRAT.ps \
> > > > > > >> > > > >> > >> 'name="CPRAT"; level="L0";'
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Turns out that all the values are 0.
This can
> > also
> > > be
> > > > > > seen
> > > > > > >> via
> > > > > > >> > > > >> wgrib:
> > > > > > >> > > > >> > >> wgrib -V -d 277 WRFPRS_d01.00_2latlon
> > > > > > >> > > > >> > >> ...
> > > > > > >> > > > >> > >> min/max data 0 0
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Do you expect this or should there be
some
> > non-zero
> > > > > > values?
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Second, I looked at the PRECC variable
using
> > ncview
> > > > and
> > > > > > see
> > > > > > >> > that
> > > > > > >> > > it
> > > > > > >> > > > >> > ranges
> > > > > > >> > > > >> > >> from 0 to 1.157e-06. Those values are so
small
> > that
> > > > the
> > > > > > MET
> > > > > > >> > > tools
> > > > > > >> > > > >> won't
> > > > > > >> > > > >> > >> really be able to distinguish between
them.
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Next, I tried running the NetCDF data
through
> > > > > > >> plot_data_plane,
> > > > > > >> > > but
> > > > > > >> > > > >> got
> > > > > > >> > > > >> > >> this
> > > > > > >> > > > >> > >> error:
> > > > > > >> > > > >> > >> met-5.0/bin/plot_data_plane \
> > > > > > >> > > > >> > >> b40.lgm21ka.1deg.003M.cam2.h3.1870-
01.nc \
> > > > > > >> > > > >> > >>
> b40.lgm21ka.1deg.003M.cam2.h3.1870-01_PRECC.ps
> > \
> > > > > > >> > > > >> > >> 'name="PRECC"; level="(0,*,*)";'
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> ERROR : NcCfFile::data(NcVar *, const
LongArray
> > &,
> > > > > > >> DataPlane
> > > > > > >> > &)
> > > > > > >> > > > >> const
> > > > > > >> > > > >> > ->
> > > > > > >> > > > >> > >> star found in bad slot
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> After running this through the debugger,
I found
> > > that
> > > > > MET
> > > > > > is
> > > > > > >> > > > getting
> > > > > > >> > > > >> > >> confused by the presence of the slat and
slon
> > > > variables.
> > > > > > >> It's
> > > > > > >> > > > using
> > > > > > >> > > > >> > them
> > > > > > >> > > > >> > >> to define the grid rather than the lat
and lon
> > > > > variables.
> > > > > > >> And
> > > > > > >> > > that
> > > > > > >> > > > >> > leads
> > > > > > >> > > > >> > >> to the difference in the grids. Also,
MET
> stores
> > > > > > longitude
> > > > > > >> > > values
> > > > > > >> > > > >> > >> internally in degrees_west rather than
the more
> > > common
> > > > > > >> > > > degrees_east.
> > > > > > >> > > > >> > When
> > > > > > >> > > > >> > >> you see -0.625 degrees longitude, that's
> > > degrees_west.
> > > > > > Very
> > > > > > >> > > > >> confusing,
> > > > > > >> > > > >> > I
> > > > > > >> > > > >> > >> know!
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> I tweaked the NetCDF CF code to print
warning
> > > messages
> > > > > > when
> > > > > > >> it
> > > > > > >> > > > >> > encounters
> > > > > > >> > > > >> > >> multiple variables for latitude and
longitude,
> and
> > > to
> > > > > use
> > > > > > >> the
> > > > > > >> > > first
> > > > > > >> > > > >> > >> instance of them rather than the second.
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Doing so enables me to run
plot_data_plane. But
> > > when
> > > > I
> > > > > > run
> > > > > > >> > > through
> > > > > > >> > > > >> > >> grid_stat, I get the following error:
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> ERROR : process_command_line() -> The
forecast
> > and
> > > > > > >> observation
> > > > > > >> > > > >> grids do
> > > > > > >> > > > >> > >> not match:
> > > > > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 191
lat_ll:
> > -89.529
> > > > > > lon_ll:
> > > > > > >> > > -0.625
> > > > > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250 !=
> > > > > > >> > > > >> > >> Projection: Lat/Lon Nx: 288 Ny: 192
lat_ll:
> > -90.000
> > > > > > lon_ll:
> > > > > > >> > > -0.000
> > > > > > >> > > > >> > >> delta_lat: 0.942 delta_lon: 1.250
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> So we need to rerun copygb to put the
GRIB1 data
> > > onto
> > > > > this
> > > > > > >> > grid:
> > > > > > >> > > > >> > >> copygb -xg"*255 0 288 192 -90000 0000
128
> 90000
> > > > 358750
> > > > > > >> 1250
> > > > > > >> > 942
> > > > > > >> > > > >> 64*"
> > > > > > >> > > > >> > >> WRFPRS_d01.00_2latlon
WRFPRS_d01.00_3latlon
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> After doing that, I was finally able to
run
> > > grid_stat
> > > > to
> > > > > > >> > compare
> > > > > > >> > > > >> these
> > > > > > >> > > > >> > >> fields. But since the forecast contains
all 0's
> > and
> > > > the
> > > > > > >> > > > observation
> > > > > > >> > > > >> > >> basically contains all 0's, I didn't get
any
> > > > meaningful
> > > > > > >> > > statistics.
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Seems like I need to get you that patch
for
> > reading
> > > > the
> > > > > > >> lat/lon
> > > > > > >> > > > >> > >> dimensions. You need to start using the
copygb
> > > > command
> > > > > > >> listed
> > > > > > >> > > > above
> > > > > > >> > > > >> for
> > > > > > >> > > > >> > >> regridding GRIB files. And you need to
figure
> out
> > > why
> > > > > > your
> > > > > > >> > data
> > > > > > >> > > is
> > > > > > >> > > > >> all
> > > > > > >> > > > >> > >> 0's.
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> How does that all sound?
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> Thanks,
> > > > > > >> > > > >> > >> John Halley Gotway
> > > > > > >> > > > >> > >> met_help at ucar.edu
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> On Tue, Oct 7, 2014 at 9:38 AM, Jinwoong
Yoo via
> > RT
> > > <
> > > > > > >> > > > >> met_help at ucar.edu>
> > > > > > >> > > > >> > >> wrote:
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Tue Oct 07 09:38:10 2014: Request 69290
was
> > acted
> > > > > upon.
> > > > > > >> > > > >> > >> > Transaction: Ticket created by
> > > > jinwoong.yoo at gmail.com
> > > > > > >> > > > >> > >> > Queue: met_help
> > > > > > >> > > > >> > >> > Subject: grid_stat Error
> > > > > > >> > > > >> > >> > Owner: Nobody
> > > > > > >> > > > >> > >> > Requestors: jinwoong.yoo at gmail.com
> > > > > > >> > > > >> > >> > Status: new
> > > > > > >> > > > >> > >> > Ticket <URL:
> > > > > > >> > > > >>
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69290
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Dear WRF Help and MET Help
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Grid_stat produced error message below
and
> > > stopped:
> > > > > > >> > > > >> > >> > [jyoo at yslogin4 analysis]$
> > > > > > >> > > > >> > >> >
> > > > > /glade/p/ral/jnt/MET/MET_releases/met-5.0/bin/grid_stat
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> >
> > > > > > >> > > > >>
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
/glade/scratch/jyoo/DOMAINS/postprd/lgm/postprd/outcopygb/WRFPRS_d01.00_2latlon
> > > > > > >> > > > >> > >> >
> > > > > /glade/scratch/jyoo/domain/mean/analysis/LGMCCSM/6hrly/
> > > > > > >> > > > >> > >> > b40.lgm21ka.1deg.003M.cam2.h3.1870-
01.nc
> > > > > > >> GridStatConfig_ccsm
> > > > > > >> > > > >> -outdir
> > > > > > >> > > > >> > >> >
> > > /glade/scratch/jyoo/domain/mean/analysis/gridstatout
> > > > > > >> > > > >> > >> > DEBUG 1: Default Config File:
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> >
> > > > > > >> > > > >>
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> /glade/p/ral/jnt/MET/MET_releases/met-
5.0/share/met/config/GridStatConfig_default
> > > > > > >> > > > >> > >> > DEBUG 1: User Config File:
GridStatConfig_ccsm
> > > > > > >> > > > >> > >> > WARNING:
> > > > > > >> > > > >> > >> > WARNING: NcCfFile::open() -> could not
extract
> > > init
> > > > > time
> > > > > > >> from
> > > > > > >> > > > file
> > > > > > >> > > > >> > name
> > > > > > >> > > > >> > >> > WARNING: Using init time of 0
> > > > > > >> > > > >> > >> > WARNING:
> > > > > > >> > > > >> > >> > ERROR :
> > > > > > >> > > > >> > >> > ERROR : process_command_line() -> The
> forecast
> > > and
> > > > > > >> > observation
> > > > > > >> > > > >> grids
> > > > > > >> > > > >> > do
> > > > > > >> > > > >> > >> > not match: Projection: Lat/Lon Nx: 288
Ny: 191
> > > > lat_ll:
> > > > > > >> > -89.529
> > > > > > >> > > > >> lon_ll:
> > > > > > >> > > > >> > >> > -0.625 delta_lat: 0.942 delta_lon:
1.250 !=
> > > > > Projection:
> > > > > > >> > Lat/Lon
> > > > > > >> > > > Nx:
> > > > > > >> > > > >> > 288
> > > > > > >> > > > >> > >> Ny:
> > > > > > >> > > > >> > >> > 191 lat_ll: -89.529 lon_ll: 0.625
delta_lat:
> > 0.942
> > > > > > >> delta_lon:
> > > > > > >> > > > 1.250
> > > > > > >> > > > >> > >> > ERROR :
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Interestingly, it seems that my
forecast file
> > grid
> > > > > looks
> > > > > > >> the
> > > > > > >> > > same
> > > > > > >> > > > >> as
> > > > > > >> > > > >> > the
> > > > > > >> > > > >> > >> > observation file grid as below:
> > > > > > >> > > > >> > >> > latlon: lat -89.529000 to 89.529000
by
> > 0.942000
> > > > > nxny
> > > > > > >> > 55008
> > > > > > >> > > > >> > >> > long 0.625000 to 358.750000
by
> > 1.250000,
> > > > > (288
> > > > > > x
> > > > > > >> > 191)
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > However, grid_stat reads long 0.625000
as
> > lon_ll:
> > > > > > -0.625,
> > > > > > >> > > making
> > > > > > >> > > > >> > error.
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Can anyone explain why?
> > > > > > >> > > > >> > >> > Thank you very much.
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Regards,
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> > Jinwoong Yoo
> > > > > > >> > > > >> > >> > UNM
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >> >
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> >
> > > > > > >> > > > >> >
> > > > > > >> > > > >>
> > > > > > >> > > > >>
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list