[Met_help] [rt.rap.ucar.edu #69676] History for Questions about MODE
John Halley Gotway via RT
met_help at ucar.edu
Mon Dec 1 13:27:19 MST 2014
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I am trying to get some information from the MODE software and Laurie suggested that you might be able to assist again. I get the files read by MODE but after numerous changes of the configuration file, MODE still does not recognise the forecast field in the 20121102_SWFDPH.grb file. MODE does not apply any threshold value to this field and therefore does not compare the forecast and the observation field (SWFDP_MODE.png). Might this be due to the fact that the forecast field only consists of 1's and 0's and the observation is a continuous rainfall field? Or is there possibly some way to get around it?
I know you are busy but would appreciate any assistance in this regard. I have attached all the files required by MODE if my explanation does not make sense and you would like to test for yourself.
The command I used to execute MODE is:
/bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb MODEConfig_APCP_24
Kind regards,
Stephanie
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Questions about MODE
From: John Halley Gotway
Time: Mon Nov 10 11:59:19 2014
Hi Stephanie,
I see you're having trouble getting MODE to read data from your input
GRIB file. It'd probably be easiest to just have you send me some
sample data for testing. Please send me a sample forecast file,
observation file, and MODE configuration file. You can post it to our
anonymous ftp site following these instructions (normally I'd point
you to info on our website, but it's currently down):
ftp ftp.rap.ucar.edu
Name = anonymous
Password = "your email address"
cd incoming/irap/met_help
mkdir landman_data
cd landman_data
put "your data files"
exit
Please send me an email once you've posted the sample data, and I'll
go grab it and take a look.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Mon Nov 10 11:54:11 2014, johnhg wrote:
> I am trying to get some information from the MODE software and
Laurie
> suggested that you might be able to assist again. I get the files
> read by MODE but after numerous changes of the configuration
file,
> MODE still does not recognise the forecast field in the
> 20121102_SWFDPH.grb file. MODE does not apply any threshold value
> to this field and therefore does not compare the forecast and the
> observation field (SWFDP_MODE.png). Might this be due to the fact
> that the forecast field only consists of 1's and 0's and the
> observation is a continuous rainfall field? Or is there possibly
> some way to get around it?
>
> I know you are busy but would appreciate any assistance in this
> regard. I have attached all the files required by MODE if my
> explanation does not make sense and you would like to test for
> yourself.
> The command I used to execute MODE is:
> /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb MODEConfig_APCP_24
>
> Kind regards,
> Stephanie
------------------------------------------------
Subject: Questions about MODE
From: Stephanie Landman
Time: Mon Nov 10 23:14:54 2014
John,
Thank you for your willingness to assist me with this. I appreciate
it.
I have placed the data under the landman_data directory:
-rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
-rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
-rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
The 20121102_SWFDPH.grb file is the forecast file. I created the grib
files from binary data in order for MODE to recognise the format, so
the variable within the grib files; PRES is just a default parameter.
The forecast field is actually a subjective guidance area of expected
severe weather over the domain (example image attached). Therefore the
field consist of only 1's and 0's. The corresponding PRES parameter in
the 20121102_HYDRO.grb file is the corresponding QPE field used as
ground truth. Attached is also the output that I am getting from MODE
so far.
Thank you again for your time and assistance.
Regards,
Stephanie
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Monday, November 10, 2014 8:59 PM
To: Stephanie Landman
Subject: [rt.rap.ucar.edu #69676] Questions about MODE
Hi Stephanie,
I see you're having trouble getting MODE to read data from your input
GRIB file. It'd probably be easiest to just have you send me some
sample data for testing. Please send me a sample forecast file,
observation file, and MODE configuration file. You can post it to our
anonymous ftp site following these instructions (normally I'd point
you to info on our website, but it's currently down):
ftp ftp.rap.ucar.edu
Name = anonymous
Password = "your email address"
cd incoming/irap/met_help
mkdir landman_data
cd landman_data
put "your data files"
exit
Please send me an email once you've posted the sample data, and I'll
go grab it and take a look.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Mon Nov 10 11:54:11 2014, johnhg wrote:
> I am trying to get some information from the MODE software and
Laurie
> suggested that you might be able to assist again. I get the files
> read by MODE but after numerous changes of the configuration
file,
> MODE still does not recognise the forecast field in the
> 20121102_SWFDPH.grb file. MODE does not apply any threshold value
> to this field and therefore does not compare the forecast and the
> observation field (SWFDP_MODE.png). Might this be due to the fact
> that the forecast field only consists of 1's and 0's and the
> observation is a continuous rainfall field? Or is there possibly
> some way to get around it?
>
> I know you are busy but would appreciate any assistance in this
> regard. I have attached all the files required by MODE if my
> explanation does not make sense and you would like to test for
> yourself.
> The command I used to execute MODE is:
> /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb MODEConfig_APCP_24
>
> Kind regards,
> Stephanie
------------------------------------------------
Subject: Questions about MODE
From: John Halley Gotway
Time: Tue Nov 11 13:04:20 2014
Stephanie,
Thanks for sending that data, it makes it much easier to debug. After
looking through it, I have a few suggestions...
First, in order to get a quick view of the data files, I ran them
through
the plot_data_plane tool, like this:
METv4.0/bin/plot_data_plane 20121102_HYDRO.grb 20121102_HYDRO.ps
'name="PRES";level="Z0";'
METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb 20121102_SWFDPH.ps
'name="PRES";level="Z0";'
I converted the resulting images to png and attached them.
Next, looking in your MODE configuration file, I see that you're using
MET
version 4.0. There were two significant bugs relating to MODE that
are
fixed in METv4.1 and later versions. They are described in the
METv4.1
release notes:
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_release_notes.php
If possible, I'd suggest updating to the latest version of MET, 5.0.
But in my testing, I used METv4.0, since that's what you're using.
The
issue really is just in how you've set up the configuration file. I'd
suggest trying the attached config file.
Here are some of the changes I made...
(1) You didn't have all of the object definition criteria specified
for the
forecast field, so it was reverting to the values it read from the
default
configuration file, including a convolution threshold of >=5.0. That
led
to 0 objects in the forecast field.
(2) Your forecast is just a binary field of 0's and 1's. It doesn't
make
much sense to smooth a binary field that already looks pretty smooth.
So I
set the forecast conv_radius to 0. And I set the forecast conv_thresh
to
==1.0, meaning we'll define an object only where the forecast field is
1.
(3) In the observation section, you were applying a raw threshold
(raw_thresh). That threshold is typically not needed and should only
be
used when there's a good reason to use it. Basically, we were tossing
out
any observation values that were less than 50. Instead, I just set
the
raw_thresh to >=0 to keep all the values. I used the same convolution
radius you did (10) but turned up the convolution threshold to >=10.
The choice of threshold should really be driven by knowing your data
well.
What threshold in the observation field is really comparable to the
way the
forecast object is defined? Please play around with the observation
radius
and threshold to define objects that correspond well with the forecast
object.
(4) I turned off the merging step by setting "merge_flag = NONE". I'd
suggest running MODE in as simple a way as possible before adding in
additional merging logic.
(5) Lastly, I set max_centroid_distance = 1000 so as to have all
possible
object comparisons be considered.
I've attached the first page of the resulting graphical output from
MODE.
Please take a look and let me know what additional questions you have.
Thanks,
John
On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you for your willingness to assist me with this. I appreciate
it.
> I have placed the data under the landman_data directory:
> -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
>
> The 20121102_SWFDPH.grb file is the forecast file. I created the
grib
> files from binary data in order for MODE to recognise the format, so
the
> variable within the grib files; PRES is just a default parameter.
The
> forecast field is actually a subjective guidance area of expected
severe
> weather over the domain (example image attached). Therefore the
field
> consist of only 1's and 0's. The corresponding PRES parameter in the
> 20121102_HYDRO.grb file is the corresponding QPE field used as
ground
> truth. Attached is also the output that I am getting from MODE so
far.
>
> Thank you again for your time and assistance.
>
> Regards,
> Stephanie
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, November 10, 2014 8:59 PM
> To: Stephanie Landman
> Subject: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Hi Stephanie,
>
> I see you're having trouble getting MODE to read data from your
input GRIB
> file. It'd probably be easiest to just have you send me some sample
data
> for testing. Please send me a sample forecast file, observation
file, and
> MODE configuration file. You can post it to our anonymous ftp site
> following these instructions (normally I'd point you to info on our
> website, but it's currently down):
>
> ftp ftp.rap.ucar.edu
> Name = anonymous
> Password = "your email address"
> cd incoming/irap/met_help
> mkdir landman_data
> cd landman_data
> put "your data files"
> exit
>
> Please send me an email once you've posted the sample data, and I'll
go
> grab it and take a look.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
>
>
> On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > I am trying to get some information from the MODE software and
Laurie
> > suggested that you might be able to assist again. I get the
files
> > read by MODE but after numerous changes of the configuration
file,
> > MODE still does not recognise the forecast field in the
> > 20121102_SWFDPH.grb file. MODE does not apply any threshold
value
> > to this field and therefore does not compare the forecast and
the
> > observation field (SWFDP_MODE.png). Might this be due to the
fact
> > that the forecast field only consists of 1's and 0's and the
> > observation is a continuous rainfall field? Or is there
possibly
> > some way to get around it?
> >
> > I know you are busy but would appreciate any assistance in this
> > regard. I have attached all the files required by MODE if my
> > explanation does not make sense and you would like to test for
> > yourself.
> > The command I used to execute MODE is:
> > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
MODEConfig_APCP_24
> >
> > Kind regards,
> > Stephanie
>
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #69676] Questions about MODE
From: Stephanie Landman
Time: Thu Nov 13 05:42:54 2014
John,
Thank you very much for the quick assistance. I appreciate it.
1. As you suggested, I have requested our IT department to upgrade the
software - hope that happens soon(ish).
2. W.r.t. to the 50 mm threshold: the guidance forecast field is for
severe weather (> 50mm/day), but 50 might be too high for a low
resolution observation field (and 1 is too small), so I do still need
to test the threshold values to best represent severe rainfall in the
TRMM QPE file.
3. Then another question: if I provide MODE with forecast and
observation fields both containing only 0's and 1's (i.e. dichotomous
forecasts and observations), do I then apply the same values to the
observations as you did below with the forecast field? Or won't that
work? I want to test another forecast/observation data set and is
wondering if MODE will work...
4. Lastly: I have been trying to read the netCDF output file and
extract only the obs_clus_id field. Apart from me having to convert
the whole file to grib format (since most of our programs are written
for grib formatted files) - and cdo does not seem to work on this
output - can you possibly provide me with either a method or a website
that might help? I have tried reading it with Grads after creating a
control file but was unsuccessful (file below) and as I said before,
CDO does not work in converting this to grib1.
dset ^mode_000000L_20121029_000000V_000000A_obj.nc
title File
undef 99999.0
xdef dimension1 173 linear 10.000000 0.250000
ydef dimension2 149 linear -37.000000 0.250000
tdef dimension3 1 linear 0Z2nov2012 24hr
vars 8
fcst_raw 1 99 atlas []
fcst_obj_raw 1 99 atlas []
fcst_obj_id 1 99 atlas []
fcst_clus_id 1 99 atlas []
obs_raw 1 99 atlas []
obs_obj_raw 1 99 atlas []
obs_obj_id 1 99 atlas []
obs_clus_id 1 99 atlas []
endvars
Regards and thank you again.
Stephanie
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, November 11, 2014 10:04 PM
To: Stephanie Landman
Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
Stephanie,
Thanks for sending that data, it makes it much easier to debug. After
looking through it, I have a few suggestions...
First, in order to get a quick view of the data files, I ran them
through the plot_data_plane tool, like this:
METv4.0/bin/plot_data_plane 20121102_HYDRO.grb 20121102_HYDRO.ps
'name="PRES";level="Z0";'
METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb 20121102_SWFDPH.ps
'name="PRES";level="Z0";'
I converted the resulting images to png and attached them.
Next, looking in your MODE configuration file, I see that you're using
MET version 4.0. There were two significant bugs relating to MODE
that are fixed in METv4.1 and later versions. They are described in
the METv4.1 release notes:
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_release_notes.php
If possible, I'd suggest updating to the latest version of MET, 5.0.
But in my testing, I used METv4.0, since that's what you're using.
The issue really is just in how you've set up the configuration file.
I'd suggest trying the attached config file.
Here are some of the changes I made...
(1) You didn't have all of the object definition criteria specified
for the forecast field, so it was reverting to the values it read from
the default configuration file, including a convolution threshold of
>=5.0. That led to 0 objects in the forecast field.
(2) Your forecast is just a binary field of 0's and 1's. It doesn't
make much sense to smooth a binary field that already looks pretty
smooth. So I set the forecast conv_radius to 0. And I set the
forecast conv_thresh to ==1.0, meaning we'll define an object only
where the forecast field is 1.
(3) In the observation section, you were applying a raw threshold
(raw_thresh). That threshold is typically not needed and should only
be used when there's a good reason to use it. Basically, we were
tossing out any observation values that were less than 50. Instead, I
just set the raw_thresh to >=0 to keep all the values. I used the
same convolution radius you did (10) but turned up the convolution
threshold to >=10.
The choice of threshold should really be driven by knowing your data
well.
What threshold in the observation field is really comparable to the
way the forecast object is defined? Please play around with the
observation radius and threshold to define objects that correspond
well with the forecast object.
(4) I turned off the merging step by setting "merge_flag = NONE". I'd
suggest running MODE in as simple a way as possible before adding in
additional merging logic.
(5) Lastly, I set max_centroid_distance = 1000 so as to have all
possible object comparisons be considered.
I've attached the first page of the resulting graphical output from
MODE.
Please take a look and let me know what additional questions you have.
Thanks,
John
On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you for your willingness to assist me with this. I appreciate
it.
> I have placed the data under the landman_data directory:
> -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
>
> The 20121102_SWFDPH.grb file is the forecast file. I created the
grib
> files from binary data in order for MODE to recognise the format, so
> the variable within the grib files; PRES is just a default
parameter.
> The forecast field is actually a subjective guidance area of
expected
> severe weather over the domain (example image attached). Therefore
the
> field consist of only 1's and 0's. The corresponding PRES parameter
in
> the 20121102_HYDRO.grb file is the corresponding QPE field used as
> ground truth. Attached is also the output that I am getting from
MODE so far.
>
> Thank you again for your time and assistance.
>
> Regards,
> Stephanie
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, November 10, 2014 8:59 PM
> To: Stephanie Landman
> Subject: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Hi Stephanie,
>
> I see you're having trouble getting MODE to read data from your
input
> GRIB file. It'd probably be easiest to just have you send me some
> sample data for testing. Please send me a sample forecast file,
> observation file, and MODE configuration file. You can post it to
our
> anonymous ftp site following these instructions (normally I'd point
> you to info on our website, but it's currently down):
>
> ftp ftp.rap.ucar.edu
> Name = anonymous
> Password = "your email address"
> cd incoming/irap/met_help
> mkdir landman_data
> cd landman_data
> put "your data files"
> exit
>
> Please send me an email once you've posted the sample data, and I'll
> go grab it and take a look.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
>
>
> On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > I am trying to get some information from the MODE software and
Laurie
> > suggested that you might be able to assist again. I get the
files
> > read by MODE but after numerous changes of the configuration
file,
> > MODE still does not recognise the forecast field in the
> > 20121102_SWFDPH.grb file. MODE does not apply any threshold
value
> > to this field and therefore does not compare the forecast and
the
> > observation field (SWFDP_MODE.png). Might this be due to the
fact
> > that the forecast field only consists of 1's and 0's and the
> > observation is a continuous rainfall field? Or is there
possibly
> > some way to get around it?
> >
> > I know you are busy but would appreciate any assistance in this
> > regard. I have attached all the files required by MODE if my
> > explanation does not make sense and you would like to test for
> > yourself.
> > The command I used to execute MODE is:
> > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
MODEConfig_APCP_24
> >
> > Kind regards,
> > Stephanie
>
>
>
>
>
------------------------------------------------
Subject: Questions about MODE
From: John Halley Gotway
Time: Fri Nov 14 09:49:08 2014
Stephanie,
The logic in MODE is pretty straight-forward...
- Read raw data from the gridded data files you pass it.
- Apply the raw threshold (raw_thresh) to the raw data and sets any
values not meeting the threshold criteria to 0. This is only useful
in
very specific cases, and probably not in yours.
- Use the specified convolution radius (conv_radius) to smooth the
data.
- Apply the convolution threshold (conv_thresh) to the smoothed data
to
define objects.
- Restore the raw data values back to the interior of the resolved
objects.
- Apply the matching/merging logic and writes results (there's a lot
of
details I'm glossing over here!)
Setting the convolution radius to 0 applies no smoothing, while
increasing
it applies more smoothing. Hopefully with that information, you'll be
able
to adjust the convolution radius and threshold to define objects in
the way
you want. If your input field contains values of 0 and 1, you could
either...
- Apply no smoothing with a convolution radius of 0 and then
threshold
the objects at 1. That will create objects exactly where the input
values
are 1.
- Apply some amount of smoothing and then threshold the objects with
some
value less than 1. That will create a smoothed version of the binary
data.
How you choose to define the objects really just depends on the
phenomena
you're trying to study.
Regarding your last question, unfortunately, I do know have a good
solution
for converting the gridded NetCDF output of MODE to GRIB. That NetCDF
file
does contain several gridded fields, but also contains arrays of data
-
like the lat/lon locations for the objects boundaries. That sort of
un-gridded data wouldn't fit well into GRIB. What specific field or
fields
from that NetCDF file are you interested in? And what exactly would
you
like to do with them? If I know your intended use, I may be able to
provide better suggestions.
Thanks,
John
On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you very much for the quick assistance. I appreciate it.
> 1. As you suggested, I have requested our IT department to upgrade
the
> software - hope that happens soon(ish).
> 2. W.r.t. to the 50 mm threshold: the guidance forecast field is for
> severe weather (> 50mm/day), but 50 might be too high for a low
resolution
> observation field (and 1 is too small), so I do still need to test
the
> threshold values to best represent severe rainfall in the TRMM QPE
file.
> 3. Then another question: if I provide MODE with forecast and
observation
> fields both containing only 0's and 1's (i.e. dichotomous forecasts
and
> observations), do I then apply the same values to the observations
as you
> did below with the forecast field? Or won't that work? I want to
test
> another forecast/observation data set and is wondering if MODE will
work...
> 4. Lastly: I have been trying to read the netCDF output file and
extract
> only the obs_clus_id field. Apart from me having to convert the
whole file
> to grib format (since most of our programs are written for grib
formatted
> files) - and cdo does not seem to work on this output - can you
possibly
> provide me with either a method or a website that might help? I have
tried
> reading it with Grads after creating a control file but was
unsuccessful
> (file below) and as I said before, CDO does not work in converting
this to
> grib1.
>
> dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> title File
> undef 99999.0
> xdef dimension1 173 linear 10.000000 0.250000
> ydef dimension2 149 linear -37.000000 0.250000
> tdef dimension3 1 linear 0Z2nov2012 24hr
> vars 8
> fcst_raw 1 99 atlas []
> fcst_obj_raw 1 99 atlas []
> fcst_obj_id 1 99 atlas []
> fcst_clus_id 1 99 atlas []
> obs_raw 1 99 atlas []
> obs_obj_raw 1 99 atlas []
> obs_obj_id 1 99 atlas []
> obs_clus_id 1 99 atlas []
> endvars
>
> Regards and thank you again.
>
> Stephanie
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, November 11, 2014 10:04 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> Thanks for sending that data, it makes it much easier to debug.
After
> looking through it, I have a few suggestions...
>
> First, in order to get a quick view of the data files, I ran them
through
> the plot_data_plane tool, like this:
> METv4.0/bin/plot_data_plane 20121102_HYDRO.grb 20121102_HYDRO.ps
> 'name="PRES";level="Z0";'
> METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
20121102_SWFDPH.ps
> 'name="PRES";level="Z0";'
>
> I converted the resulting images to png and attached them.
>
> Next, looking in your MODE configuration file, I see that you're
using MET
> version 4.0. There were two significant bugs relating to MODE that
are
> fixed in METv4.1 and later versions. They are described in the
METv4.1
> release notes:
>
>
>
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_release_notes.php
>
> If possible, I'd suggest updating to the latest version of MET, 5.0.
>
> But in my testing, I used METv4.0, since that's what you're using.
The
> issue really is just in how you've set up the configuration file.
I'd
> suggest trying the attached config file.
>
> Here are some of the changes I made...
>
> (1) You didn't have all of the object definition criteria specified
for
> the forecast field, so it was reverting to the values it read from
the
> default configuration file, including a convolution threshold of
>=5.0.
> That led to 0 objects in the forecast field.
>
> (2) Your forecast is just a binary field of 0's and 1's. It doesn't
make
> much sense to smooth a binary field that already looks pretty
smooth. So I
> set the forecast conv_radius to 0. And I set the forecast
conv_thresh to
> ==1.0, meaning we'll define an object only where the forecast field
is 1.
>
> (3) In the observation section, you were applying a raw threshold
> (raw_thresh). That threshold is typically not needed and should
only be
> used when there's a good reason to use it. Basically, we were
tossing out
> any observation values that were less than 50. Instead, I just set
the
> raw_thresh to >=0 to keep all the values. I used the same
convolution
> radius you did (10) but turned up the convolution threshold to >=10.
>
> The choice of threshold should really be driven by knowing your data
well.
> What threshold in the observation field is really comparable to the
way
> the forecast object is defined? Please play around with the
observation
> radius and threshold to define objects that correspond well with the
> forecast object.
>
> (4) I turned off the merging step by setting "merge_flag = NONE".
I'd
> suggest running MODE in as simple a way as possible before adding in
> additional merging logic.
>
> (5) Lastly, I set max_centroid_distance = 1000 so as to have all
possible
> object comparisons be considered.
>
> I've attached the first page of the resulting graphical output from
MODE.
>
> Please take a look and let me know what additional questions you
have.
>
> Thanks,
> John
>
>
> On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you for your willingness to assist me with this. I
appreciate it.
> > I have placed the data under the landman_data directory:
> > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> >
> > The 20121102_SWFDPH.grb file is the forecast file. I created the
grib
> > files from binary data in order for MODE to recognise the format,
so
> > the variable within the grib files; PRES is just a default
parameter.
> > The forecast field is actually a subjective guidance area of
expected
> > severe weather over the domain (example image attached). Therefore
the
> > field consist of only 1's and 0's. The corresponding PRES
parameter in
> > the 20121102_HYDRO.grb file is the corresponding QPE field used as
> > ground truth. Attached is also the output that I am getting from
MODE so
> far.
> >
> > Thank you again for your time and assistance.
> >
> > Regards,
> > Stephanie
> >
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, November 10, 2014 8:59 PM
> > To: Stephanie Landman
> > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Hi Stephanie,
> >
> > I see you're having trouble getting MODE to read data from your
input
> > GRIB file. It'd probably be easiest to just have you send me some
> > sample data for testing. Please send me a sample forecast file,
> > observation file, and MODE configuration file. You can post it to
our
> > anonymous ftp site following these instructions (normally I'd
point
> > you to info on our website, but it's currently down):
> >
> > ftp ftp.rap.ucar.edu
> > Name = anonymous
> > Password = "your email address"
> > cd incoming/irap/met_help
> > mkdir landman_data
> > cd landman_data
> > put "your data files"
> > exit
> >
> > Please send me an email once you've posted the sample data, and
I'll
> > go grab it and take a look.
> >
> > Thanks,
> > John Halley Gotway
> > met_help at ucar.edu
> >
> >
> >
> >
> > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > I am trying to get some information from the MODE software and
Laurie
> > > suggested that you might be able to assist again. I get the
files
> > > read by MODE but after numerous changes of the configuration
file,
> > > MODE still does not recognise the forecast field in the
> > > 20121102_SWFDPH.grb file. MODE does not apply any threshold
value
> > > to this field and therefore does not compare the forecast and
the
> > > observation field (SWFDP_MODE.png). Might this be due to the
fact
> > > that the forecast field only consists of 1's and 0's and the
> > > observation is a continuous rainfall field? Or is there
possibly
> > > some way to get around it?
> > >
> > > I know you are busy but would appreciate any assistance in this
> > > regard. I have attached all the files required by MODE if my
> > > explanation does not make sense and you would like to test
for
> > > yourself.
> > > The command I used to execute MODE is:
> > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
MODEConfig_APCP_24
> > >
> > > Kind regards,
> > > Stephanie
> >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Questions about MODE
From: Stephanie Landman
Time: Wed Nov 19 07:12:28 2014
John,
Thank you as always for coming back to me.
What I would have liked to do with the obs cluster output from the
netCDF file is to display it in another graphics package alongside
other verification products already developed in-house. So I guess I
would have liked to modify the display a bit more and adapt it to
products the users in the SADC community already feel comfortable
with. All with the necessary acknowledgments of course. But I can do
without if it is not possible to extract the information.
My last two questions/confirmations, I promise:
1. Just to confirm the units of the centroid distance: number of
grids? In attached file the distance is 5.22 (green), therefore 5.22
grid boxes?
2. I am unsure of the difference between "Intersection_Area" and
"Intersection_over_Area": again in the attached file, is the
"Intersection_Area" value of 108 the number of the 1273 fcst grids and
143 obs grids that overlay? And then the "Union_Area" the complete
number of grids that make up "cluster 1" consisting of 1308 grids? How
is "Intersection_over_Area" then computed to get 0.755?
Again, thank you for everything.
Regards,
Stephanie
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, November 14, 2014 6:49 PM
To: Stephanie Landman
Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
Stephanie,
The logic in MODE is pretty straight-forward...
- Read raw data from the gridded data files you pass it.
- Apply the raw threshold (raw_thresh) to the raw data and sets any
values not meeting the threshold criteria to 0. This is only useful
in very specific cases, and probably not in yours.
- Use the specified convolution radius (conv_radius) to smooth the
data.
- Apply the convolution threshold (conv_thresh) to the smoothed data
to define objects.
- Restore the raw data values back to the interior of the resolved
objects.
- Apply the matching/merging logic and writes results (there's a lot
of details I'm glossing over here!)
Setting the convolution radius to 0 applies no smoothing, while
increasing it applies more smoothing. Hopefully with that
information, you'll be able to adjust the convolution radius and
threshold to define objects in the way you want. If your input field
contains values of 0 and 1, you could either...
- Apply no smoothing with a convolution radius of 0 and then
threshold the objects at 1. That will create objects exactly where
the input values are 1.
- Apply some amount of smoothing and then threshold the objects with
some value less than 1. That will create a smoothed version of the
binary data.
How you choose to define the objects really just depends on the
phenomena you're trying to study.
Regarding your last question, unfortunately, I do know have a good
solution for converting the gridded NetCDF output of MODE to GRIB.
That NetCDF file does contain several gridded fields, but also
contains arrays of data - like the lat/lon locations for the objects
boundaries. That sort of un-gridded data wouldn't fit well into GRIB.
What specific field or fields from that NetCDF file are you interested
in? And what exactly would you like to do with them? If I know your
intended use, I may be able to provide better suggestions.
Thanks,
John
On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you very much for the quick assistance. I appreciate it.
> 1. As you suggested, I have requested our IT department to upgrade
the
> software - hope that happens soon(ish).
> 2. W.r.t. to the 50 mm threshold: the guidance forecast field is for
> severe weather (> 50mm/day), but 50 might be too high for a low
> resolution observation field (and 1 is too small), so I do still
need
> to test the threshold values to best represent severe rainfall in
the TRMM QPE file.
> 3. Then another question: if I provide MODE with forecast and
> observation fields both containing only 0's and 1's (i.e.
dichotomous
> forecasts and observations), do I then apply the same values to the
> observations as you did below with the forecast field? Or won't that
> work? I want to test another forecast/observation data set and is
wondering if MODE will work...
> 4. Lastly: I have been trying to read the netCDF output file and
> extract only the obs_clus_id field. Apart from me having to convert
> the whole file to grib format (since most of our programs are
written
> for grib formatted
> files) - and cdo does not seem to work on this output - can you
> possibly provide me with either a method or a website that might
help?
> I have tried reading it with Grads after creating a control file but
> was unsuccessful (file below) and as I said before, CDO does not
work
> in converting this to grib1.
>
> dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> title File
> undef 99999.0
> xdef dimension1 173 linear 10.000000 0.250000 ydef dimension2 149
> linear -37.000000 0.250000 tdef dimension3 1 linear 0Z2nov2012 24hr
> vars 8
> fcst_raw 1 99 atlas []
> fcst_obj_raw 1 99 atlas []
> fcst_obj_id 1 99 atlas []
> fcst_clus_id 1 99 atlas []
> obs_raw 1 99 atlas []
> obs_obj_raw 1 99 atlas []
> obs_obj_id 1 99 atlas []
> obs_clus_id 1 99 atlas []
> endvars
>
> Regards and thank you again.
>
> Stephanie
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, November 11, 2014 10:04 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> Thanks for sending that data, it makes it much easier to debug.
After
> looking through it, I have a few suggestions...
>
> First, in order to get a quick view of the data files, I ran them
> through the plot_data_plane tool, like this:
> METv4.0/bin/plot_data_plane 20121102_HYDRO.grb 20121102_HYDRO.ps
> 'name="PRES";level="Z0";'
> METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
20121102_SWFDPH.ps
> 'name="PRES";level="Z0";'
>
> I converted the resulting images to png and attached them.
>
> Next, looking in your MODE configuration file, I see that you're
using
> MET version 4.0. There were two significant bugs relating to MODE
> that are fixed in METv4.1 and later versions. They are described in
> the METv4.1 release notes:
>
>
>
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_releas
> e_notes.php
>
> If possible, I'd suggest updating to the latest version of MET, 5.0.
>
> But in my testing, I used METv4.0, since that's what you're using.
> The issue really is just in how you've set up the configuration
file.
> I'd suggest trying the attached config file.
>
> Here are some of the changes I made...
>
> (1) You didn't have all of the object definition criteria specified
> for the forecast field, so it was reverting to the values it read
from
> the default configuration file, including a convolution threshold of
>=5.0.
> That led to 0 objects in the forecast field.
>
> (2) Your forecast is just a binary field of 0's and 1's. It doesn't
> make much sense to smooth a binary field that already looks pretty
> smooth. So I set the forecast conv_radius to 0. And I set the
> forecast conv_thresh to ==1.0, meaning we'll define an object only
where the forecast field is 1.
>
> (3) In the observation section, you were applying a raw threshold
> (raw_thresh). That threshold is typically not needed and should
only
> be used when there's a good reason to use it. Basically, we were
> tossing out any observation values that were less than 50. Instead,
I
> just set the raw_thresh to >=0 to keep all the values. I used the
> same convolution radius you did (10) but turned up the convolution
threshold to >=10.
>
> The choice of threshold should really be driven by knowing your data
well.
> What threshold in the observation field is really comparable to the
> way the forecast object is defined? Please play around with the
> observation radius and threshold to define objects that correspond
> well with the forecast object.
>
> (4) I turned off the merging step by setting "merge_flag = NONE".
I'd
> suggest running MODE in as simple a way as possible before adding in
> additional merging logic.
>
> (5) Lastly, I set max_centroid_distance = 1000 so as to have all
> possible object comparisons be considered.
>
> I've attached the first page of the resulting graphical output from
MODE.
>
> Please take a look and let me know what additional questions you
have.
>
> Thanks,
> John
>
>
> On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you for your willingness to assist me with this. I
appreciate it.
> > I have placed the data under the landman_data directory:
> > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> >
> > The 20121102_SWFDPH.grb file is the forecast file. I created the
> > grib files from binary data in order for MODE to recognise the
> > format, so the variable within the grib files; PRES is just a
default parameter.
> > The forecast field is actually a subjective guidance area of
> > expected severe weather over the domain (example image attached).
> > Therefore the field consist of only 1's and 0's. The corresponding
> > PRES parameter in the 20121102_HYDRO.grb file is the corresponding
> > QPE field used as ground truth. Attached is also the output that I
> > am getting from MODE so
> far.
> >
> > Thank you again for your time and assistance.
> >
> > Regards,
> > Stephanie
> >
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, November 10, 2014 8:59 PM
> > To: Stephanie Landman
> > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Hi Stephanie,
> >
> > I see you're having trouble getting MODE to read data from your
> > input GRIB file. It'd probably be easiest to just have you send
me
> > some sample data for testing. Please send me a sample forecast
> > file, observation file, and MODE configuration file. You can post
> > it to our anonymous ftp site following these instructions
(normally
> > I'd point you to info on our website, but it's currently down):
> >
> > ftp ftp.rap.ucar.edu
> > Name = anonymous
> > Password = "your email address"
> > cd incoming/irap/met_help
> > mkdir landman_data
> > cd landman_data
> > put "your data files"
> > exit
> >
> > Please send me an email once you've posted the sample data, and
I'll
> > go grab it and take a look.
> >
> > Thanks,
> > John Halley Gotway
> > met_help at ucar.edu
> >
> >
> >
> >
> > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > I am trying to get some information from the MODE software and
Laurie
> > > suggested that you might be able to assist again. I get the
files
> > > read by MODE but after numerous changes of the configuration
file,
> > > MODE still does not recognise the forecast field in the
> > > 20121102_SWFDPH.grb file. MODE does not apply any threshold
value
> > > to this field and therefore does not compare the forecast and
the
> > > observation field (SWFDP_MODE.png). Might this be due to the
fact
> > > that the forecast field only consists of 1's and 0's and the
> > > observation is a continuous rainfall field? Or is there
possibly
> > > some way to get around it?
> > >
> > > I know you are busy but would appreciate any assistance in this
> > > regard. I have attached all the files required by MODE if my
> > > explanation does not make sense and you would like to test
for
> > > yourself.
> > > The command I used to execute MODE is:
> > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
> > > MODEConfig_APCP_24
> > >
> > > Kind regards,
> > > Stephanie
> >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Questions about MODE
From: John Halley Gotway
Time: Wed Nov 19 09:58:15 2014
Stephanie,
It's in in general much harder to write a GRIB file than it is to read
it.
I just tried using the "cdo copy" operator to try to convert the
NetCDF
output of MODE to GRIB and it failed, as I suspected it would. There
is a
python utility named "pygrib" which supposedly can read and write GRIB
files. However, I haven't used it in the past. There is of course a
way
to make this work, but I don't have an easy solution for you at this
point.
In answer to your questions...
1. Yes, the centroid distance, and all distance in MODE are given in
grid
units. Once MODE reads in the gridded data, all the math and logic is
performed on the grid. MODE ignores the area distortions of the
underlying
projection and treats all grid boxes equally. So be aware of that
when
running MODE over a large domain where the area of the grid boxes
changes
significantly.
2. The area of the cluster forecast object is 1273 and the area of the
cluster observation object is 143. Their intersection is 108 and
union is
1308. The "Intersection_over_Area" is computed as the intersection
area
divided by the minimum of the forecast and observation areas. In this
case, that's 108/min(143, 1273) = 0.755.
The nice thing about that measure is that it's always between 0 and 1.
You're right, we could have instead computed the intersection / union,
which would also always be between 0 and 1. I don't remember the
reasoning
for doing one versus the other. But hopefully that explains how it's
calculated.
Thanks,
John
On Wed, Nov 19, 2014 at 7:12 AM, Stephanie Landman via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you as always for coming back to me.
> What I would have liked to do with the obs cluster output from the
netCDF
> file is to display it in another graphics package alongside other
> verification products already developed in-house. So I guess I would
have
> liked to modify the display a bit more and adapt it to products the
users
> in the SADC community already feel comfortable with. All with the
necessary
> acknowledgments of course. But I can do without if it is not
possible to
> extract the information.
>
> My last two questions/confirmations, I promise:
> 1. Just to confirm the units of the centroid distance: number of
grids? In
> attached file the distance is 5.22 (green), therefore 5.22 grid
boxes?
> 2. I am unsure of the difference between "Intersection_Area" and
> "Intersection_over_Area": again in the attached file, is the
> "Intersection_Area" value of 108 the number of the 1273 fcst grids
and 143
> obs grids that overlay? And then the "Union_Area" the complete
number of
> grids that make up "cluster 1" consisting of 1308 grids? How is
> "Intersection_over_Area" then computed to get 0.755?
>
> Again, thank you for everything.
>
> Regards,
> Stephanie
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, November 14, 2014 6:49 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> The logic in MODE is pretty straight-forward...
> - Read raw data from the gridded data files you pass it.
> - Apply the raw threshold (raw_thresh) to the raw data and sets
any
> values not meeting the threshold criteria to 0. This is only useful
in
> very specific cases, and probably not in yours.
> - Use the specified convolution radius (conv_radius) to smooth the
data.
> - Apply the convolution threshold (conv_thresh) to the smoothed
data to
> define objects.
> - Restore the raw data values back to the interior of the resolved
> objects.
> - Apply the matching/merging logic and writes results (there's a
lot of
> details I'm glossing over here!)
>
> Setting the convolution radius to 0 applies no smoothing, while
increasing
> it applies more smoothing. Hopefully with that information, you'll
be able
> to adjust the convolution radius and threshold to define objects in
the way
> you want. If your input field contains values of 0 and 1, you could
> either...
> - Apply no smoothing with a convolution radius of 0 and then
threshold
> the objects at 1. That will create objects exactly where the input
values
> are 1.
> - Apply some amount of smoothing and then threshold the objects
with
> some value less than 1. That will create a smoothed version of the
binary
> data.
>
> How you choose to define the objects really just depends on the
phenomena
> you're trying to study.
>
> Regarding your last question, unfortunately, I do know have a good
> solution for converting the gridded NetCDF output of MODE to GRIB.
That
> NetCDF file does contain several gridded fields, but also contains
arrays
> of data - like the lat/lon locations for the objects boundaries.
That sort
> of un-gridded data wouldn't fit well into GRIB. What specific field
or
> fields from that NetCDF file are you interested in? And what
exactly would
> you like to do with them? If I know your intended use, I may be
able to
> provide better suggestions.
>
> Thanks,
> John
>
>
>
>
> On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT <
> met_help at ucar.edu
> > wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you very much for the quick assistance. I appreciate it.
> > 1. As you suggested, I have requested our IT department to upgrade
the
> > software - hope that happens soon(ish).
> > 2. W.r.t. to the 50 mm threshold: the guidance forecast field is
for
> > severe weather (> 50mm/day), but 50 might be too high for a low
> > resolution observation field (and 1 is too small), so I do still
need
> > to test the threshold values to best represent severe rainfall in
the
> TRMM QPE file.
> > 3. Then another question: if I provide MODE with forecast and
> > observation fields both containing only 0's and 1's (i.e.
dichotomous
> > forecasts and observations), do I then apply the same values to
the
> > observations as you did below with the forecast field? Or won't
that
> > work? I want to test another forecast/observation data set and is
> wondering if MODE will work...
> > 4. Lastly: I have been trying to read the netCDF output file and
> > extract only the obs_clus_id field. Apart from me having to
convert
> > the whole file to grib format (since most of our programs are
written
> > for grib formatted
> > files) - and cdo does not seem to work on this output - can you
> > possibly provide me with either a method or a website that might
help?
> > I have tried reading it with Grads after creating a control file
but
> > was unsuccessful (file below) and as I said before, CDO does not
work
> > in converting this to grib1.
> >
> > dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> > title File
> > undef 99999.0
> > xdef dimension1 173 linear 10.000000 0.250000 ydef dimension2 149
> > linear -37.000000 0.250000 tdef dimension3 1 linear 0Z2nov2012
24hr
> > vars 8
> > fcst_raw 1 99 atlas []
> > fcst_obj_raw 1 99 atlas []
> > fcst_obj_id 1 99 atlas []
> > fcst_clus_id 1 99 atlas []
> > obs_raw 1 99 atlas []
> > obs_obj_raw 1 99 atlas []
> > obs_obj_id 1 99 atlas []
> > obs_clus_id 1 99 atlas []
> > endvars
> >
> > Regards and thank you again.
> >
> > Stephanie
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Tuesday, November 11, 2014 10:04 PM
> > To: Stephanie Landman
> > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Stephanie,
> >
> > Thanks for sending that data, it makes it much easier to debug.
After
> > looking through it, I have a few suggestions...
> >
> > First, in order to get a quick view of the data files, I ran them
> > through the plot_data_plane tool, like this:
> > METv4.0/bin/plot_data_plane 20121102_HYDRO.grb
20121102_HYDRO.ps
> > 'name="PRES";level="Z0";'
> > METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
20121102_SWFDPH.ps
> > 'name="PRES";level="Z0";'
> >
> > I converted the resulting images to png and attached them.
> >
> > Next, looking in your MODE configuration file, I see that you're
using
> > MET version 4.0. There were two significant bugs relating to MODE
> > that are fixed in METv4.1 and later versions. They are described
in
> > the METv4.1 release notes:
> >
> >
> >
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_releas
> > e_notes.php
> >
> > If possible, I'd suggest updating to the latest version of MET,
5.0.
> >
> > But in my testing, I used METv4.0, since that's what you're using.
> > The issue really is just in how you've set up the configuration
file.
> > I'd suggest trying the attached config file.
> >
> > Here are some of the changes I made...
> >
> > (1) You didn't have all of the object definition criteria
specified
> > for the forecast field, so it was reverting to the values it read
from
> > the default configuration file, including a convolution threshold
of
> >=5.0.
> > That led to 0 objects in the forecast field.
> >
> > (2) Your forecast is just a binary field of 0's and 1's. It
doesn't
> > make much sense to smooth a binary field that already looks pretty
> > smooth. So I set the forecast conv_radius to 0. And I set the
> > forecast conv_thresh to ==1.0, meaning we'll define an object only
where
> the forecast field is 1.
> >
> > (3) In the observation section, you were applying a raw threshold
> > (raw_thresh). That threshold is typically not needed and should
only
> > be used when there's a good reason to use it. Basically, we were
> > tossing out any observation values that were less than 50.
Instead, I
> > just set the raw_thresh to >=0 to keep all the values. I used the
> > same convolution radius you did (10) but turned up the convolution
> threshold to >=10.
> >
> > The choice of threshold should really be driven by knowing your
data
> well.
> > What threshold in the observation field is really comparable to
the
> > way the forecast object is defined? Please play around with the
> > observation radius and threshold to define objects that correspond
> > well with the forecast object.
> >
> > (4) I turned off the merging step by setting "merge_flag = NONE".
I'd
> > suggest running MODE in as simple a way as possible before adding
in
> > additional merging logic.
> >
> > (5) Lastly, I set max_centroid_distance = 1000 so as to have all
> > possible object comparisons be considered.
> >
> > I've attached the first page of the resulting graphical output
from MODE.
> >
> > Please take a look and let me know what additional questions you
have.
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> > >
> > > John,
> > >
> > > Thank you for your willingness to assist me with this. I
appreciate it.
> > > I have placed the data under the landman_data directory:
> > > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> > >
> > > The 20121102_SWFDPH.grb file is the forecast file. I created the
> > > grib files from binary data in order for MODE to recognise the
> > > format, so the variable within the grib files; PRES is just a
default
> parameter.
> > > The forecast field is actually a subjective guidance area of
> > > expected severe weather over the domain (example image
attached).
> > > Therefore the field consist of only 1's and 0's. The
corresponding
> > > PRES parameter in the 20121102_HYDRO.grb file is the
corresponding
> > > QPE field used as ground truth. Attached is also the output that
I
> > > am getting from MODE so
> > far.
> > >
> > > Thank you again for your time and assistance.
> > >
> > > Regards,
> > > Stephanie
> > >
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Monday, November 10, 2014 8:59 PM
> > > To: Stephanie Landman
> > > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> > >
> > > Hi Stephanie,
> > >
> > > I see you're having trouble getting MODE to read data from your
> > > input GRIB file. It'd probably be easiest to just have you send
me
> > > some sample data for testing. Please send me a sample forecast
> > > file, observation file, and MODE configuration file. You can
post
> > > it to our anonymous ftp site following these instructions
(normally
> > > I'd point you to info on our website, but it's currently down):
> > >
> > > ftp ftp.rap.ucar.edu
> > > Name = anonymous
> > > Password = "your email address"
> > > cd incoming/irap/met_help
> > > mkdir landman_data
> > > cd landman_data
> > > put "your data files"
> > > exit
> > >
> > > Please send me an email once you've posted the sample data, and
I'll
> > > go grab it and take a look.
> > >
> > > Thanks,
> > > John Halley Gotway
> > > met_help at ucar.edu
> > >
> > >
> > >
> > >
> > > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > > I am trying to get some information from the MODE software and
Laurie
> > > > suggested that you might be able to assist again. I get the
files
> > > > read by MODE but after numerous changes of the
configuration file,
> > > > MODE still does not recognise the forecast field in the
> > > > 20121102_SWFDPH.grb file. MODE does not apply any threshold
value
> > > > to this field and therefore does not compare the forecast
and the
> > > > observation field (SWFDP_MODE.png). Might this be due to
the fact
> > > > that the forecast field only consists of 1's and 0's and
the
> > > > observation is a continuous rainfall field? Or is there
possibly
> > > > some way to get around it?
> > > >
> > > > I know you are busy but would appreciate any assistance in
this
> > > > regard. I have attached all the files required by MODE if
my
> > > > explanation does not make sense and you would like to test
for
> > > > yourself.
> > > > The command I used to execute MODE is:
> > > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
> > > > MODEConfig_APCP_24
> > > >
> > > > Kind regards,
> > > > Stephanie
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #69676] Questions about MODE
From: Stephanie Landman
Time: Thu Nov 20 05:46:29 2014
John,
Thank you again for your help and patience.
I think I am now on the right track with MODE for our use and will
definitely apply it to our operational verification suite.
Regards,
Stephanie
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Wednesday, November 19, 2014 6:58 PM
To: Stephanie Landman
Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
Stephanie,
It's in in general much harder to write a GRIB file than it is to read
it.
I just tried using the "cdo copy" operator to try to convert the
NetCDF output of MODE to GRIB and it failed, as I suspected it would.
There is a python utility named "pygrib" which supposedly can read and
write GRIB files. However, I haven't used it in the past. There is
of course a way to make this work, but I don't have an easy solution
for you at this point.
In answer to your questions...
1. Yes, the centroid distance, and all distance in MODE are given in
grid units. Once MODE reads in the gridded data, all the math and
logic is performed on the grid. MODE ignores the area distortions of
the underlying projection and treats all grid boxes equally. So be
aware of that when running MODE over a large domain where the area of
the grid boxes changes significantly.
2. The area of the cluster forecast object is 1273 and the area of the
cluster observation object is 143. Their intersection is 108 and
union is 1308. The "Intersection_over_Area" is computed as the
intersection area divided by the minimum of the forecast and
observation areas. In this case, that's 108/min(143, 1273) = 0.755.
The nice thing about that measure is that it's always between 0 and 1.
You're right, we could have instead computed the intersection / union,
which would also always be between 0 and 1. I don't remember the
reasoning for doing one versus the other. But hopefully that explains
how it's calculated.
Thanks,
John
On Wed, Nov 19, 2014 at 7:12 AM, Stephanie Landman via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you as always for coming back to me.
> What I would have liked to do with the obs cluster output from the
> netCDF file is to display it in another graphics package alongside
> other verification products already developed in-house. So I guess I
> would have liked to modify the display a bit more and adapt it to
> products the users in the SADC community already feel comfortable
> with. All with the necessary acknowledgments of course. But I can do
> without if it is not possible to extract the information.
>
> My last two questions/confirmations, I promise:
> 1. Just to confirm the units of the centroid distance: number of
> grids? In attached file the distance is 5.22 (green), therefore 5.22
grid boxes?
> 2. I am unsure of the difference between "Intersection_Area" and
> "Intersection_over_Area": again in the attached file, is the
> "Intersection_Area" value of 108 the number of the 1273 fcst grids
and
> 143 obs grids that overlay? And then the "Union_Area" the complete
> number of grids that make up "cluster 1" consisting of 1308 grids?
How
> is "Intersection_over_Area" then computed to get 0.755?
>
> Again, thank you for everything.
>
> Regards,
> Stephanie
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, November 14, 2014 6:49 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> The logic in MODE is pretty straight-forward...
> - Read raw data from the gridded data files you pass it.
> - Apply the raw threshold (raw_thresh) to the raw data and sets
any
> values not meeting the threshold criteria to 0. This is only useful
> in very specific cases, and probably not in yours.
> - Use the specified convolution radius (conv_radius) to smooth the
data.
> - Apply the convolution threshold (conv_thresh) to the smoothed
data
> to define objects.
> - Restore the raw data values back to the interior of the resolved
> objects.
> - Apply the matching/merging logic and writes results (there's a
lot
> of details I'm glossing over here!)
>
> Setting the convolution radius to 0 applies no smoothing, while
> increasing it applies more smoothing. Hopefully with that
> information, you'll be able to adjust the convolution radius and
> threshold to define objects in the way you want. If your input
field
> contains values of 0 and 1, you could either...
> - Apply no smoothing with a convolution radius of 0 and then
> threshold the objects at 1. That will create objects exactly where
> the input values are 1.
> - Apply some amount of smoothing and then threshold the objects
with
> some value less than 1. That will create a smoothed version of the
> binary data.
>
> How you choose to define the objects really just depends on the
> phenomena you're trying to study.
>
> Regarding your last question, unfortunately, I do know have a good
> solution for converting the gridded NetCDF output of MODE to GRIB.
> That NetCDF file does contain several gridded fields, but also
> contains arrays of data - like the lat/lon locations for the objects
> boundaries. That sort of un-gridded data wouldn't fit well into
GRIB.
> What specific field or fields from that NetCDF file are you
interested
> in? And what exactly would you like to do with them? If I know
your
> intended use, I may be able to provide better suggestions.
>
> Thanks,
> John
>
>
>
>
> On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT <
> met_help at ucar.edu
> > wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you very much for the quick assistance. I appreciate it.
> > 1. As you suggested, I have requested our IT department to upgrade
> > the software - hope that happens soon(ish).
> > 2. W.r.t. to the 50 mm threshold: the guidance forecast field is
for
> > severe weather (> 50mm/day), but 50 might be too high for a low
> > resolution observation field (and 1 is too small), so I do still
> > need to test the threshold values to best represent severe
rainfall
> > in the
> TRMM QPE file.
> > 3. Then another question: if I provide MODE with forecast and
> > observation fields both containing only 0's and 1's (i.e.
> > dichotomous forecasts and observations), do I then apply the same
> > values to the observations as you did below with the forecast
field?
> > Or won't that work? I want to test another forecast/observation
data
> > set and is
> wondering if MODE will work...
> > 4. Lastly: I have been trying to read the netCDF output file and
> > extract only the obs_clus_id field. Apart from me having to
convert
> > the whole file to grib format (since most of our programs are
> > written for grib formatted
> > files) - and cdo does not seem to work on this output - can you
> > possibly provide me with either a method or a website that might
help?
> > I have tried reading it with Grads after creating a control file
but
> > was unsuccessful (file below) and as I said before, CDO does not
> > work in converting this to grib1.
> >
> > dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> > title File
> > undef 99999.0
> > xdef dimension1 173 linear 10.000000 0.250000 ydef dimension2 149
> > linear -37.000000 0.250000 tdef dimension3 1 linear 0Z2nov2012
24hr
> > vars 8
> > fcst_raw 1 99 atlas []
> > fcst_obj_raw 1 99 atlas []
> > fcst_obj_id 1 99 atlas []
> > fcst_clus_id 1 99 atlas []
> > obs_raw 1 99 atlas []
> > obs_obj_raw 1 99 atlas []
> > obs_obj_id 1 99 atlas []
> > obs_clus_id 1 99 atlas []
> > endvars
> >
> > Regards and thank you again.
> >
> > Stephanie
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Tuesday, November 11, 2014 10:04 PM
> > To: Stephanie Landman
> > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Stephanie,
> >
> > Thanks for sending that data, it makes it much easier to debug.
> > After looking through it, I have a few suggestions...
> >
> > First, in order to get a quick view of the data files, I ran them
> > through the plot_data_plane tool, like this:
> > METv4.0/bin/plot_data_plane 20121102_HYDRO.grb
20121102_HYDRO.ps
> > 'name="PRES";level="Z0";'
> > METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
> > 20121102_SWFDPH.ps 'name="PRES";level="Z0";'
> >
> > I converted the resulting images to png and attached them.
> >
> > Next, looking in your MODE configuration file, I see that you're
> > using MET version 4.0. There were two significant bugs relating
to
> > MODE that are fixed in METv4.1 and later versions. They are
> > described in the METv4.1 release notes:
> >
> >
> >
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_rele
> > as
> > e_notes.php
> >
> > If possible, I'd suggest updating to the latest version of MET,
5.0.
> >
> > But in my testing, I used METv4.0, since that's what you're using.
> > The issue really is just in how you've set up the configuration
file.
> > I'd suggest trying the attached config file.
> >
> > Here are some of the changes I made...
> >
> > (1) You didn't have all of the object definition criteria
specified
> >for the forecast field, so it was reverting to the values it read
> >from the default configuration file, including a convolution
> >threshold of =5.0.
> > That led to 0 objects in the forecast field.
> >
> > (2) Your forecast is just a binary field of 0's and 1's. It
doesn't
> > make much sense to smooth a binary field that already looks pretty
> > smooth. So I set the forecast conv_radius to 0. And I set the
> > forecast conv_thresh to ==1.0, meaning we'll define an object only
> > where
> the forecast field is 1.
> >
> > (3) In the observation section, you were applying a raw threshold
> > (raw_thresh). That threshold is typically not needed and should
> > only be used when there's a good reason to use it. Basically, we
> > were tossing out any observation values that were less than 50.
> > Instead, I just set the raw_thresh to >=0 to keep all the values.
I
> > used the same convolution radius you did (10) but turned up the
> > convolution
> threshold to >=10.
> >
> > The choice of threshold should really be driven by knowing your
data
> well.
> > What threshold in the observation field is really comparable to
the
> > way the forecast object is defined? Please play around with the
> > observation radius and threshold to define objects that correspond
> > well with the forecast object.
> >
> > (4) I turned off the merging step by setting "merge_flag = NONE".
> > I'd suggest running MODE in as simple a way as possible before
> > adding in additional merging logic.
> >
> > (5) Lastly, I set max_centroid_distance = 1000 so as to have all
> > possible object comparisons be considered.
> >
> > I've attached the first page of the resulting graphical output
from MODE.
> >
> > Please take a look and let me know what additional questions you
have.
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> > >
> > > John,
> > >
> > > Thank you for your willingness to assist me with this. I
appreciate it.
> > > I have placed the data under the landman_data directory:
> > > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> > >
> > > The 20121102_SWFDPH.grb file is the forecast file. I created the
> > > grib files from binary data in order for MODE to recognise the
> > > format, so the variable within the grib files; PRES is just a
> > > default
> parameter.
> > > The forecast field is actually a subjective guidance area of
> > > expected severe weather over the domain (example image
attached).
> > > Therefore the field consist of only 1's and 0's. The
corresponding
> > > PRES parameter in the 20121102_HYDRO.grb file is the
corresponding
> > > QPE field used as ground truth. Attached is also the output that
I
> > > am getting from MODE so
> > far.
> > >
> > > Thank you again for your time and assistance.
> > >
> > > Regards,
> > > Stephanie
> > >
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Monday, November 10, 2014 8:59 PM
> > > To: Stephanie Landman
> > > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> > >
> > > Hi Stephanie,
> > >
> > > I see you're having trouble getting MODE to read data from your
> > > input GRIB file. It'd probably be easiest to just have you send
> > > me some sample data for testing. Please send me a sample
forecast
> > > file, observation file, and MODE configuration file. You can
post
> > > it to our anonymous ftp site following these instructions
> > > (normally I'd point you to info on our website, but it's
currently down):
> > >
> > > ftp ftp.rap.ucar.edu
> > > Name = anonymous
> > > Password = "your email address"
> > > cd incoming/irap/met_help
> > > mkdir landman_data
> > > cd landman_data
> > > put "your data files"
> > > exit
> > >
> > > Please send me an email once you've posted the sample data, and
> > > I'll go grab it and take a look.
> > >
> > > Thanks,
> > > John Halley Gotway
> > > met_help at ucar.edu
> > >
> > >
> > >
> > >
> > > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > > I am trying to get some information from the MODE software and
Laurie
> > > > suggested that you might be able to assist again. I get the
files
> > > > read by MODE but after numerous changes of the
configuration file,
> > > > MODE still does not recognise the forecast field in the
> > > > 20121102_SWFDPH.grb file. MODE does not apply any threshold
value
> > > > to this field and therefore does not compare the forecast
and the
> > > > observation field (SWFDP_MODE.png). Might this be due to
the fact
> > > > that the forecast field only consists of 1's and 0's and
the
> > > > observation is a continuous rainfall field? Or is there
possibly
> > > > some way to get around it?
> > > >
> > > > I know you are busy but would appreciate any assistance in
this
> > > > regard. I have attached all the files required by MODE if
my
> > > > explanation does not make sense and you would like to test
for
> > > > yourself.
> > > > The command I used to execute MODE is:
> > > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
> > > > MODEConfig_APCP_24
> > > >
> > > > Kind regards,
> > > > Stephanie
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about MODE
From: John Halley Gotway
Time: Thu Nov 20 10:05:08 2014
Stephanie,
Glad to hear you're all set! Just let us know if any more issues or
questions arise. We're happy to help.
Out of curiosity, if you're running MODE operationally and posting
results
to a public website, would you mind sending me the location? We'd be
interested to see it.
Thanks,
John
On Thu, Nov 20, 2014 at 5:46 AM, Stephanie Landman via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you again for your help and patience.
> I think I am now on the right track with MODE for our use and will
> definitely apply it to our operational verification suite.
>
> Regards,
> Stephanie
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, November 19, 2014 6:58 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> It's in in general much harder to write a GRIB file than it is to
read it.
> I just tried using the "cdo copy" operator to try to convert the
NetCDF
> output of MODE to GRIB and it failed, as I suspected it would.
There is a
> python utility named "pygrib" which supposedly can read and write
GRIB
> files. However, I haven't used it in the past. There is of course
a way
> to make this work, but I don't have an easy solution for you at this
point.
>
> In answer to your questions...
>
> 1. Yes, the centroid distance, and all distance in MODE are given in
grid
> units. Once MODE reads in the gridded data, all the math and logic
is
> performed on the grid. MODE ignores the area distortions of the
underlying
> projection and treats all grid boxes equally. So be aware of that
when
> running MODE over a large domain where the area of the grid boxes
changes
> significantly.
>
> 2. The area of the cluster forecast object is 1273 and the area of
the
> cluster observation object is 143. Their intersection is 108 and
union is
> 1308. The "Intersection_over_Area" is computed as the intersection
area
> divided by the minimum of the forecast and observation areas. In
this
> case, that's 108/min(143, 1273) = 0.755.
>
> The nice thing about that measure is that it's always between 0 and
1.
> You're right, we could have instead computed the intersection /
union,
> which would also always be between 0 and 1. I don't remember the
reasoning
> for doing one versus the other. But hopefully that explains how
it's
> calculated.
>
> Thanks,
> John
>
>
> On Wed, Nov 19, 2014 at 7:12 AM, Stephanie Landman via RT <
> met_help at ucar.edu
> > wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you as always for coming back to me.
> > What I would have liked to do with the obs cluster output from the
> > netCDF file is to display it in another graphics package alongside
> > other verification products already developed in-house. So I guess
I
> > would have liked to modify the display a bit more and adapt it to
> > products the users in the SADC community already feel comfortable
> > with. All with the necessary acknowledgments of course. But I can
do
> > without if it is not possible to extract the information.
> >
> > My last two questions/confirmations, I promise:
> > 1. Just to confirm the units of the centroid distance: number of
> > grids? In attached file the distance is 5.22 (green), therefore
5.22
> grid boxes?
> > 2. I am unsure of the difference between "Intersection_Area" and
> > "Intersection_over_Area": again in the attached file, is the
> > "Intersection_Area" value of 108 the number of the 1273 fcst grids
and
> > 143 obs grids that overlay? And then the "Union_Area" the complete
> > number of grids that make up "cluster 1" consisting of 1308 grids?
How
> > is "Intersection_over_Area" then computed to get 0.755?
> >
> > Again, thank you for everything.
> >
> > Regards,
> > Stephanie
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Friday, November 14, 2014 6:49 PM
> > To: Stephanie Landman
> > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Stephanie,
> >
> > The logic in MODE is pretty straight-forward...
> > - Read raw data from the gridded data files you pass it.
> > - Apply the raw threshold (raw_thresh) to the raw data and sets
any
> > values not meeting the threshold criteria to 0. This is only
useful
> > in very specific cases, and probably not in yours.
> > - Use the specified convolution radius (conv_radius) to smooth
the
> data.
> > - Apply the convolution threshold (conv_thresh) to the smoothed
data
> > to define objects.
> > - Restore the raw data values back to the interior of the
resolved
> > objects.
> > - Apply the matching/merging logic and writes results (there's a
lot
> > of details I'm glossing over here!)
> >
> > Setting the convolution radius to 0 applies no smoothing, while
> > increasing it applies more smoothing. Hopefully with that
> > information, you'll be able to adjust the convolution radius and
> > threshold to define objects in the way you want. If your input
field
> > contains values of 0 and 1, you could either...
> > - Apply no smoothing with a convolution radius of 0 and then
> > threshold the objects at 1. That will create objects exactly
where
> > the input values are 1.
> > - Apply some amount of smoothing and then threshold the objects
with
> > some value less than 1. That will create a smoothed version of
the
> > binary data.
> >
> > How you choose to define the objects really just depends on the
> > phenomena you're trying to study.
> >
> > Regarding your last question, unfortunately, I do know have a good
> > solution for converting the gridded NetCDF output of MODE to GRIB.
> > That NetCDF file does contain several gridded fields, but also
> > contains arrays of data - like the lat/lon locations for the
objects
> > boundaries. That sort of un-gridded data wouldn't fit well into
GRIB.
> > What specific field or fields from that NetCDF file are you
interested
> > in? And what exactly would you like to do with them? If I know
your
> > intended use, I may be able to provide better suggestions.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> > >
> > > John,
> > >
> > > Thank you very much for the quick assistance. I appreciate it.
> > > 1. As you suggested, I have requested our IT department to
upgrade
> > > the software - hope that happens soon(ish).
> > > 2. W.r.t. to the 50 mm threshold: the guidance forecast field is
for
> > > severe weather (> 50mm/day), but 50 might be too high for a low
> > > resolution observation field (and 1 is too small), so I do still
> > > need to test the threshold values to best represent severe
rainfall
> > > in the
> > TRMM QPE file.
> > > 3. Then another question: if I provide MODE with forecast and
> > > observation fields both containing only 0's and 1's (i.e.
> > > dichotomous forecasts and observations), do I then apply the
same
> > > values to the observations as you did below with the forecast
field?
> > > Or won't that work? I want to test another forecast/observation
data
> > > set and is
> > wondering if MODE will work...
> > > 4. Lastly: I have been trying to read the netCDF output file and
> > > extract only the obs_clus_id field. Apart from me having to
convert
> > > the whole file to grib format (since most of our programs are
> > > written for grib formatted
> > > files) - and cdo does not seem to work on this output - can you
> > > possibly provide me with either a method or a website that might
help?
> > > I have tried reading it with Grads after creating a control file
but
> > > was unsuccessful (file below) and as I said before, CDO does not
> > > work in converting this to grib1.
> > >
> > > dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> > > title File
> > > undef 99999.0
> > > xdef dimension1 173 linear 10.000000 0.250000 ydef dimension2
149
> > > linear -37.000000 0.250000 tdef dimension3 1 linear 0Z2nov2012
24hr
> > > vars 8
> > > fcst_raw 1 99 atlas []
> > > fcst_obj_raw 1 99 atlas []
> > > fcst_obj_id 1 99 atlas []
> > > fcst_clus_id 1 99 atlas []
> > > obs_raw 1 99 atlas []
> > > obs_obj_raw 1 99 atlas []
> > > obs_obj_id 1 99 atlas []
> > > obs_clus_id 1 99 atlas []
> > > endvars
> > >
> > > Regards and thank you again.
> > >
> > > Stephanie
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Tuesday, November 11, 2014 10:04 PM
> > > To: Stephanie Landman
> > > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> > >
> > > Stephanie,
> > >
> > > Thanks for sending that data, it makes it much easier to debug.
> > > After looking through it, I have a few suggestions...
> > >
> > > First, in order to get a quick view of the data files, I ran
them
> > > through the plot_data_plane tool, like this:
> > > METv4.0/bin/plot_data_plane 20121102_HYDRO.grb
20121102_HYDRO.ps
> > > 'name="PRES";level="Z0";'
> > > METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
> > > 20121102_SWFDPH.ps 'name="PRES";level="Z0";'
> > >
> > > I converted the resulting images to png and attached them.
> > >
> > > Next, looking in your MODE configuration file, I see that you're
> > > using MET version 4.0. There were two significant bugs relating
to
> > > MODE that are fixed in METv4.1 and later versions. They are
> > > described in the METv4.1 release notes:
> > >
> > >
> > >
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_rele
> > > as
> > > e_notes.php
> > >
> > > If possible, I'd suggest updating to the latest version of MET,
5.0.
> > >
> > > But in my testing, I used METv4.0, since that's what you're
using.
> > > The issue really is just in how you've set up the configuration
file.
> > > I'd suggest trying the attached config file.
> > >
> > > Here are some of the changes I made...
> > >
> > > (1) You didn't have all of the object definition criteria
specified
> > >for the forecast field, so it was reverting to the values it read
> > >from the default configuration file, including a convolution
> > >threshold of =5.0.
> > > That led to 0 objects in the forecast field.
> > >
> > > (2) Your forecast is just a binary field of 0's and 1's. It
doesn't
> > > make much sense to smooth a binary field that already looks
pretty
> > > smooth. So I set the forecast conv_radius to 0. And I set the
> > > forecast conv_thresh to ==1.0, meaning we'll define an object
only
> > > where
> > the forecast field is 1.
> > >
> > > (3) In the observation section, you were applying a raw
threshold
> > > (raw_thresh). That threshold is typically not needed and should
> > > only be used when there's a good reason to use it. Basically,
we
> > > were tossing out any observation values that were less than 50.
> > > Instead, I just set the raw_thresh to >=0 to keep all the
values. I
> > > used the same convolution radius you did (10) but turned up the
> > > convolution
> > threshold to >=10.
> > >
> > > The choice of threshold should really be driven by knowing your
data
> > well.
> > > What threshold in the observation field is really comparable to
the
> > > way the forecast object is defined? Please play around with the
> > > observation radius and threshold to define objects that
correspond
> > > well with the forecast object.
> > >
> > > (4) I turned off the merging step by setting "merge_flag =
NONE".
> > > I'd suggest running MODE in as simple a way as possible before
> > > adding in additional merging logic.
> > >
> > > (5) Lastly, I set max_centroid_distance = 1000 so as to have all
> > > possible object comparisons be considered.
> > >
> > > I've attached the first page of the resulting graphical output
from
> MODE.
> > >
> > > Please take a look and let me know what additional questions you
have.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676
>
> > > >
> > > > John,
> > > >
> > > > Thank you for your willingness to assist me with this. I
appreciate
> it.
> > > > I have placed the data under the landman_data directory:
> > > > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > > > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > > > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> > > >
> > > > The 20121102_SWFDPH.grb file is the forecast file. I created
the
> > > > grib files from binary data in order for MODE to recognise the
> > > > format, so the variable within the grib files; PRES is just a
> > > > default
> > parameter.
> > > > The forecast field is actually a subjective guidance area of
> > > > expected severe weather over the domain (example image
attached).
> > > > Therefore the field consist of only 1's and 0's. The
corresponding
> > > > PRES parameter in the 20121102_HYDRO.grb file is the
corresponding
> > > > QPE field used as ground truth. Attached is also the output
that I
> > > > am getting from MODE so
> > > far.
> > > >
> > > > Thank you again for your time and assistance.
> > > >
> > > > Regards,
> > > > Stephanie
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Monday, November 10, 2014 8:59 PM
> > > > To: Stephanie Landman
> > > > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> > > >
> > > > Hi Stephanie,
> > > >
> > > > I see you're having trouble getting MODE to read data from
your
> > > > input GRIB file. It'd probably be easiest to just have you
send
> > > > me some sample data for testing. Please send me a sample
forecast
> > > > file, observation file, and MODE configuration file. You can
post
> > > > it to our anonymous ftp site following these instructions
> > > > (normally I'd point you to info on our website, but it's
currently
> down):
> > > >
> > > > ftp ftp.rap.ucar.edu
> > > > Name = anonymous
> > > > Password = "your email address"
> > > > cd incoming/irap/met_help
> > > > mkdir landman_data
> > > > cd landman_data
> > > > put "your data files"
> > > > exit
> > > >
> > > > Please send me an email once you've posted the sample data,
and
> > > > I'll go grab it and take a look.
> > > >
> > > > Thanks,
> > > > John Halley Gotway
> > > > met_help at ucar.edu
> > > >
> > > >
> > > >
> > > >
> > > > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > > > I am trying to get some information from the MODE software
and
> Laurie
> > > > > suggested that you might be able to assist again. I get
the
> files
> > > > > read by MODE but after numerous changes of the
configuration
> file,
> > > > > MODE still does not recognise the forecast field in the
> > > > > 20121102_SWFDPH.grb file. MODE does not apply any
threshold
> value
> > > > > to this field and therefore does not compare the forecast
and
> the
> > > > > observation field (SWFDP_MODE.png). Might this be due to
the
> fact
> > > > > that the forecast field only consists of 1's and 0's and
the
> > > > > observation is a continuous rainfall field? Or is there
possibly
> > > > > some way to get around it?
> > > > >
> > > > > I know you are busy but would appreciate any assistance in
this
> > > > > regard. I have attached all the files required by MODE if
my
> > > > > explanation does not make sense and you would like to
test for
> > > > > yourself.
> > > > > The command I used to execute MODE is:
> > > > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
> > > > > MODEConfig_APCP_24
> > > > >
> > > > > Kind regards,
> > > > > Stephanie
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #69676] Questions about MODE
From: Stephanie Landman
Time: Thu Nov 20 12:18:41 2014
John,
Yes of course, will be happy to. I will even send you the product
before hand; just for you to double check that I am not interpreting
the output incorrectly and that you feel comfortable with me not
butchering your product :)
Regards and thanks again,
Stephanie
________________________________________
From: John Halley Gotway via RT [met_help at ucar.edu]
Sent: 20 November 2014 07:05 PM
To: Stephanie Landman
Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
Stephanie,
Glad to hear you're all set! Just let us know if any more issues or
questions arise. We're happy to help.
Out of curiosity, if you're running MODE operationally and posting
results
to a public website, would you mind sending me the location? We'd be
interested to see it.
Thanks,
John
On Thu, Nov 20, 2014 at 5:46 AM, Stephanie Landman via RT
<met_help at ucar.edu
> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Thank you again for your help and patience.
> I think I am now on the right track with MODE for our use and will
> definitely apply it to our operational verification suite.
>
> Regards,
> Stephanie
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, November 19, 2014 6:58 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> It's in in general much harder to write a GRIB file than it is to
read it.
> I just tried using the "cdo copy" operator to try to convert the
NetCDF
> output of MODE to GRIB and it failed, as I suspected it would.
There is a
> python utility named "pygrib" which supposedly can read and write
GRIB
> files. However, I haven't used it in the past. There is of course
a way
> to make this work, but I don't have an easy solution for you at this
point.
>
> In answer to your questions...
>
> 1. Yes, the centroid distance, and all distance in MODE are given in
grid
> units. Once MODE reads in the gridded data, all the math and logic
is
> performed on the grid. MODE ignores the area distortions of the
underlying
> projection and treats all grid boxes equally. So be aware of that
when
> running MODE over a large domain where the area of the grid boxes
changes
> significantly.
>
> 2. The area of the cluster forecast object is 1273 and the area of
the
> cluster observation object is 143. Their intersection is 108 and
union is
> 1308. The "Intersection_over_Area" is computed as the intersection
area
> divided by the minimum of the forecast and observation areas. In
this
> case, that's 108/min(143, 1273) = 0.755.
>
> The nice thing about that measure is that it's always between 0 and
1.
> You're right, we could have instead computed the intersection /
union,
> which would also always be between 0 and 1. I don't remember the
reasoning
> for doing one versus the other. But hopefully that explains how
it's
> calculated.
>
> Thanks,
> John
>
>
> On Wed, Nov 19, 2014 at 7:12 AM, Stephanie Landman via RT <
> met_help at ucar.edu
> > wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you as always for coming back to me.
> > What I would have liked to do with the obs cluster output from the
> > netCDF file is to display it in another graphics package alongside
> > other verification products already developed in-house. So I guess
I
> > would have liked to modify the display a bit more and adapt it to
> > products the users in the SADC community already feel comfortable
> > with. All with the necessary acknowledgments of course. But I can
do
> > without if it is not possible to extract the information.
> >
> > My last two questions/confirmations, I promise:
> > 1. Just to confirm the units of the centroid distance: number of
> > grids? In attached file the distance is 5.22 (green), therefore
5.22
> grid boxes?
> > 2. I am unsure of the difference between "Intersection_Area" and
> > "Intersection_over_Area": again in the attached file, is the
> > "Intersection_Area" value of 108 the number of the 1273 fcst grids
and
> > 143 obs grids that overlay? And then the "Union_Area" the complete
> > number of grids that make up "cluster 1" consisting of 1308 grids?
How
> > is "Intersection_over_Area" then computed to get 0.755?
> >
> > Again, thank you for everything.
> >
> > Regards,
> > Stephanie
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Friday, November 14, 2014 6:49 PM
> > To: Stephanie Landman
> > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Stephanie,
> >
> > The logic in MODE is pretty straight-forward...
> > - Read raw data from the gridded data files you pass it.
> > - Apply the raw threshold (raw_thresh) to the raw data and sets
any
> > values not meeting the threshold criteria to 0. This is only
useful
> > in very specific cases, and probably not in yours.
> > - Use the specified convolution radius (conv_radius) to smooth
the
> data.
> > - Apply the convolution threshold (conv_thresh) to the smoothed
data
> > to define objects.
> > - Restore the raw data values back to the interior of the
resolved
> > objects.
> > - Apply the matching/merging logic and writes results (there's a
lot
> > of details I'm glossing over here!)
> >
> > Setting the convolution radius to 0 applies no smoothing, while
> > increasing it applies more smoothing. Hopefully with that
> > information, you'll be able to adjust the convolution radius and
> > threshold to define objects in the way you want. If your input
field
> > contains values of 0 and 1, you could either...
> > - Apply no smoothing with a convolution radius of 0 and then
> > threshold the objects at 1. That will create objects exactly
where
> > the input values are 1.
> > - Apply some amount of smoothing and then threshold the objects
with
> > some value less than 1. That will create a smoothed version of
the
> > binary data.
> >
> > How you choose to define the objects really just depends on the
> > phenomena you're trying to study.
> >
> > Regarding your last question, unfortunately, I do know have a good
> > solution for converting the gridded NetCDF output of MODE to GRIB.
> > That NetCDF file does contain several gridded fields, but also
> > contains arrays of data - like the lat/lon locations for the
objects
> > boundaries. That sort of un-gridded data wouldn't fit well into
GRIB.
> > What specific field or fields from that NetCDF file are you
interested
> > in? And what exactly would you like to do with them? If I know
your
> > intended use, I may be able to provide better suggestions.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> > >
> > > John,
> > >
> > > Thank you very much for the quick assistance. I appreciate it.
> > > 1. As you suggested, I have requested our IT department to
upgrade
> > > the software - hope that happens soon(ish).
> > > 2. W.r.t. to the 50 mm threshold: the guidance forecast field is
for
> > > severe weather (> 50mm/day), but 50 might be too high for a low
> > > resolution observation field (and 1 is too small), so I do still
> > > need to test the threshold values to best represent severe
rainfall
> > > in the
> > TRMM QPE file.
> > > 3. Then another question: if I provide MODE with forecast and
> > > observation fields both containing only 0's and 1's (i.e.
> > > dichotomous forecasts and observations), do I then apply the
same
> > > values to the observations as you did below with the forecast
field?
> > > Or won't that work? I want to test another forecast/observation
data
> > > set and is
> > wondering if MODE will work...
> > > 4. Lastly: I have been trying to read the netCDF output file and
> > > extract only the obs_clus_id field. Apart from me having to
convert
> > > the whole file to grib format (since most of our programs are
> > > written for grib formatted
> > > files) - and cdo does not seem to work on this output - can you
> > > possibly provide me with either a method or a website that might
help?
> > > I have tried reading it with Grads after creating a control file
but
> > > was unsuccessful (file below) and as I said before, CDO does not
> > > work in converting this to grib1.
> > >
> > > dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> > > title File
> > > undef 99999.0
> > > xdef dimension1 173 linear 10.000000 0.250000 ydef dimension2
149
> > > linear -37.000000 0.250000 tdef dimension3 1 linear 0Z2nov2012
24hr
> > > vars 8
> > > fcst_raw 1 99 atlas []
> > > fcst_obj_raw 1 99 atlas []
> > > fcst_obj_id 1 99 atlas []
> > > fcst_clus_id 1 99 atlas []
> > > obs_raw 1 99 atlas []
> > > obs_obj_raw 1 99 atlas []
> > > obs_obj_id 1 99 atlas []
> > > obs_clus_id 1 99 atlas []
> > > endvars
> > >
> > > Regards and thank you again.
> > >
> > > Stephanie
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Tuesday, November 11, 2014 10:04 PM
> > > To: Stephanie Landman
> > > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> > >
> > > Stephanie,
> > >
> > > Thanks for sending that data, it makes it much easier to debug.
> > > After looking through it, I have a few suggestions...
> > >
> > > First, in order to get a quick view of the data files, I ran
them
> > > through the plot_data_plane tool, like this:
> > > METv4.0/bin/plot_data_plane 20121102_HYDRO.grb
20121102_HYDRO.ps
> > > 'name="PRES";level="Z0";'
> > > METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
> > > 20121102_SWFDPH.ps 'name="PRES";level="Z0";'
> > >
> > > I converted the resulting images to png and attached them.
> > >
> > > Next, looking in your MODE configuration file, I see that you're
> > > using MET version 4.0. There were two significant bugs relating
to
> > > MODE that are fixed in METv4.1 and later versions. They are
> > > described in the METv4.1 release notes:
> > >
> > >
> > >
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_rele
> > > as
> > > e_notes.php
> > >
> > > If possible, I'd suggest updating to the latest version of MET,
5.0.
> > >
> > > But in my testing, I used METv4.0, since that's what you're
using.
> > > The issue really is just in how you've set up the configuration
file.
> > > I'd suggest trying the attached config file.
> > >
> > > Here are some of the changes I made...
> > >
> > > (1) You didn't have all of the object definition criteria
specified
> > >for the forecast field, so it was reverting to the values it read
> > >from the default configuration file, including a convolution
> > >threshold of =5.0.
> > > That led to 0 objects in the forecast field.
> > >
> > > (2) Your forecast is just a binary field of 0's and 1's. It
doesn't
> > > make much sense to smooth a binary field that already looks
pretty
> > > smooth. So I set the forecast conv_radius to 0. And I set the
> > > forecast conv_thresh to ==1.0, meaning we'll define an object
only
> > > where
> > the forecast field is 1.
> > >
> > > (3) In the observation section, you were applying a raw
threshold
> > > (raw_thresh). That threshold is typically not needed and should
> > > only be used when there's a good reason to use it. Basically,
we
> > > were tossing out any observation values that were less than 50.
> > > Instead, I just set the raw_thresh to >=0 to keep all the
values. I
> > > used the same convolution radius you did (10) but turned up the
> > > convolution
> > threshold to >=10.
> > >
> > > The choice of threshold should really be driven by knowing your
data
> > well.
> > > What threshold in the observation field is really comparable to
the
> > > way the forecast object is defined? Please play around with the
> > > observation radius and threshold to define objects that
correspond
> > > well with the forecast object.
> > >
> > > (4) I turned off the merging step by setting "merge_flag =
NONE".
> > > I'd suggest running MODE in as simple a way as possible before
> > > adding in additional merging logic.
> > >
> > > (5) Lastly, I set max_centroid_distance = 1000 so as to have all
> > > possible object comparisons be considered.
> > >
> > > I've attached the first page of the resulting graphical output
from
> MODE.
> > >
> > > Please take a look and let me know what additional questions you
have.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676
>
> > > >
> > > > John,
> > > >
> > > > Thank you for your willingness to assist me with this. I
appreciate
> it.
> > > > I have placed the data under the landman_data directory:
> > > > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > > > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > > > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> > > >
> > > > The 20121102_SWFDPH.grb file is the forecast file. I created
the
> > > > grib files from binary data in order for MODE to recognise the
> > > > format, so the variable within the grib files; PRES is just a
> > > > default
> > parameter.
> > > > The forecast field is actually a subjective guidance area of
> > > > expected severe weather over the domain (example image
attached).
> > > > Therefore the field consist of only 1's and 0's. The
corresponding
> > > > PRES parameter in the 20121102_HYDRO.grb file is the
corresponding
> > > > QPE field used as ground truth. Attached is also the output
that I
> > > > am getting from MODE so
> > > far.
> > > >
> > > > Thank you again for your time and assistance.
> > > >
> > > > Regards,
> > > > Stephanie
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Monday, November 10, 2014 8:59 PM
> > > > To: Stephanie Landman
> > > > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> > > >
> > > > Hi Stephanie,
> > > >
> > > > I see you're having trouble getting MODE to read data from
your
> > > > input GRIB file. It'd probably be easiest to just have you
send
> > > > me some sample data for testing. Please send me a sample
forecast
> > > > file, observation file, and MODE configuration file. You can
post
> > > > it to our anonymous ftp site following these instructions
> > > > (normally I'd point you to info on our website, but it's
currently
> down):
> > > >
> > > > ftp ftp.rap.ucar.edu
> > > > Name = anonymous
> > > > Password = "your email address"
> > > > cd incoming/irap/met_help
> > > > mkdir landman_data
> > > > cd landman_data
> > > > put "your data files"
> > > > exit
> > > >
> > > > Please send me an email once you've posted the sample data,
and
> > > > I'll go grab it and take a look.
> > > >
> > > > Thanks,
> > > > John Halley Gotway
> > > > met_help at ucar.edu
> > > >
> > > >
> > > >
> > > >
> > > > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > > > I am trying to get some information from the MODE software
and
> Laurie
> > > > > suggested that you might be able to assist again. I get
the
> files
> > > > > read by MODE but after numerous changes of the
configuration
> file,
> > > > > MODE still does not recognise the forecast field in the
> > > > > 20121102_SWFDPH.grb file. MODE does not apply any
threshold
> value
> > > > > to this field and therefore does not compare the forecast
and
> the
> > > > > observation field (SWFDP_MODE.png). Might this be due to
the
> fact
> > > > > that the forecast field only consists of 1's and 0's and
the
> > > > > observation is a continuous rainfall field? Or is there
possibly
> > > > > some way to get around it?
> > > > >
> > > > > I know you are busy but would appreciate any assistance in
this
> > > > > regard. I have attached all the files required by MODE if
my
> > > > > explanation does not make sense and you would like to
test for
> > > > > yourself.
> > > > > The command I used to execute MODE is:
> > > > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
> > > > > MODEConfig_APCP_24
> > > > >
> > > > > Kind regards,
> > > > > Stephanie
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Questions about MODE
From: John Halley Gotway
Time: Thu Nov 20 16:16:15 2014
Sounds good. I'll go ahead and resolve this helpdesk ticket now.
Thanks,
John
On Thu, Nov 20, 2014 at 12:18 PM, Stephanie Landman via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
>
> John,
>
> Yes of course, will be happy to. I will even send you the product
before
> hand; just for you to double check that I am not interpreting the
output
> incorrectly and that you feel comfortable with me not butchering
your
> product :)
>
> Regards and thanks again,
> Stephanie
>
> ________________________________________
> From: John Halley Gotway via RT [met_help at ucar.edu]
> Sent: 20 November 2014 07:05 PM
> To: Stephanie Landman
> Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
>
> Stephanie,
>
> Glad to hear you're all set! Just let us know if any more issues or
> questions arise. We're happy to help.
>
> Out of curiosity, if you're running MODE operationally and posting
results
> to a public website, would you mind sending me the location? We'd
be
> interested to see it.
>
> Thanks,
> John
>
> On Thu, Nov 20, 2014 at 5:46 AM, Stephanie Landman via RT <
> met_help at ucar.edu
> > wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> >
> > John,
> >
> > Thank you again for your help and patience.
> > I think I am now on the right track with MODE for our use and will
> > definitely apply it to our operational verification suite.
> >
> > Regards,
> > Stephanie
> >
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Wednesday, November 19, 2014 6:58 PM
> > To: Stephanie Landman
> > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> >
> > Stephanie,
> >
> > It's in in general much harder to write a GRIB file than it is to
read
> it.
> > I just tried using the "cdo copy" operator to try to convert the
NetCDF
> > output of MODE to GRIB and it failed, as I suspected it would.
There is
> a
> > python utility named "pygrib" which supposedly can read and write
GRIB
> > files. However, I haven't used it in the past. There is of
course a way
> > to make this work, but I don't have an easy solution for you at
this
> point.
> >
> > In answer to your questions...
> >
> > 1. Yes, the centroid distance, and all distance in MODE are given
in grid
> > units. Once MODE reads in the gridded data, all the math and
logic is
> > performed on the grid. MODE ignores the area distortions of the
> underlying
> > projection and treats all grid boxes equally. So be aware of that
when
> > running MODE over a large domain where the area of the grid boxes
changes
> > significantly.
> >
> > 2. The area of the cluster forecast object is 1273 and the area of
the
> > cluster observation object is 143. Their intersection is 108 and
union
> is
> > 1308. The "Intersection_over_Area" is computed as the
intersection area
> > divided by the minimum of the forecast and observation areas. In
this
> > case, that's 108/min(143, 1273) = 0.755.
> >
> > The nice thing about that measure is that it's always between 0
and 1.
> > You're right, we could have instead computed the intersection /
union,
> > which would also always be between 0 and 1. I don't remember the
> reasoning
> > for doing one versus the other. But hopefully that explains how
it's
> > calculated.
> >
> > Thanks,
> > John
> >
> >
> > On Wed, Nov 19, 2014 at 7:12 AM, Stephanie Landman via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> > >
> > > John,
> > >
> > > Thank you as always for coming back to me.
> > > What I would have liked to do with the obs cluster output from
the
> > > netCDF file is to display it in another graphics package
alongside
> > > other verification products already developed in-house. So I
guess I
> > > would have liked to modify the display a bit more and adapt it
to
> > > products the users in the SADC community already feel
comfortable
> > > with. All with the necessary acknowledgments of course. But I
can do
> > > without if it is not possible to extract the information.
> > >
> > > My last two questions/confirmations, I promise:
> > > 1. Just to confirm the units of the centroid distance: number of
> > > grids? In attached file the distance is 5.22 (green), therefore
5.22
> > grid boxes?
> > > 2. I am unsure of the difference between "Intersection_Area" and
> > > "Intersection_over_Area": again in the attached file, is the
> > > "Intersection_Area" value of 108 the number of the 1273 fcst
grids and
> > > 143 obs grids that overlay? And then the "Union_Area" the
complete
> > > number of grids that make up "cluster 1" consisting of 1308
grids? How
> > > is "Intersection_over_Area" then computed to get 0.755?
> > >
> > > Again, thank you for everything.
> > >
> > > Regards,
> > > Stephanie
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Friday, November 14, 2014 6:49 PM
> > > To: Stephanie Landman
> > > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> > >
> > > Stephanie,
> > >
> > > The logic in MODE is pretty straight-forward...
> > > - Read raw data from the gridded data files you pass it.
> > > - Apply the raw threshold (raw_thresh) to the raw data and
sets any
> > > values not meeting the threshold criteria to 0. This is only
useful
> > > in very specific cases, and probably not in yours.
> > > - Use the specified convolution radius (conv_radius) to smooth
the
> > data.
> > > - Apply the convolution threshold (conv_thresh) to the
smoothed data
> > > to define objects.
> > > - Restore the raw data values back to the interior of the
resolved
> > > objects.
> > > - Apply the matching/merging logic and writes results (there's
a lot
> > > of details I'm glossing over here!)
> > >
> > > Setting the convolution radius to 0 applies no smoothing, while
> > > increasing it applies more smoothing. Hopefully with that
> > > information, you'll be able to adjust the convolution radius and
> > > threshold to define objects in the way you want. If your input
field
> > > contains values of 0 and 1, you could either...
> > > - Apply no smoothing with a convolution radius of 0 and then
> > > threshold the objects at 1. That will create objects exactly
where
> > > the input values are 1.
> > > - Apply some amount of smoothing and then threshold the
objects with
> > > some value less than 1. That will create a smoothed version of
the
> > > binary data.
> > >
> > > How you choose to define the objects really just depends on the
> > > phenomena you're trying to study.
> > >
> > > Regarding your last question, unfortunately, I do know have a
good
> > > solution for converting the gridded NetCDF output of MODE to
GRIB.
> > > That NetCDF file does contain several gridded fields, but also
> > > contains arrays of data - like the lat/lon locations for the
objects
> > > boundaries. That sort of un-gridded data wouldn't fit well into
GRIB.
> > > What specific field or fields from that NetCDF file are you
interested
> > > in? And what exactly would you like to do with them? If I know
your
> > > intended use, I may be able to provide better suggestions.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > >
> > > On Thu, Nov 13, 2014 at 5:42 AM, Stephanie Landman via RT <
> > > met_help at ucar.edu
> > > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676
>
> > > >
> > > > John,
> > > >
> > > > Thank you very much for the quick assistance. I appreciate it.
> > > > 1. As you suggested, I have requested our IT department to
upgrade
> > > > the software - hope that happens soon(ish).
> > > > 2. W.r.t. to the 50 mm threshold: the guidance forecast field
is for
> > > > severe weather (> 50mm/day), but 50 might be too high for a
low
> > > > resolution observation field (and 1 is too small), so I do
still
> > > > need to test the threshold values to best represent severe
rainfall
> > > > in the
> > > TRMM QPE file.
> > > > 3. Then another question: if I provide MODE with forecast and
> > > > observation fields both containing only 0's and 1's (i.e.
> > > > dichotomous forecasts and observations), do I then apply the
same
> > > > values to the observations as you did below with the forecast
field?
> > > > Or won't that work? I want to test another
forecast/observation data
> > > > set and is
> > > wondering if MODE will work...
> > > > 4. Lastly: I have been trying to read the netCDF output file
and
> > > > extract only the obs_clus_id field. Apart from me having to
convert
> > > > the whole file to grib format (since most of our programs are
> > > > written for grib formatted
> > > > files) - and cdo does not seem to work on this output - can
you
> > > > possibly provide me with either a method or a website that
might
> help?
> > > > I have tried reading it with Grads after creating a control
file but
> > > > was unsuccessful (file below) and as I said before, CDO does
not
> > > > work in converting this to grib1.
> > > >
> > > > dset ^mode_000000L_20121029_000000V_000000A_obj.nc
> > > > title File
> > > > undef 99999.0
> > > > xdef dimension1 173 linear 10.000000 0.250000 ydef dimension2
149
> > > > linear -37.000000 0.250000 tdef dimension3 1 linear 0Z2nov2012
24hr
> > > > vars 8
> > > > fcst_raw 1 99 atlas []
> > > > fcst_obj_raw 1 99 atlas []
> > > > fcst_obj_id 1 99 atlas []
> > > > fcst_clus_id 1 99 atlas []
> > > > obs_raw 1 99 atlas []
> > > > obs_obj_raw 1 99 atlas []
> > > > obs_obj_id 1 99 atlas []
> > > > obs_clus_id 1 99 atlas []
> > > > endvars
> > > >
> > > > Regards and thank you again.
> > > >
> > > > Stephanie
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Tuesday, November 11, 2014 10:04 PM
> > > > To: Stephanie Landman
> > > > Subject: Re: [rt.rap.ucar.edu #69676] Questions about MODE
> > > >
> > > > Stephanie,
> > > >
> > > > Thanks for sending that data, it makes it much easier to
debug.
> > > > After looking through it, I have a few suggestions...
> > > >
> > > > First, in order to get a quick view of the data files, I ran
them
> > > > through the plot_data_plane tool, like this:
> > > > METv4.0/bin/plot_data_plane 20121102_HYDRO.grb
20121102_HYDRO.ps
> > > > 'name="PRES";level="Z0";'
> > > > METv4.0/bin/plot_data_plane 20121102_SWFDPH.grb
> > > > 20121102_SWFDPH.ps 'name="PRES";level="Z0";'
> > > >
> > > > I converted the resulting images to png and attached them.
> > > >
> > > > Next, looking in your MODE configuration file, I see that
you're
> > > > using MET version 4.0. There were two significant bugs
relating to
> > > > MODE that are fixed in METv4.1 and later versions. They are
> > > > described in the METv4.1 release notes:
> > > >
> > > >
> > > >
http://www.dtcenter.org/met/users/support/release_notes/METv4.1_rele
> > > > as
> > > > e_notes.php
> > > >
> > > > If possible, I'd suggest updating to the latest version of
MET, 5.0.
> > > >
> > > > But in my testing, I used METv4.0, since that's what you're
using.
> > > > The issue really is just in how you've set up the
configuration file.
> > > > I'd suggest trying the attached config file.
> > > >
> > > > Here are some of the changes I made...
> > > >
> > > > (1) You didn't have all of the object definition criteria
specified
> > > >for the forecast field, so it was reverting to the values it
read
> > > >from the default configuration file, including a convolution
> > > >threshold of =5.0.
> > > > That led to 0 objects in the forecast field.
> > > >
> > > > (2) Your forecast is just a binary field of 0's and 1's. It
doesn't
> > > > make much sense to smooth a binary field that already looks
pretty
> > > > smooth. So I set the forecast conv_radius to 0. And I set
the
> > > > forecast conv_thresh to ==1.0, meaning we'll define an object
only
> > > > where
> > > the forecast field is 1.
> > > >
> > > > (3) In the observation section, you were applying a raw
threshold
> > > > (raw_thresh). That threshold is typically not needed and
should
> > > > only be used when there's a good reason to use it. Basically,
we
> > > > were tossing out any observation values that were less than
50.
> > > > Instead, I just set the raw_thresh to >=0 to keep all the
values. I
> > > > used the same convolution radius you did (10) but turned up
the
> > > > convolution
> > > threshold to >=10.
> > > >
> > > > The choice of threshold should really be driven by knowing
your data
> > > well.
> > > > What threshold in the observation field is really comparable
to the
> > > > way the forecast object is defined? Please play around with
the
> > > > observation radius and threshold to define objects that
correspond
> > > > well with the forecast object.
> > > >
> > > > (4) I turned off the merging step by setting "merge_flag =
NONE".
> > > > I'd suggest running MODE in as simple a way as possible before
> > > > adding in additional merging logic.
> > > >
> > > > (5) Lastly, I set max_centroid_distance = 1000 so as to have
all
> > > > possible object comparisons be considered.
> > > >
> > > > I've attached the first page of the resulting graphical output
from
> > MODE.
> > > >
> > > > Please take a look and let me know what additional questions
you
> have.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > > On Mon, Nov 10, 2014 at 11:14 PM, Stephanie Landman via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=69676 >
> > > > >
> > > > > John,
> > > > >
> > > > > Thank you for your willingness to assist me with this. I
appreciate
> > it.
> > > > > I have placed the data under the landman_data directory:
> > > > > -rw-r--r-- 1 120 120 92326 Nov 11 06:02 20121102_HYDRO.grb
> > > > > -rw-r--r-- 1 120 120 38750 Nov 11 06:02 20121102_SWFDPH.grb
> > > > > -rw-r--r-- 1 120 120 4598 Nov 11 06:02 MODEConfig_APCP_24
> > > > >
> > > > > The 20121102_SWFDPH.grb file is the forecast file. I created
the
> > > > > grib files from binary data in order for MODE to recognise
the
> > > > > format, so the variable within the grib files; PRES is just
a
> > > > > default
> > > parameter.
> > > > > The forecast field is actually a subjective guidance area of
> > > > > expected severe weather over the domain (example image
attached).
> > > > > Therefore the field consist of only 1's and 0's. The
corresponding
> > > > > PRES parameter in the 20121102_HYDRO.grb file is the
corresponding
> > > > > QPE field used as ground truth. Attached is also the output
that I
> > > > > am getting from MODE so
> > > > far.
> > > > >
> > > > > Thank you again for your time and assistance.
> > > > >
> > > > > Regards,
> > > > > Stephanie
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > > Sent: Monday, November 10, 2014 8:59 PM
> > > > > To: Stephanie Landman
> > > > > Subject: [rt.rap.ucar.edu #69676] Questions about MODE
> > > > >
> > > > > Hi Stephanie,
> > > > >
> > > > > I see you're having trouble getting MODE to read data from
your
> > > > > input GRIB file. It'd probably be easiest to just have you
send
> > > > > me some sample data for testing. Please send me a sample
forecast
> > > > > file, observation file, and MODE configuration file. You
can post
> > > > > it to our anonymous ftp site following these instructions
> > > > > (normally I'd point you to info on our website, but it's
currently
> > down):
> > > > >
> > > > > ftp ftp.rap.ucar.edu
> > > > > Name = anonymous
> > > > > Password = "your email address"
> > > > > cd incoming/irap/met_help
> > > > > mkdir landman_data
> > > > > cd landman_data
> > > > > put "your data files"
> > > > > exit
> > > > >
> > > > > Please send me an email once you've posted the sample data,
and
> > > > > I'll go grab it and take a look.
> > > > >
> > > > > Thanks,
> > > > > John Halley Gotway
> > > > > met_help at ucar.edu
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon Nov 10 11:54:11 2014, johnhg wrote:
> > > > > > I am trying to get some information from the MODE software
and
> > Laurie
> > > > > > suggested that you might be able to assist again. I get
the
> > files
> > > > > > read by MODE but after numerous changes of the
configuration
> > file,
> > > > > > MODE still does not recognise the forecast field in the
> > > > > > 20121102_SWFDPH.grb file. MODE does not apply any
threshold
> > value
> > > > > > to this field and therefore does not compare the
forecast and
> > the
> > > > > > observation field (SWFDP_MODE.png). Might this be due
to the
> > fact
> > > > > > that the forecast field only consists of 1's and 0's
and the
> > > > > > observation is a continuous rainfall field? Or is there
> possibly
> > > > > > some way to get around it?
> > > > > >
> > > > > > I know you are busy but would appreciate any assistance in
this
> > > > > > regard. I have attached all the files required by MODE
if my
> > > > > > explanation does not make sense and you would like to
test for
> > > > > > yourself.
> > > > > > The command I used to execute MODE is:
> > > > > > /bin/mode 20121102_SWFDPH.grb 20121102_HYDRO.grb
> > > > > > MODEConfig_APCP_24
> > > > > >
> > > > > > Kind regards,
> > > > > > Stephanie
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
------------------------------------------------
More information about the Met_help
mailing list