[Met_help] [rt.rap.ucar.edu #79625] History for MODE discrepancy
John Halley Gotway via RT
met_help at ucar.edu
Fri Mar 3 17:52:30 MST 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
So I ran MODE to verify forecast composite reflectivity where the forecast
file was in GRIB2 and the observations were in netCDF. When I looked at the
postscript file output by MODE, the forecast reflectivity images did not
resemble plots of the forecast reflectivity created through other means,
and the statistical results are therefore not representative of the
forecast itself. I've attached some relevant images to illustrate this.
*mode_compref-1.png* shows what the forecast reflectivity field looks like
in the postscript file.
*00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the forecast
reflectivity field looks like when plotted using other means.
Clearly there is a difference. I tried re-running MODE to see if I made a
syntax error - nope. I tried multiple other sources to view the forecast
composite reflectivity to check if I had made an error with my comparison
image - nope.
There is a warning message when I run MODE that might give some insight
into the problem:
WARNING: Multiple GRIB2 table entries match lookup criteria (parm_name =
REFC):
WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0, grib2_cntr = 7,
grib2_ltab = 1, index_b = 16, index_c = 196
WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1, grib2_cntr = 0,
grib2_ltab = 0, index_b = 16, index_c = 5
WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab = 0, grib2_cntr
= 7, grib2_ltab = 1, index_b = 16, index_c = 196
I wouldn't think this would be an issue, however. Here is the output from
wgrib2 on the forecast file:
1:0:00Z25may2016:REFC Composite reflectivity [dB]:lvl1=(10,0)
lvl2=(255,missing):entire atmosphere:18 hour fcst:
2:1303053:00Z25may2016:APCP Total Precipitation [kg/m^2]:lvl1=(1,0)
lvl2=(255,missing):surface:17-18 hour acc fcst:
3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation (non-convective)
[kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour acc fcst:
So there's only one REFC array. That matches what I have in my configure
file, unless I messed up the level entry:
fcst = {
field = {
name = "REFC";
level = "R2";
}
I have attached the config file for your convenience.
So what is going on here?
Jeff
--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: MODE discrepancy
From: John Halley Gotway
Time: Thu Feb 23 13:40:48 2017
Jeff,
The problem is in how you have the level information set. Setting
'level =
"R2";' tells MODE to extract record number 2 from the GRIB file you're
passing to it. Looking in your wgrib2 output, the 2nd record is APCP,
not
REFC. Since you specified an explicit record number to use, MODE
isn't
using the 'name = "REFC";' setting at all.
I'd suggest using the following instead:
fcst = {
field = {
name = "REFC";
level = "L0";
}
But you can read more about the level settings for GRIB files in the
met-5.2/data/config/README file. If you still want to specify an
explicit
record number for some reason, it should be "R3" for REFC in the 3rd
GRIB
record.
Try turning up the verbosity level of MODE a bit (-v 4) and it should
dump
out some info about the GRIB record number its actually reading.
Hopefully that solves the issue. If not, please let me know.
Thanks,
John
On Thu, Feb 23, 2017 at 12:55 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:
>
> Thu Feb 23 12:55:31 2017: Request 79625 was acted upon.
> Transaction: Ticket created by jeffduda319 at gmail.com
> Queue: met_help
> Subject: MODE discrepancy
> Owner: Nobody
> Requestors: jeffduda319 at gmail.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
>
>
> So I ran MODE to verify forecast composite reflectivity where the
forecast
> file was in GRIB2 and the observations were in netCDF. When I looked
at the
> postscript file output by MODE, the forecast reflectivity images did
not
> resemble plots of the forecast reflectivity created through other
means,
> and the statistical results are therefore not representative of the
> forecast itself. I've attached some relevant images to illustrate
this.
>
> *mode_compref-1.png* shows what the forecast reflectivity field
looks like
> in the postscript file.
> *00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the forecast
> reflectivity field looks like when plotted using other means.
>
> Clearly there is a difference. I tried re-running MODE to see if I
made a
> syntax error - nope. I tried multiple other sources to view the
forecast
> composite reflectivity to check if I had made an error with my
comparison
> image - nope.
>
> There is a warning message when I run MODE that might give some
insight
> into the problem:
> WARNING: Multiple GRIB2 table entries match lookup criteria
(parm_name =
> REFC):
> WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0, grib2_cntr
= 7,
> grib2_ltab = 1, index_b = 16, index_c = 196
> WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1, grib2_cntr
= 0,
> grib2_ltab = 0, index_b = 16, index_c = 5
> WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab = 0,
grib2_cntr
> = 7, grib2_ltab = 1, index_b = 16, index_c = 196
>
> I wouldn't think this would be an issue, however. Here is the output
from
> wgrib2 on the forecast file:
> 1:0:00Z25may2016:REFC Composite reflectivity [dB]:lvl1=(10,0)
> lvl2=(255,missing):entire atmosphere:18 hour fcst:
> 2:1303053:00Z25may2016:APCP Total Precipitation [kg/m^2]:lvl1=(1,0)
> lvl2=(255,missing):surface:17-18 hour acc fcst:
> 3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation (non-
convective)
> [kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour acc fcst:
>
> So there's only one REFC array. That matches what I have in my
configure
> file, unless I messed up the level entry:
> fcst = {
> field = {
> name = "REFC";
> level = "R2";
> }
>
> I have attached the config file for your convenience.
>
> So what is going on here?
>
> Jeff
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>
------------------------------------------------
Subject: MODE discrepancy
From: Jeff Duda
Time: Thu Feb 23 13:52:13 2017
OOPS! I see why I missed that now. The "010000A" portion of the output
file
name should have given it away, but I was testing on forecast hour 00
output this whole time, so I was getting something I was expecting to
see,
even though it was still technically wrong. Thanks.
Jeff
On Thu, Feb 23, 2017 at 2:40 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jeff,
>
> The problem is in how you have the level information set. Setting
'level =
> "R2";' tells MODE to extract record number 2 from the GRIB file
you're
> passing to it. Looking in your wgrib2 output, the 2nd record is
APCP, not
> REFC. Since you specified an explicit record number to use, MODE
isn't
> using the 'name = "REFC";' setting at all.
>
> I'd suggest using the following instead:
> fcst = {
> field = {
> name = "REFC";
> level = "L0";
> }
>
> But you can read more about the level settings for GRIB files in the
> met-5.2/data/config/README file. If you still want to specify an
explicit
> record number for some reason, it should be "R3" for REFC in the 3rd
GRIB
> record.
>
> Try turning up the verbosity level of MODE a bit (-v 4) and it
should dump
> out some info about the GRIB record number its actually reading.
>
> Hopefully that solves the issue. If not, please let me know.
>
> Thanks,
> John
>
> On Thu, Feb 23, 2017 at 12:55 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Thu Feb 23 12:55:31 2017: Request 79625 was acted upon.
> > Transaction: Ticket created by jeffduda319 at gmail.com
> > Queue: met_help
> > Subject: MODE discrepancy
> > Owner: Nobody
> > Requestors: jeffduda319 at gmail.com
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
> >
> >
> > So I ran MODE to verify forecast composite reflectivity where the
> forecast
> > file was in GRIB2 and the observations were in netCDF. When I
looked at
> the
> > postscript file output by MODE, the forecast reflectivity images
did not
> > resemble plots of the forecast reflectivity created through other
means,
> > and the statistical results are therefore not representative of
the
> > forecast itself. I've attached some relevant images to illustrate
this.
> >
> > *mode_compref-1.png* shows what the forecast reflectivity field
looks
> like
> > in the postscript file.
> > *00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the forecast
> > reflectivity field looks like when plotted using other means.
> >
> > Clearly there is a difference. I tried re-running MODE to see if I
made a
> > syntax error - nope. I tried multiple other sources to view the
forecast
> > composite reflectivity to check if I had made an error with my
comparison
> > image - nope.
> >
> > There is a warning message when I run MODE that might give some
insight
> > into the problem:
> > WARNING: Multiple GRIB2 table entries match lookup criteria
(parm_name =
> > REFC):
> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0,
grib2_cntr = 7,
> > grib2_ltab = 1, index_b = 16, index_c = 196
> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1,
grib2_cntr = 0,
> > grib2_ltab = 0, index_b = 16, index_c = 5
> > WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab = 0,
> grib2_cntr
> > = 7, grib2_ltab = 1, index_b = 16, index_c = 196
> >
> > I wouldn't think this would be an issue, however. Here is the
output from
> > wgrib2 on the forecast file:
> > 1:0:00Z25may2016:REFC Composite reflectivity [dB]:lvl1=(10,0)
> > lvl2=(255,missing):entire atmosphere:18 hour fcst:
> > 2:1303053:00Z25may2016:APCP Total Precipitation
[kg/m^2]:lvl1=(1,0)
> > lvl2=(255,missing):surface:17-18 hour acc fcst:
> > 3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation (non-
convective)
> > [kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour acc
fcst:
> >
> > So there's only one REFC array. That matches what I have in my
configure
> > file, unless I messed up the level entry:
> > fcst = {
> > field = {
> > name = "REFC";
> > level = "R2";
> > }
> >
> > I have attached the config file for your convenience.
> >
> > So what is going on here?
> >
> > Jeff
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>
--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology
------------------------------------------------
Subject: MODE discrepancy
From: Jeff Duda
Time: Thu Feb 23 13:55:35 2017
John,
While I have your attention (again!) could you clear up another thing
for
me? What is "AREA_THRESH" in the ASCII output supposed to represent?
It
mentions a "filtered" field. Is that referring to F in the equation at
the
bottom of page 191 of the User's Guide (also panel d of figure 14.1)?
If
so, then how does that differ from "AREA"?
Jeff
On Thu, Feb 23, 2017 at 2:52 PM, Jeff Duda <jeffduda319 at gmail.com>
wrote:
> OOPS! I see why I missed that now. The "010000A" portion of the
output
> file name should have given it away, but I was testing on forecast
hour 00
> output this whole time, so I was getting something I was expecting
to see,
> even though it was still technically wrong. Thanks.
>
> Jeff
>
> On Thu, Feb 23, 2017 at 2:40 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> The problem is in how you have the level information set. Setting
'level
>> =
>> "R2";' tells MODE to extract record number 2 from the GRIB file
you're
>> passing to it. Looking in your wgrib2 output, the 2nd record is
APCP, not
>> REFC. Since you specified an explicit record number to use, MODE
isn't
>> using the 'name = "REFC";' setting at all.
>>
>> I'd suggest using the following instead:
>> fcst = {
>> field = {
>> name = "REFC";
>> level = "L0";
>> }
>>
>> But you can read more about the level settings for GRIB files in
the
>> met-5.2/data/config/README file. If you still want to specify an
explicit
>> record number for some reason, it should be "R3" for REFC in the
3rd GRIB
>> record.
>>
>> Try turning up the verbosity level of MODE a bit (-v 4) and it
should dump
>> out some info about the GRIB record number its actually reading.
>>
>> Hopefully that solves the issue. If not, please let me know.
>>
>> Thanks,
>> John
>>
>> On Thu, Feb 23, 2017 at 12:55 PM, Jeff Duda via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > Thu Feb 23 12:55:31 2017: Request 79625 was acted upon.
>> > Transaction: Ticket created by jeffduda319 at gmail.com
>> > Queue: met_help
>> > Subject: MODE discrepancy
>> > Owner: Nobody
>> > Requestors: jeffduda319 at gmail.com
>> > Status: new
>> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
>> >
>> >
>> > So I ran MODE to verify forecast composite reflectivity where the
>> forecast
>> > file was in GRIB2 and the observations were in netCDF. When I
looked at
>> the
>> > postscript file output by MODE, the forecast reflectivity images
did not
>> > resemble plots of the forecast reflectivity created through other
means,
>> > and the statistical results are therefore not representative of
the
>> > forecast itself. I've attached some relevant images to illustrate
this.
>> >
>> > *mode_compref-1.png* shows what the forecast reflectivity field
looks
>> like
>> > in the postscript file.
>> > *00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the forecast
>> > reflectivity field looks like when plotted using other means.
>> >
>> > Clearly there is a difference. I tried re-running MODE to see if
I made
>> a
>> > syntax error - nope. I tried multiple other sources to view the
forecast
>> > composite reflectivity to check if I had made an error with my
>> comparison
>> > image - nope.
>> >
>> > There is a warning message when I run MODE that might give some
insight
>> > into the problem:
>> > WARNING: Multiple GRIB2 table entries match lookup criteria
(parm_name =
>> > REFC):
>> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0,
grib2_cntr = 7,
>> > grib2_ltab = 1, index_b = 16, index_c = 196
>> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1,
grib2_cntr = 0,
>> > grib2_ltab = 0, index_b = 16, index_c = 5
>> > WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab = 0,
>> grib2_cntr
>> > = 7, grib2_ltab = 1, index_b = 16, index_c = 196
>> >
>> > I wouldn't think this would be an issue, however. Here is the
output
>> from
>> > wgrib2 on the forecast file:
>> > 1:0:00Z25may2016:REFC Composite reflectivity [dB]:lvl1=(10,0)
>> > lvl2=(255,missing):entire atmosphere:18 hour fcst:
>> > 2:1303053:00Z25may2016:APCP Total Precipitation
[kg/m^2]:lvl1=(1,0)
>> > lvl2=(255,missing):surface:17-18 hour acc fcst:
>> > 3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation (non-
convective)
>> > [kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour acc
fcst:
>> >
>> > So there's only one REFC array. That matches what I have in my
configure
>> > file, unless I messed up the level entry:
>> > fcst = {
>> > field = {
>> > name = "REFC";
>> > level = "R2";
>> > }
>> >
>> > I have attached the config file for your convenience.
>> >
>> > So what is going on here?
>> >
>> > Jeff
>> >
>> > --
>> > Jeff Duda
>> > Post-doctoral research fellow
>> > University of Oklahoma School of Meteorology
>> >
>> >
>>
>>
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology
------------------------------------------------
Subject: MODE discrepancy
From: John Halley Gotway
Time: Thu Feb 23 14:02:27 2017
Jeff,
The AREA of an object is a count of the number of grid points which
fall
inside that object.
The AREA_THRESH of an object is a count of the number of grid points
inside
an object at which the raw input value meets the object definition
threshold criteria.
The convolution radius defines the amount of smoothing applied to the
raw
data. If you have a value of 10 next to a value of 0, the smoothed
value
at the 0 grid point might end up being 5. If you define objects with
a
threshold >4, then both of those two points are counted in the AREA
but
only one with the raw value of 10 would be counted in AREA_THRESH. So
basically, the more smoothing you do, the greater the discrepancy
between
AREA and AREA_THRESH. Or if you set the convolution radius = 0, then
AREA
= AREA_THRESH.
Make sense?
If realize the documentation says "filtered field" and that's
technically
correct. But that only matters if you set the "raw_thresh" to
something
other than NA.
Thanks,
John
On Thu, Feb 23, 2017 at 1:55 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
>
> John,
> While I have your attention (again!) could you clear up another
thing for
> me? What is "AREA_THRESH" in the ASCII output supposed to represent?
It
> mentions a "filtered" field. Is that referring to F in the equation
at the
> bottom of page 191 of the User's Guide (also panel d of figure
14.1)? If
> so, then how does that differ from "AREA"?
>
> Jeff
>
> On Thu, Feb 23, 2017 at 2:52 PM, Jeff Duda <jeffduda319 at gmail.com>
wrote:
>
> > OOPS! I see why I missed that now. The "010000A" portion of the
output
> > file name should have given it away, but I was testing on forecast
hour
> 00
> > output this whole time, so I was getting something I was expecting
to
> see,
> > even though it was still technically wrong. Thanks.
> >
> > Jeff
> >
> > On Thu, Feb 23, 2017 at 2:40 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jeff,
> >>
> >> The problem is in how you have the level information set.
Setting
> 'level
> >> =
> >> "R2";' tells MODE to extract record number 2 from the GRIB file
you're
> >> passing to it. Looking in your wgrib2 output, the 2nd record is
APCP,
> not
> >> REFC. Since you specified an explicit record number to use, MODE
isn't
> >> using the 'name = "REFC";' setting at all.
> >>
> >> I'd suggest using the following instead:
> >> fcst = {
> >> field = {
> >> name = "REFC";
> >> level = "L0";
> >> }
> >>
> >> But you can read more about the level settings for GRIB files in
the
> >> met-5.2/data/config/README file. If you still want to specify an
> explicit
> >> record number for some reason, it should be "R3" for REFC in the
3rd
> GRIB
> >> record.
> >>
> >> Try turning up the verbosity level of MODE a bit (-v 4) and it
should
> dump
> >> out some info about the GRIB record number its actually reading.
> >>
> >> Hopefully that solves the issue. If not, please let me know.
> >>
> >> Thanks,
> >> John
> >>
> >> On Thu, Feb 23, 2017 at 12:55 PM, Jeff Duda via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > Thu Feb 23 12:55:31 2017: Request 79625 was acted upon.
> >> > Transaction: Ticket created by jeffduda319 at gmail.com
> >> > Queue: met_help
> >> > Subject: MODE discrepancy
> >> > Owner: Nobody
> >> > Requestors: jeffduda319 at gmail.com
> >> > Status: new
> >> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625
> >
> >> >
> >> >
> >> > So I ran MODE to verify forecast composite reflectivity where
the
> >> forecast
> >> > file was in GRIB2 and the observations were in netCDF. When I
looked
> at
> >> the
> >> > postscript file output by MODE, the forecast reflectivity
images did
> not
> >> > resemble plots of the forecast reflectivity created through
other
> means,
> >> > and the statistical results are therefore not representative of
the
> >> > forecast itself. I've attached some relevant images to
illustrate
> this.
> >> >
> >> > *mode_compref-1.png* shows what the forecast reflectivity field
looks
> >> like
> >> > in the postscript file.
> >> > *00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the
forecast
> >> > reflectivity field looks like when plotted using other means.
> >> >
> >> > Clearly there is a difference. I tried re-running MODE to see
if I
> made
> >> a
> >> > syntax error - nope. I tried multiple other sources to view the
> forecast
> >> > composite reflectivity to check if I had made an error with my
> >> comparison
> >> > image - nope.
> >> >
> >> > There is a warning message when I run MODE that might give some
> insight
> >> > into the problem:
> >> > WARNING: Multiple GRIB2 table entries match lookup criteria
> (parm_name =
> >> > REFC):
> >> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0,
grib2_cntr =
> 7,
> >> > grib2_ltab = 1, index_b = 16, index_c = 196
> >> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1,
grib2_cntr =
> 0,
> >> > grib2_ltab = 0, index_b = 16, index_c = 5
> >> > WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab = 0,
> >> grib2_cntr
> >> > = 7, grib2_ltab = 1, index_b = 16, index_c = 196
> >> >
> >> > I wouldn't think this would be an issue, however. Here is the
output
> >> from
> >> > wgrib2 on the forecast file:
> >> > 1:0:00Z25may2016:REFC Composite reflectivity [dB]:lvl1=(10,0)
> >> > lvl2=(255,missing):entire atmosphere:18 hour fcst:
> >> > 2:1303053:00Z25may2016:APCP Total Precipitation
[kg/m^2]:lvl1=(1,0)
> >> > lvl2=(255,missing):surface:17-18 hour acc fcst:
> >> > 3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation
> (non-convective)
> >> > [kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour acc
fcst:
> >> >
> >> > So there's only one REFC array. That matches what I have in my
> configure
> >> > file, unless I messed up the level entry:
> >> > fcst = {
> >> > field = {
> >> > name = "REFC";
> >> > level = "R2";
> >> > }
> >> >
> >> > I have attached the config file for your convenience.
> >> >
> >> > So what is going on here?
> >> >
> >> > Jeff
> >> >
> >> > --
> >> > Jeff Duda
> >> > Post-doctoral research fellow
> >> > University of Oklahoma School of Meteorology
> >> >
> >> >
> >>
> >>
> >
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
>
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>
------------------------------------------------
Subject: MODE discrepancy
From: Jeff Duda
Time: Thu Feb 23 16:10:35 2017
John,
So let me see if I understand this correctly by paraphrasing. Here
we're
assuming raw_thresh = NA.
An object is defined by whether or not grid points in the *convolved
*field
exceed conv_thresh, the convolution threshold. Once the values in the
raw
field are returned to the masked area defined by the convolved field,
AREA_THRESH is then meant to describe the area *within an object that
has
already been defined from the convolved field *in which the value of
the
*raw* field *also* exceeded conv_thresh (i.e., there's no separate
threshold for the raw field, just one that is used first on the
convolved
field, then on the raw field after objects have already been defined).
Regarding AREA_FILTER: if, when returning the raw field values to the
masked area defined by the convolved field there are grid points
within an
object that the raw field values happen to be missing or 0.0 or some
background value below conv_thresh, and those are then excluded from
the
area calculation. Is this right?
If I have this right, then
AREA >= AREA_THRESH and
AREA >= AREA_FILTER
should both always be true statements. Would it also be true that
AREA_THRESH <= AREA_FILTER always, since AREA_FILTER only excludes
data
points where the raw field was 0.0 (or missing), and AREA_THRESH would
exclude those same points *plus* additional raw field points that did
not
exceed conv_thresh?
Jeff
On Thu, Feb 23, 2017 at 3:02 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jeff,
>
> The AREA of an object is a count of the number of grid points which
fall
> inside that object.
>
> The AREA_THRESH of an object is a count of the number of grid points
inside
> an object at which the raw input value meets the object definition
> threshold criteria.
>
> The convolution radius defines the amount of smoothing applied to
the raw
> data. If you have a value of 10 next to a value of 0, the smoothed
value
> at the 0 grid point might end up being 5. If you define objects
with a
> threshold >4, then both of those two points are counted in the AREA
but
> only one with the raw value of 10 would be counted in AREA_THRESH.
So
> basically, the more smoothing you do, the greater the discrepancy
between
> AREA and AREA_THRESH. Or if you set the convolution radius = 0,
then AREA
> = AREA_THRESH.
>
> Make sense?
>
> If realize the documentation says "filtered field" and that's
technically
> correct. But that only matters if you set the "raw_thresh" to
something
> other than NA.
>
> Thanks,
> John
>
> On Thu, Feb 23, 2017 at 1:55 PM, Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
> >
> > John,
> > While I have your attention (again!) could you clear up another
thing for
> > me? What is "AREA_THRESH" in the ASCII output supposed to
represent? It
> > mentions a "filtered" field. Is that referring to F in the
equation at
> the
> > bottom of page 191 of the User's Guide (also panel d of figure
14.1)? If
> > so, then how does that differ from "AREA"?
> >
> > Jeff
> >
> > On Thu, Feb 23, 2017 at 2:52 PM, Jeff Duda <jeffduda319 at gmail.com>
> wrote:
> >
> > > OOPS! I see why I missed that now. The "010000A" portion of the
output
> > > file name should have given it away, but I was testing on
forecast hour
> > 00
> > > output this whole time, so I was getting something I was
expecting to
> > see,
> > > even though it was still technically wrong. Thanks.
> > >
> > > Jeff
> > >
> > > On Thu, Feb 23, 2017 at 2:40 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jeff,
> > >>
> > >> The problem is in how you have the level information set.
Setting
> > 'level
> > >> =
> > >> "R2";' tells MODE to extract record number 2 from the GRIB file
you're
> > >> passing to it. Looking in your wgrib2 output, the 2nd record
is APCP,
> > not
> > >> REFC. Since you specified an explicit record number to use,
MODE
> isn't
> > >> using the 'name = "REFC";' setting at all.
> > >>
> > >> I'd suggest using the following instead:
> > >> fcst = {
> > >> field = {
> > >> name = "REFC";
> > >> level = "L0";
> > >> }
> > >>
> > >> But you can read more about the level settings for GRIB files
in the
> > >> met-5.2/data/config/README file. If you still want to specify
an
> > explicit
> > >> record number for some reason, it should be "R3" for REFC in
the 3rd
> > GRIB
> > >> record.
> > >>
> > >> Try turning up the verbosity level of MODE a bit (-v 4) and it
should
> > dump
> > >> out some info about the GRIB record number its actually
reading.
> > >>
> > >> Hopefully that solves the issue. If not, please let me know.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Thu, Feb 23, 2017 at 12:55 PM, Jeff Duda via RT
<met_help at ucar.edu
> >
> > >> wrote:
> > >>
> > >> >
> > >> > Thu Feb 23 12:55:31 2017: Request 79625 was acted upon.
> > >> > Transaction: Ticket created by jeffduda319 at gmail.com
> > >> > Queue: met_help
> > >> > Subject: MODE discrepancy
> > >> > Owner: Nobody
> > >> > Requestors: jeffduda319 at gmail.com
> > >> > Status: new
> > >> > Ticket <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=79625
> > >
> > >> >
> > >> >
> > >> > So I ran MODE to verify forecast composite reflectivity where
the
> > >> forecast
> > >> > file was in GRIB2 and the observations were in netCDF. When I
looked
> > at
> > >> the
> > >> > postscript file output by MODE, the forecast reflectivity
images did
> > not
> > >> > resemble plots of the forecast reflectivity created through
other
> > means,
> > >> > and the statistical results are therefore not representative
of the
> > >> > forecast itself. I've attached some relevant images to
illustrate
> > this.
> > >> >
> > >> > *mode_compref-1.png* shows what the forecast reflectivity
field
> looks
> > >> like
> > >> > in the postscript file.
> > >> > *00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the
forecast
> > >> > reflectivity field looks like when plotted using other means.
> > >> >
> > >> > Clearly there is a difference. I tried re-running MODE to see
if I
> > made
> > >> a
> > >> > syntax error - nope. I tried multiple other sources to view
the
> > forecast
> > >> > composite reflectivity to check if I had made an error with
my
> > >> comparison
> > >> > image - nope.
> > >> >
> > >> > There is a warning message when I run MODE that might give
some
> > insight
> > >> > into the problem:
> > >> > WARNING: Multiple GRIB2 table entries match lookup criteria
> > (parm_name =
> > >> > REFC):
> > >> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0,
grib2_cntr
> =
> > 7,
> > >> > grib2_ltab = 1, index_b = 16, index_c = 196
> > >> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1,
grib2_cntr
> =
> > 0,
> > >> > grib2_ltab = 0, index_b = 16, index_c = 5
> > >> > WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab =
0,
> > >> grib2_cntr
> > >> > = 7, grib2_ltab = 1, index_b = 16, index_c = 196
> > >> >
> > >> > I wouldn't think this would be an issue, however. Here is the
output
> > >> from
> > >> > wgrib2 on the forecast file:
> > >> > 1:0:00Z25may2016:REFC Composite reflectivity [dB]:lvl1=(10,0)
> > >> > lvl2=(255,missing):entire atmosphere:18 hour fcst:
> > >> > 2:1303053:00Z25may2016:APCP Total Precipitation
[kg/m^2]:lvl1=(1,0)
> > >> > lvl2=(255,missing):surface:17-18 hour acc fcst:
> > >> > 3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation
> > (non-convective)
> > >> > [kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour acc
fcst:
> > >> >
> > >> > So there's only one REFC array. That matches what I have in
my
> > configure
> > >> > file, unless I messed up the level entry:
> > >> > fcst = {
> > >> > field = {
> > >> > name = "REFC";
> > >> > level = "R2";
> > >> > }
> > >> >
> > >> > I have attached the config file for your convenience.
> > >> >
> > >> > So what is going on here?
> > >> >
> > >> > Jeff
> > >> >
> > >> > --
> > >> > Jeff Duda
> > >> > Post-doctoral research fellow
> > >> > University of Oklahoma School of Meteorology
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> >
> >
> >
> > --
> > Jeff Duda
> > Post-doctoral research fellow
> > University of Oklahoma School of Meteorology
> >
> >
>
>
--
Jeff Duda
Post-doctoral research fellow
University of Oklahoma School of Meteorology
------------------------------------------------
Subject: MODE discrepancy
From: John Halley Gotway
Time: Fri Feb 24 15:35:08 2017
Jeff,
That logic all looks pretty good to me. Here's a selection from of
code
from met-5.2/src/libcode/vx_shapedata/interest.cc where these areas
are
computed. I'm thinking the comments from the code may clarify:
230 //
231 // Object area
232 //
233 area = Mask->area();
234
235 //
236 // Object filtered area: the area of the raw field inside
the
mask
237 // area that is non-zero
238 //
239 area_filter = (double) ShapeData_intersection(*Raw, *Mask);
240
241 //
242 // Object threshold area: the area of the raw field inside
the
mask
243 // area that meets the threshold criteria
244 //
245 area_thresh = (double) ShapeData_intersection(*Thresh,
*Mask);
AREA = # grid points where convolved value meets the threshold
criteria.
AREA_FILTER = # grid points inside object where value > 0
AREA_THRESH = # grid points inside the object where the threshold
criteria
is met
Defining AREA_FILTER as the number of non-zero grid points is a result
of
MODE being developed on precip data, where 0 is the lower bound.
However,
when you apply MODE other fields, like temperature in Kelvin, 0
becomes
much less meaningful.
Thanks,
John
On Thu, Feb 23, 2017 at 4:10 PM, Jeff Duda via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
>
> John,
> So let me see if I understand this correctly by paraphrasing. Here
we're
> assuming raw_thresh = NA.
>
> An object is defined by whether or not grid points in the *convolved
*field
> exceed conv_thresh, the convolution threshold. Once the values in
the raw
> field are returned to the masked area defined by the convolved
field,
> AREA_THRESH is then meant to describe the area *within an object
that has
> already been defined from the convolved field *in which the value of
the
> *raw* field *also* exceeded conv_thresh (i.e., there's no separate
> threshold for the raw field, just one that is used first on the
convolved
> field, then on the raw field after objects have already been
defined).
>
> Regarding AREA_FILTER: if, when returning the raw field values to
the
> masked area defined by the convolved field there are grid points
within an
> object that the raw field values happen to be missing or 0.0 or some
> background value below conv_thresh, and those are then excluded from
the
> area calculation. Is this right?
>
> If I have this right, then
> AREA >= AREA_THRESH and
> AREA >= AREA_FILTER
> should both always be true statements. Would it also be true that
> AREA_THRESH <= AREA_FILTER always, since AREA_FILTER only excludes
data
> points where the raw field was 0.0 (or missing), and AREA_THRESH
would
> exclude those same points *plus* additional raw field points that
did not
> exceed conv_thresh?
>
> Jeff
>
> On Thu, Feb 23, 2017 at 3:02 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > The AREA of an object is a count of the number of grid points
which fall
> > inside that object.
> >
> > The AREA_THRESH of an object is a count of the number of grid
points
> inside
> > an object at which the raw input value meets the object definition
> > threshold criteria.
> >
> > The convolution radius defines the amount of smoothing applied to
the raw
> > data. If you have a value of 10 next to a value of 0, the
smoothed value
> > at the 0 grid point might end up being 5. If you define objects
with a
> > threshold >4, then both of those two points are counted in the
AREA but
> > only one with the raw value of 10 would be counted in AREA_THRESH.
So
> > basically, the more smoothing you do, the greater the discrepancy
between
> > AREA and AREA_THRESH. Or if you set the convolution radius = 0,
then
> AREA
> > = AREA_THRESH.
> >
> > Make sense?
> >
> > If realize the documentation says "filtered field" and that's
technically
> > correct. But that only matters if you set the "raw_thresh" to
something
> > other than NA.
> >
> > Thanks,
> > John
> >
> > On Thu, Feb 23, 2017 at 1:55 PM, Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79625 >
> > >
> > > John,
> > > While I have your attention (again!) could you clear up another
thing
> for
> > > me? What is "AREA_THRESH" in the ASCII output supposed to
represent? It
> > > mentions a "filtered" field. Is that referring to F in the
equation at
> > the
> > > bottom of page 191 of the User's Guide (also panel d of figure
14.1)?
> If
> > > so, then how does that differ from "AREA"?
> > >
> > > Jeff
> > >
> > > On Thu, Feb 23, 2017 at 2:52 PM, Jeff Duda
<jeffduda319 at gmail.com>
> > wrote:
> > >
> > > > OOPS! I see why I missed that now. The "010000A" portion of
the
> output
> > > > file name should have given it away, but I was testing on
forecast
> hour
> > > 00
> > > > output this whole time, so I was getting something I was
expecting to
> > > see,
> > > > even though it was still technically wrong. Thanks.
> > > >
> > > > Jeff
> > > >
> > > > On Thu, Feb 23, 2017 at 2:40 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Jeff,
> > > >>
> > > >> The problem is in how you have the level information set.
Setting
> > > 'level
> > > >> =
> > > >> "R2";' tells MODE to extract record number 2 from the GRIB
file
> you're
> > > >> passing to it. Looking in your wgrib2 output, the 2nd record
is
> APCP,
> > > not
> > > >> REFC. Since you specified an explicit record number to use,
MODE
> > isn't
> > > >> using the 'name = "REFC";' setting at all.
> > > >>
> > > >> I'd suggest using the following instead:
> > > >> fcst = {
> > > >> field = {
> > > >> name = "REFC";
> > > >> level = "L0";
> > > >> }
> > > >>
> > > >> But you can read more about the level settings for GRIB files
in the
> > > >> met-5.2/data/config/README file. If you still want to
specify an
> > > explicit
> > > >> record number for some reason, it should be "R3" for REFC in
the 3rd
> > > GRIB
> > > >> record.
> > > >>
> > > >> Try turning up the verbosity level of MODE a bit (-v 4) and
it
> should
> > > dump
> > > >> out some info about the GRIB record number its actually
reading.
> > > >>
> > > >> Hopefully that solves the issue. If not, please let me know.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Thu, Feb 23, 2017 at 12:55 PM, Jeff Duda via RT <
> met_help at ucar.edu
> > >
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > Thu Feb 23 12:55:31 2017: Request 79625 was acted upon.
> > > >> > Transaction: Ticket created by jeffduda319 at gmail.com
> > > >> > Queue: met_help
> > > >> > Subject: MODE discrepancy
> > > >> > Owner: Nobody
> > > >> > Requestors: jeffduda319 at gmail.com
> > > >> > Status: new
> > > >> > Ticket <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=79625
> > > >
> > > >> >
> > > >> >
> > > >> > So I ran MODE to verify forecast composite reflectivity
where the
> > > >> forecast
> > > >> > file was in GRIB2 and the observations were in netCDF. When
I
> looked
> > > at
> > > >> the
> > > >> > postscript file output by MODE, the forecast reflectivity
images
> did
> > > not
> > > >> > resemble plots of the forecast reflectivity created through
other
> > > means,
> > > >> > and the statistical results are therefore not
representative of
> the
> > > >> > forecast itself. I've attached some relevant images to
illustrate
> > > this.
> > > >> >
> > > >> > *mode_compref-1.png* shows what the forecast reflectivity
field
> > looks
> > > >> like
> > > >> > in the postscript file.
> > > >> > *00Z_NMMB_EnKF_free_compref_wobs_f18.png* shows what the
forecast
> > > >> > reflectivity field looks like when plotted using other
means.
> > > >> >
> > > >> > Clearly there is a difference. I tried re-running MODE to
see if I
> > > made
> > > >> a
> > > >> > syntax error - nope. I tried multiple other sources to view
the
> > > forecast
> > > >> > composite reflectivity to check if I had made an error with
my
> > > >> comparison
> > > >> > image - nope.
> > > >> >
> > > >> > There is a warning message when I run MODE that might give
some
> > > insight
> > > >> > into the problem:
> > > >> > WARNING: Multiple GRIB2 table entries match lookup criteria
> > > (parm_name =
> > > >> > REFC):
> > > >> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 0,
> grib2_cntr
> > =
> > > 7,
> > > >> > grib2_ltab = 1, index_b = 16, index_c = 196
> > > >> > WARNING: parm_name: REFC, index_a = 0, grib2_mtab = 1,
> grib2_cntr
> > =
> > > 0,
> > > >> > grib2_ltab = 0, index_b = 16, index_c = 5
> > > >> > WARNING: Using: parm_name: REFC, index_a = 0, grib2_mtab
= 0,
> > > >> grib2_cntr
> > > >> > = 7, grib2_ltab = 1, index_b = 16, index_c = 196
> > > >> >
> > > >> > I wouldn't think this would be an issue, however. Here is
the
> output
> > > >> from
> > > >> > wgrib2 on the forecast file:
> > > >> > 1:0:00Z25may2016:REFC Composite reflectivity
[dB]:lvl1=(10,0)
> > > >> > lvl2=(255,missing):entire atmosphere:18 hour fcst:
> > > >> > 2:1303053:00Z25may2016:APCP Total Precipitation
> [kg/m^2]:lvl1=(1,0)
> > > >> > lvl2=(255,missing):surface:17-18 hour acc fcst:
> > > >> > 3:1618407:00Z25may2016:NCPCP Large-Scale Precipitation
> > > (non-convective)
> > > >> > [kg/m^2]:lvl1=(1,0) lvl2=(255,missing):surface:17-18 hour
acc
> fcst:
> > > >> >
> > > >> > So there's only one REFC array. That matches what I have in
my
> > > configure
> > > >> > file, unless I messed up the level entry:
> > > >> > fcst = {
> > > >> > field = {
> > > >> > name = "REFC";
> > > >> > level = "R2";
> > > >> > }
> > > >> >
> > > >> > I have attached the config file for your convenience.
> > > >> >
> > > >> > So what is going on here?
> > > >> >
> > > >> > Jeff
> > > >> >
> > > >> > --
> > > >> > Jeff Duda
> > > >> > Post-doctoral research fellow
> > > >> > University of Oklahoma School of Meteorology
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Jeff Duda
> > > > Post-doctoral research fellow
> > > > University of Oklahoma School of Meteorology
> > > >
> > >
> > >
> > >
> > > --
> > > Jeff Duda
> > > Post-doctoral research fellow
> > > University of Oklahoma School of Meteorology
> > >
> > >
> >
> >
>
>
> --
> Jeff Duda
> Post-doctoral research fellow
> University of Oklahoma School of Meteorology
>
>
------------------------------------------------
More information about the Met_help
mailing list