[Met_help] [rt.rap.ucar.edu #85872] History for point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
John Halley Gotway via RT
met_help at ucar.edu
Thu Jun 28 16:16:47 MDT 2018
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello. Trying to validate several QPE analysis fields against gauges,
MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to sum up
both from hourlies. In the resulting *.nc file, CMORPH's field is
APCP_24:level = "A24", while MRMS is APCP:level = "A24", which results
in different FCST_VAR names in the *.stat files (and some difficulty in
plotting them in MetViewer together).
Is there a way to tell point_stat to use a FCST_VAR in the *.stat that's
different from the variable name in the NetCDF file for the analysis,
e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
In the two attached parm files I used,
compute_precip.pointstatconfig.mrms.old produced stats with
FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
compute_precip.pointstatconfig.mrms (my failed attempt at forcing a
change of FCST_VAR to APCP_24) lead to the following err message when
running point_stat:
DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-20180401.nc
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for APCP_24A24.
WARNING:
WARNING: process_fcst_climo_files() -> no fields matching APCP_24A24
found in file: mrms24/mrms.2018040112.24h.nc
WARNING:
ERROR :
ERROR : process_fcst_climo_files() -> no requested forecast data
found! Exiting...
ERROR :
+ exit
Is there a good way change the FCST_VAR in *.stat?
Thank you -
Ying
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: John Halley Gotway
Time: Mon Jun 25 15:03:05 2018
Hi Ying,
I see you're having some issues getting Point-Stat configured the way
you'd
like. We should be able to get this solved by tweaking your Point-
Stat
config file. Yes, you can definitely have the "fcst" and "obs"
dictionaries set to different variable names. This is the important
message:
WARNING: process_fcst_climo_files() -> no fields matching APCP_24A24
found
in file: mrms24/mrms.2018040112.24h.nc
Point-Stat can't find the data you requested in that file. Please run
'ncdump -h' on that file to look at the header:
ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
And then send me that "header_dump" file.
Thanks,
John
On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
> Transaction: Ticket created by ying.lin at noaa.gov
> Queue: met_help
> Subject: point_stat: can FCST_VAR in *.stat be different from
the
> field in *.nc?
> Owner: Nobody
> Requestors: ying.lin at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>
>
> Hello. Trying to validate several QPE analysis fields against
gauges,
> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to sum up
> both from hourlies. In the resulting *.nc file, CMORPH's field is
> APCP_24:level = "A24", while MRMS is APCP:level = "A24", which
results
> in different FCST_VAR names in the *.stat files (and some difficulty
in
> plotting them in MetViewer together).
>
> Is there a way to tell point_stat to use a FCST_VAR in the *.stat
that's
> different from the variable name in the NetCDF file for the
analysis,
> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
>
> In the two attached parm files I used,
> compute_precip.pointstatconfig.mrms.old produced stats with
> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
> compute_precip.pointstatconfig.mrms (my failed attempt at forcing a
> change of FCST_VAR to APCP_24) lead to the following err message
when
> running point_stat:
>
> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-20180401.nc
> DEBUG 2:
> DEBUG 2:
>
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for APCP_24A24.
> WARNING:
> WARNING: process_fcst_climo_files() -> no fields matching APCP_24A24
> found in file: mrms24/mrms.2018040112.24h.nc
> WARNING:
> ERROR :
> ERROR : process_fcst_climo_files() -> no requested forecast data
> found! Exiting...
> ERROR :
> + exit
>
> Is there a good way change the FCST_VAR in *.stat?
>
> Thank you -
>
> Ying
>
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: Ying Lin
Time: Mon Jun 25 15:56:58 2018
Hi John,
Thanks for looking into my inquiry! Attached are 1) ncdump -h
output for mrms.2018040112.24h.nc and 2) as a comparison, the
counterpart for cmorph.
Ying
On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
> Hi Ying,
>
> I see you're having some issues getting Point-Stat configured the
way you'd
> like. We should be able to get this solved by tweaking your Point-
Stat
> config file. Yes, you can definitely have the "fcst" and "obs"
> dictionaries set to different variable names. This is the important
> message:
>
> WARNING: process_fcst_climo_files() -> no fields matching APCP_24A24
found
> in file: mrms24/mrms.2018040112.24h.nc
>
> Point-Stat can't find the data you requested in that file. Please
run
> 'ncdump -h' on that file to look at the header:
> ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
>
> And then send me that "header_dump" file.
>
> Thanks,
> John
>
> On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
>> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
>> Transaction: Ticket created by ying.lin at noaa.gov
>> Queue: met_help
>> Subject: point_stat: can FCST_VAR in *.stat be different from
the
>> field in *.nc?
>> Owner: Nobody
>> Requestors: ying.lin at noaa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>
>>
>> Hello. Trying to validate several QPE analysis fields against
gauges,
>> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to sum
up
>> both from hourlies. In the resulting *.nc file, CMORPH's field is
>> APCP_24:level = "A24", while MRMS is APCP:level = "A24", which
results
>> in different FCST_VAR names in the *.stat files (and some
difficulty in
>> plotting them in MetViewer together).
>>
>> Is there a way to tell point_stat to use a FCST_VAR in the *.stat
that's
>> different from the variable name in the NetCDF file for the
analysis,
>> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
>>
>> In the two attached parm files I used,
>> compute_precip.pointstatconfig.mrms.old produced stats with
>> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
>> compute_precip.pointstatconfig.mrms (my failed attempt at forcing a
>> change of FCST_VAR to APCP_24) lead to the following err message
when
>> running point_stat:
>>
>> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
>> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-20180401.nc
>> DEBUG 2:
>> DEBUG 2:
>>
>>
--------------------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 2: Reading data for APCP_24A24.
>> WARNING:
>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>> found in file: mrms24/mrms.2018040112.24h.nc
>> WARNING:
>> ERROR :
>> ERROR : process_fcst_climo_files() -> no requested forecast data
>> found! Exiting...
>> ERROR :
>> + exit
>>
>> Is there a good way change the FCST_VAR in *.stat?
>>
>> Thank you -
>>
>> Ying
>>
>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>
>>
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: Ying Lin
Time: Mon Jun 25 15:56:58 2018
netcdf mrms.2018040112.24h {
dimensions:
lat = 3500 ;
lon = 7000 ;
variables:
float lat(lat) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
float lon(lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:standard_name = "longitude" ;
float APCP(lat, lon) ;
APCP:name = "APCP" ;
APCP:long_name = "Local gauge bias corrected radar precipitation
accumulation 1-hour" ;
APCP:level = "A24" ;
APCP:units = "mm" ;
APCP:_FillValue = -9999.f ;
APCP:init_time = "20180401_120000" ;
APCP:init_time_ut = "1522584000" ;
APCP:valid_time = "20180401_120000" ;
APCP:valid_time_ut = "1522584000" ;
APCP:accum_time = "240000" ;
APCP:accum_time_sec = 86400 ;
// global attributes:
:_NCProperties =
"version=1|netcdflibversion=4.4.1.1|hdf5libversion=1.8.18" ;
:FileOrigins = "File mrms.2018040112.24h.nc generated
20180623_224731 UTC on host t14a1 by the MET pcp_combine tool" ;
:MET_version = "V7.0" ;
:MET_tool = "pcp_combine" ;
:RunCommand = "Sum: 24 files with accumulations of 010000." ;
:Projection = "LatLon" ;
:lat_ll = "20.005000 degrees_north" ;
:lon_ll = "-129.995000 degrees_east" ;
:delta_lat = "0.010000 degrees" ;
:delta_lon = "0.010000 degrees" ;
:Nlat = "3500 grid_points" ;
:Nlon = "7000 grid_points" ;
}
------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: Ying Lin
Time: Mon Jun 25 15:56:58 2018
netcdf cmorph.2018040112.24h {
dimensions:
lat = 1649 ;
lon = 4948 ;
variables:
float lat(lat) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
float lon(lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:standard_name = "longitude" ;
float APCP_24(lat, lon) ;
APCP_24:name = "APCP_24" ;
APCP_24:long_name = "Total Precipitation" ;
APCP_24:level = "A24" ;
APCP_24:units = "kg/m^2" ;
APCP_24:_FillValue = -9999.f ;
APCP_24:init_time = "20180401_120000" ;
APCP_24:init_time_ut = "1522584000" ;
APCP_24:valid_time = "20180401_120000" ;
APCP_24:valid_time_ut = "1522584000" ;
APCP_24:accum_time = "240000" ;
APCP_24:accum_time_sec = 86400 ;
// global attributes:
:_NCProperties =
"version=1|netcdflibversion=4.4.1.1|hdf5libversion=1.8.18" ;
:FileOrigins = "File cmorph.2018040112.24h.nc generated
20180623_222308 UTC on host t14a1 by the MET pcp_combine tool" ;
:MET_version = "V7.0" ;
:MET_tool = "pcp_combine" ;
:RunCommand = "Sum: 24 files with accumulations of 010000." ;
:Projection = "LatLon" ;
:lat_ll = "-59.963616 degrees_north" ;
:lon_ll = "0.036378 degrees_east" ;
:delta_lat = "0.072771 degrees" ;
:delta_lon = "0.072756 degrees" ;
:Nlat = "1649 grid_points" ;
:Nlon = "4948 grid_points" ;
}
------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: John Halley Gotway
Time: Mon Jun 25 16:23:20 2018
Ying,
Great, thanks for sending those. This should be pretty straight-
forward.
You're putting MRMS in the "fcst" slot and CMORPH in the "obs" slot.
Looking in the MRMS header, I see that the data variable is named
"APCP".
And in the CMORPH header, it's named "APCP_24". When processing
NetCDF
files, just set the "name" equal to the variable name.
And "level" can either be set to the contents of the "level"
attribute...
or give indexes into the dimensions to be used, like this "(*,*)".
So you can make Grid-Stat happy by switching APCP and APCP_24 like
this:
cat_thresh = [
>=0.254,>=2.54,>=6.35,>=12.7,>=19.05,>=25.4,>=38.1,>=50.8,>=76.2,>=101.6
]; }
fcst = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }
obs = { field = [ { name = "APCP_24"; level = [ "A24" ]; } ];
}
Two more points to make...
(1) Since cat_thresh is set to the same list, rather than specifying
it
inside the "fcst" and "obs" dictionaries, just specify it once at the
top-level and it'll apply to both. That'll avoid copy/paste errors.
(2) It looks like these are the output of pcp_combine. For some
reason, the MRMS output is named "APCP" while the CMORPH output is
named "APCP_24".
Note that you can use the "-name" command line option for pcp_combine
to manually define the output variable name.
For example, you might decide to specify "-name APCP_24" in your
pcp_combine call for MRMS to get consistent variable names. Up to
you.
Thanks,
John
On Mon, Jun 25, 2018 at 3:57 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>
> Hi John,
>
> Thanks for looking into my inquiry! Attached are 1) ncdump -h
> output for mrms.2018040112.24h.nc and 2) as a comparison, the
> counterpart for cmorph.
>
> Ying
>
> On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
> > Hi Ying,
> >
> > I see you're having some issues getting Point-Stat configured the
way
> you'd
> > like. We should be able to get this solved by tweaking your
Point-Stat
> > config file. Yes, you can definitely have the "fcst" and "obs"
> > dictionaries set to different variable names. This is the
important
> > message:
> >
> > WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
> found
> > in file: mrms24/mrms.2018040112.24h.nc
> >
> > Point-Stat can't find the data you requested in that file. Please
run
> > 'ncdump -h' on that file to look at the header:
> > ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
> >
> > And then send me that "header_dump" file.
> >
> > Thanks,
> > John
> >
> > On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT
<met_help at ucar.edu>
> wrote:
> >
> >> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
> >> Transaction: Ticket created by ying.lin at noaa.gov
> >> Queue: met_help
> >> Subject: point_stat: can FCST_VAR in *.stat be different
from the
> >> field in *.nc?
> >> Owner: Nobody
> >> Requestors: ying.lin at noaa.gov
> >> Status: new
> >> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872
> >
> >>
> >>
> >> Hello. Trying to validate several QPE analysis fields against
gauges,
> >> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to sum
up
> >> both from hourlies. In the resulting *.nc file, CMORPH's field
is
> >> APCP_24:level = "A24", while MRMS is APCP:level = "A24", which
results
> >> in different FCST_VAR names in the *.stat files (and some
difficulty in
> >> plotting them in MetViewer together).
> >>
> >> Is there a way to tell point_stat to use a FCST_VAR in the *.stat
that's
> >> different from the variable name in the NetCDF file for the
analysis,
> >> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
> >>
> >> In the two attached parm files I used,
> >> compute_precip.pointstatconfig.mrms.old produced stats with
> >> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
> >> compute_precip.pointstatconfig.mrms (my failed attempt at forcing
a
> >> change of FCST_VAR to APCP_24) lead to the following err message
when
> >> running point_stat:
> >>
> >> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
> >> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-20180401.nc
> >> DEBUG 2:
> >> DEBUG 2:
> >>
> >>
>
--------------------------------------------------------------------------------
> >> DEBUG 2:
> >> DEBUG 2: Reading data for APCP_24A24.
> >> WARNING:
> >> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
> >> found in file: mrms24/mrms.2018040112.24h.nc
> >> WARNING:
> >> ERROR :
> >> ERROR : process_fcst_climo_files() -> no requested forecast data
> >> found! Exiting...
> >> ERROR :
> >> + exit
> >>
> >> Is there a good way change the FCST_VAR in *.stat?
> >>
> >> Thank you -
> >>
> >> Ying
> >>
> >>
> >> --
> >> Ying Lin
> >> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >> NCWCP Cubicle No. 2015
> >> Ying.Lin at noaa.gov
> >>
> >>
> >>
> >>
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #85872] point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: Ying Lin
Time: Thu Jun 28 10:56:56 2018
Thanks much John. Lots of great information in your email.
1) Great tips about the parm file - simplified and now it's more
legible
(and produced identical results).
2) Specifying "-name APCP_24" in pcp_combine works well - resulted in
FCST_VAR *.stat that's consistent with *.stat from verif of other
fields, makes it easier for comparison/aggregate stats
Questions:
1) Is it better practice to have 'name = "APCP"; level = [ "A24" ]'
than 'name = "APCP_24"; level = [ "A24" ]'? On the online examples
(e.g.
https://dtcenter.org/met/users/support/faqs/faq.php?name=pcp_combine&category=add_example)
when precip is concerned, 'level' is used for length of accumulation
time in hours, so is 'name = "APCP_24"; level = [ "A24" ]' rather
ugly
and best avoided, since I can use pcp_combine to have '-name APCP'
instead, when the default (e.g. for CMORPH's 24h pcp_combine output)
is
'APCP_24'?
2) I was running point_stat to validate MRMS and CMORPH (and ST4)
against daily gauges, not verifying MRMS against CMORPH. So my
original
question was, if the original field variable name is 'APCP', can I do
something in the parm file to force the FCST_VAR in (e.g.) *.stat file
to be 'APCP_24', in order for the .stat file to be consistent with the
other field's (e.g. CMORPH's), so that they can all be easily compared
in MetViewer? I was able to get verif stats from both originally,
setting the forecast field name to that in the 24h *.nc file, but the
resulting different FCST_VAR names in the *.stat files required some
wrangling (Tatiana helped) for them to be displayed together in
MetViewer. Now that I can force the name to be consistent through
pcp_combine, this is no longer an important point.
To clarify, if I run pcp_combine w/o specifying '-name", the resulting
*.nc fields are
CMORPH:
APCP_24:level = "A24"
MRMS APCP:level = "A24"
Thanks again -
Ying
On 06/25/2018 06:23 PM, John Halley Gotway via RT wrote:
> Ying,
>
> Great, thanks for sending those. This should be pretty straight-
forward.
> You're putting MRMS in the "fcst" slot and CMORPH in the "obs" slot.
> Looking in the MRMS header, I see that the data variable is named
"APCP".
> And in the CMORPH header, it's named "APCP_24". When processing
NetCDF
> files, just set the "name" equal to the variable name.
>
> And "level" can either be set to the contents of the "level"
attribute...
> or give indexes into the dimensions to be used, like this "(*,*)".
>
> So you can make Grid-Stat happy by switching APCP and APCP_24 like
this:
>
> cat_thresh = [
>=0.254,>=2.54,>=6.35,>=12.7,>=19.05,>=25.4,>=38.1,>=50.8,>=76.2,>=101.6
> ]; }
>
> fcst = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }
> obs = { field = [ { name = "APCP_24"; level = [ "A24" ]; } ];
> }
>
> Two more points to make...
>
> (1) Since cat_thresh is set to the same list, rather than specifying
it
> inside the "fcst" and "obs" dictionaries, just specify it once at
the
> top-level and it'll apply to both. That'll avoid copy/paste errors.
>
> (2) It looks like these are the output of pcp_combine. For some
> reason, the MRMS output is named "APCP" while the CMORPH output is
> named "APCP_24".
> Note that you can use the "-name" command line option for
pcp_combine
> to manually define the output variable name.
>
> For example, you might decide to specify "-name APCP_24" in your
> pcp_combine call for MRMS to get consistent variable names. Up to
> you.
>
> Thanks,
>
> John
>
>
> On Mon, Jun 25, 2018 at 3:57 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>
>> Hi John,
>>
>> Thanks for looking into my inquiry! Attached are 1) ncdump
-h
>> output for mrms.2018040112.24h.nc and 2) as a comparison, the
>> counterpart for cmorph.
>>
>> Ying
>>
>> On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
>>> Hi Ying,
>>>
>>> I see you're having some issues getting Point-Stat configured the
way
>> you'd
>>> like. We should be able to get this solved by tweaking your
Point-Stat
>>> config file. Yes, you can definitely have the "fcst" and "obs"
>>> dictionaries set to different variable names. This is the
important
>>> message:
>>>
>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>> found
>>> in file: mrms24/mrms.2018040112.24h.nc
>>>
>>> Point-Stat can't find the data you requested in that file. Please
run
>>> 'ncdump -h' on that file to look at the header:
>>> ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
>>>
>>> And then send me that "header_dump" file.
>>>
>>> Thanks,
>>> John
>>>
>>> On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT
<met_help at ucar.edu>
>> wrote:
>>>> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
>>>> Transaction: Ticket created by ying.lin at noaa.gov
>>>> Queue: met_help
>>>> Subject: point_stat: can FCST_VAR in *.stat be different
from the
>>>> field in *.nc?
>>>> Owner: Nobody
>>>> Requestors: ying.lin at noaa.gov
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872
>>>>
>>>> Hello. Trying to validate several QPE analysis fields against
gauges,
>>>> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to sum
up
>>>> both from hourlies. In the resulting *.nc file, CMORPH's field
is
>>>> APCP_24:level = "A24", while MRMS is APCP:level = "A24", which
results
>>>> in different FCST_VAR names in the *.stat files (and some
difficulty in
>>>> plotting them in MetViewer together).
>>>>
>>>> Is there a way to tell point_stat to use a FCST_VAR in the *.stat
that's
>>>> different from the variable name in the NetCDF file for the
analysis,
>>>> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
>>>>
>>>> In the two attached parm files I used,
>>>> compute_precip.pointstatconfig.mrms.old produced stats with
>>>> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
>>>> compute_precip.pointstatconfig.mrms (my failed attempt at forcing
a
>>>> change of FCST_VAR to APCP_24) lead to the following err message
when
>>>> running point_stat:
>>>>
>>>> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
>>>> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-20180401.nc
>>>> DEBUG 2:
>>>> DEBUG 2:
>>>>
>>>>
>>
--------------------------------------------------------------------------------
>>>> DEBUG 2:
>>>> DEBUG 2: Reading data for APCP_24A24.
>>>> WARNING:
>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>>>> found in file: mrms24/mrms.2018040112.24h.nc
>>>> WARNING:
>>>> ERROR :
>>>> ERROR : process_fcst_climo_files() -> no requested forecast data
>>>> found! Exiting...
>>>> ERROR :
>>>> + exit
>>>>
>>>> Is there a good way change the FCST_VAR in *.stat?
>>>>
>>>> Thank you -
>>>>
>>>> Ying
>>>>
>>>>
>>>> --
>>>> Ying Lin
>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>> NCWCP Cubicle No. 2015
>>>> Ying.Lin at noaa.gov
>>>>
>>>>
>>>>
>>>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>
>>
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: John Halley Gotway
Time: Thu Jun 28 11:40:39 2018
Ying,
(1) I don't really have a best practice to recommend on using
"APCP_24" vs
"APCP" and level = "A24". It's really up to you and/or folks at NCEP
in
using MET/METViewer. But I do think it's an excellent question to
ask...
what standards and best practices for naming conventions would EMC
like to
adopt.
Personally, I think I prefer naming it APCP_24... so that you have
separate
entries in METViewer for APCP_01, APCP_03, APCP_06, and APCP_24... and
can
easily what accumulation intervals are available in your database.
That
seems convenient to me. But that's just my preference.
(2) For your second question... no there is currently no way to
override
what Point-Stat writes to the FCST_VAR output column. There actually
is
logic for doing this in STAT-Analysis. You can use the "-set_hdr"
option
to explicitly specify the contents of the output header columns. For
example, if you run STAT-Analysis to aggregate data where VX_MASK =
EAST
and VX_MASK = WEST, the output header column will, by default, be
written
as a concatenation of the unique input strings: VX_MASK = EAST,WEST.
But
you can manually override that by setting -set_hdr VX_MASK CONUS. And
then
EAST,WEST will be replaced by CONUS.
Perhaps we could add a similar config file option for Point-Stat,
Grid-Stat, Ensemble-Stat, Wavelet-Stat, MODE, and MTD to do what
STAT-Analysis is already doing:
set_hdr_column = [ "FCST_VAR" ];
set_hdr_value = [ "APCP_24" ];
Data is messy and this would give us an option for cleaning it up.
Do you think this functionality would be useful?
Thanks,
John
On Thu, Jun 28, 2018 at 10:57 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>
> Thanks much John. Lots of great information in your email.
>
> 1) Great tips about the parm file - simplified and now it's more
legible
> (and produced identical results).
> 2) Specifying "-name APCP_24" in pcp_combine works well - resulted
in
> FCST_VAR *.stat that's consistent with *.stat from verif of other
> fields, makes it easier for comparison/aggregate stats
>
> Questions:
>
> 1) Is it better practice to have 'name = "APCP"; level = [ "A24"
]'
> than 'name = "APCP_24"; level = [ "A24" ]'? On the online
examples
> (e.g.
>
>
https://dtcenter.org/met/users/support/faqs/faq.php?name=pcp_combine&category=add_example)
>
> when precip is concerned, 'level' is used for length of
accumulation
> time in hours, so is 'name = "APCP_24"; level = [ "A24" ]' rather
ugly
> and best avoided, since I can use pcp_combine to have '-name APCP'
> instead, when the default (e.g. for CMORPH's 24h pcp_combine output)
is
> 'APCP_24'?
>
> 2) I was running point_stat to validate MRMS and CMORPH (and ST4)
> against daily gauges, not verifying MRMS against CMORPH. So my
original
> question was, if the original field variable name is 'APCP', can I
do
> something in the parm file to force the FCST_VAR in (e.g.) *.stat
file
> to be 'APCP_24', in order for the .stat file to be consistent with
the
> other field's (e.g. CMORPH's), so that they can all be easily
compared
> in MetViewer? I was able to get verif stats from both originally,
> setting the forecast field name to that in the 24h *.nc file, but
the
> resulting different FCST_VAR names in the *.stat files required some
> wrangling (Tatiana helped) for them to be displayed together in
> MetViewer. Now that I can force the name to be consistent through
> pcp_combine, this is no longer an important point.
>
> To clarify, if I run pcp_combine w/o specifying '-name", the
resulting
> *.nc fields are
>
> CMORPH:
> APCP_24:level = "A24"
> MRMS APCP:level = "A24"
>
> Thanks again -
>
> Ying
>
> On 06/25/2018 06:23 PM, John Halley Gotway via RT wrote:
> > Ying,
> >
> > Great, thanks for sending those. This should be pretty straight-
forward.
> > You're putting MRMS in the "fcst" slot and CMORPH in the "obs"
slot.
> > Looking in the MRMS header, I see that the data variable is named
"APCP".
> > And in the CMORPH header, it's named "APCP_24". When processing
NetCDF
> > files, just set the "name" equal to the variable name.
> >
> > And "level" can either be set to the contents of the "level"
attribute...
> > or give indexes into the dimensions to be used, like this "(*,*)".
> >
> > So you can make Grid-Stat happy by switching APCP and APCP_24 like
this:
> >
> > cat_thresh = [
>
>=0.254,>=2.54,>=6.35,>=12.7,>=19.05,>=25.4,>=38.1,>=50.8,>=76.2,>=101.6
> > ]; }
> >
> > fcst = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }
> > obs = { field = [ { name = "APCP_24"; level = [ "A24" ]; } ];
> > }
> >
> > Two more points to make...
> >
> > (1) Since cat_thresh is set to the same list, rather than
specifying it
> > inside the "fcst" and "obs" dictionaries, just specify it once at
the
> > top-level and it'll apply to both. That'll avoid copy/paste
errors.
> >
> > (2) It looks like these are the output of pcp_combine. For some
> > reason, the MRMS output is named "APCP" while the CMORPH output is
> > named "APCP_24".
> > Note that you can use the "-name" command line option for
pcp_combine
> > to manually define the output variable name.
> >
> > For example, you might decide to specify "-name APCP_24" in your
> > pcp_combine call for MRMS to get consistent variable names. Up to
> > you.
> >
> > Thanks,
> >
> > John
> >
> >
> > On Mon, Jun 25, 2018 at 3:57 PM Ying Lin via RT
<met_help at ucar.edu>
> wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
> >>
> >> Hi John,
> >>
> >> Thanks for looking into my inquiry! Attached are 1) ncdump
-h
> >> output for mrms.2018040112.24h.nc and 2) as a comparison, the
> >> counterpart for cmorph.
> >>
> >> Ying
> >>
> >> On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
> >>> Hi Ying,
> >>>
> >>> I see you're having some issues getting Point-Stat configured
the way
> >> you'd
> >>> like. We should be able to get this solved by tweaking your
Point-Stat
> >>> config file. Yes, you can definitely have the "fcst" and "obs"
> >>> dictionaries set to different variable names. This is the
important
> >>> message:
> >>>
> >>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
> >> found
> >>> in file: mrms24/mrms.2018040112.24h.nc
> >>>
> >>> Point-Stat can't find the data you requested in that file.
Please run
> >>> 'ncdump -h' on that file to look at the header:
> >>> ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
> >>>
> >>> And then send me that "header_dump" file.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>> On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT
<met_help at ucar.edu>
> >> wrote:
> >>>> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
> >>>> Transaction: Ticket created by ying.lin at noaa.gov
> >>>> Queue: met_help
> >>>> Subject: point_stat: can FCST_VAR in *.stat be different
from
> the
> >>>> field in *.nc?
> >>>> Owner: Nobody
> >>>> Requestors: ying.lin at noaa.gov
> >>>> Status: new
> >>>> Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872
> >>>>
> >>>> Hello. Trying to validate several QPE analysis fields against
gauges,
> >>>> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to
sum up
> >>>> both from hourlies. In the resulting *.nc file, CMORPH's field
is
> >>>> APCP_24:level = "A24", while MRMS is APCP:level = "A24", which
results
> >>>> in different FCST_VAR names in the *.stat files (and some
difficulty
> in
> >>>> plotting them in MetViewer together).
> >>>>
> >>>> Is there a way to tell point_stat to use a FCST_VAR in the
*.stat
> that's
> >>>> different from the variable name in the NetCDF file for the
analysis,
> >>>> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
> >>>>
> >>>> In the two attached parm files I used,
> >>>> compute_precip.pointstatconfig.mrms.old produced stats with
> >>>> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
> >>>> compute_precip.pointstatconfig.mrms (my failed attempt at
forcing a
> >>>> change of FCST_VAR to APCP_24) lead to the following err
message when
> >>>> running point_stat:
> >>>>
> >>>> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
> >>>> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-
20180401.nc
> >>>> DEBUG 2:
> >>>> DEBUG 2:
> >>>>
> >>>>
> >>
>
--------------------------------------------------------------------------------
> >>>> DEBUG 2:
> >>>> DEBUG 2: Reading data for APCP_24A24.
> >>>> WARNING:
> >>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
> >>>> found in file: mrms24/mrms.2018040112.24h.nc
> >>>> WARNING:
> >>>> ERROR :
> >>>> ERROR : process_fcst_climo_files() -> no requested forecast
data
> >>>> found! Exiting...
> >>>> ERROR :
> >>>> + exit
> >>>>
> >>>> Is there a good way change the FCST_VAR in *.stat?
> >>>>
> >>>> Thank you -
> >>>>
> >>>> Ying
> >>>>
> >>>>
> >>>> --
> >>>> Ying Lin
> >>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >>>> NCWCP Cubicle No. 2015
> >>>> Ying.Lin at noaa.gov
> >>>>
> >>>>
> >>>>
> >>>>
> >> --
> >> Ying Lin
> >> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >> NCWCP Cubicle No. 2015
> >> Ying.Lin at noaa.gov
> >>
> >>
> >>
> >>
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #85872] point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: Ying Lin
Time: Thu Jun 28 12:19:48 2018
Hi John,
1) I'm going to keep it APCP_24 then, from the reasons you outlined it
sounds like a good idea.
2) Yes, I think having a "set_hdr_value" for hdr_column would be a
good
idea. The availability of the "-name" option in pcp_combine (thx!)
makes it a low-priority wish-list item. I'm also validating ST4 24h
total (in GRIB1), which point_stat considers to have FCST_VAR =
APCP_24
(consistent with CMORPH) so I'm happy, but as you said, data is messy
... in the future some other GRIB1/2 fields to be verified/validated
might have a non-standard FCST_VAR.
Thanks again for all the great info/advice. Please close this ticket
at
your convenience.
Ying
On 06/28/2018 01:40 PM, John Halley Gotway via RT wrote:
> Ying,
>
> (1) I don't really have a best practice to recommend on using
"APCP_24" vs
> "APCP" and level = "A24". It's really up to you and/or folks at
NCEP in
> using MET/METViewer. But I do think it's an excellent question to
ask...
> what standards and best practices for naming conventions would EMC
like to
> adopt.
>
> Personally, I think I prefer naming it APCP_24... so that you have
separate
> entries in METViewer for APCP_01, APCP_03, APCP_06, and APCP_24...
and can
> easily what accumulation intervals are available in your database.
That
> seems convenient to me. But that's just my preference.
>
> (2) For your second question... no there is currently no way to
override
> what Point-Stat writes to the FCST_VAR output column. There
actually is
> logic for doing this in STAT-Analysis. You can use the "-set_hdr"
option
> to explicitly specify the contents of the output header columns.
For
> example, if you run STAT-Analysis to aggregate data where VX_MASK =
EAST
> and VX_MASK = WEST, the output header column will, by default, be
written
> as a concatenation of the unique input strings: VX_MASK = EAST,WEST.
But
> you can manually override that by setting -set_hdr VX_MASK CONUS.
And then
> EAST,WEST will be replaced by CONUS.
>
> Perhaps we could add a similar config file option for Point-Stat,
> Grid-Stat, Ensemble-Stat, Wavelet-Stat, MODE, and MTD to do what
> STAT-Analysis is already doing:
> set_hdr_column = [ "FCST_VAR" ];
> set_hdr_value = [ "APCP_24" ];
>
> Data is messy and this would give us an option for cleaning it up.
>
> Do you think this functionality would be useful?
>
> Thanks,
> John
>
>
> On Thu, Jun 28, 2018 at 10:57 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>
>> Thanks much John. Lots of great information in your email.
>>
>> 1) Great tips about the parm file - simplified and now it's more
legible
>> (and produced identical results).
>> 2) Specifying "-name APCP_24" in pcp_combine works well - resulted
in
>> FCST_VAR *.stat that's consistent with *.stat from verif of other
>> fields, makes it easier for comparison/aggregate stats
>>
>> Questions:
>>
>> 1) Is it better practice to have 'name = "APCP"; level = [ "A24"
]'
>> than 'name = "APCP_24"; level = [ "A24" ]'? On the online
examples
>> (e.g.
>>
>>
https://dtcenter.org/met/users/support/faqs/faq.php?name=pcp_combine&category=add_example)
>>
>> when precip is concerned, 'level' is used for length of
accumulation
>> time in hours, so is 'name = "APCP_24"; level = [ "A24" ]' rather
ugly
>> and best avoided, since I can use pcp_combine to have '-name APCP'
>> instead, when the default (e.g. for CMORPH's 24h pcp_combine
output) is
>> 'APCP_24'?
>>
>> 2) I was running point_stat to validate MRMS and CMORPH (and ST4)
>> against daily gauges, not verifying MRMS against CMORPH. So my
original
>> question was, if the original field variable name is 'APCP', can I
do
>> something in the parm file to force the FCST_VAR in (e.g.) *.stat
file
>> to be 'APCP_24', in order for the .stat file to be consistent with
the
>> other field's (e.g. CMORPH's), so that they can all be easily
compared
>> in MetViewer? I was able to get verif stats from both originally,
>> setting the forecast field name to that in the 24h *.nc file, but
the
>> resulting different FCST_VAR names in the *.stat files required
some
>> wrangling (Tatiana helped) for them to be displayed together in
>> MetViewer. Now that I can force the name to be consistent through
>> pcp_combine, this is no longer an important point.
>>
>> To clarify, if I run pcp_combine w/o specifying '-name", the
resulting
>> *.nc fields are
>>
>> CMORPH:
>> APCP_24:level = "A24"
>> MRMS APCP:level = "A24"
>>
>> Thanks again -
>>
>> Ying
>>
>> On 06/25/2018 06:23 PM, John Halley Gotway via RT wrote:
>>> Ying,
>>>
>>> Great, thanks for sending those. This should be pretty straight-
forward.
>>> You're putting MRMS in the "fcst" slot and CMORPH in the "obs"
slot.
>>> Looking in the MRMS header, I see that the data variable is named
"APCP".
>>> And in the CMORPH header, it's named "APCP_24". When processing
NetCDF
>>> files, just set the "name" equal to the variable name.
>>>
>>> And "level" can either be set to the contents of the "level"
attribute...
>>> or give indexes into the dimensions to be used, like this "(*,*)".
>>>
>>> So you can make Grid-Stat happy by switching APCP and APCP_24 like
this:
>>>
>>> cat_thresh = [
>>>
=0.254,>=2.54,>=6.35,>=12.7,>=19.05,>=25.4,>=38.1,>=50.8,>=76.2,>=101.6
>>> ]; }
>>>
>>> fcst = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }
>>> obs = { field = [ { name = "APCP_24"; level = [ "A24" ]; } ];
>>> }
>>>
>>> Two more points to make...
>>>
>>> (1) Since cat_thresh is set to the same list, rather than
specifying it
>>> inside the "fcst" and "obs" dictionaries, just specify it once at
the
>>> top-level and it'll apply to both. That'll avoid copy/paste
errors.
>>>
>>> (2) It looks like these are the output of pcp_combine. For some
>>> reason, the MRMS output is named "APCP" while the CMORPH output is
>>> named "APCP_24".
>>> Note that you can use the "-name" command line option for
pcp_combine
>>> to manually define the output variable name.
>>>
>>> For example, you might decide to specify "-name APCP_24" in your
>>> pcp_combine call for MRMS to get consistent variable names. Up to
>>> you.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>> On Mon, Jun 25, 2018 at 3:57 PM Ying Lin via RT
<met_help at ucar.edu>
>> wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>>>
>>>> Hi John,
>>>>
>>>> Thanks for looking into my inquiry! Attached are 1)
ncdump -h
>>>> output for mrms.2018040112.24h.nc and 2) as a comparison, the
>>>> counterpart for cmorph.
>>>>
>>>> Ying
>>>>
>>>> On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
>>>>> Hi Ying,
>>>>>
>>>>> I see you're having some issues getting Point-Stat configured
the way
>>>> you'd
>>>>> like. We should be able to get this solved by tweaking your
Point-Stat
>>>>> config file. Yes, you can definitely have the "fcst" and "obs"
>>>>> dictionaries set to different variable names. This is the
important
>>>>> message:
>>>>>
>>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>>>> found
>>>>> in file: mrms24/mrms.2018040112.24h.nc
>>>>>
>>>>> Point-Stat can't find the data you requested in that file.
Please run
>>>>> 'ncdump -h' on that file to look at the header:
>>>>> ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
>>>>>
>>>>> And then send me that "header_dump" file.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT
<met_help at ucar.edu>
>>>> wrote:
>>>>>> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
>>>>>> Transaction: Ticket created by ying.lin at noaa.gov
>>>>>> Queue: met_help
>>>>>> Subject: point_stat: can FCST_VAR in *.stat be
different from
>> the
>>>>>> field in *.nc?
>>>>>> Owner: Nobody
>>>>>> Requestors: ying.lin at noaa.gov
>>>>>> Status: new
>>>>>> Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872
>>>>>> Hello. Trying to validate several QPE analysis fields against
gauges,
>>>>>> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to
sum up
>>>>>> both from hourlies. In the resulting *.nc file, CMORPH's field
is
>>>>>> APCP_24:level = "A24", while MRMS is APCP:level = "A24", which
results
>>>>>> in different FCST_VAR names in the *.stat files (and some
difficulty
>> in
>>>>>> plotting them in MetViewer together).
>>>>>>
>>>>>> Is there a way to tell point_stat to use a FCST_VAR in the
*.stat
>> that's
>>>>>> different from the variable name in the NetCDF file for the
analysis,
>>>>>> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
>>>>>>
>>>>>> In the two attached parm files I used,
>>>>>> compute_precip.pointstatconfig.mrms.old produced stats with
>>>>>> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
>>>>>> compute_precip.pointstatconfig.mrms (my failed attempt at
forcing a
>>>>>> change of FCST_VAR to APCP_24) lead to the following err
message when
>>>>>> running point_stat:
>>>>>>
>>>>>> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
>>>>>> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-
20180401.nc
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>>
>>>>>>
>>
--------------------------------------------------------------------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Reading data for APCP_24A24.
>>>>>> WARNING:
>>>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>>>>>> found in file: mrms24/mrms.2018040112.24h.nc
>>>>>> WARNING:
>>>>>> ERROR :
>>>>>> ERROR : process_fcst_climo_files() -> no requested forecast
data
>>>>>> found! Exiting...
>>>>>> ERROR :
>>>>>> + exit
>>>>>>
>>>>>> Is there a good way change the FCST_VAR in *.stat?
>>>>>>
>>>>>> Thank you -
>>>>>>
>>>>>> Ying
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ying Lin
>>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>>>> NCWCP Cubicle No. 2015
>>>>>> Ying.Lin at noaa.gov
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Ying Lin
>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>> NCWCP Cubicle No. 2015
>>>> Ying.Lin at noaa.gov
>>>>
>>>>
>>>>
>>>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>
>>
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
------------------------------------------------
Subject: point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: John Halley Gotway
Time: Thu Jun 28 14:20:00 2018
Ying,
Great, thanks. I went ahead and created a development ticket in JiRA
to
capture this idea of manually overriding the output header columns.
See
attached. I can't make any promises about if/when we can get it
implemented. But I wanted to make sure we captured it.
Thanks,
John
On Thu, Jun 28, 2018 at 12:20 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>
> Hi John,
>
> 1) I'm going to keep it APCP_24 then, from the reasons you outlined
it
> sounds like a good idea.
>
> 2) Yes, I think having a "set_hdr_value" for hdr_column would be a
good
> idea. The availability of the "-name" option in pcp_combine (thx!)
> makes it a low-priority wish-list item. I'm also validating ST4 24h
> total (in GRIB1), which point_stat considers to have FCST_VAR =
APCP_24
> (consistent with CMORPH) so I'm happy, but as you said, data is
messy
> ... in the future some other GRIB1/2 fields to be verified/validated
> might have a non-standard FCST_VAR.
>
> Thanks again for all the great info/advice. Please close this
ticket at
> your convenience.
>
> Ying
>
> On 06/28/2018 01:40 PM, John Halley Gotway via RT wrote:
> > Ying,
> >
> > (1) I don't really have a best practice to recommend on using
"APCP_24"
> vs
> > "APCP" and level = "A24". It's really up to you and/or folks at
NCEP in
> > using MET/METViewer. But I do think it's an excellent question to
ask...
> > what standards and best practices for naming conventions would EMC
like
> to
> > adopt.
> >
> > Personally, I think I prefer naming it APCP_24... so that you have
> separate
> > entries in METViewer for APCP_01, APCP_03, APCP_06, and APCP_24...
and
> can
> > easily what accumulation intervals are available in your database.
That
> > seems convenient to me. But that's just my preference.
> >
> > (2) For your second question... no there is currently no way to
override
> > what Point-Stat writes to the FCST_VAR output column. There
actually is
> > logic for doing this in STAT-Analysis. You can use the "-set_hdr"
option
> > to explicitly specify the contents of the output header columns.
For
> > example, if you run STAT-Analysis to aggregate data where VX_MASK
= EAST
> > and VX_MASK = WEST, the output header column will, by default, be
written
> > as a concatenation of the unique input strings: VX_MASK =
EAST,WEST. But
> > you can manually override that by setting -set_hdr VX_MASK CONUS.
And
> then
> > EAST,WEST will be replaced by CONUS.
> >
> > Perhaps we could add a similar config file option for Point-Stat,
> > Grid-Stat, Ensemble-Stat, Wavelet-Stat, MODE, and MTD to do what
> > STAT-Analysis is already doing:
> > set_hdr_column = [ "FCST_VAR" ];
> > set_hdr_value = [ "APCP_24" ];
> >
> > Data is messy and this would give us an option for cleaning it up.
> >
> > Do you think this functionality would be useful?
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jun 28, 2018 at 10:57 AM Ying Lin via RT
<met_help at ucar.edu>
> wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
> >>
> >> Thanks much John. Lots of great information in your email.
> >>
> >> 1) Great tips about the parm file - simplified and now it's more
legible
> >> (and produced identical results).
> >> 2) Specifying "-name APCP_24" in pcp_combine works well -
resulted in
> >> FCST_VAR *.stat that's consistent with *.stat from verif of other
> >> fields, makes it easier for comparison/aggregate stats
> >>
> >> Questions:
> >>
> >> 1) Is it better practice to have 'name = "APCP"; level = [
"A24" ]'
> >> than 'name = "APCP_24"; level = [ "A24" ]'? On the online
examples
> >> (e.g.
> >>
> >>
>
https://dtcenter.org/met/users/support/faqs/faq.php?name=pcp_combine&category=add_example
> )
> >>
> >> when precip is concerned, 'level' is used for length of
accumulation
> >> time in hours, so is 'name = "APCP_24"; level = [ "A24" ]'
rather ugly
> >> and best avoided, since I can use pcp_combine to have '-name
APCP'
> >> instead, when the default (e.g. for CMORPH's 24h pcp_combine
output) is
> >> 'APCP_24'?
> >>
> >> 2) I was running point_stat to validate MRMS and CMORPH (and ST4)
> >> against daily gauges, not verifying MRMS against CMORPH. So my
original
> >> question was, if the original field variable name is 'APCP', can
I do
> >> something in the parm file to force the FCST_VAR in (e.g.) *.stat
file
> >> to be 'APCP_24', in order for the .stat file to be consistent
with the
> >> other field's (e.g. CMORPH's), so that they can all be easily
compared
> >> in MetViewer? I was able to get verif stats from both
originally,
> >> setting the forecast field name to that in the 24h *.nc file, but
the
> >> resulting different FCST_VAR names in the *.stat files required
some
> >> wrangling (Tatiana helped) for them to be displayed together in
> >> MetViewer. Now that I can force the name to be consistent
through
> >> pcp_combine, this is no longer an important point.
> >>
> >> To clarify, if I run pcp_combine w/o specifying '-name", the
resulting
> >> *.nc fields are
> >>
> >> CMORPH:
> >> APCP_24:level = "A24"
> >> MRMS APCP:level = "A24"
> >>
> >> Thanks again -
> >>
> >> Ying
> >>
> >> On 06/25/2018 06:23 PM, John Halley Gotway via RT wrote:
> >>> Ying,
> >>>
> >>> Great, thanks for sending those. This should be pretty
> straight-forward.
> >>> You're putting MRMS in the "fcst" slot and CMORPH in the "obs"
slot.
> >>> Looking in the MRMS header, I see that the data variable is
named
> "APCP".
> >>> And in the CMORPH header, it's named "APCP_24". When processing
NetCDF
> >>> files, just set the "name" equal to the variable name.
> >>>
> >>> And "level" can either be set to the contents of the "level"
> attribute...
> >>> or give indexes into the dimensions to be used, like this
"(*,*)".
> >>>
> >>> So you can make Grid-Stat happy by switching APCP and APCP_24
like
> this:
> >>>
> >>> cat_thresh = [
> >>>
=0.254,>=2.54,>=6.35,>=12.7,>=19.05,>=25.4,>=38.1,>=50.8,>=76.2,>=101.6
> >>> ]; }
> >>>
> >>> fcst = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }
> >>> obs = { field = [ { name = "APCP_24"; level = [ "A24" ]; } ];
> >>> }
> >>>
> >>> Two more points to make...
> >>>
> >>> (1) Since cat_thresh is set to the same list, rather than
specifying it
> >>> inside the "fcst" and "obs" dictionaries, just specify it once
at the
> >>> top-level and it'll apply to both. That'll avoid copy/paste
errors.
> >>>
> >>> (2) It looks like these are the output of pcp_combine. For some
> >>> reason, the MRMS output is named "APCP" while the CMORPH output
is
> >>> named "APCP_24".
> >>> Note that you can use the "-name" command line option for
pcp_combine
> >>> to manually define the output variable name.
> >>>
> >>> For example, you might decide to specify "-name APCP_24" in your
> >>> pcp_combine call for MRMS to get consistent variable names. Up
to
> >>> you.
> >>>
> >>> Thanks,
> >>>
> >>> John
> >>>
> >>>
> >>> On Mon, Jun 25, 2018 at 3:57 PM Ying Lin via RT
<met_help at ucar.edu>
> >> wrote:
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Thanks for looking into my inquiry! Attached are 1)
ncdump -h
> >>>> output for mrms.2018040112.24h.nc and 2) as a comparison, the
> >>>> counterpart for cmorph.
> >>>>
> >>>> Ying
> >>>>
> >>>> On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
> >>>>> Hi Ying,
> >>>>>
> >>>>> I see you're having some issues getting Point-Stat configured
the way
> >>>> you'd
> >>>>> like. We should be able to get this solved by tweaking your
> Point-Stat
> >>>>> config file. Yes, you can definitely have the "fcst" and
"obs"
> >>>>> dictionaries set to different variable names. This is the
important
> >>>>> message:
> >>>>>
> >>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
> >>>> found
> >>>>> in file: mrms24/mrms.2018040112.24h.nc
> >>>>>
> >>>>> Point-Stat can't find the data you requested in that file.
Please
> run
> >>>>> 'ncdump -h' on that file to look at the header:
> >>>>> ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
> >>>>>
> >>>>> And then send me that "header_dump" file.
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>> On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT
<met_help at ucar.edu>
> >>>> wrote:
> >>>>>> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
> >>>>>> Transaction: Ticket created by ying.lin at noaa.gov
> >>>>>> Queue: met_help
> >>>>>> Subject: point_stat: can FCST_VAR in *.stat be
different
> from
> >> the
> >>>>>> field in *.nc?
> >>>>>> Owner: Nobody
> >>>>>> Requestors: ying.lin at noaa.gov
> >>>>>> Status: new
> >>>>>> Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872
> >>>>>> Hello. Trying to validate several QPE analysis fields
against
> gauges,
> >>>>>> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to
sum up
> >>>>>> both from hourlies. In the resulting *.nc file, CMORPH's
field is
> >>>>>> APCP_24:level = "A24", while MRMS is APCP:level = "A24",
which
> results
> >>>>>> in different FCST_VAR names in the *.stat files (and some
difficulty
> >> in
> >>>>>> plotting them in MetViewer together).
> >>>>>>
> >>>>>> Is there a way to tell point_stat to use a FCST_VAR in the
*.stat
> >> that's
> >>>>>> different from the variable name in the NetCDF file for the
> analysis,
> >>>>>> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
> >>>>>>
> >>>>>> In the two attached parm files I used,
> >>>>>> compute_precip.pointstatconfig.mrms.old produced stats with
> >>>>>> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
> >>>>>> compute_precip.pointstatconfig.mrms (my failed attempt at
forcing a
> >>>>>> change of FCST_VAR to APCP_24) lead to the following err
message
> when
> >>>>>> running point_stat:
> >>>>>>
> >>>>>> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
> >>>>>> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-
20180401.nc
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2:
> >>>>>>
> >>>>>>
> >>
>
--------------------------------------------------------------------------------
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2: Reading data for APCP_24A24.
> >>>>>> WARNING:
> >>>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
> >>>>>> found in file: mrms24/mrms.2018040112.24h.nc
> >>>>>> WARNING:
> >>>>>> ERROR :
> >>>>>> ERROR : process_fcst_climo_files() -> no requested forecast
data
> >>>>>> found! Exiting...
> >>>>>> ERROR :
> >>>>>> + exit
> >>>>>>
> >>>>>> Is there a good way change the FCST_VAR in *.stat?
> >>>>>>
> >>>>>> Thank you -
> >>>>>>
> >>>>>> Ying
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Ying Lin
> >>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >>>>>> NCWCP Cubicle No. 2015
> >>>>>> Ying.Lin at noaa.gov
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> --
> >>>> Ying Lin
> >>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >>>> NCWCP Cubicle No. 2015
> >>>> Ying.Lin at noaa.gov
> >>>>
> >>>>
> >>>>
> >>>>
> >> --
> >> Ying Lin
> >> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >> NCWCP Cubicle No. 2015
> >> Ying.Lin at noaa.gov
> >>
> >>
> >>
> >>
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
Subject: Thanks! Re: [rt.rap.ucar.edu #85872] point_stat: can FCST_VAR in *.stat be different from the field in *.nc?
From: Ying Lin
Time: Thu Jun 28 15:01:36 2018
That's great John. Thank you very much -
Ying
On 06/28/2018 04:20 PM, John Halley Gotway via RT wrote:
> Ying,
>
> Great, thanks. I went ahead and created a development ticket in
JiRA to
> capture this idea of manually overriding the output header columns.
See
> attached. I can't make any promises about if/when we can get it
> implemented. But I wanted to make sure we captured it.
>
> Thanks,
> John
>
> On Thu, Jun 28, 2018 at 12:20 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>
>> Hi John,
>>
>> 1) I'm going to keep it APCP_24 then, from the reasons you outlined
it
>> sounds like a good idea.
>>
>> 2) Yes, I think having a "set_hdr_value" for hdr_column would be a
good
>> idea. The availability of the "-name" option in pcp_combine
(thx!)
>> makes it a low-priority wish-list item. I'm also validating ST4 24h
>> total (in GRIB1), which point_stat considers to have FCST_VAR =
APCP_24
>> (consistent with CMORPH) so I'm happy, but as you said, data is
messy
>> ... in the future some other GRIB1/2 fields to be
verified/validated
>> might have a non-standard FCST_VAR.
>>
>> Thanks again for all the great info/advice. Please close this
ticket at
>> your convenience.
>>
>> Ying
>>
>> On 06/28/2018 01:40 PM, John Halley Gotway via RT wrote:
>>> Ying,
>>>
>>> (1) I don't really have a best practice to recommend on using
"APCP_24"
>> vs
>>> "APCP" and level = "A24". It's really up to you and/or folks at
NCEP in
>>> using MET/METViewer. But I do think it's an excellent question to
ask...
>>> what standards and best practices for naming conventions would EMC
like
>> to
>>> adopt.
>>>
>>> Personally, I think I prefer naming it APCP_24... so that you have
>> separate
>>> entries in METViewer for APCP_01, APCP_03, APCP_06, and APCP_24...
and
>> can
>>> easily what accumulation intervals are available in your database.
That
>>> seems convenient to me. But that's just my preference.
>>>
>>> (2) For your second question... no there is currently no way to
override
>>> what Point-Stat writes to the FCST_VAR output column. There
actually is
>>> logic for doing this in STAT-Analysis. You can use the "-set_hdr"
option
>>> to explicitly specify the contents of the output header columns.
For
>>> example, if you run STAT-Analysis to aggregate data where VX_MASK
= EAST
>>> and VX_MASK = WEST, the output header column will, by default, be
written
>>> as a concatenation of the unique input strings: VX_MASK =
EAST,WEST. But
>>> you can manually override that by setting -set_hdr VX_MASK CONUS.
And
>> then
>>> EAST,WEST will be replaced by CONUS.
>>>
>>> Perhaps we could add a similar config file option for Point-Stat,
>>> Grid-Stat, Ensemble-Stat, Wavelet-Stat, MODE, and MTD to do what
>>> STAT-Analysis is already doing:
>>> set_hdr_column = [ "FCST_VAR" ];
>>> set_hdr_value = [ "APCP_24" ];
>>>
>>> Data is messy and this would give us an option for cleaning it up.
>>>
>>> Do you think this functionality would be useful?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On Thu, Jun 28, 2018 at 10:57 AM Ying Lin via RT
<met_help at ucar.edu>
>> wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>>>
>>>> Thanks much John. Lots of great information in your email.
>>>>
>>>> 1) Great tips about the parm file - simplified and now it's more
legible
>>>> (and produced identical results).
>>>> 2) Specifying "-name APCP_24" in pcp_combine works well -
resulted in
>>>> FCST_VAR *.stat that's consistent with *.stat from verif of other
>>>> fields, makes it easier for comparison/aggregate stats
>>>>
>>>> Questions:
>>>>
>>>> 1) Is it better practice to have 'name = "APCP"; level = [
"A24" ]'
>>>> than 'name = "APCP_24"; level = [ "A24" ]'? On the online
examples
>>>> (e.g.
>>>>
>>>>
>>
https://dtcenter.org/met/users/support/faqs/faq.php?name=pcp_combine&category=add_example
>> )
>>>> when precip is concerned, 'level' is used for length of
accumulation
>>>> time in hours, so is 'name = "APCP_24"; level = [ "A24" ]'
rather ugly
>>>> and best avoided, since I can use pcp_combine to have '-name
APCP'
>>>> instead, when the default (e.g. for CMORPH's 24h pcp_combine
output) is
>>>> 'APCP_24'?
>>>>
>>>> 2) I was running point_stat to validate MRMS and CMORPH (and ST4)
>>>> against daily gauges, not verifying MRMS against CMORPH. So my
original
>>>> question was, if the original field variable name is 'APCP', can
I do
>>>> something in the parm file to force the FCST_VAR in (e.g.) *.stat
file
>>>> to be 'APCP_24', in order for the .stat file to be consistent
with the
>>>> other field's (e.g. CMORPH's), so that they can all be easily
compared
>>>> in MetViewer? I was able to get verif stats from both
originally,
>>>> setting the forecast field name to that in the 24h *.nc file, but
the
>>>> resulting different FCST_VAR names in the *.stat files required
some
>>>> wrangling (Tatiana helped) for them to be displayed together in
>>>> MetViewer. Now that I can force the name to be consistent
through
>>>> pcp_combine, this is no longer an important point.
>>>>
>>>> To clarify, if I run pcp_combine w/o specifying '-name", the
resulting
>>>> *.nc fields are
>>>>
>>>> CMORPH:
>>>> APCP_24:level = "A24"
>>>> MRMS APCP:level = "A24"
>>>>
>>>> Thanks again -
>>>>
>>>> Ying
>>>>
>>>> On 06/25/2018 06:23 PM, John Halley Gotway via RT wrote:
>>>>> Ying,
>>>>>
>>>>> Great, thanks for sending those. This should be pretty
>> straight-forward.
>>>>> You're putting MRMS in the "fcst" slot and CMORPH in the "obs"
slot.
>>>>> Looking in the MRMS header, I see that the data variable is
named
>> "APCP".
>>>>> And in the CMORPH header, it's named "APCP_24". When processing
NetCDF
>>>>> files, just set the "name" equal to the variable name.
>>>>>
>>>>> And "level" can either be set to the contents of the "level"
>> attribute...
>>>>> or give indexes into the dimensions to be used, like this
"(*,*)".
>>>>>
>>>>> So you can make Grid-Stat happy by switching APCP and APCP_24
like
>> this:
>>>>> cat_thresh = [
>>>>>
=0.254,>=2.54,>=6.35,>=12.7,>=19.05,>=25.4,>=38.1,>=50.8,>=76.2,>=101.6
>>>>> ]; }
>>>>>
>>>>> fcst = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }
>>>>> obs = { field = [ { name = "APCP_24"; level = [ "A24" ]; } ];
>>>>> }
>>>>>
>>>>> Two more points to make...
>>>>>
>>>>> (1) Since cat_thresh is set to the same list, rather than
specifying it
>>>>> inside the "fcst" and "obs" dictionaries, just specify it once
at the
>>>>> top-level and it'll apply to both. That'll avoid copy/paste
errors.
>>>>>
>>>>> (2) It looks like these are the output of pcp_combine. For some
>>>>> reason, the MRMS output is named "APCP" while the CMORPH output
is
>>>>> named "APCP_24".
>>>>> Note that you can use the "-name" command line option for
pcp_combine
>>>>> to manually define the output variable name.
>>>>>
>>>>> For example, you might decide to specify "-name APCP_24" in your
>>>>> pcp_combine call for MRMS to get consistent variable names. Up
to
>>>>> you.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Mon, Jun 25, 2018 at 3:57 PM Ying Lin via RT
<met_help at ucar.edu>
>>>> wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Thanks for looking into my inquiry! Attached are 1)
ncdump -h
>>>>>> output for mrms.2018040112.24h.nc and 2) as a comparison, the
>>>>>> counterpart for cmorph.
>>>>>>
>>>>>> Ying
>>>>>>
>>>>>> On 06/25/2018 05:03 PM, John Halley Gotway via RT wrote:
>>>>>>> Hi Ying,
>>>>>>>
>>>>>>> I see you're having some issues getting Point-Stat configured
the way
>>>>>> you'd
>>>>>>> like. We should be able to get this solved by tweaking your
>> Point-Stat
>>>>>>> config file. Yes, you can definitely have the "fcst" and
"obs"
>>>>>>> dictionaries set to different variable names. This is the
important
>>>>>>> message:
>>>>>>>
>>>>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>>>>>> found
>>>>>>> in file: mrms24/mrms.2018040112.24h.nc
>>>>>>>
>>>>>>> Point-Stat can't find the data you requested in that file.
Please
>> run
>>>>>>> 'ncdump -h' on that file to look at the header:
>>>>>>> ncdump -h mrms24/mrms.2018040112.24h.nc > header_dump
>>>>>>>
>>>>>>> And then send me that "header_dump" file.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>> On Mon, Jun 25, 2018 at 11:17 AM Ying Lin via RT
<met_help at ucar.edu>
>>>>>> wrote:
>>>>>>>> Mon Jun 25 11:09:13 2018: Request 85872 was acted upon.
>>>>>>>> Transaction: Ticket created by ying.lin at noaa.gov
>>>>>>>> Queue: met_help
>>>>>>>> Subject: point_stat: can FCST_VAR in *.stat be
different
>> from
>>>> the
>>>>>>>> field in *.nc?
>>>>>>>> Owner: Nobody
>>>>>>>> Requestors: ying.lin at noaa.gov
>>>>>>>> Status: new
>>>>>>>> Ticket <URL:
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=85872
>>>>>>>> Hello. Trying to validate several QPE analysis fields
against
>> gauges,
>>>>>>>> MRMS (gauge QC'd) and CMORPH among them. Used pcp_combine to
sum up
>>>>>>>> both from hourlies. In the resulting *.nc file, CMORPH's
field is
>>>>>>>> APCP_24:level = "A24", while MRMS is APCP:level = "A24",
which
>> results
>>>>>>>> in different FCST_VAR names in the *.stat files (and some
difficulty
>>>> in
>>>>>>>> plotting them in MetViewer together).
>>>>>>>>
>>>>>>>> Is there a way to tell point_stat to use a FCST_VAR in the
*.stat
>>>> that's
>>>>>>>> different from the variable name in the NetCDF file for the
>> analysis,
>>>>>>>> e.g. for *mrms*.stat, use 'APCP_24' instead of 'APCP'?
>>>>>>>>
>>>>>>>> In the two attached parm files I used,
>>>>>>>> compute_precip.pointstatconfig.mrms.old produced stats with
>>>>>>>> FCST_VAR=APCP (what's in the 24h MRMS *.nc file);
>>>>>>>> compute_precip.pointstatconfig.mrms (my failed attempt at
forcing a
>>>>>>>> change of FCST_VAR to APCP_24) lead to the following err
message
>> when
>>>>>>>> running point_stat:
>>>>>>>>
>>>>>>>> DEBUG 1: Forecast File: mrms24/mrms.2018040112.24h.nc
>>>>>>>> DEBUG 1: Observation File: gauge.nc/good-usa-dlyprcp-
20180401.nc
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2:
>>>>>>>>
>>>>>>>>
>>
--------------------------------------------------------------------------------
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2: Reading data for APCP_24A24.
>>>>>>>> WARNING:
>>>>>>>> WARNING: process_fcst_climo_files() -> no fields matching
APCP_24A24
>>>>>>>> found in file: mrms24/mrms.2018040112.24h.nc
>>>>>>>> WARNING:
>>>>>>>> ERROR :
>>>>>>>> ERROR : process_fcst_climo_files() -> no requested forecast
data
>>>>>>>> found! Exiting...
>>>>>>>> ERROR :
>>>>>>>> + exit
>>>>>>>>
>>>>>>>> Is there a good way change the FCST_VAR in *.stat?
>>>>>>>>
>>>>>>>> Thank you -
>>>>>>>>
>>>>>>>> Ying
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ying Lin
>>>>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>>>>>> NCWCP Cubicle No. 2015
>>>>>>>> Ying.Lin at noaa.gov
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Ying Lin
>>>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>>>> NCWCP Cubicle No. 2015
>>>>>> Ying.Lin at noaa.gov
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Ying Lin
>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>> NCWCP Cubicle No. 2015
>>>> Ying.Lin at noaa.gov
>>>>
>>>>
>>>>
>>>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>
>>
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
------------------------------------------------
More information about the Met_help
mailing list