[Met_help] [rt.rap.ucar.edu #91310] History for Mode Time Domain merging algorithm

[Randy Bullock via RT]

----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Hi All,

I am using MTD module of MET package to track thunderstorms. I could run MTD over my data and I have my outputs. I have a problem that I try to explain in the following lines:

Imagine that I have two objects at time step 0 and by passing the time the two objects (storms) move toward each other an become closer, and at time step = n they merge together and become a unified object. If I run MTD over my data during my selected period, MTD considers the two objects as 1 merged object from time step =0 to time step =n.

If we want to track both objects, since they have been considered as a merged object, therefore the calculated centroid from the merged objects will be the location of both storms at each time step, which is a point in middle of both objects with a little movement, while the real track lines for both objects (before merging at time step =n) is two lines intersecting each other at time step =n.

I was thinking that is there any options in MTD config file to somehow control the merging scheme of objects to escape from this problem? or do you have any idea to overcome this problem?

Thanks,
Hooman


----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: Mode Time Domain merging algorithm
From: Randy Bullock
Time: Wed Jul 31 10:27:32 2019

Hi Hooman -

Thanks for emailing met-help.

In the situation you describe, where two storms collide and become
one,
then they become part of one 3D spacetime object.  MTD doesn't really
"merge" them (merging instead refers to when we consider two separate
3D
objects to be part of one 3D composite object ... it's more of a
conceptual
thing).   If you make a spacetime plot of the two storms colliding,
then it
becomes clear that they are really part of one 3D object.  Since MTD
uses
the time dimension, a single 3D object encodes the entire history of
the 2D
objects that make it up, so there reallly isn't any way to separate
them.

However, if the two storms come near each other but don't quite
collide,
then you could set the convolution radius to a small value and the
convolution threshold to a higher value.  Then MTD might keep them
separate.

Hope this helps.

Randy

On Tue, Jul 30, 2019 at 6:03 AM Hooman Ayat via RT <met_help at ucar.edu>
wrote:

>
> Tue Jul 30 06:03:28 2019: Request 91310 was acted upon.
> Transaction: Ticket created by h.ayat at student.unsw.edu.au
>        Queue: met_help
>      Subject: Mode Time Domain merging algorithm
>        Owner: Nobody
>   Requestors: h.ayat at student.unsw.edu.au
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91310 >
>
>
> Hi All,
>
> I am using MTD module of MET package to track thunderstorms. I could
run
> MTD over my data and I have my outputs. I have a problem that I try
to
> explain in the following lines:
>
> Imagine that I have two objects at time step 0 and by passing the
time the
> two objects (storms) move toward each other an become closer, and at
time
> step = n they merge together and become a unified object. If I run
MTD over
> my data during my selected period, MTD considers the two objects as
1
> merged object from time step =0 to time step =n.
>
> If we want to track both objects, since they have been considered as
a
> merged object, therefore the calculated centroid from the merged
objects
> will be the location of both storms at each time step, which is a
point in
> middle of both objects with a little movement, while the real track
lines
> for both objects (before merging at time step =n) is two lines
intersecting
> each other at time step =n.
>
> I was thinking that is there any options in MTD config file to
somehow
> control the merging scheme of objects to escape from this problem?
or do
> you have any idea to overcome this problem?
>
> Thanks,
> Hooman
>
>

------------------------------------------------