[Met_help] [rt.rap.ucar.edu #61217] History for MODE threshold question
John Halley Gotway via RT
met_help at ucar.edu
Thu May 16 15:22:12 MDT 2013
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I am not sure whether the "le" command is working for the thresholding /identification of objects. I accept that this is probably not because it doesn't work but due to the incompetence of the user! So far all my efforts have returned one object, namely the entire field, unless I use the "ge" option.
I've attached a sample forecast and analysis grib field and the cfg file.
I know it has to come down to tweaking these thresholds. Any ideas?
Thanks
Marion
====================================================================
fcst_raw_thresh = "le100000.0";
obs_raw_thresh = "le100000.0";
fcst_conv_radius = 1;
obs_conv_radius = 1;
bad_data_thresh = 0.50;
fcst_conv_thresh = "le100000.0";
obs_conv_thresh = "le100000.0";
fcst_area_thresh = "ge0";
obs_area_thresh = "ge0";
fcst_inten_perc = 0;
fcst_inten_perc_thresh = "lt100.0";
obs_inten_perc = 0;
obs_inten_perc_thresh = "lt100.0";
fcst_merge_thresh = "le100000.0";
obs_merge_thresh = "le100000.0";
--
Dr Marion Mittermaier Manager: Model diagnostics and novel verification
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884830 Fax: +44 (0)1392 885681
E-mail: marion.mittermaier at metoffice.gov.uk http://www.metoffice.gov.uk
http://www.metoffice.gov.uk/research/people/marion-mittermaier
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: MODE threshold question
From: John Halley Gotway
Time: Thu May 02 11:00:42 2013
Marion,
Please try the following settings instead:
fcst_raw_thresh = "ge0.0";
obs_raw_thresh = "ge0.0";
fcst_conv_radius = 0;
obs_conv_radius = 0;
fcst_conv_thresh = "le100000.0";
obs_conv_thresh = "le100000.0";
I've attached an image showing the objects created using these
settings. Looks like it's doing what one would expect.
I'm guessing the source of the confusion is the function of the
"fcst_raw_thresh" and "obs_raw_thresh" settings. These should
generally not be changed from their default value of "ge0.0". Kind of
a
long explanation here, but those are used in "pre-processing" the
data. Any values that don't meet those threshold criteria are
replaced with a value of 0.
Why would you ever want to do that? An issue arose in the past when
evaluating radar data for convective forecasts. The forecasts were
for areas of convection >=35 dBZ. However, the observation
contained the full range of reflectivity values - well below 35 dBZ.
So the forecasts contained areas of 35 dBZ surrounded by a bunch of
0's, while the observations contained areas of 35 dBZ
surrounded by a continuous range of values less than 35 dBZ. This
created a problem in the convolution step of MODE. The forecast areas
were much smaller than the observation areas because of being
smoothed with all those 0's. The solution was to redefine the
observation field using this filtering criteria. After the filtering
threshold (>=35dBZ) was applied, both fields contained ares of 35
dBZ surrounded by 0's. Clear as mud?
So you would only use those settings when there is a difference in how
the forecast and observation fields are "defined".
Next, I see that you set the convolution radius to 1. I assume that
means that you don't want to smooth the data at all. Setting it to 0
(as I did above), skips the smoothing step.
Hope that helps.
Thanks,
John
On 05/02/2013 06:39 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> Thu May 02 06:39:37 2013: Request 61217 was acted upon.
> Transaction: Ticket created by marion.mittermaier at metoffice.gov.uk
> Queue: met_help
> Subject: MODE threshold question
> Owner: Nobody
> Requestors: marion.mittermaier at metoffice.gov.uk
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
>
> Hello,
>
> I am not sure whether the "le" command is working for the
thresholding /identification of objects. I accept that this is
probably not because it doesn't work but due to the incompetence of
the user! So far all my efforts have returned one object, namely the
entire field, unless I use the "ge" option.
>
> I've attached a sample forecast and analysis grib field and the cfg
file.
>
> I know it has to come down to tweaking these thresholds. Any ideas?
>
> Thanks
> Marion
> ====================================================================
>
> fcst_raw_thresh = "le100000.0";
> obs_raw_thresh = "le100000.0";
>
> fcst_conv_radius = 1;
> obs_conv_radius = 1;
>
> bad_data_thresh = 0.50;
>
> fcst_conv_thresh = "le100000.0";
> obs_conv_thresh = "le100000.0";
>
> fcst_area_thresh = "ge0";
> obs_area_thresh = "ge0";
>
> fcst_inten_perc = 0;
> fcst_inten_perc_thresh = "lt100.0";
> obs_inten_perc = 0;
> obs_inten_perc_thresh = "lt100.0";
>
> fcst_merge_thresh = "le100000.0";
> obs_merge_thresh = "le100000.0";
>
------------------------------------------------
Subject: MODE threshold question
From: marion.mittermaier at metoffice.gov.uk
Time: Tue May 07 07:40:54 2013
Hello John,
thanks, these threshold do appear to give some objects. However, it
does some to provide a mystery cluster 1 which doesn't appear as a
coloured blob and has an intensity greater than the set threshold.
See the attached ps output file. It would appear as though it is
tagging the whole domain somehow. Any ideas why this is so? I have
found that I can constrain this by using the area criteria and looking
for areas less than a certain threshold. I think this is okay but I
don't want to exclude objects that should be included so I'll have to
look carefully at the threshold.
Marion
--
Dr Marion Mittermaier Manager: Model diagnostics and novel
verification
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884830 Fax: +44 (0)1392 885681
E-mail: marion.mittermaier at metoffice.gov.uk
http://www.metoffice.gov.uk
http://www.metoffice.gov.uk/research/people/marion-mittermaier
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: 02 May 2013 18:01
To: Mittermaier, Marion
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
Marion,
Please try the following settings instead:
fcst_raw_thresh = "ge0.0";
obs_raw_thresh = "ge0.0";
fcst_conv_radius = 0;
obs_conv_radius = 0;
fcst_conv_thresh = "le100000.0";
obs_conv_thresh = "le100000.0";
I've attached an image showing the objects created using these
settings. Looks like it's doing what one would expect.
I'm guessing the source of the confusion is the function of the
"fcst_raw_thresh" and "obs_raw_thresh" settings. These should
generally not be changed from their default value of "ge0.0". Kind of
a long explanation here, but those are used in "pre-processing" the
data. Any values that don't meet those threshold criteria are
replaced with a value of 0.
Why would you ever want to do that? An issue arose in the past when
evaluating radar data for convective forecasts. The forecasts were
for areas of convection >=35 dBZ. However, the observation contained
the full range of reflectivity values - well below 35 dBZ. So the
forecasts contained areas of 35 dBZ surrounded by a bunch of 0's,
while the observations contained areas of 35 dBZ surrounded by a
continuous range of values less than 35 dBZ. This created a problem
in the convolution step of MODE. The forecast areas were much smaller
than the observation areas because of being smoothed with all those
0's. The solution was to redefine the observation field using this
filtering criteria. After the filtering threshold (>=35dBZ) was
applied, both fields contained ares of 35 dBZ surrounded by 0's.
Clear as mud?
So you would only use those settings when there is a difference in how
the forecast and observation fields are "defined".
Next, I see that you set the convolution radius to 1. I assume that
means that you don't want to smooth the data at all. Setting it to 0
(as I did above), skips the smoothing step.
Hope that helps.
Thanks,
John
On 05/02/2013 06:39 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> Thu May 02 06:39:37 2013: Request 61217 was acted upon.
> Transaction: Ticket created by marion.mittermaier at metoffice.gov.uk
> Queue: met_help
> Subject: MODE threshold question
> Owner: Nobody
> Requestors: marion.mittermaier at metoffice.gov.uk
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217
> >
>
>
> Hello,
>
> I am not sure whether the "le" command is working for the
thresholding /identification of objects. I accept that this is
probably not because it doesn't work but due to the incompetence of
the user! So far all my efforts have returned one object, namely the
entire field, unless I use the "ge" option.
>
> I've attached a sample forecast and analysis grib field and the cfg
file.
>
> I know it has to come down to tweaking these thresholds. Any ideas?
>
> Thanks
> Marion
> ====================================================================
>
> fcst_raw_thresh = "le100000.0";
> obs_raw_thresh = "le100000.0";
>
> fcst_conv_radius = 1;
> obs_conv_radius = 1;
>
> bad_data_thresh = 0.50;
>
> fcst_conv_thresh = "le100000.0";
> obs_conv_thresh = "le100000.0";
>
> fcst_area_thresh = "ge0";
> obs_area_thresh = "ge0";
>
> fcst_inten_perc = 0;
> fcst_inten_perc_thresh = "lt100.0";
> obs_inten_perc = 0;
> obs_inten_perc_thresh = "lt100.0";
>
> fcst_merge_thresh = "le100000.0";
> obs_merge_thresh = "le100000.0";
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
From: John Halley Gotway
Time: Tue May 07 10:42:57 2013
Marian,
Ah yes, I see what you're describing. This behavior goes away when
you set the convolution radius to 0 (rather than 1, as you have it
set). It appears there's an issue in the convolution (smoothing)
step when dealing with bad data values. The internal representation
for bad data is -9999. The convolution should be skipping those
values, but based on this behavior, I'm guessing it's not in all
cases. This hasn't come up in the past because we very seldom set use
"less-than" thresholds. For now, I'd suggest using a convolution
radius of 0, and I'll debug this further.
Thanks for finding this issue!
John
On 05/07/2013 07:40 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
> Hello John,
>
> thanks, these threshold do appear to give some objects. However, it
does some to provide a mystery cluster 1 which doesn't appear as a
coloured blob and has an intensity greater than the set threshold.
>
> See the attached ps output file. It would appear as though it is
tagging the whole domain somehow. Any ideas why this is so? I have
found that I can constrain this by using the area criteria and looking
for areas less than a certain threshold. I think this is okay but I
don't want to exclude objects that should be included so I'll have to
look carefully at the threshold.
>
> Marion
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #61217] MODE threshold question
From: marion.mittermaier at metoffice.gov.uk
Time: Tue May 07 11:06:19 2013
Thanks John.
Glad to know I can be of help ;-)
I will give that a go and see where I get to. I am certainly trying to
find MODE's limits with our current diagnostic requirement!
Marion
--
Dr Marion Mittermaier Manager: Model diagnostics and novel
verification
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884830 Fax: +44 (0)1392 885681
E-mail: marion.mittermaier at metoffice.gov.uk
http://www.metoffice.gov.uk
http://www.metoffice.gov.uk/research/people/marion-mittermaier
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: 07 May 2013 17:43
To: Mittermaier, Marion
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
Marian,
Ah yes, I see what you're describing. This behavior goes away when
you set the convolution radius to 0 (rather than 1, as you have it
set). It appears there's an issue in the convolution (smoothing) step
when dealing with bad data values. The internal representation for
bad data is -9999. The convolution should be skipping those values,
but based on this behavior, I'm guessing it's not in all cases. This
hasn't come up in the past because we very seldom set use "less-than"
thresholds. For now, I'd suggest using a convolution radius of 0, and
I'll debug this further.
Thanks for finding this issue!
John
On 05/07/2013 07:40 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
> Hello John,
>
> thanks, these threshold do appear to give some objects. However, it
does some to provide a mystery cluster 1 which doesn't appear as a
coloured blob and has an intensity greater than the set threshold.
>
> See the attached ps output file. It would appear as though it is
tagging the whole domain somehow. Any ideas why this is so? I have
found that I can constrain this by using the area criteria and looking
for areas less than a certain threshold. I think this is okay but I
don't want to exclude objects that should be included so I'll have to
look carefully at the threshold.
>
> Marion
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
From: John Halley Gotway
Time: Tue May 07 11:19:06 2013
Marion,
Good news. This issue can be resolved using a configuration file
setting. Please change the "raw_thresh" settings to ">=-9999" as
follows and this problem will go away:
fcst_raw_thresh = "ge-9999";
obs_raw_thresh = "ge-9999";
When they were set to ">=0", the filtering step saw bad data values of
-9999, and, since they weren't ">=0", they were replaced with a value
of 0. Then those 0's were used in the convolution,
resulting in the odd outline object. Now they will meet that
threshold criteria, and will be preserved.
I'll investigate updating the filtering step to better handle bad data
values.
Thanks,
John
On 05/07/2013 11:06 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
> Thanks John.
>
> Glad to know I can be of help ;-)
>
> I will give that a go and see where I get to. I am certainly trying
to find MODE's limits with our current diagnostic requirement!
>
> Marion
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #61217] MODE threshold question
From: marion.mittermaier at metoffice.gov.uk
Time: Tue May 07 11:40:05 2013
Hi John,
thanks I will amend my config file accordingly.
Marion
--
Dr Marion Mittermaier Manager: Model diagnostics and novel
verification
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884830 Fax: +44 (0)1392 885681
E-mail: marion.mittermaier at metoffice.gov.uk
http://www.metoffice.gov.uk
http://www.metoffice.gov.uk/research/people/marion-mittermaier
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: 07 May 2013 18:19
To: Mittermaier, Marion
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
Marion,
Good news. This issue can be resolved using a configuration file
setting. Please change the "raw_thresh" settings to ">=-9999" as
follows and this problem will go away:
fcst_raw_thresh = "ge-9999";
obs_raw_thresh = "ge-9999";
When they were set to ">=0", the filtering step saw bad data values of
-9999, and, since they weren't ">=0", they were replaced with a value
of 0. Then those 0's were used in the convolution, resulting in the
odd outline object. Now they will meet that threshold criteria, and
will be preserved.
I'll investigate updating the filtering step to better handle bad data
values.
Thanks,
John
On 05/07/2013 11:06 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
> Thanks John.
>
> Glad to know I can be of help ;-)
>
> I will give that a go and see where I get to. I am certainly trying
to find MODE's limits with our current diagnostic requirement!
>
> Marion
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
From: John Halley Gotway
Time: Tue May 07 11:44:52 2013
Marion,
Great. FYI - I did add a fix to the development version so that the
default filtering threshold of ">=0.0" will also work. We had been
failing to check for bad data in the filtering step. Adding
that check in produces the desired behavior. So this change will be
included in the upcoming METv4.1 release.
I'd rather not have to post a bugfix for this for METv3.1 and METv4.0,
but could do so if it'd be helpful to you.
Thanks,
John
On 05/07/2013 11:40 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
> Hi John,
>
> thanks I will amend my config file accordingly.
>
> Marion
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #61217] MODE threshold question
From: marion.mittermaier at metoffice.gov.uk
Time: Tue May 07 11:48:48 2013
Hi John,
no I think I can manage this way. I will wait to download v4.1 when it
is released.
I am busy training up two other colleagues to run/use MODE. At some
point I was planning on getting them to install MODE (rather than use
my build) as well so I will wait until the new version is available.
Marion
--
Dr Marion Mittermaier Manager: Model diagnostics and novel
verification
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884830 Fax: +44 (0)1392 885681
E-mail: marion.mittermaier at metoffice.gov.uk
http://www.metoffice.gov.uk
http://www.metoffice.gov.uk/research/people/marion-mittermaier
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: 07 May 2013 18:45
To: Mittermaier, Marion
Subject: Re: [rt.rap.ucar.edu #61217] MODE threshold question
Marion,
Great. FYI - I did add a fix to the development version so that the
default filtering threshold of ">=0.0" will also work. We had been
failing to check for bad data in the filtering step. Adding that
check in produces the desired behavior. So this change will be
included in the upcoming METv4.1 release.
I'd rather not have to post a bugfix for this for METv3.1 and METv4.0,
but could do so if it'd be helpful to you.
Thanks,
John
On 05/07/2013 11:40 AM, marion.mittermaier at metoffice.gov.uk via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=61217 >
>
> Hi John,
>
> thanks I will amend my config file accordingly.
>
> Marion
>
>
>
------------------------------------------------
More information about the Met_help
mailing list