[Met_help] [rt.rap.ucar.edu #84210] History for Fwd: numbering of objects in MTD
John Halley Gotway via RT
met_help at ucar.edu
Wed Jul 10 17:01:09 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I am working with MTD to look at atmospheric rivers (ARs).
Things seem to be working well, but I have one point of confusion.
At the first time there is a cluster numbered 1; it disappears and the next
cluster is #2; it lasts for a couple days and then disappears; then the
same thing happens with cluster #3 (this is all as expected).
However, the next cluster that appears is again numbered #1 - many time
periods after the previous cluster #1 disappeared. (And then the final
cluster is #4)
(I attempted to attach the netcdf file to clarify - but it was about 23 Mb
- and it didn't go through)
Also, I have the conv_radius = 0
Can you tell me if MTD thinks that the much later cluster is the same as
the first, or is it just re-using numbers?
Thank you!
-Laurel DeHaan
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Fwd: numbering of objects in MTD
From: Randy Bullock
Time: Tue Feb 27 08:56:35 2018
HI -
Thanks for your email.
I'd like to have a look at that netcdf file. If it's too big to
email,
then you can ftp it to us. Do the following on your command line:
(1) ftp ftp.rap.ucar.edu
(2) login as "anonymous", and use your email address as password.
(3) cd incoming/irap/met_help
(4) bin
(5) put filename
(6) quit
where "filename" is the name of your netcdf file.
Let me know the name of the netcdf file, and I can grab it from our
local
ftp server here.
Thanks
Randy Bullock
On Mon, Feb 26, 2018 at 3:27 PM, Dehaan, Laurel via RT
<met_help at ucar.edu>
wrote:
>
> Mon Feb 26 15:27:39 2018: Request 84210 was acted upon.
> Transaction: Ticket created by ldehaan at ucsd.edu
> Queue: met_help
> Subject: Fwd: numbering of objects in MTD
> Owner: Nobody
> Requestors: ldehaan at ucsd.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
>
>
> Hi,
>
> I am working with MTD to look at atmospheric rivers (ARs).
> Things seem to be working well, but I have one point of confusion.
> At the first time there is a cluster numbered 1; it disappears and
the next
> cluster is #2; it lasts for a couple days and then disappears; then
the
> same thing happens with cluster #3 (this is all as expected).
> However, the next cluster that appears is again numbered #1 - many
time
> periods after the previous cluster #1 disappeared. (And then the
final
> cluster is #4)
>
> (I attempted to attach the netcdf file to clarify - but it was about
23 Mb
> - and it didn't go through)
> Also, I have the conv_radius = 0
>
> Can you tell me if MTD thinks that the much later cluster is the
same as
> the first, or is it just re-using numbers?
>
> Thank you!
> -Laurel DeHaan
>
>
------------------------------------------------
Subject: Fwd: numbering of objects in MTD
From: Dehaan, Laurel
Time: Tue Feb 27 09:46:59 2018
Thanks Randy.
I just just ftp'd mtd_F072_20180108_120000V_obj.nc to you
-Laurel
On Tue, Feb 27, 2018 at 7:56 AM, Randy Bullock via RT
<met_help at ucar.edu>
wrote:
> HI -
>
> Thanks for your email.
>
> I'd like to have a look at that netcdf file. If it's too big to
email,
> then you can ftp it to us. Do the following on your command line:
>
> (1) ftp ftp.rap.ucar.edu
>
> (2) login as "anonymous", and use your email address as password.
>
> (3) cd incoming/irap/met_help
>
> (4) bin
>
> (5) put filename
>
> (6) quit
>
> where "filename" is the name of your netcdf file.
>
> Let me know the name of the netcdf file, and I can grab it from our
local
> ftp server here.
>
> Thanks
>
> Randy Bullock
>
> On Mon, Feb 26, 2018 at 3:27 PM, Dehaan, Laurel via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Mon Feb 26 15:27:39 2018: Request 84210 was acted upon.
> > Transaction: Ticket created by ldehaan at ucsd.edu
> > Queue: met_help
> > Subject: Fwd: numbering of objects in MTD
> > Owner: Nobody
> > Requestors: ldehaan at ucsd.edu
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
> >
> >
> > Hi,
> >
> > I am working with MTD to look at atmospheric rivers (ARs).
> > Things seem to be working well, but I have one point of confusion.
> > At the first time there is a cluster numbered 1; it disappears and
the
> next
> > cluster is #2; it lasts for a couple days and then disappears;
then the
> > same thing happens with cluster #3 (this is all as expected).
> > However, the next cluster that appears is again numbered #1 - many
time
> > periods after the previous cluster #1 disappeared. (And then the
final
> > cluster is #4)
> >
> > (I attempted to attach the netcdf file to clarify - but it was
about 23
> Mb
> > - and it didn't go through)
> > Also, I have the conv_radius = 0
> >
> > Can you tell me if MTD thinks that the much later cluster is the
same as
> > the first, or is it just re-using numbers?
> >
> > Thank you!
> > -Laurel DeHaan
> >
> >
>
>
------------------------------------------------
Subject: Fwd: numbering of objects in MTD
From: Randy Bullock
Time: Wed Feb 28 11:21:01 2018
Hi Laurel -
Sorry for the delay in getting back to you, but we're trying to get a
new
MET release out the door, so things are a little hairy right now.
Anyway, regarding your question: No, I don't think that MTD is "re-
using"
object numbers. I had a look at your file and used ncview to look at
the
fcst_cluster_id field at successive times, and I see the effect you
talked
about. I don't think that's a problem with MTD, however, as I'll try
to
explain.
If you look at the attached file "sketch.jpg", (which I drew by hand
...
please forgive my total lack of artistic talent), you can see two
clusters:
cluster number 1 in red, and cluster number 2 in blue. If you looked
at
the spatial (ie, xy) plots in time sequence, you'd see cluster number
one
appearing, then cluster number two appearing, then cluster number 1
disappearing, then cluster number 1 re-appearing. This is what I
think is
happening in your data.
That said, I don't think the merges in this field are good ones. I
think
that MTD is matching objects that have similar speed and direction,
but are
separated by too much time. Try increasing the time_centroid_delta
weight
in the config file, or changing the time_centroid_delta interest map.
You
have a lot of time steps in your data, so that default interest map is
probably not doing the job.
I made a 3D animation of the fcst_cluster_id field (one frame is
attached:
022.png ... the full animation was too big to email), and it looks to
me
like this might be the explanation for the poor merges you're getting.
Hope this helps.
Randy
On Tue, Feb 27, 2018 at 9:47 AM, Dehaan, Laurel via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
>
> Thanks Randy.
>
> I just just ftp'd mtd_F072_20180108_120000V_obj.nc to you
>
> -Laurel
>
> On Tue, Feb 27, 2018 at 7:56 AM, Randy Bullock via RT
<met_help at ucar.edu>
> wrote:
>
> > HI -
> >
> > Thanks for your email.
> >
> > I'd like to have a look at that netcdf file. If it's too big to
email,
> > then you can ftp it to us. Do the following on your command line:
> >
> > (1) ftp ftp.rap.ucar.edu
> >
> > (2) login as "anonymous", and use your email address as password.
> >
> > (3) cd incoming/irap/met_help
> >
> > (4) bin
> >
> > (5) put filename
> >
> > (6) quit
> >
> > where "filename" is the name of your netcdf file.
> >
> > Let me know the name of the netcdf file, and I can grab it from
our local
> > ftp server here.
> >
> > Thanks
> >
> > Randy Bullock
> >
> > On Mon, Feb 26, 2018 at 3:27 PM, Dehaan, Laurel via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > Mon Feb 26 15:27:39 2018: Request 84210 was acted upon.
> > > Transaction: Ticket created by ldehaan at ucsd.edu
> > > Queue: met_help
> > > Subject: Fwd: numbering of objects in MTD
> > > Owner: Nobody
> > > Requestors: ldehaan at ucsd.edu
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210
> >
> > >
> > >
> > > Hi,
> > >
> > > I am working with MTD to look at atmospheric rivers (ARs).
> > > Things seem to be working well, but I have one point of
confusion.
> > > At the first time there is a cluster numbered 1; it disappears
and the
> > next
> > > cluster is #2; it lasts for a couple days and then disappears;
then the
> > > same thing happens with cluster #3 (this is all as expected).
> > > However, the next cluster that appears is again numbered #1 -
many time
> > > periods after the previous cluster #1 disappeared. (And then
the final
> > > cluster is #4)
> > >
> > > (I attempted to attach the netcdf file to clarify - but it was
about 23
> > Mb
> > > - and it didn't go through)
> > > Also, I have the conv_radius = 0
> > >
> > > Can you tell me if MTD thinks that the much later cluster is the
same
> as
> > > the first, or is it just re-using numbers?
> > >
> > > Thank you!
> > > -Laurel DeHaan
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Fwd: numbering of objects in MTD
From: Dehaan, Laurel
Time: Wed Feb 28 11:41:47 2018
Thanks Randy!
That's very helpful.
One quick follow up question. Does the conv_radius parameter in the
config
file apply to the time dimension, or just x and y?
-Laurel
On Wed, Feb 28, 2018 at 10:21 AM, Randy Bullock via RT
<met_help at ucar.edu>
wrote:
> Hi Laurel -
>
> Sorry for the delay in getting back to you, but we're trying to get
a new
> MET release out the door, so things are a little hairy right now.
>
> Anyway, regarding your question: No, I don't think that MTD is "re-
using"
> object numbers. I had a look at your file and used ncview to look
at the
> fcst_cluster_id field at successive times, and I see the effect you
talked
> about. I don't think that's a problem with MTD, however, as I'll
try to
> explain.
> If you look at the attached file "sketch.jpg", (which I drew by hand
...
> please forgive my total lack of artistic talent), you can see two
clusters:
> cluster number 1 in red, and cluster number 2 in blue. If you
looked at
> the spatial (ie, xy) plots in time sequence, you'd see cluster
number one
> appearing, then cluster number two appearing, then cluster number 1
> disappearing, then cluster number 1 re-appearing. This is what I
think is
> happening in your data.
>
> That said, I don't think the merges in this field are good ones. I
think
> that MTD is matching objects that have similar speed and direction,
but are
> separated by too much time. Try increasing the time_centroid_delta
weight
> in the config file, or changing the time_centroid_delta interest
map. You
> have a lot of time steps in your data, so that default interest map
is
> probably not doing the job.
>
> I made a 3D animation of the fcst_cluster_id field (one frame is
attached:
> 022.png ... the full animation was too big to email), and it looks
to me
> like this might be the explanation for the poor merges you're
getting.
>
> Hope this helps.
>
> Randy
>
> On Tue, Feb 27, 2018 at 9:47 AM, Dehaan, Laurel via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
> >
> > Thanks Randy.
> >
> > I just just ftp'd mtd_F072_20180108_120000V_obj.nc to you
> >
> > -Laurel
> >
> > On Tue, Feb 27, 2018 at 7:56 AM, Randy Bullock via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> > > HI -
> > >
> > > Thanks for your email.
> > >
> > > I'd like to have a look at that netcdf file. If it's too big to
email,
> > > then you can ftp it to us. Do the following on your command
line:
> > >
> > > (1) ftp ftp.rap.ucar.edu
> > >
> > > (2) login as "anonymous", and use your email address as
password.
> > >
> > > (3) cd incoming/irap/met_help
> > >
> > > (4) bin
> > >
> > > (5) put filename
> > >
> > > (6) quit
> > >
> > > where "filename" is the name of your netcdf file.
> > >
> > > Let me know the name of the netcdf file, and I can grab it from
our
> local
> > > ftp server here.
> > >
> > > Thanks
> > >
> > > Randy Bullock
> > >
> > > On Mon, Feb 26, 2018 at 3:27 PM, Dehaan, Laurel via RT <
> > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > Mon Feb 26 15:27:39 2018: Request 84210 was acted upon.
> > > > Transaction: Ticket created by ldehaan at ucsd.edu
> > > > Queue: met_help
> > > > Subject: Fwd: numbering of objects in MTD
> > > > Owner: Nobody
> > > > Requestors: ldehaan at ucsd.edu
> > > > Status: new
> > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=84210
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I am working with MTD to look at atmospheric rivers (ARs).
> > > > Things seem to be working well, but I have one point of
confusion.
> > > > At the first time there is a cluster numbered 1; it disappears
and
> the
> > > next
> > > > cluster is #2; it lasts for a couple days and then disappears;
then
> the
> > > > same thing happens with cluster #3 (this is all as expected).
> > > > However, the next cluster that appears is again numbered #1 -
many
> time
> > > > periods after the previous cluster #1 disappeared. (And then
the
> final
> > > > cluster is #4)
> > > >
> > > > (I attempted to attach the netcdf file to clarify - but it was
about
> 23
> > > Mb
> > > > - and it didn't go through)
> > > > Also, I have the conv_radius = 0
> > > >
> > > > Can you tell me if MTD thinks that the much later cluster is
the same
> > as
> > > > the first, or is it just re-using numbers?
> > > >
> > > > Thank you!
> > > > -Laurel DeHaan
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Fwd: numbering of objects in MTD
From: Randy Bullock
Time: Wed Feb 28 11:53:31 2018
Hi Laurel -
The convolution radius applies to x and y, not t. Currently the time
convolution radius is hard-coded to 1, and is not tunable by the user.
Randy
On Wed, Feb 28, 2018 at 11:41 AM, Dehaan, Laurel via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
>
> Thanks Randy!
>
> That's very helpful.
>
> One quick follow up question. Does the conv_radius parameter in the
config
> file apply to the time dimension, or just x and y?
>
> -Laurel
>
> On Wed, Feb 28, 2018 at 10:21 AM, Randy Bullock via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Laurel -
> >
> > Sorry for the delay in getting back to you, but we're trying to
get a new
> > MET release out the door, so things are a little hairy right now.
> >
> > Anyway, regarding your question: No, I don't think that MTD is
> "re-using"
> > object numbers. I had a look at your file and used ncview to look
at the
> > fcst_cluster_id field at successive times, and I see the effect
you
> talked
> > about. I don't think that's a problem with MTD, however, as I'll
try to
> > explain.
> > If you look at the attached file "sketch.jpg", (which I drew by
hand ...
> > please forgive my total lack of artistic talent), you can see two
> clusters:
> > cluster number 1 in red, and cluster number 2 in blue. If you
looked at
> > the spatial (ie, xy) plots in time sequence, you'd see cluster
number one
> > appearing, then cluster number two appearing, then cluster number
1
> > disappearing, then cluster number 1 re-appearing. This is what I
think
> is
> > happening in your data.
> >
> > That said, I don't think the merges in this field are good ones.
I think
> > that MTD is matching objects that have similar speed and
direction, but
> are
> > separated by too much time. Try increasing the
time_centroid_delta
> weight
> > in the config file, or changing the time_centroid_delta interest
map.
> You
> > have a lot of time steps in your data, so that default interest
map is
> > probably not doing the job.
> >
> > I made a 3D animation of the fcst_cluster_id field (one frame is
> attached:
> > 022.png ... the full animation was too big to email), and it looks
to me
> > like this might be the explanation for the poor merges you're
getting.
> >
> > Hope this helps.
> >
> > Randy
> >
> > On Tue, Feb 27, 2018 at 9:47 AM, Dehaan, Laurel via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
> > >
> > > Thanks Randy.
> > >
> > > I just just ftp'd mtd_F072_20180108_120000V_obj.nc to you
> > >
> > > -Laurel
> > >
> > > On Tue, Feb 27, 2018 at 7:56 AM, Randy Bullock via RT <
> met_help at ucar.edu
> > >
> > > wrote:
> > >
> > > > HI -
> > > >
> > > > Thanks for your email.
> > > >
> > > > I'd like to have a look at that netcdf file. If it's too big
to
> email,
> > > > then you can ftp it to us. Do the following on your command
line:
> > > >
> > > > (1) ftp ftp.rap.ucar.edu
> > > >
> > > > (2) login as "anonymous", and use your email address as
password.
> > > >
> > > > (3) cd incoming/irap/met_help
> > > >
> > > > (4) bin
> > > >
> > > > (5) put filename
> > > >
> > > > (6) quit
> > > >
> > > > where "filename" is the name of your netcdf file.
> > > >
> > > > Let me know the name of the netcdf file, and I can grab it
from our
> > local
> > > > ftp server here.
> > > >
> > > > Thanks
> > > >
> > > > Randy Bullock
> > > >
> > > > On Mon, Feb 26, 2018 at 3:27 PM, Dehaan, Laurel via RT <
> > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > Mon Feb 26 15:27:39 2018: Request 84210 was acted upon.
> > > > > Transaction: Ticket created by ldehaan at ucsd.edu
> > > > > Queue: met_help
> > > > > Subject: Fwd: numbering of objects in MTD
> > > > > Owner: Nobody
> > > > > Requestors: ldehaan at ucsd.edu
> > > > > Status: new
> > > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=84210
> > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am working with MTD to look at atmospheric rivers (ARs).
> > > > > Things seem to be working well, but I have one point of
confusion.
> > > > > At the first time there is a cluster numbered 1; it
disappears and
> > the
> > > > next
> > > > > cluster is #2; it lasts for a couple days and then
disappears; then
> > the
> > > > > same thing happens with cluster #3 (this is all as
expected).
> > > > > However, the next cluster that appears is again numbered #1
- many
> > time
> > > > > periods after the previous cluster #1 disappeared. (And
then the
> > final
> > > > > cluster is #4)
> > > > >
> > > > > (I attempted to attach the netcdf file to clarify - but it
was
> about
> > 23
> > > > Mb
> > > > > - and it didn't go through)
> > > > > Also, I have the conv_radius = 0
> > > > >
> > > > > Can you tell me if MTD thinks that the much later cluster is
the
> same
> > > as
> > > > > the first, or is it just re-using numbers?
> > > > >
> > > > > Thank you!
> > > > > -Laurel DeHaan
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Fwd: numbering of objects in MTD
From: Dehaan, Laurel
Time: Wed Feb 28 12:03:54 2018
Got it.
That explains what I was seeing.
Thanks again!
-Laurel
On Wed, Feb 28, 2018 at 10:53 AM, Randy Bullock via RT
<met_help at ucar.edu>
wrote:
> Hi Laurel -
>
> The convolution radius applies to x and y, not t. Currently the
time
> convolution radius is hard-coded to 1, and is not tunable by the
user.
>
> Randy
>
> On Wed, Feb 28, 2018 at 11:41 AM, Dehaan, Laurel via RT
<met_help at ucar.edu
> >
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210 >
> >
> > Thanks Randy!
> >
> > That's very helpful.
> >
> > One quick follow up question. Does the conv_radius parameter in
the
> config
> > file apply to the time dimension, or just x and y?
> >
> > -Laurel
> >
> > On Wed, Feb 28, 2018 at 10:21 AM, Randy Bullock via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > > Hi Laurel -
> > >
> > > Sorry for the delay in getting back to you, but we're trying to
get a
> new
> > > MET release out the door, so things are a little hairy right
now.
> > >
> > > Anyway, regarding your question: No, I don't think that MTD is
> > "re-using"
> > > object numbers. I had a look at your file and used ncview to
look at
> the
> > > fcst_cluster_id field at successive times, and I see the effect
you
> > talked
> > > about. I don't think that's a problem with MTD, however, as
I'll try
> to
> > > explain.
> > > If you look at the attached file "sketch.jpg", (which I drew by
hand
> ...
> > > please forgive my total lack of artistic talent), you can see
two
> > clusters:
> > > cluster number 1 in red, and cluster number 2 in blue. If you
looked
> at
> > > the spatial (ie, xy) plots in time sequence, you'd see cluster
number
> one
> > > appearing, then cluster number two appearing, then cluster
number 1
> > > disappearing, then cluster number 1 re-appearing. This is what
I think
> > is
> > > happening in your data.
> > >
> > > That said, I don't think the merges in this field are good ones.
I
> think
> > > that MTD is matching objects that have similar speed and
direction, but
> > are
> > > separated by too much time. Try increasing the
time_centroid_delta
> > weight
> > > in the config file, or changing the time_centroid_delta interest
map.
> > You
> > > have a lot of time steps in your data, so that default interest
map is
> > > probably not doing the job.
> > >
> > > I made a 3D animation of the fcst_cluster_id field (one frame is
> > attached:
> > > 022.png ... the full animation was too big to email), and it
looks to
> me
> > > like this might be the explanation for the poor merges you're
getting.
> > >
> > > Hope this helps.
> > >
> > > Randy
> > >
> > > On Tue, Feb 27, 2018 at 9:47 AM, Dehaan, Laurel via RT <
> > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84210
>
> > > >
> > > > Thanks Randy.
> > > >
> > > > I just just ftp'd mtd_F072_20180108_120000V_obj.nc to you
> > > >
> > > > -Laurel
> > > >
> > > > On Tue, Feb 27, 2018 at 7:56 AM, Randy Bullock via RT <
> > met_help at ucar.edu
> > > >
> > > > wrote:
> > > >
> > > > > HI -
> > > > >
> > > > > Thanks for your email.
> > > > >
> > > > > I'd like to have a look at that netcdf file. If it's too
big to
> > email,
> > > > > then you can ftp it to us. Do the following on your command
line:
> > > > >
> > > > > (1) ftp ftp.rap.ucar.edu
> > > > >
> > > > > (2) login as "anonymous", and use your email address as
password.
> > > > >
> > > > > (3) cd incoming/irap/met_help
> > > > >
> > > > > (4) bin
> > > > >
> > > > > (5) put filename
> > > > >
> > > > > (6) quit
> > > > >
> > > > > where "filename" is the name of your netcdf file.
> > > > >
> > > > > Let me know the name of the netcdf file, and I can grab it
from our
> > > local
> > > > > ftp server here.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Randy Bullock
> > > > >
> > > > > On Mon, Feb 26, 2018 at 3:27 PM, Dehaan, Laurel via RT <
> > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > Mon Feb 26 15:27:39 2018: Request 84210 was acted upon.
> > > > > > Transaction: Ticket created by ldehaan at ucsd.edu
> > > > > > Queue: met_help
> > > > > > Subject: Fwd: numbering of objects in MTD
> > > > > > Owner: Nobody
> > > > > > Requestors: ldehaan at ucsd.edu
> > > > > > Status: new
> > > > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > Ticket/Display.html?id=84210
> > > > >
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am working with MTD to look at atmospheric rivers (ARs).
> > > > > > Things seem to be working well, but I have one point of
> confusion.
> > > > > > At the first time there is a cluster numbered 1; it
disappears
> and
> > > the
> > > > > next
> > > > > > cluster is #2; it lasts for a couple days and then
disappears;
> then
> > > the
> > > > > > same thing happens with cluster #3 (this is all as
expected).
> > > > > > However, the next cluster that appears is again numbered
#1 -
> many
> > > time
> > > > > > periods after the previous cluster #1 disappeared. (And
then the
> > > final
> > > > > > cluster is #4)
> > > > > >
> > > > > > (I attempted to attach the netcdf file to clarify - but it
was
> > about
> > > 23
> > > > > Mb
> > > > > > - and it didn't go through)
> > > > > > Also, I have the conv_radius = 0
> > > > > >
> > > > > > Can you tell me if MTD thinks that the much later cluster
is the
> > same
> > > > as
> > > > > > the first, or is it just re-using numbers?
> > > > > >
> > > > > > Thank you!
> > > > > > -Laurel DeHaan
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list