[Met_help] [rt.rap.ucar.edu #75243] History for Validating model precipitation

John Halley Gotway via RT met_help at ucar.edu
Fri Mar 4 14:17:31 MST 2016


----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

We would like to use MET to do some validation of our model precipitation forecasts.  Specifically, our model output includes 6 hourly QPF.  I downloaded the NCEP Stage IV precipitation observational data (CONUS). I am looking for some guidance on how to set the Gridstat config file to handle our netcdf precipitation forecasts vs. the obs NCEP Stage IV GRIB forecasts.  I looked at the MET 5.0 GRIB tutorials for using Gridstat to validate precipitation.  The two step approach to first verifying precip categories and the precip probabilities is appealing, but the example used netcdf observed precipitation.

Thanks in advance for your help,
Bill

-----------------------------------------------------------------------------------------------

Hi Bill,

It really all comes down to a question of data formats.  The Stage IV data is available in GRIB which MET easily reads.  MET reads a couple flavors of gridded NetCDF.  It's just a question of using one of those.

Is this NetCDF data already readable by MET?

If not, you could post a sample file to our anonymous ftp site, and I could take a look to offer some suggestions.  Here are some instructions:

http://www.dtcenter.org/met/users/support/met_help.php#ftp

Thanks,
John

-----------------------------------------------------------------------------------------------

Hi John,

I am still confused on how to specify the verification mask for the NCEP Stage IV precip.  It is supposed to cover the CONUS but when I dump the a Stage IV GRIB file it shows an NCEP grid number of 255, which does not appear as a grid in the appendix B of the MET documentation.  When I go to the NCEP site 255 is listed as "non-defined grid - specified in the GDS". Can you provide me some guidance on this?

Thanks,
Bill


----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: Validating model precipitation
From: John Halley Gotway
Time: Wed Feb 24 12:20:30 2016

Bill,

Grid 255 really isn't anything to be concerned about.  The GRIB1
format allocates a single byte in which to store a grid identification
number.  A byte can have a value between 0 and 255, and theoretically
those numbers could be used to identify the NCEP grid number... e.g.
set it to 212 for NCEP Grid 212, as defined here:
   http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html#GRID212

Practically speaking, I don't think they actually do that anymore.
Instead, they set the grid number to 255 which means that you should
read the grid description section (GDS) of the GRIB file to get the
grid definition.

Actually, looking at the "History" section on this website, they
switched the Stage4 grid number from 240 to 255 back in 2004:
   http://www.emc.ncep.noaa.gov/mmb/ylin/pcpanl/stage4/

Running "wgrib -V" on a StageIV file reveals the following grid info:
     polar stereo: Lat1 23.117000 Long1 -119.023000 Orient -105.000000
     north pole (1121 x 881) Dx 4763 Dy 4763 scan 64 mode 8

And that grid is the same as NCEP Grid 240, as defined here:
   http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html#GRID240

Next, you're wondering about how to use this in MET.  If I had one of
your sample forecast data files, I could run through an example.
Instead, I'll just use a sample GFS file and compare it to StageIV to
illustrate how you could use automated regridding and masking out the
CONUS region...

# Pull sample GFS and StageIV file to compare
wget
http://nomads.ncep.noaa.gov/pub/data/nccf/com/hourly/prod/nam_pcpn_anal.20160220/ST4.2016022012.06h.gz
wget
http://nomads.ncdc.noaa.gov/data/gfs4/201602/20160220/gfs_4_20160220_0000_012.grb2

# Uncompress
gunzip nam_pcpn_anal.20160220/ST4.2016022012.06h.gz

# Next, run Grid-Stat to compare the 20160220 12-hour GFS forecast to
the
# 6-hour Stage4 accumulation valid at 2016022012.
# I picked these because the accumulation interval of 6-hour is
already present in
# both files.  If that's not the case in your data, you would need to
run the
# pcp_combine tool on the forecast or observation files to get the
accumulation
# intervals to match up.

# Run Grid-Stat using the following commands and the attached config
file
mkdir out
met-5.1/bin/grid_stat \
   gfs_4_20160220_0000_012.grb2 \
   ST4.2016022012.06h \
   GridStatConfig \
   -outdir out

Note the following two sections of the Grid-Stat config file:
----------------
regrid = {
   to_grid    = OBS;
   vld_thresh = 0.5;
   method     = BUDGET;
   width      = 2;
}
----------------
This tells Grid-Stat that I want to do verification on the
"observation" grid.  Grid-Stat reads the GFS and Stage4 data and then
automatically regrids the GFS data to the Stage4 domain using budget
interpolation.  Use "FCST" to verify on the forecast domain.  And use
either a named grid or a grid specification string to regrid both the
forecast and observation to a common grid.  For example, to_grid =
"G212"; will regrid both to NCEP Grid 212 before comparing them.
----------------
mask = {
   grid = [ "FULL" ];
   poly = [ "MET_BASE/poly/CONUS.poly" ];
}
----------------
This says you want to compute statistics over the FULL model domain as
well as the CONUS masking area.

To demonstrate that Grid-Stat worked as expected, I ran the following
commands to plot its NetCDF matched pairs output file:

met-5.1/bin/plot_data_plane \
   out/grid_stat_120000L_20160220_120000V_pairs.nc \
   out/DIFF_APCP_06_A06_APCP_06_A06_CONUS.ps \
   'name="DIFF_APCP_06_A06_APCP_06_A06_CONUS"; level="(*,*)";'

And I attached the resulting plot of that difference field.  Notice
that the CONUS region is masked out.

Lastly, you have another option for defining that masking region.
Rather than passing the ascii CONUS.poly file to grid_stat, you could
run the gen_vx_mask tool and pass the NetCDF output of that tool to
grid_stat.  The advantage to gen_vx_mask is that it'll make grid_stat
run a bit faster and you can use it to construct much more complex
masking areas.

Hopefully that helps get you going.  Just let me know what other
issues or questions come up.

Thanks,
John







------------------------------------------------
Subject: Validating model precipitation
From: John Halley Gotway
Time: Fri Mar 04 09:36:32 2016

Hi Bill,

I see you're having trouble using Grid-Stat and are getting the
following error:
ERROR  : VarInfo::set_level_info_grib() - failed to parse level string
'(*,*)'

I did some testing and was able to replicate the behavior you're
seeing, which confirms my guess as to what's going on.

I see the following in the config file you sent me:

  obs = {
     field = [
        {
         name  = "APCP";
         level = ["(*,*)"];
...

I'm guessing that you are actually passing in a GRIB file for the
observation when you call Grid-Stat.  But you've defined the level
information as "(*,*)" which results in the error you're getting.
Instead, replace "(*,*)" with "AHH" where HH is the accumulation
interval you'd like to use.  For example, "A24" means a 24-hour
accumulation or "A06" for 6-hourly.

The MET tools support a few different gridded data formats.  However,
the way you define what data you'd like to use varies depending on the
file format.  Take a look in met-5.1/data/config/README and search for
"GRIB1".  That section describes the "level" setting.

Hope that helps.

Thanks,
John

------------------------------------------------
Subject: Validating model precipitation
From: bill.stern at noaa.gov
Time: Fri Mar 04 10:42:16 2016

John ,
I guess I need to better understand the "level" specification for Grib
files.
Thanks for your help.

Bill

On Friday, March 4, 2016, John Halley Gotway via RT
<met_help at ucar.edu>
wrote:

> Hi Bill,
>
> I see you're having trouble using Grid-Stat and are getting the
following
> error:
> ERROR  : VarInfo::set_level_info_grib() - failed to parse level
string
> '(*,*)'
>
> I did some testing and was able to replicate the behavior you're
seeing,
> which confirms my guess as to what's going on.
>
> I see the following in the config file you sent me:
>
>   obs = {
>      field = [
>         {
>          name  = "APCP";
>          level = ["(*,*)"];
> ...
>
> I'm guessing that you are actually passing in a GRIB file for the
> observation when you call Grid-Stat.  But you've defined the level
> information as "(*,*)" which results in the error you're getting.
Instead,
> replace "(*,*)" with "AHH" where HH is the accumulation interval
you'd like
> to use.  For example, "A24" means a 24-hour accumulation or "A06"
for
> 6-hourly.
>
> The MET tools support a few different gridded data formats.
However, the
> way you define what data you'd like to use varies depending on the
file
> format.  Take a look in met-5.1/data/config/README and search for
"GRIB1".
> That section describes the "level" setting.
>
> Hope that helps.
>
> Thanks,
> John
>
>

--
Bill Stern, Meteorologist
Room 206
NOAA/Geophysical Fluid Dynamics Laboratory
Princeton University Forrestal Campus
201 Forrestal Road Princeton, NJ 08540-6649
Tel:  (609)452-6545
Fax:  (609)987-5063
------------------------------
------------------------------------
Email Address:  bill.stern at noaa.gov
------------------------------------------------------------------
Anonymous ftp Address:  ftp.gfdl.noaa.gov
------------------------------------------------------------------
On the World Wide Web:  http://www.gfdl.noaa.gov/bill-stern-gfdl-noaa
------------------------------------------------------------------

------------------------------------------------


More information about the Met_help mailing list