[Met_help] [rt.rap.ucar.edu #60718] History for Question about MODE tool
John Halley Gotway via RT
met_help at ucar.edu
Tue Mar 26 09:56:38 MDT 2013
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I have a question about the MODE tool. I am trying to get the total coverage area of objects on the grid (for the fcst and obs fields).
The .ps output file given by MODE gives me this information on the first page.
When I use the Netcdf output file (.nc) to get the same information, by counting the number of grid-points with values for the variables fcst_obj_id and obs_obj_id, I get different values (usually greater than the one found in the .ps file)...
I'm wondering why these values are different?
I know that In the documentation, you wrote this statement: "The object colors plotted by ncview will generally not correspond to those in MODE's PostScript output", but I don't understand why...
Which value is the right one?
Best regards,
Michael Jr. Powers
Météorologue | Meteorologist
Centre de Prévision des Intempéries du Québec | Quebec Storm Prediction Center
SMC - Environnement Canada | MSC - Environment Canada
Téléphone | Telephone: 514-283-9904
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60718] Question about MODE tool
From: John Halley Gotway
Time: Wed Mar 20 14:55:52 2013
Michael,
You raise an excellent point! After close inspection of the code and
some internal discussions, we realize that you have uncovered a bug.
In MODE, we define the area of an object as a count of the
number of grid boxes that are turned on. The object id's in the
output NetCDF file accurately represent this count. However, the
areas reported in both the PostScript and ASCII output of MODE are
artificially inflated.
I'm not sure how much detail you want to hear, but this arose from a
two different ways we keep track of objects in MODE. Consider an
object that consists of a single grid point. When that data is
plotted, it will result in one box being filled in. And the centroid
of that object is the center of the box that is plotted, not the grid
point itself. In MODE, we keep track of objects in two
different ways:
- Our sample object consists of just one point, so it's area should
be 1.
- But when you think about the perimeter of the object that gets
plotted, there are 4 grid points.
MODE is incorrectly reporting the second of these counts as the area,
instead of the first.
So the question now is how to disseminate the fix. The next version
of MET, version 4.1, is due out in the next couple of weeks. We'll
include this change in METv4.1 along with an explanation in the
release notes.
We could also post a bugfix for METv4.0, but I have some reservations
about that. This fix will dramatically impact the output of MODE, and
data computed before and after the fix really should not be
compared. I worry that users will apply the bugfix and continue to
compare their MODE output before/after.
For that reason, we do not currently plan on posting this as a bugfix
for METv4.0. Please let me know if that's problematic for you.
Thank you for taking the time to analyze your data and uncover this
issue! We really appreciate it.
John Halley Gotway
met_help at ucar.edu
On 03/20/2013 05:59 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>
> Wed Mar 20 05:59:30 2013: Request 60718 was acted upon.
> Transaction: Ticket created by Michael-Jr.Powers at ec.gc.ca
> Queue: met_help
> Subject: Question about MODE tool
> Owner: Nobody
> Requestors: Michael-Jr.Powers at ec.gc.ca
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>
>
> Hi,
>
>
>
> I have a question about the MODE tool. I am trying to get the total
coverage area of objects on the grid (for the fcst and obs fields).
>
>
>
> The .ps output file given by MODE gives me this information on the
first page.
>
>
>
> When I use the Netcdf output file (.nc) to get the same information,
by counting the number of grid-points with values for the variables
fcst_obj_id and obs_obj_id, I get different values (usually greater
than the one found in the .ps file)...
>
>
>
> I'm wondering why these values are different?
>
>
>
> I know that In the documentation, you wrote this statement: "The
object colors plotted by ncview will generally not correspond to those
in MODE's PostScript output", but I don't understand why...
>
>
>
> Which value is the right one?
>
>
>
> Best regards,
>
> Michael Jr. Powers
>
> Météorologue | Meteorologist
> Centre de Prévision des Intempéries du Québec | Quebec Storm
Prediction Center
> SMC - Environnement Canada | MSC - Environment Canada
> Téléphone | Telephone: 514-283-9904
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #60718] Question about MODE tool
From: Powers,Michael-Jr [Montreal]
Time: Thu Mar 21 08:31:02 2013
Hello John,
Thank you for your answer.
I was actually looking
at the area covered by objects in the Netcdf files in order to get the
number of grid-points with no forecast and no observation. After a few
days of struggle with inspecting the data, I found the "bug". I'm glad
to know why I had such a hard time understanding what was wrong...
My goal here is to build a contingency table with the area covered by
objects on the fcst field and obs field. For that, I need the area of
Matched Forecast (MF), the area of Unmatched Forecast (UF), the area
of Matched Observation (MO), the area of Unmatched Observation (UO),
the Intersection area (IA) and the area with No Forecast and No
Observation (NFNO). The contingency table should be defined as
following:
Observation
Yes No
Forecast: Yes
MF+MO-IA UF
No UO NFNO
All these values can be found in
the .ps file, expect for the NFNO value. I can get the latter from the
Netcdf output file by adding (or subtracting) the fcst_obj_id with the
obs_obj_id. If I do this though, I have a problem because the area of
objects is defined differently in the Netcdf file that in the .ps file
(as you mentioned).
Do you have any suggestions of what I should
do in order to get the right information to build my contingency
table?
Best regards,
Michael Jr. Powers
Météorologue |
Meteorologist
Centre de Prévision des Intempéries du Québec | Quebec
Storm Prediction Center
SMC - Environnement Canada | MSC -
Environment Canada
Téléphone | Telephone: 514-283-9904
-----Message d'origine-----
De : John Halley Gotway via RT
[mailto:met_help at ucar.edu]
Envoyé : 20 mars 2013 16:56
À :
Powers,Michael-Jr [Montreal]
Objet : Re: [rt.rap.ucar.edu #60718]
Question about MODE tool
Michael,
You raise an excellent point!
After close inspection of the code and some internal discussions, we
realize that you have uncovered a bug. In MODE, we define the area of
an object as a count of the
number of grid boxes that are turned on.
The object id's in the output NetCDF file accurately represent this
count. However, the areas reported in both the PostScript and ASCII
output of MODE are
artificially inflated.
I'm not sure how much
detail you want to hear, but this arose from a two different ways we
keep track of objects in MODE. Consider an object that consists of a
single grid point. When that data is
plotted, it will result in one
box being filled in. And the centroid of that object is the center of
the box that is plotted, not the grid point itself. In MODE, we keep
track of objects in two
different ways:
- Our sample object
consists of just one point, so it's area should be 1.
- But when
you think about the perimeter of the object that gets plotted, there
are 4 grid points.
MODE is incorrectly reporting the second of
these counts as the area, instead of the first.
So the question now
is how to disseminate the fix. The next version of MET, version 4.1,
is due out in the next couple of weeks. We'll include this change in
METv4.1 along with an explanation in the
release notes.
We could
also post a bugfix for METv4.0, but I have some reservations about
that. This fix will dramatically impact the output of MODE, and data
computed before and after the fix really should not be
compared. I
worry that users will apply the bugfix and continue to compare their
MODE output before/after.
For that reason, we do not currently plan
on posting this as a bugfix for METv4.0. Please let me know if that's
problematic for you.
Thank you for taking the time to analyze your
data and uncover this issue! We really appreciate it.
John Halley
Gotway
met_help at ucar.edu
On 03/20/2013 05:59 AM, Powers,Michael-Jr
[Montreal] via RT wrote:
>
> Wed Mar 20 05:59:30 2013: Request 60718
was acted upon.
> Transaction: Ticket created by Michael-
Jr.Powers at ec.gc.ca
> Queue: met_help
> Subject:
Question about MODE tool
> Owner: Nobody
> Requestors:
Michael-Jr.Powers at ec.gc.ca
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>
>
> Hi,
>
>
>
> I have a question about the MODE tool. I am trying to get
the total coverage area of objects on the grid (for the fcst and obs
fields).
>
>
>
> The .ps output file given by MODE gives me this
information on the first page.
>
>
>
> When I use the Netcdf
output file (.nc) to get the same information, by counting the number
of grid-points with values for the variables fcst_obj_id and
obs_obj_id, I get different values (usually greater than the one found
in the .ps file)...
>
>
>
> I'm wondering why these values are
different?
>
>
>
> I know that In the documentation, you wrote
this statement: "The object colors plotted by ncview will generally
not correspond to those in MODE's PostScript output", but I don't
understand why...
>
>
>
> Which value is the right one?
>
>
>
> Best regards,
>
> Michael Jr. Powers
>
> Météorologue |
Meteorologist
> Centre de Prévision des Intempéries du Québec |
Quebec Storm Prediction Center
> SMC - Environnement Canada | MSC -
Environment Canada
> Téléphone | Telephone: 514-283-9904
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60718] Question about MODE tool
From: John Halley Gotway
Time: Thu Mar 21 13:44:42 2013
Michael,
As long as you're already parsing the NetCDF output file, I'd suggest
retrieving all of the counts from there. Just look in the
"fcst_clus_id" and "obs_clus_id" variables - the "clus" stands for
"cluster". In those fields, interpret the values as follows:
- A value of -1 means that grid point is part of an unmatched
object.
- A value > 0 means that grid point is part of a matched object.
- A value of -9999 means that grid point is not part of an object.
I believe you can derive all the counts you're after from there.
Hope that helps.
Thanks,
John Halley Gotway
On 03/21/2013 08:31 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>
> Hello John,
>
> Thank you for your answer.
>
> I was actually looking at the area covered by objects in the Netcdf
files in order to get the number of grid-points with no forecast and
no observation. After a few days of struggle with inspecting the data,
I found the "bug". I'm glad to know why I had such a hard time
understanding what was wrong...
>
> My goal here is to build a contingency table with the area covered
by objects on the fcst field and obs field. For that, I need the area
of Matched Forecast (MF), the area of Unmatched Forecast (UF), the
area of Matched Observation (MO), the area of Unmatched Observation
(UO), the Intersection area (IA) and the area with No Forecast and No
Observation (NFNO). The contingency table should be defined as
following:
>
> Observation
> Yes No
> Forecast: Yes MF+MO-IA UF
> No UO NFNO
>
> All these values can be found in the .ps file, expect for the NFNO
value. I can get the latter from the Netcdf output file by adding (or
subtracting) the fcst_obj_id with the obs_obj_id. If I do this though,
I have a problem because the area of objects is defined differently in
the Netcdf file that in the .ps file (as you mentioned).
>
> Do you have any suggestions of what I should do in order to get the
right information to build my contingency table?
>
> Best regards,
>
> Michael Jr. Powers
> Météorologue | Meteorologist
> Centre de Prévision des Intempéries du Québec | Quebec Storm
Prediction Center
> SMC - Environnement Canada | MSC - Environment Canada
> Téléphone | Telephone: 514-283-9904
>
> -----Message d'origine-----
> De : John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Envoyé : 20 mars 2013 16:56
> À : Powers,Michael-Jr [Montreal]
> Objet : Re: [rt.rap.ucar.edu #60718] Question about MODE tool
>
> Michael,
>
> You raise an excellent point! After close inspection of the code
and some internal discussions, we realize that you have uncovered a
bug. In MODE, we define the area of an object as a count of the
> number of grid boxes that are turned on. The object id's in the
output NetCDF file accurately represent this count. However, the
areas reported in both the PostScript and ASCII output of MODE are
> artificially inflated.
>
> I'm not sure how much detail you want to hear, but this arose from a
two different ways we keep track of objects in MODE. Consider an
object that consists of a single grid point. When that data is
> plotted, it will result in one box being filled in. And the
centroid of that object is the center of the box that is plotted, not
the grid point itself. In MODE, we keep track of objects in two
> different ways:
> - Our sample object consists of just one point, so it's area
should be 1.
> - But when you think about the perimeter of the object that gets
plotted, there are 4 grid points.
>
> MODE is incorrectly reporting the second of these counts as the
area, instead of the first.
>
> So the question now is how to disseminate the fix. The next version
of MET, version 4.1, is due out in the next couple of weeks. We'll
include this change in METv4.1 along with an explanation in the
> release notes.
>
> We could also post a bugfix for METv4.0, but I have some
reservations about that. This fix will dramatically impact the output
of MODE, and data computed before and after the fix really should not
be
> compared. I worry that users will apply the bugfix and continue to
compare their MODE output before/after.
>
> For that reason, we do not currently plan on posting this as a
bugfix for METv4.0. Please let me know if that's problematic for you.
>
> Thank you for taking the time to analyze your data and uncover this
issue! We really appreciate it.
>
> John Halley Gotway
> met_help at ucar.edu
>
> On 03/20/2013 05:59 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>>
>> Wed Mar 20 05:59:30 2013: Request 60718 was acted upon.
>> Transaction: Ticket created by Michael-Jr.Powers at ec.gc.ca
>> Queue: met_help
>> Subject: Question about MODE tool
>> Owner: Nobody
>> Requestors: Michael-Jr.Powers at ec.gc.ca
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>>
>>
>> Hi,
>>
>>
>>
>> I have a question about the MODE tool. I am trying to get the total
coverage area of objects on the grid (for the fcst and obs fields).
>>
>>
>>
>> The .ps output file given by MODE gives me this information on the
first page.
>>
>>
>>
>> When I use the Netcdf output file (.nc) to get the same
information, by counting the number of grid-points with values for
the variables fcst_obj_id and obs_obj_id, I get different values
(usually greater than the one found in the .ps file)...
>>
>>
>>
>> I'm wondering why these values are different?
>>
>>
>>
>> I know that In the documentation, you wrote this statement: "The
object colors plotted by ncview will generally not correspond to those
in MODE's PostScript output", but I don't understand why...
>>
>>
>>
>> Which value is the right one?
>>
>>
>>
>> Best regards,
>>
>> Michael Jr. Powers
>>
>> Météorologue | Meteorologist
>> Centre de Prévision des Intempéries du Québec | Quebec Storm
Prediction Center
>> SMC - Environnement Canada | MSC - Environment Canada
>> Téléphone | Telephone: 514-283-9904
>>
>>
>>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #60718] Question about MODE tool
From: Filion,Anna-Belle [Montreal]
Time: Mon Mar 25 17:18:10 2013
Hi,
I first installed the MET package at Environment Canada to use
MODE. I am using it to do an object based verification of severe
weather and build a contingency table from the mode_analysis tool.
Michael mentioned me the bug, but when I look to my MODE output with
gv or the mode_analysis tool the area of my objects looks pretty good
to me and they don't look like a value of the perimeter at all.
For example, I have severe weather observations on a grid( which is
pretty scarced so I can easily get only one data on my grid like you
mentioned). I have a convolution radius of 35 grid points and I keep
everything ge 0. So, if I have only one observation on my grid I will
get an object with the shape of a circle. The area of the circle that
I should get is 3849 and the perimeter is 220. The area given by gv
and the mode_analysis tool is 3996 gs. This is pretty close to the
value I was expecting and the difference could be due to the way the
area is computed according to the centroid.
So, I don't get what
you said about the perimeter. Therefore, I don't understand the reason
that the value in gv and the mode_analysis tool should be wrong.
Can you please provide me more information, since I am using the
mode_analysis tool to compute results for my master degree which I
thought up to now to be accurate.
Thanks
Anna-Belle Filion
-----Message d'origine-----
De : Powers,Michael-Jr [Montreal]
Envoyé : 25 mars 2013 10:05
À : Filion,Anna-Belle [Montreal]
Objet :
TR: [rt.rap.ucar.edu #60718] Question about MODE tool
-----Message d'origine-----
De : John Halley Gotway via RT
[mailto:met_help at ucar.edu]
Envoyé : 21 mars 2013 15:45
À :
Powers,Michael-Jr [Montreal]
Objet : Re: [rt.rap.ucar.edu #60718]
Question about MODE tool
Michael,
As long as you're already
parsing the NetCDF output file, I'd suggest retrieving all of the
counts from there. Just look in the "fcst_clus_id" and "obs_clus_id"
variables - the "clus" stands for
"cluster". In those fields,
interpret the values as follows:
- A value of -1 means that grid
point is part of an unmatched object.
- A value > 0 means that grid
point is part of a matched object.
- A value of -9999 means that
grid point is not part of an object.
I believe you can derive all
the counts you're after from there.
Hope that helps.
Thanks,
John Halley Gotway
On 03/21/2013 08:31 AM, Powers,Michael-Jr
[Montreal] via RT wrote:
>
> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>
> Hello
John,
>
> Thank you for your answer.
>
> I was actually looking at
the area covered by objects in the Netcdf files in order to get the
number of grid-points with no forecast and no observation. After a few
days of struggle with inspecting the data, I found the "bug". I'm glad
to know why I had such a hard time understanding what was wrong...
>
> My goal here is to build a contingency table with the area covered
by objects on the fcst field and obs field. For that, I need the area
of Matched Forecast (MF), the area of Unmatched Forecast (UF), the
area of Matched Observation (MO), the area of Unmatched Observation
(UO), the Intersection area (IA) and the area with No Forecast and No
Observation (NFNO). The contingency table should be defined as
following:
>
> Observation
> Yes No
> Forecast: Yes
MF+MO-IA UF
> No UO NFNO
>
> All these values can be
found in the .ps file, expect for the NFNO value. I can get the latter
from the Netcdf output file by adding (or subtracting) the fcst_obj_id
with the obs_obj_id. If I do this though, I have a problem because the
area of objects is defined differently in the Netcdf file that in the
.ps file (as you mentioned).
>
> Do you have any suggestions of what
I should do in order to get the right information to build my
contingency table?
>
> Best regards,
>
> Michael Jr. Powers
>
Météorologue | Meteorologist
> Centre de Prévision des Intempéries du
Québec | Quebec Storm Prediction Center
> SMC - Environnement Canada
| MSC - Environment Canada
> Téléphone | Telephone: 514-283-9904
>
> -----Message d'origine-----
> De : John Halley Gotway via RT
[mailto:met_help at ucar.edu]
> Envoyé : 20 mars 2013 16:56
> À :
Powers,Michael-Jr [Montreal]
> Objet : Re: [rt.rap.ucar.edu #60718]
Question about MODE tool
>
> Michael,
>
> You raise an excellent
point! After close inspection of the code and some internal
discussions, we realize that you have uncovered a bug. In MODE, we
define the area of an object as a count of the
> number of grid boxes
that are turned on. The object id's in the output NetCDF file
accurately represent this count. However, the areas reported in both
the PostScript and ASCII output of MODE are
> artificially inflated.
>
> I'm not sure how much detail you want to hear, but this arose
from a two different ways we keep track of objects in MODE. Consider
an object that consists of a single grid point. When that data is
>
plotted, it will result in one box being filled in. And the centroid
of that object is the center of the box that is plotted, not the grid
point itself. In MODE, we keep track of objects in two
> different
ways:
> - Our sample object consists of just one point, so it's
area should be 1.
> - But when you think about the perimeter of
the object that gets plotted, there are 4 grid points.
>
> MODE is
incorrectly reporting the second of these counts as the area, instead
of the first.
>
> So the question now is how to disseminate the fix.
The next version of MET, version 4.1, is due out in the next couple of
weeks. We'll include this change in METv4.1 along with an explanation
in the
> release notes.
>
> We could also post a bugfix for
METv4.0, but I have some reservations about that. This fix will
dramatically impact the output of MODE, and data computed before and
after the fix really should not be
> compared. I worry that users
will apply the bugfix and continue to compare their MODE output
before/after.
>
> For that reason, we do not currently plan on
posting this as a bugfix for METv4.0. Please let me know if that's
problematic for you.
>
> Thank you for taking the time to analyze
your data and uncover this issue! We really appreciate it.
>
> John
Halley Gotway
> met_help at ucar.edu
>
> On 03/20/2013 05:59 AM,
Powers,Michael-Jr [Montreal] via RT wrote:
>>
>> Wed Mar 20 05:59:30
2013: Request 60718 was acted upon.
>> Transaction: Ticket created by
Michael-Jr.Powers at ec.gc.ca
>> Queue: met_help
>>
Subject: Question about MODE tool
>> Owner: Nobody
>>
Requestors: Michael-Jr.Powers at ec.gc.ca
>> Status: new
>>
Ticket <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>>
>>
>> Hi,
>>
>>
>>
>> I have a question about the MODE tool.
I am trying to get the total coverage area of objects on the grid (for
the fcst and obs fields).
>>
>>
>>
>> The .ps output file given by
MODE gives me this information on the first page.
>>
>>
>>
>> When
I use the Netcdf output file (.nc) to get the same information, by
counting the number of grid-points with values for the variables
fcst_obj_id and obs_obj_id, I get different values (usually greater
than the one found in the .ps file)...
>>
>>
>>
>> I'm wondering
why these values are different?
>>
>>
>>
>> I know that In the
documentation, you wrote this statement: "The object colors plotted by
ncview will generally not correspond to those in MODE's PostScript
output", but I don't understand why...
>>
>>
>>
>> Which value is
the right one?
>>
>>
>>
>> Best regards,
>>
>> Michael Jr.
Powers
>>
>> Météorologue | Meteorologist
>> Centre de Prévision
des Intempéries du Québec | Quebec Storm Prediction Center
>> SMC -
Environnement Canada | MSC - Environment Canada
>> Téléphone |
Telephone: 514-283-9904
>>
>>
>>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #60718] Question about MODE tool
From: John Halley Gotway
Time: Mon Mar 25 21:34:15 2013
Anna-Belle,
I think there's been a bit of miscommunication about this issue.
Perhaps
my earlier explanation wasn't clear. I didn't mean that we're using
the
"perimeter" of the object instead of the "area". The problem is that
the
object areas are artificially inflated - perhaps 10% or so, depending
on
the object's size and shape. The easiest way to describe it is that
we're
incorrectly adding one extra row and column of grid squares to the
area of
each object.
The good news is that the issue affects the forecast and observation
objects in the same way. So it will likely have little impact on the
conclusions you draw from MODE. But once the issue is resolved, the
overall areas of the objects will be slightly smaller.
This may explain the difference in area you're seeing from 3849 to
3996
grid squares.
Make sense?
We're still working on a fix for this issue. And the original
software
developer for MODE will be writing up a short white-paper to explain
the
source of the problem and the fix.
We're planning to include the fix in the METv4.1 release, due out in a
couple of weeks. But at this point, we are not planning to release a
bugfix for METv4.0. MODE output before and after the fix really
should
not be compared. So we thought putting the fix in the new version
would
provide a clean break. But if users would like us to post a fix for
METv4.0, we certainly can.
Hope that helps clarify. Sorry for all the confusion and trouble.
And thanks to your colleague's careful eye in comparing the PostScript
and
NetCDF output of MODE.
Thanks,
John Halley Gotway
met_help at ucar.edu
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>
> Hi,
>
> I first installed the MET package at Environment Canada to use MODE.
I am
> using it to do an object based verification of severe weather and
build a
> contingency table from the mode_analysis tool.
>
> Michael mentioned me the bug, but when I look to my MODE output with
gv or
> the mode_analysis tool the area of my objects looks pretty good to
me and
> they don't look like a value of the perimeter at all.
>
> For example, I have severe weather observations on a grid( which is
pretty
> scarced so I can easily get only one data on my grid like you
mentioned).
> I have a convolution radius of 35 grid points and I keep everything
ge 0.
> So, if I have only one observation on my grid I will get an object
with
> the shape of a circle. The area of the circle that I should get is
3849
> and the perimeter is 220. The area given by gv and the mode_analysis
tool
> is 3996 gs. This is pretty close to the value I was expecting and
the
> difference could be due to the way the area is computed according to
the
> centroid.
>
> So, I don't get what you said about the perimeter. Therefore, I
don't
> understand the reason that the value in gv and the mode_analysis
tool
> should be wrong.
>
> Can you please provide me more information, since I am using the
> mode_analysis tool to compute results for my master degree which I
thought
> up to now to be accurate.
>
>
> Thanks
> Anna-Belle Filion
>
>
> -----Message d'origine-----
> De : Powers,Michael-Jr [Montreal]
> Envoyé : 25 mars 2013 10:05
> À : Filion,Anna-Belle [Montreal]
> Objet : TR: [rt.rap.ucar.edu #60718] Question about MODE tool
>
>
>
>
> -----Message d'origine-----
> De : John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Envoyé : 21 mars 2013 15:45
> À : Powers,Michael-Jr [Montreal]
> Objet : Re: [rt.rap.ucar.edu #60718] Question about MODE tool
>
> Michael,
>
> As long as you're already parsing the NetCDF output file, I'd
suggest
> retrieving all of the counts from there. Just look in the
"fcst_clus_id"
> and "obs_clus_id" variables - the "clus" stands for
> "cluster". In those fields, interpret the values as follows:
> - A value of -1 means that grid point is part of an unmatched
object.
> - A value > 0 means that grid point is part of a matched object.
> - A value of -9999 means that grid point is not part of an object.
>
> I believe you can derive all the counts you're after from there.
>
> Hope that helps.
>
> Thanks,
> John Halley Gotway
>
> On 03/21/2013 08:31 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>>
>> Hello John,
>>
>> Thank you for your answer.
>>
>> I was actually looking at the area covered by objects in the Netcdf
>> files in order to get the number of grid-points with no forecast
and no
>> observation. After a few days of struggle with inspecting the data,
I
>> found the "bug". I'm glad to know why I had such a hard time
>> understanding what was wrong...
>>
>> My goal here is to build a contingency table with the area covered
by
>> objects on the fcst field and obs field. For that, I need the area
of
>> Matched Forecast (MF), the area of Unmatched Forecast (UF), the
area of
>> Matched Observation (MO), the area of Unmatched Observation (UO),
the
>> Intersection area (IA) and the area with No Forecast and No
Observation
>> (NFNO). The contingency table should be defined as following:
>>
>> Observation
>> Yes No
>> Forecast: Yes MF+MO-IA UF
>> No UO NFNO
>>
>> All these values can be found in the .ps file, expect for the NFNO
>> value. I can get the latter from the Netcdf output file by adding
(or
>> subtracting) the fcst_obj_id with the obs_obj_id. If I do this
though, I
>> have a problem because the area of objects is defined differently
in the
>> Netcdf file that in the .ps file (as you mentioned).
>>
>> Do you have any suggestions of what I should do in order to get the
>> right information to build my contingency table?
>>
>> Best regards,
>>
>> Michael Jr. Powers
>> Météorologue | Meteorologist
>> Centre de Prévision des Intempéries du Québec | Quebec Storm
>> Prediction Center
>> SMC - Environnement Canada | MSC - Environment Canada
>> Téléphone | Telephone: 514-283-9904
>>
>> -----Message d'origine-----
>> De : John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Envoyé : 20 mars 2013 16:56
>> À : Powers,Michael-Jr [Montreal]
>> Objet : Re: [rt.rap.ucar.edu #60718] Question about MODE tool
>>
>> Michael,
>>
>> You raise an excellent point! After close inspection of the code
and
>> some internal discussions, we realize that you have uncovered a
bug. In
>> MODE, we define the area of an object as a count of the
>> number of grid boxes that are turned on. The object id's in the
output
>> NetCDF file accurately represent this count. However, the areas
>> reported in both the PostScript and ASCII output of MODE are
>> artificially inflated.
>>
>> I'm not sure how much detail you want to hear, but this arose from
a two
>> different ways we keep track of objects in MODE. Consider an
object
>> that consists of a single grid point. When that data is
>> plotted, it will result in one box being filled in. And the
centroid of
>> that object is the center of the box that is plotted, not the grid
point
>> itself. In MODE, we keep track of objects in two
>> different ways:
>> - Our sample object consists of just one point, so it's area
should
>> be 1.
>> - But when you think about the perimeter of the object that gets
>> plotted, there are 4 grid points.
>>
>> MODE is incorrectly reporting the second of these counts as the
area,
>> instead of the first.
>>
>> So the question now is how to disseminate the fix. The next
version of
>> MET, version 4.1, is due out in the next couple of weeks. We'll
include
>> this change in METv4.1 along with an explanation in the
>> release notes.
>>
>> We could also post a bugfix for METv4.0, but I have some
reservations
>> about that. This fix will dramatically impact the output of MODE,
and
>> data computed before and after the fix really should not be
>> compared. I worry that users will apply the bugfix and continue to
>> compare their MODE output before/after.
>>
>> For that reason, we do not currently plan on posting this as a
bugfix
>> for METv4.0. Please let me know if that's problematic for you.
>>
>> Thank you for taking the time to analyze your data and uncover this
>> issue! We really appreciate it.
>>
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 03/20/2013 05:59 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>>>
>>> Wed Mar 20 05:59:30 2013: Request 60718 was acted upon.
>>> Transaction: Ticket created by Michael-Jr.Powers at ec.gc.ca
>>> Queue: met_help
>>> Subject: Question about MODE tool
>>> Owner: Nobody
>>> Requestors: Michael-Jr.Powers at ec.gc.ca
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718
>>> >
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have a question about the MODE tool. I am trying to get the
total
>>> coverage area of objects on the grid (for the fcst and obs
fields).
>>>
>>>
>>>
>>> The .ps output file given by MODE gives me this information on the
>>> first page.
>>>
>>>
>>>
>>> When I use the Netcdf output file (.nc) to get the same
information, by
>>> counting the number of grid-points with values for the variables
>>> fcst_obj_id and obs_obj_id, I get different values (usually
greater
>>> than the one found in the .ps file)...
>>>
>>>
>>>
>>> I'm wondering why these values are different?
>>>
>>>
>>>
>>> I know that In the documentation, you wrote this statement: "The
object
>>> colors plotted by ncview will generally not correspond to those in
>>> MODE's PostScript output", but I don't understand why...
>>>
>>>
>>>
>>> Which value is the right one?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Michael Jr. Powers
>>>
>>> Météorologue | Meteorologist
>>> Centre de Prévision des Intempéries du Québec | Quebec Storm
>>> Prediction Center
>>> SMC - Environnement Canada | MSC - Environment Canada
>>> Téléphone | Telephone: 514-283-9904
>>>
>>>
>>>
>>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #60718] Question about MODE tool
From: Filion,Anna-Belle [Montreal]
Time: Tue Mar 26 08:14:16 2013
Thanks John.
It make more sense now. I won't need a patch since a
increase of 10% in obs and forecast object area should not affect that
much my results.
Anna-Belle Filion
-----Message d'origine-----
De : Powers,Michael-Jr [Montreal]
Envoyé : 26 mars 2013 10:01
À :
Filion,Anna-Belle [Montreal]
Objet : TR: [rt.rap.ucar.edu #60718]
Question about MODE tool
Michael Jr. Powers
Météorologue |
Meteorologist
Centre de Prévision des Intempéries du Québec | Quebec
Storm Prediction Center
SMC - Environnement Canada | MSC -
Environment Canada
Téléphone | Telephone: 514-283-9904
-----Message d'origine-----
De : John Halley Gotway via RT
[mailto:met_help at ucar.edu]
Envoyé : 25 mars 2013 23:34
À :
Powers,Michael-Jr [Montreal]
Objet : RE: [rt.rap.ucar.edu #60718]
Question about MODE tool
Anna-Belle,
I think there's been a bit
of miscommunication about this issue. Perhaps
my earlier explanation
wasn't clear. I didn't mean that we're using the
"perimeter" of the
object instead of the "area". The problem is that the
object areas
are artificially inflated - perhaps 10% or so, depending on
the
object's size and shape. The easiest way to describe it is that we're
incorrectly adding one extra row and column of grid squares to the
area of
each object.
The good news is that the issue affects the
forecast and observation
objects in the same way. So it will likely
have little impact on the
conclusions you draw from MODE. But once
the issue is resolved, the
overall areas of the objects will be
slightly smaller.
This may explain the difference in area you're
seeing from 3849 to 3996
grid squares.
Make sense?
We're still
working on a fix for this issue. And the original software
developer
for MODE will be writing up a short white-paper to explain the
source
of the problem and the fix.
We're planning to include the fix in
the METv4.1 release, due out in a
couple of weeks. But at this
point, we are not planning to release a
bugfix for METv4.0. MODE
output before and after the fix really should
not be compared. So we
thought putting the fix in the new version would
provide a clean
break. But if users would like us to post a fix for
METv4.0, we
certainly can.
Hope that helps clarify. Sorry for all the
confusion and trouble.
And thanks to your colleague's careful eye
in comparing the PostScript and
NetCDF output of MODE.
Thanks,
John Halley Gotway
met_help at ucar.edu
>
> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>
> Hi,
>
> I first installed the MET package at Environment Canada to use MODE.
I am
> using it to do an object based verification of severe weather
and build a
> contingency table from the mode_analysis tool.
>
>
Michael mentioned me the bug, but when I look to my MODE output with
gv or
> the mode_analysis tool the area of my objects looks pretty
good to me and
> they don't look like a value of the perimeter at
all.
>
> For example, I have severe weather observations on a grid(
which is pretty
> scarced so I can easily get only one data on my
grid like you mentioned).
> I have a convolution radius of 35 grid
points and I keep everything ge 0.
> So, if I have only one
observation on my grid I will get an object with
> the shape of a
circle. The area of the circle that I should get is 3849
> and the
perimeter is 220. The area given by gv and the mode_analysis tool
>
is 3996 gs. This is pretty close to the value I was expecting and the
> difference could be due to the way the area is computed according to
the
> centroid.
>
> So, I don't get what you said about the
perimeter. Therefore, I don't
> understand the reason that the value
in gv and the mode_analysis tool
> should be wrong.
>
> Can you
please provide me more information, since I am using the
>
mode_analysis tool to compute results for my master degree which I
thought
> up to now to be accurate.
>
>
> Thanks
> Anna-Belle
Filion
>
>
> -----Message d'origine-----
> De : Powers,Michael-Jr
[Montreal]
> Envoyé : 25 mars 2013 10:05
> À : Filion,Anna-Belle
[Montreal]
> Objet : TR: [rt.rap.ucar.edu #60718] Question about
MODE tool
>
>
>
>
> -----Message d'origine-----
> De : John
Halley Gotway via RT [mailto:met_help at ucar.edu]
> Envoyé : 21 mars
2013 15:45
> À : Powers,Michael-Jr [Montreal]
> Objet : Re:
[rt.rap.ucar.edu #60718] Question about MODE tool
>
> Michael,
>
>
As long as you're already parsing the NetCDF output file, I'd suggest
> retrieving all of the counts from there. Just look in the
"fcst_clus_id"
> and "obs_clus_id" variables - the "clus" stands for
> "cluster". In those fields, interpret the values as follows:
> -
A value of -1 means that grid point is part of an unmatched object.
>
- A value > 0 means that grid point is part of a matched object.
>
- A value of -9999 means that grid point is not part of an object.
>
> I believe you can derive all the counts you're after from there.
>
> Hope that helps.
>
> Thanks,
> John Halley Gotway
>
> On
03/21/2013 08:31 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718 >
>>
>> Hello John,
>>
>> Thank you for your answer.
>>
>> I was
actually looking at the area covered by objects in the Netcdf
>>
files in order to get the number of grid-points with no forecast and
no
>> observation. After a few days of struggle with inspecting the
data, I
>> found the "bug". I'm glad to know why I had such a hard
time
>> understanding what was wrong...
>>
>> My goal here is to
build a contingency table with the area covered by
>> objects on the
fcst field and obs field. For that, I need the area of
>> Matched
Forecast (MF), the area of Unmatched Forecast (UF), the area of
>>
Matched Observation (MO), the area of Unmatched Observation (UO), the
>> Intersection area (IA) and the area with No Forecast and No
Observation
>> (NFNO). The contingency table should be defined as
following:
>>
>> Observation
>> Yes No
>> Forecast:
Yes MF+MO-IA UF
>> No UO NFNO
>>
>> All these values
can be found in the .ps file, expect for the NFNO
>> value. I can get
the latter from the Netcdf output file by adding (or
>> subtracting)
the fcst_obj_id with the obs_obj_id. If I do this though, I
>> have a
problem because the area of objects is defined differently in the
>>
Netcdf file that in the .ps file (as you mentioned).
>>
>> Do you
have any suggestions of what I should do in order to get the
>> right
information to build my contingency table?
>>
>> Best regards,
>>
>> Michael Jr. Powers
>> Météorologue | Meteorologist
>> Centre de
Prévision des Intempéries du Québec | Quebec Storm
>> Prediction
Center
>> SMC - Environnement Canada | MSC - Environment Canada
>>
Téléphone | Telephone: 514-283-9904
>>
>> -----Message
d'origine-----
>> De : John Halley Gotway via RT
[mailto:met_help at ucar.edu]
>> Envoyé : 20 mars 2013 16:56
>> À :
Powers,Michael-Jr [Montreal]
>> Objet : Re: [rt.rap.ucar.edu #60718]
Question about MODE tool
>>
>> Michael,
>>
>> You raise an
excellent point! After close inspection of the code and
>> some
internal discussions, we realize that you have uncovered a bug. In
>> MODE, we define the area of an object as a count of the
>> number
of grid boxes that are turned on. The object id's in the output
>>
NetCDF file accurately represent this count. However, the areas
>>
reported in both the PostScript and ASCII output of MODE are
>>
artificially inflated.
>>
>> I'm not sure how much detail you want
to hear, but this arose from a two
>> different ways we keep track of
objects in MODE. Consider an object
>> that consists of a single
grid point. When that data is
>> plotted, it will result in one box
being filled in. And the centroid of
>> that object is the center of
the box that is plotted, not the grid point
>> itself. In MODE, we
keep track of objects in two
>> different ways:
>> - Our sample
object consists of just one point, so it's area should
>> be 1.
>>
- But when you think about the perimeter of the object that gets
>>
plotted, there are 4 grid points.
>>
>> MODE is incorrectly
reporting the second of these counts as the area,
>> instead of the
first.
>>
>> So the question now is how to disseminate the fix. The
next version of
>> MET, version 4.1, is due out in the next couple of
weeks. We'll include
>> this change in METv4.1 along with an
explanation in the
>> release notes.
>>
>> We could also post a
bugfix for METv4.0, but I have some reservations
>> about that. This
fix will dramatically impact the output of MODE, and
>> data computed
before and after the fix really should not be
>> compared. I worry
that users will apply the bugfix and continue to
>> compare their
MODE output before/after.
>>
>> For that reason, we do not currently
plan on posting this as a bugfix
>> for METv4.0. Please let me know
if that's problematic for you.
>>
>> Thank you for taking the time
to analyze your data and uncover this
>> issue! We really appreciate
it.
>>
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On
03/20/2013 05:59 AM, Powers,Michael-Jr [Montreal] via RT wrote:
>>>
>>> Wed Mar 20 05:59:30 2013: Request 60718 was acted upon.
>>>
Transaction: Ticket created by Michael-Jr.Powers at ec.gc.ca
>>>
Queue: met_help
>>> Subject: Question about MODE tool
>>>
Owner: Nobody
>>> Requestors: Michael-Jr.Powers at ec.gc.ca
>>>
Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60718
>>> >
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have a question about the MODE
tool. I am trying to get the total
>>> coverage area of objects on
the grid (for the fcst and obs fields).
>>>
>>>
>>>
>>> The .ps
output file given by MODE gives me this information on the
>>> first
page.
>>>
>>>
>>>
>>> When I use the Netcdf output file (.nc) to
get the same information, by
>>> counting the number of grid-points
with values for the variables
>>> fcst_obj_id and obs_obj_id, I get
different values (usually greater
>>> than the one found in the .ps
file)...
>>>
>>>
>>>
>>> I'm wondering why these values are
different?
>>>
>>>
>>>
>>> I know that In the documentation, you
wrote this statement: "The object
>>> colors plotted by ncview will
generally not correspond to those in
>>> MODE's PostScript output",
but I don't understand why...
>>>
>>>
>>>
>>> Which value is the
right one?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Michael Jr.
Powers
>>>
>>> Météorologue | Meteorologist
>>> Centre de
Prévision des Intempéries du Québec | Quebec Storm
>>> Prediction
Center
>>> SMC - Environnement Canada | MSC - Environment Canada
>>>
Téléphone | Telephone: 514-283-9904
>>>
>>>
>>>
>>
>
>
------------------------------------------------
More information about the Met_help
mailing list