[Met_help] [rt.rap.ucar.edu #90244] History for understanding text output from mode-td

[John Halley Gotway via RT]

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

Help me understand a confusing part of the text output from a MODE-TD run.
The discussion will refer to the attached files (probably mostly the 2d
one, but because I suspect matching may be involved I also attached the
3d_pair_simple version). I see from that output that I had 50 forecast
objects and 27 observation objects in total. Up through line 521 of the 2d
file, those lines describe the attributes of the forecast objects, and then
up through line 796 the observation object attributes are displayed.

What I don't understand is what is being displayed after that point in the
file. It appears some of the forecast and observation objects are repeated.
For example, let's look at forecast object #1. There are several entries
for F001 at the top of the 2d file for an object that persisted over the
first 6 time frames of the input. The OBJECT_CAT for this object is listed
as CF000, implying it was a single object (no cluster). However, at line
797 there is another set of entries for F001, and this time the OBJECT_CAT
is CF001, and this entry persists for time indices 0 to 2. This second F001
object appears to occur in a different part of the domain, so I don't think
it's the same object. But what does it mean that there is another F001? A
similar pattern occurs for F002-F004 and O001-O004. How do I interpret
these entries?

Jeff Duda

-- 
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO


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

Subject: understanding text output from mode-td
From: David Fillmore
Time: Fri May 17 10:53:11 2019

Hi Jeff -
I've passed this question on to Randy Bullock who works on the MODE
and the MODE-TD tools.
I think he is out today and Monday, but should have a chance to follow
up early next week.
thanks,
David

------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Fri May 17 12:00:33 2019

Hi Jeff and Randy,

I took a look at the data you sent, and I suspect you've uncovered a
bug in
the output of MTD.  As you've described...
(1) Lines 2 - 521 contain information about 2D slices of the simple
forecast objects.
(2) Lines 522 - 796 contain information about 2D slices of the simple
observation objects.
(3) Lines 797 - 849 *SHOULD* contain information about 2D slices of
the
*CLUSTER* forecast objects.
(4) Lines 850 - 896 *SHOULD* contain information about 2D slices of
the
*CLUSTER* forecast objects.

The problem in (3) and (4) is that the OBJECT_ID column should begin
with a
"C" to indicate that the info is for a cluster object.

Looks like this bug is present in the output of met-8.0, met-8.1, and
the
current development version.

Randy, please take a look and confirm that this is the case.   It'd
probably be wise to carefully review the contents of the OBJECT_ID and
OBJECT_CAT columns across all the MTD output files.  If confirmed,
we'll
need a bugfix for this... and this will be our first one after
transitioning to GitHub.

Thanks,
John



On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT
<met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> Hi Jeff -
> I've passed this question on to Randy Bullock who works on the MODE
and
> the MODE-TD tools.
> I think he is out today and Monday, but should have a chance to
follow up
> early next week.
> thanks,
> David
>

------------------------------------------------
Subject: understanding text output from mode-td
From: Randy Bullock
Time: Tue May 21 14:30:29 2019


The issue with the composite object numbers in the text output files
should now be fixed in the repository.

Randy

On Fri May 17 12:00:33 2019, johnhg wrote:
> Hi Jeff and Randy,
>
> I took a look at the data you sent, and I suspect you've uncovered a
bug in
> the output of MTD.  As you've described...
> (1) Lines 2 - 521 contain information about 2D slices of the simple
> forecast objects.
> (2) Lines 522 - 796 contain information about 2D slices of the
simple
> observation objects.
> (3) Lines 797 - 849 *SHOULD* contain information about 2D slices of
the
> *CLUSTER* forecast objects.
> (4) Lines 850 - 896 *SHOULD* contain information about 2D slices of
the
> *CLUSTER* forecast objects.
>
> The problem in (3) and (4) is that the OBJECT_ID column should begin
with a
> "C" to indicate that the info is for a cluster object.
>
> Looks like this bug is present in the output of met-8.0, met-8.1,
and the
> current development version.
>
> Randy, please take a look and confirm that this is the case.   It'd
> probably be wise to carefully review the contents of the OBJECT_ID
and
> OBJECT_CAT columns across all the MTD output files.  If confirmed,
we'll
> need a bugfix for this... and this will be our first one after
> transitioning to GitHub.
>
> Thanks,
> John
>
>
>
> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > Hi Jeff -
> > I've passed this question on to Randy Bullock who works on the
MODE and
> > the MODE-TD tools.
> > I think he is out today and Monday, but should have a chance to
follow up
> > early next week.
> > thanks,
> > David
> >



------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Tue May 21 14:41:54 2019

Jeff,

Just following up with some more details on this.  We've now moved the
MET
code repo from subversion to GitHub... and just today made it publicly
visible:
   https://github.com/NCAR/MET

The "default" branch is named "master_v8.1" which is where the version
8.1
release lives plus all known bugfixes.  Randy's commit is the first
bugfix.

Here's the page in github which shows that Randy's fix changed 3
files:
https://github.com/NCAR/MET/commit/0c4c8595e5db3f92bbb81ad016e89e6459cd73c1

For previous versions of MET, for every fix we posted a new set of
patches.  Starting with the met-8.1 release, we've chosen to do this
in a
more systematic way.  We'll buffer up a set of patches and then do a
minor
bugfix release.  The first one will be named met-8.1.1 and will
include
this mtd bugfix plus fixes for a couple other issues we're
investigating.
I don't have timeline for this first bugfix release yet.  But if
holding
you up, you're always welcome to go grab those 3 files which have
changed,
layer them on top of met-8.1 and recompile.

Hope that helps.

Thanks,
John

On Tue, May 21, 2019 at 2:31 PM Randy Bullock via RT
<met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
>
> The issue with the composite object numbers in the text output files
> should now be fixed in the repository.
>
> Randy
>
> On Fri May 17 12:00:33 2019, johnhg wrote:
> > Hi Jeff and Randy,
> >
> > I took a look at the data you sent, and I suspect you've uncovered
a bug
> in
> > the output of MTD.  As you've described...
> > (1) Lines 2 - 521 contain information about 2D slices of the
simple
> > forecast objects.
> > (2) Lines 522 - 796 contain information about 2D slices of the
simple
> > observation objects.
> > (3) Lines 797 - 849 *SHOULD* contain information about 2D slices
of the
> > *CLUSTER* forecast objects.
> > (4) Lines 850 - 896 *SHOULD* contain information about 2D slices
of the
> > *CLUSTER* forecast objects.
> >
> > The problem in (3) and (4) is that the OBJECT_ID column should
begin
> with a
> > "C" to indicate that the info is for a cluster object.
> >
> > Looks like this bug is present in the output of met-8.0, met-8.1,
and the
> > current development version.
> >
> > Randy, please take a look and confirm that this is the case.
It'd
> > probably be wise to carefully review the contents of the OBJECT_ID
and
> > OBJECT_CAT columns across all the MTD output files.  If confirmed,
we'll
> > need a bugfix for this... and this will be our first one after
> > transitioning to GitHub.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > >
> > > Hi Jeff -
> > > I've passed this question on to Randy Bullock who works on the
MODE and
> > > the MODE-TD tools.
> > > I think he is out today and Monday, but should have a chance to
follow
> up
> > > early next week.
> > > thanks,
> > > David
> > >
>
>
>
>

------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Tue May 21 14:45:38 2019

Jeff and Randy,

For the sake of completeness and tracking the issues found in the
code, I
added this GitHub issue and then resolved it:
https://github.com/NCAR/MET/issues/1128

Thanks,
John

On Tue, May 21, 2019 at 2:41 PM John Halley Gotway <johnhg at ucar.edu>
wrote:

> Jeff,
>
> Just following up with some more details on this.  We've now moved
the MET
> code repo from subversion to GitHub... and just today made it
publicly
> visible:
>    https://github.com/NCAR/MET
>
> The "default" branch is named "master_v8.1" which is where the
version 8.1
> release lives plus all known bugfixes.  Randy's commit is the first
bugfix.
>
> Here's the page in github which shows that Randy's fix changed 3
files:
>
https://github.com/NCAR/MET/commit/0c4c8595e5db3f92bbb81ad016e89e6459cd73c1
>
> For previous versions of MET, for every fix we posted a new set of
> patches.  Starting with the met-8.1 release, we've chosen to do this
in a
> more systematic way.  We'll buffer up a set of patches and then do a
minor
> bugfix release.  The first one will be named met-8.1.1 and will
include
> this mtd bugfix plus fixes for a couple other issues we're
investigating.
> I don't have timeline for this first bugfix release yet.  But if
holding
> you up, you're always welcome to go grab those 3 files which have
changed,
> layer them on top of met-8.1 and recompile.
>
> Hope that helps.
>
> Thanks,
> John
>
> On Tue, May 21, 2019 at 2:31 PM Randy Bullock via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>>
>>
>> The issue with the composite object numbers in the text output
files
>> should now be fixed in the repository.
>>
>> Randy
>>
>> On Fri May 17 12:00:33 2019, johnhg wrote:
>> > Hi Jeff and Randy,
>> >
>> > I took a look at the data you sent, and I suspect you've
uncovered a
>> bug in
>> > the output of MTD.  As you've described...
>> > (1) Lines 2 - 521 contain information about 2D slices of the
simple
>> > forecast objects.
>> > (2) Lines 522 - 796 contain information about 2D slices of the
simple
>> > observation objects.
>> > (3) Lines 797 - 849 *SHOULD* contain information about 2D slices
of the
>> > *CLUSTER* forecast objects.
>> > (4) Lines 850 - 896 *SHOULD* contain information about 2D slices
of the
>> > *CLUSTER* forecast objects.
>> >
>> > The problem in (3) and (4) is that the OBJECT_ID column should
begin
>> with a
>> > "C" to indicate that the info is for a cluster object.
>> >
>> > Looks like this bug is present in the output of met-8.0, met-8.1,
and
>> the
>> > current development version.
>> >
>> > Randy, please take a look and confirm that this is the case.
It'd
>> > probably be wise to carefully review the contents of the
OBJECT_ID and
>> > OBJECT_CAT columns across all the MTD output files.  If
confirmed, we'll
>> > need a bugfix for this... and this will be our first one after
>> > transitioning to GitHub.
>> >
>> > Thanks,
>> > John
>> >
>> >
>> >
>> > On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
>> met_help at ucar.edu>
>> > wrote:
>> >
>> > >
>> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>> > >
>> > > Hi Jeff -
>> > > I've passed this question on to Randy Bullock who works on the
MODE
>> and
>> > > the MODE-TD tools.
>> > > I think he is out today and Monday, but should have a chance to
>> follow up
>> > > early next week.
>> > > thanks,
>> > > David
>> > >
>>
>>
>>
>>

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Tue May 21 15:13:32 2019

Well I need to add some other potential bugs with MODE-TD output. Some
columns appear to be all zeros when I don't think they should:

3d_pair_simple: INTERSECTION_VOLUME
3d_single_simple: CDIST_TRAVELED

Jeff

On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Hi Jeff and Randy,
>
> I took a look at the data you sent, and I suspect you've uncovered a
bug in
> the output of MTD.  As you've described...
> (1) Lines 2 - 521 contain information about 2D slices of the simple
> forecast objects.
> (2) Lines 522 - 796 contain information about 2D slices of the
simple
> observation objects.
> (3) Lines 797 - 849 *SHOULD* contain information about 2D slices of
the
> *CLUSTER* forecast objects.
> (4) Lines 850 - 896 *SHOULD* contain information about 2D slices of
the
> *CLUSTER* forecast objects.
>
> The problem in (3) and (4) is that the OBJECT_ID column should begin
with a
> "C" to indicate that the info is for a cluster object.
>
> Looks like this bug is present in the output of met-8.0, met-8.1,
and the
> current development version.
>
> Randy, please take a look and confirm that this is the case.   It'd
> probably be wise to carefully review the contents of the OBJECT_ID
and
> OBJECT_CAT columns across all the MTD output files.  If confirmed,
we'll
> need a bugfix for this... and this will be our first one after
> transitioning to GitHub.
>
> Thanks,
> John
>
>
>
> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > Hi Jeff -
> > I've passed this question on to Randy Bullock who works on the
MODE and
> > the MODE-TD tools.
> > I think he is out today and Monday, but should have a chance to
follow up
> > early next week.
> > thanks,
> > David
> >
>
>

--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Tue May 21 19:10:39 2019

It also appears MODE-TD is ignoring my masking entry in the config
file:

mask = {
   grid      = "";
   grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
   poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
   poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
}

The outputs appear to cover the entire input domain, which is not what
"CONUS_east_of_rockies_mask.nc" contains.

On Tue, May 21, 2019 at 3:13 PM Jeff Duda <jeffduda319 at gmail.com>
wrote:

> Well I need to add some other potential bugs with MODE-TD output.
Some
> columns appear to be all zeros when I don't think they should:
>
> 3d_pair_simple: INTERSECTION_VOLUME
> 3d_single_simple: CDIST_TRAVELED
>
> Jeff
>
> On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Hi Jeff and Randy,
>>
>> I took a look at the data you sent, and I suspect you've uncovered
a bug
>> in
>> the output of MTD.  As you've described...
>> (1) Lines 2 - 521 contain information about 2D slices of the simple
>> forecast objects.
>> (2) Lines 522 - 796 contain information about 2D slices of the
simple
>> observation objects.
>> (3) Lines 797 - 849 *SHOULD* contain information about 2D slices of
the
>> *CLUSTER* forecast objects.
>> (4) Lines 850 - 896 *SHOULD* contain information about 2D slices of
the
>> *CLUSTER* forecast objects.
>>
>> The problem in (3) and (4) is that the OBJECT_ID column should
begin with
>> a
>> "C" to indicate that the info is for a cluster object.
>>
>> Looks like this bug is present in the output of met-8.0, met-8.1,
and the
>> current development version.
>>
>> Randy, please take a look and confirm that this is the case.   It'd
>> probably be wise to carefully review the contents of the OBJECT_ID
and
>> OBJECT_CAT columns across all the MTD output files.  If confirmed,
we'll
>> need a bugfix for this... and this will be our first one after
>> transitioning to GitHub.
>>
>> Thanks,
>> John
>>
>>
>>
>> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT
<met_help at ucar.edu
>> >
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>> >
>> > Hi Jeff -
>> > I've passed this question on to Randy Bullock who works on the
MODE and
>> > the MODE-TD tools.
>> > I think he is out today and Monday, but should have a chance to
follow
>> up
>> > early next week.
>> > thanks,
>> > David
>> >
>>
>>
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>


--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Wed May 22 12:22:02 2019

Jeff,

There is no "mask" option supported in MODE Time Domain.  Here's the
default MTD config file:
*
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
<https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default>*

I realize that mask is supported in MODE but it's not in MTD.  There
are
several options that fall into this category.

And there is an underlying issue behind it.  In order to make the
convolution step in time and space as quick as possible, the code
assumes
that there are no missing data values present.  Checking for and
dealing
with missing data is time consuming.  But that's really what masking
means... setting the values at some of the grid points to missing
data.

So MTD should probably be enhanced to deal with missing data which
would
make supporting masking regions pretty easy.  The trick is how to keep
the
processing as fast as possible.

I believe that Randy is out of the office this week, but can hopefully
respond to these issues/discussion next week.

Thanks,
John



On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> It also appears MODE-TD is ignoring my masking entry in the config
file:
>
> mask = {
>    grid      = "";
>    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
>    poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
>    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
> }
>
> The outputs appear to cover the entire input domain, which is not
what
> "CONUS_east_of_rockies_mask.nc" contains.
>
> On Tue, May 21, 2019 at 3:13 PM Jeff Duda <jeffduda319 at gmail.com>
wrote:
>
> > Well I need to add some other potential bugs with MODE-TD output.
Some
> > columns appear to be all zeros when I don't think they should:
> >
> > 3d_pair_simple: INTERSECTION_VOLUME
> > 3d_single_simple: CDIST_TRAVELED
> >
> > Jeff
> >
> > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Hi Jeff and Randy,
> >>
> >> I took a look at the data you sent, and I suspect you've
uncovered a bug
> >> in
> >> the output of MTD.  As you've described...
> >> (1) Lines 2 - 521 contain information about 2D slices of the
simple
> >> forecast objects.
> >> (2) Lines 522 - 796 contain information about 2D slices of the
simple
> >> observation objects.
> >> (3) Lines 797 - 849 *SHOULD* contain information about 2D slices
of the
> >> *CLUSTER* forecast objects.
> >> (4) Lines 850 - 896 *SHOULD* contain information about 2D slices
of the
> >> *CLUSTER* forecast objects.
> >>
> >> The problem in (3) and (4) is that the OBJECT_ID column should
begin
> with
> >> a
> >> "C" to indicate that the info is for a cluster object.
> >>
> >> Looks like this bug is present in the output of met-8.0, met-8.1,
and
> the
> >> current development version.
> >>
> >> Randy, please take a look and confirm that this is the case.
It'd
> >> probably be wise to carefully review the contents of the
OBJECT_ID and
> >> OBJECT_CAT columns across all the MTD output files.  If
confirmed, we'll
> >> need a bugfix for this... and this will be our first one after
> >> transitioning to GitHub.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >>
> >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
> met_help at ucar.edu
> >> >
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >> >
> >> > Hi Jeff -
> >> > I've passed this question on to Randy Bullock who works on the
MODE
> and
> >> > the MODE-TD tools.
> >> > I think he is out today and Monday, but should have a chance to
follow
> >> up
> >> > early next week.
> >> > thanks,
> >> > David
> >> >
> >>
> >>
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
>
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>
>

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Wed May 22 12:47:46 2019

Okay, seems sensible. Just want to add that MTD is not throwing any
errors
or warning messages when I use that code in the config file. Perhaps
such a
message could be added.

Jeff

On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> There is no "mask" option supported in MODE Time Domain.  Here's the
> default MTD config file:
> *
>
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> <
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> >*
>
> I realize that mask is supported in MODE but it's not in MTD.  There
are
> several options that fall into this category.
>
> And there is an underlying issue behind it.  In order to make the
> convolution step in time and space as quick as possible, the code
assumes
> that there are no missing data values present.  Checking for and
dealing
> with missing data is time consuming.  But that's really what masking
> means... setting the values at some of the grid points to missing
data.
>
> So MTD should probably be enhanced to deal with missing data which
would
> make supporting masking regions pretty easy.  The trick is how to
keep the
> processing as fast as possible.
>
> I believe that Randy is out of the office this week, but can
hopefully
> respond to these issues/discussion next week.
>
> Thanks,
> John
>
>
>
> On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > It also appears MODE-TD is ignoring my masking entry in the config
file:
> >
> > mask = {
> >    grid      = "";
> >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
> >    poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
> >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
> > }
> >
> > The outputs appear to cover the entire input domain, which is not
what
> > "CONUS_east_of_rockies_mask.nc" contains.
> >
> > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <jeffduda319 at gmail.com>
wrote:
> >
> > > Well I need to add some other potential bugs with MODE-TD
output. Some
> > > columns appear to be all zeros when I don't think they should:
> > >
> > > 3d_pair_simple: INTERSECTION_VOLUME
> > > 3d_single_simple: CDIST_TRAVELED
> > >
> > > Jeff
> > >
> > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Hi Jeff and Randy,
> > >>
> > >> I took a look at the data you sent, and I suspect you've
uncovered a
> bug
> > >> in
> > >> the output of MTD.  As you've described...
> > >> (1) Lines 2 - 521 contain information about 2D slices of the
simple
> > >> forecast objects.
> > >> (2) Lines 522 - 796 contain information about 2D slices of the
simple
> > >> observation objects.
> > >> (3) Lines 797 - 849 *SHOULD* contain information about 2D
slices of
> the
> > >> *CLUSTER* forecast objects.
> > >> (4) Lines 850 - 896 *SHOULD* contain information about 2D
slices of
> the
> > >> *CLUSTER* forecast objects.
> > >>
> > >> The problem in (3) and (4) is that the OBJECT_ID column should
begin
> > with
> > >> a
> > >> "C" to indicate that the info is for a cluster object.
> > >>
> > >> Looks like this bug is present in the output of met-8.0, met-
8.1, and
> > the
> > >> current development version.
> > >>
> > >> Randy, please take a look and confirm that this is the case.
It'd
> > >> probably be wise to carefully review the contents of the
OBJECT_ID and
> > >> OBJECT_CAT columns across all the MTD output files.  If
confirmed,
> we'll
> > >> need a bugfix for this... and this will be our first one after
> > >> transitioning to GitHub.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >>
> > >>
> > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
> > met_help at ucar.edu
> > >> >
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>
> > >> >
> > >> > Hi Jeff -
> > >> > I've passed this question on to Randy Bullock who works on
the MODE
> > and
> > >> > the MODE-TD tools.
> > >> > I think he is out today and Monday, but should have a chance
to
> follow
> > >> up
> > >> > early next week.
> > >> > thanks,
> > >> > David
> > >> >
> > >>
> > >>
> > >
> > > --
> > > Jeff Duda, Research Scientist
> > > University of Colorado Boulder
> > > Cooperative Institute for Research in Environmental Sciences
> > > NOAA/OAR/ESRL/Global Systems Division
> > > Boulder, CO
> > >
> >
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
> >
>
>

--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Wed May 22 15:24:00 2019

Jeff,

Good point.  In general, the MET tools do not print warnings for items
that
don't appear in the default configuration file.  That is by design
since it
gives the user more flexibility.  For example, you might define:

*tmp_levels = [ "P500", "P800", "Z2" ];*
*wind_levels = [ "P500", "P850", "Z10" ];*

And then refer to them later...

*fcst = {*
*  field = [*
*      { name = "TMP"; level=tmp_levels; },*
*      { name = "UGRD"; level=wind_levels; },*
*      { name = "VGRD"; level=wind_levels; },*
*      { name = "WIND"; level=wind_levels; }*
*   ];*
*}*

And we wouldn't want to print a warning or error about tmp_levels or
wind_levels not appearing in the default config file.  There may be
some
more complex logic to check for situations which are or are not
acceptable,
but that hasn't risen to the top of the development priorities.  In
general, we advise that users make a copy of the default config file
for
the current version they're running and then edit it from there.  But
I
know plenty of DTC folks who don't do that.

Lots of details to consider!

Thanks,
John




On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> Okay, seems sensible. Just want to add that MTD is not throwing any
errors
> or warning messages when I use that code in the config file. Perhaps
such a
> message could be added.
>
> Jeff
>
> On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > There is no "mask" option supported in MODE Time Domain.  Here's
the
> > default MTD config file:
> > *
> >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > <
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > >*
> >
> > I realize that mask is supported in MODE but it's not in MTD.
There are
> > several options that fall into this category.
> >
> > And there is an underlying issue behind it.  In order to make the
> > convolution step in time and space as quick as possible, the code
assumes
> > that there are no missing data values present.  Checking for and
dealing
> > with missing data is time consuming.  But that's really what
masking
> > means... setting the values at some of the grid points to missing
data.
> >
> > So MTD should probably be enhanced to deal with missing data which
would
> > make supporting masking regions pretty easy.  The trick is how to
keep
> the
> > processing as fast as possible.
> >
> > I believe that Randy is out of the office this week, but can
hopefully
> > respond to these issues/discussion next week.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > >
> > > It also appears MODE-TD is ignoring my masking entry in the
config
> file:
> > >
> > > mask = {
> > >    grid      = "";
> > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
> > >    poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
> > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
> > > }
> > >
> > > The outputs appear to cover the entire input domain, which is
not what
> > > "CONUS_east_of_rockies_mask.nc" contains.
> > >
> > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda
<jeffduda319 at gmail.com>
> wrote:
> > >
> > > > Well I need to add some other potential bugs with MODE-TD
output.
> Some
> > > > columns appear to be all zeros when I don't think they should:
> > > >
> > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > > 3d_single_simple: CDIST_TRAVELED
> > > >
> > > > Jeff
> > > >
> > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Hi Jeff and Randy,
> > > >>
> > > >> I took a look at the data you sent, and I suspect you've
uncovered a
> > bug
> > > >> in
> > > >> the output of MTD.  As you've described...
> > > >> (1) Lines 2 - 521 contain information about 2D slices of the
simple
> > > >> forecast objects.
> > > >> (2) Lines 522 - 796 contain information about 2D slices of
the
> simple
> > > >> observation objects.
> > > >> (3) Lines 797 - 849 *SHOULD* contain information about 2D
slices of
> > the
> > > >> *CLUSTER* forecast objects.
> > > >> (4) Lines 850 - 896 *SHOULD* contain information about 2D
slices of
> > the
> > > >> *CLUSTER* forecast objects.
> > > >>
> > > >> The problem in (3) and (4) is that the OBJECT_ID column
should begin
> > > with
> > > >> a
> > > >> "C" to indicate that the info is for a cluster object.
> > > >>
> > > >> Looks like this bug is present in the output of met-8.0, met-
8.1,
> and
> > > the
> > > >> current development version.
> > > >>
> > > >> Randy, please take a look and confirm that this is the case.
It'd
> > > >> probably be wise to carefully review the contents of the
OBJECT_ID
> and
> > > >> OBJECT_CAT columns across all the MTD output files.  If
confirmed,
> > we'll
> > > >> need a bugfix for this... and this will be our first one
after
> > > >> transitioning to GitHub.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >>
> > > >>
> > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
> > > met_help at ucar.edu
> > > >> >
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > >> >
> > > >> > Hi Jeff -
> > > >> > I've passed this question on to Randy Bullock who works on
the
> MODE
> > > and
> > > >> > the MODE-TD tools.
> > > >> > I think he is out today and Monday, but should have a
chance to
> > follow
> > > >> up
> > > >> > early next week.
> > > >> > thanks,
> > > >> > David
> > > >> >
> > > >>
> > > >>
> > > >
> > > > --
> > > > Jeff Duda, Research Scientist
> > > > University of Colorado Boulder
> > > > Cooperative Institute for Research in Environmental Sciences
> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > Boulder, CO
> > > >
> > >
> > >
> > > --
> > > Jeff Duda, Research Scientist
> > > University of Colorado Boulder
> > > Cooperative Institute for Research in Environmental Sciences
> > > NOAA/OAR/ESRL/Global Systems Division
> > > Boulder, CO
> > >
> > >
> >
> >
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>
>

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Thu May 23 12:27:06 2019

Is there a way to extract an intensity percentile value other than the
5
defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when trying to
add
"inten_perc_value" to the config file.

Also, how does convolving in time work? It is not described in the
user's
manual. If I set conv_radius = 2.0, does that mean the convolution
window
is a 5 x 5 grid box window in space and a 5 time-slice window? If I
have
that right, can you change future versions of MTD so that you can use
different convolution radii for the time dimension and spatial
dimensions?
I don't want to smooth my data in time much, but definitely in space.
I
feel a lot of users will want that.

Jeff

On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:

> Jeff,
>
> Good point.  In general, the MET tools do not print warnings for
items that
> don't appear in the default configuration file.  That is by design
since it
> gives the user more flexibility.  For example, you might define:
>
> *tmp_levels = [ "P500", "P800", "Z2" ];*
> *wind_levels = [ "P500", "P850", "Z10" ];*
>
> And then refer to them later...
>
> *fcst = {*
> *  field = [*
> *      { name = "TMP"; level=tmp_levels; },*
> *      { name = "UGRD"; level=wind_levels; },*
> *      { name = "VGRD"; level=wind_levels; },*
> *      { name = "WIND"; level=wind_levels; }*
> *   ];*
> *}*
>
> And we wouldn't want to print a warning or error about tmp_levels or
> wind_levels not appearing in the default config file.  There may be
some
> more complex logic to check for situations which are or are not
acceptable,
> but that hasn't risen to the top of the development priorities.  In
> general, we advise that users make a copy of the default config file
for
> the current version they're running and then edit it from there.
But I
> know plenty of DTC folks who don't do that.
>
> Lots of details to consider!
>
> Thanks,
> John
>
>
>
>
> On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > Okay, seems sensible. Just want to add that MTD is not throwing
any
> errors
> > or warning messages when I use that code in the config file.
Perhaps
> such a
> > message could be added.
> >
> > Jeff
> >
> > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jeff,
> > >
> > > There is no "mask" option supported in MODE Time Domain.  Here's
the
> > > default MTD config file:
> > > *
> > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > <
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > >*
> > >
> > > I realize that mask is supported in MODE but it's not in MTD.
There
> are
> > > several options that fall into this category.
> > >
> > > And there is an underlying issue behind it.  In order to make
the
> > > convolution step in time and space as quick as possible, the
code
> assumes
> > > that there are no missing data values present.  Checking for and
> dealing
> > > with missing data is time consuming.  But that's really what
masking
> > > means... setting the values at some of the grid points to
missing data.
> > >
> > > So MTD should probably be enhanced to deal with missing data
which
> would
> > > make supporting masking regions pretty easy.  The trick is how
to keep
> > the
> > > processing as fast as possible.
> > >
> > > I believe that Randy is out of the office this week, but can
hopefully
> > > respond to these issues/discussion next week.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>
> > > >
> > > > It also appears MODE-TD is ignoring my masking entry in the
config
> > file:
> > > >
> > > > mask = {
> > > >    grid      = "";
> > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
> > > >    poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
> > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
> > > > }
> > > >
> > > > The outputs appear to cover the entire input domain, which is
not
> what
> > > > "CONUS_east_of_rockies_mask.nc" contains.
> > > >
> > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda
<jeffduda319 at gmail.com>
> > wrote:
> > > >
> > > > > Well I need to add some other potential bugs with MODE-TD
output.
> > Some
> > > > > columns appear to be all zeros when I don't think they
should:
> > > > >
> > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > > > 3d_single_simple: CDIST_TRAVELED
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Hi Jeff and Randy,
> > > > >>
> > > > >> I took a look at the data you sent, and I suspect you've
> uncovered a
> > > bug
> > > > >> in
> > > > >> the output of MTD.  As you've described...
> > > > >> (1) Lines 2 - 521 contain information about 2D slices of
the
> simple
> > > > >> forecast objects.
> > > > >> (2) Lines 522 - 796 contain information about 2D slices of
the
> > simple
> > > > >> observation objects.
> > > > >> (3) Lines 797 - 849 *SHOULD* contain information about 2D
slices
> of
> > > the
> > > > >> *CLUSTER* forecast objects.
> > > > >> (4) Lines 850 - 896 *SHOULD* contain information about 2D
slices
> of
> > > the
> > > > >> *CLUSTER* forecast objects.
> > > > >>
> > > > >> The problem in (3) and (4) is that the OBJECT_ID column
should
> begin
> > > > with
> > > > >> a
> > > > >> "C" to indicate that the info is for a cluster object.
> > > > >>
> > > > >> Looks like this bug is present in the output of met-8.0,
met-8.1,
> > and
> > > > the
> > > > >> current development version.
> > > > >>
> > > > >> Randy, please take a look and confirm that this is the
case.
>  It'd
> > > > >> probably be wise to carefully review the contents of the
OBJECT_ID
> > and
> > > > >> OBJECT_CAT columns across all the MTD output files.  If
confirmed,
> > > we'll
> > > > >> need a bugfix for this... and this will be our first one
after
> > > > >> transitioning to GitHub.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
> > > > met_help at ucar.edu
> > > > >> >
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > > >> >
> > > > >> > Hi Jeff -
> > > > >> > I've passed this question on to Randy Bullock who works
on the
> > MODE
> > > > and
> > > > >> > the MODE-TD tools.
> > > > >> > I think he is out today and Monday, but should have a
chance to
> > > follow
> > > > >> up
> > > > >> > early next week.
> > > > >> > thanks,
> > > > >> > David
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > Jeff Duda, Research Scientist
> > > > > University of Colorado Boulder
> > > > > Cooperative Institute for Research in Environmental Sciences
> > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > Boulder, CO
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeff Duda, Research Scientist
> > > > University of Colorado Boulder
> > > > Cooperative Institute for Research in Environmental Sciences
> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > Boulder, CO
> > > >
> > > >
> > >
> > >
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
> >
>
>

--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Thu May 23 13:28:55 2019

Jeff,

As of met-8.1, the conv_radius setting defines the spatial smoothing
radius
of influence.  The smoothing in time is currently hard coded as +/- 1
time
step.  That means that the smoothing of data for time t is influenced
by
times t-1 and t+1.  I agree that the amount of temporal smoothing
should be
configurable.  In fact, here's an existing GitHub issue describing
this
feature request:
   https://github.com/NCAR/MET/issues/1084

As for the intensity percentiles in MTD, it is limited to the 5 pre-
defined
ones.
By comparison, one of the inputs to the fuzzy logic engine is the a
ratio
of the object intensities.  The user can select what intensity
percentile
is used in that ratio computation.  And whatever percentile they
choose is
included as a 6th intensity percentile value.

What sort of flexibility are you looking for in extracting intensity
percentile values?  How would it ideally work in your mind?

Thanks,
John

On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> Is there a way to extract an intensity percentile value other than
the 5
> defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when trying
to add
> "inten_perc_value" to the config file.
>
> Also, how does convolving in time work? It is not described in the
user's
> manual. If I set conv_radius = 2.0, does that mean the convolution
window
> is a 5 x 5 grid box window in space and a 5 time-slice window? If I
have
> that right, can you change future versions of MTD so that you can
use
> different convolution radii for the time dimension and spatial
dimensions?
> I don't want to smooth my data in time much, but definitely in
space. I
> feel a lot of users will want that.
>
> Jeff
>
> On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Jeff,
> >
> > Good point.  In general, the MET tools do not print warnings for
items
> that
> > don't appear in the default configuration file.  That is by design
since
> it
> > gives the user more flexibility.  For example, you might define:
> >
> > *tmp_levels = [ "P500", "P800", "Z2" ];*
> > *wind_levels = [ "P500", "P850", "Z10" ];*
> >
> > And then refer to them later...
> >
> > *fcst = {*
> > *  field = [*
> > *      { name = "TMP"; level=tmp_levels; },*
> > *      { name = "UGRD"; level=wind_levels; },*
> > *      { name = "VGRD"; level=wind_levels; },*
> > *      { name = "WIND"; level=wind_levels; }*
> > *   ];*
> > *}*
> >
> > And we wouldn't want to print a warning or error about tmp_levels
or
> > wind_levels not appearing in the default config file.  There may
be some
> > more complex logic to check for situations which are or are not
> acceptable,
> > but that hasn't risen to the top of the development priorities.
In
> > general, we advise that users make a copy of the default config
file for
> > the current version they're running and then edit it from there.
But I
> > know plenty of DTC folks who don't do that.
> >
> > Lots of details to consider!
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > >
> > > Okay, seems sensible. Just want to add that MTD is not throwing
any
> > errors
> > > or warning messages when I use that code in the config file.
Perhaps
> > such a
> > > message could be added.
> > >
> > > Jeff
> > >
> > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jeff,
> > > >
> > > > There is no "mask" option supported in MODE Time Domain.
Here's the
> > > > default MTD config file:
> > > > *
> > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > <
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > >*
> > > >
> > > > I realize that mask is supported in MODE but it's not in MTD.
There
> > are
> > > > several options that fall into this category.
> > > >
> > > > And there is an underlying issue behind it.  In order to make
the
> > > > convolution step in time and space as quick as possible, the
code
> > assumes
> > > > that there are no missing data values present.  Checking for
and
> > dealing
> > > > with missing data is time consuming.  But that's really what
masking
> > > > means... setting the values at some of the grid points to
missing
> data.
> > > >
> > > > So MTD should probably be enhanced to deal with missing data
which
> > would
> > > > make supporting masking regions pretty easy.  The trick is how
to
> keep
> > > the
> > > > processing as fast as possible.
> > > >
> > > > I believe that Randy is out of the office this week, but can
> hopefully
> > > > respond to these issues/discussion next week.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > >
> > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT
<met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > > >
> > > > > It also appears MODE-TD is ignoring my masking entry in the
config
> > > file:
> > > > >
> > > > > mask = {
> > > > >    grid      = "";
> > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
> > > > >    poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
> > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
> > > > > }
> > > > >
> > > > > The outputs appear to cover the entire input domain, which
is not
> > what
> > > > > "CONUS_east_of_rockies_mask.nc" contains.
> > > > >
> > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda
<jeffduda319 at gmail.com>
> > > wrote:
> > > > >
> > > > > > Well I need to add some other potential bugs with MODE-TD
output.
> > > Some
> > > > > > columns appear to be all zeros when I don't think they
should:
> > > > > >
> > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > > > > 3d_single_simple: CDIST_TRAVELED
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > >> Hi Jeff and Randy,
> > > > > >>
> > > > > >> I took a look at the data you sent, and I suspect you've
> > uncovered a
> > > > bug
> > > > > >> in
> > > > > >> the output of MTD.  As you've described...
> > > > > >> (1) Lines 2 - 521 contain information about 2D slices of
the
> > simple
> > > > > >> forecast objects.
> > > > > >> (2) Lines 522 - 796 contain information about 2D slices
of the
> > > simple
> > > > > >> observation objects.
> > > > > >> (3) Lines 797 - 849 *SHOULD* contain information about 2D
slices
> > of
> > > > the
> > > > > >> *CLUSTER* forecast objects.
> > > > > >> (4) Lines 850 - 896 *SHOULD* contain information about 2D
slices
> > of
> > > > the
> > > > > >> *CLUSTER* forecast objects.
> > > > > >>
> > > > > >> The problem in (3) and (4) is that the OBJECT_ID column
should
> > begin
> > > > > with
> > > > > >> a
> > > > > >> "C" to indicate that the info is for a cluster object.
> > > > > >>
> > > > > >> Looks like this bug is present in the output of met-8.0,
> met-8.1,
> > > and
> > > > > the
> > > > > >> current development version.
> > > > > >>
> > > > > >> Randy, please take a look and confirm that this is the
case.
> >  It'd
> > > > > >> probably be wise to carefully review the contents of the
> OBJECT_ID
> > > and
> > > > > >> OBJECT_CAT columns across all the MTD output files.  If
> confirmed,
> > > > we'll
> > > > > >> need a bugfix for this... and this will be our first one
after
> > > > > >> transitioning to GitHub.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> John
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT <
> > > > > met_help at ucar.edu
> > > > > >> >
> > > > > >> wrote:
> > > > > >>
> > > > > >> >
> > > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> >
> > > > > >> >
> > > > > >> > Hi Jeff -
> > > > > >> > I've passed this question on to Randy Bullock who works
on the
> > > MODE
> > > > > and
> > > > > >> > the MODE-TD tools.
> > > > > >> > I think he is out today and Monday, but should have a
chance
> to
> > > > follow
> > > > > >> up
> > > > > >> > early next week.
> > > > > >> > thanks,
> > > > > >> > David
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Jeff Duda, Research Scientist
> > > > > > University of Colorado Boulder
> > > > > > Cooperative Institute for Research in Environmental
Sciences
> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > > Boulder, CO
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jeff Duda, Research Scientist
> > > > > University of Colorado Boulder
> > > > > Cooperative Institute for Research in Environmental Sciences
> > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > Boulder, CO
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Jeff Duda, Research Scientist
> > > University of Colorado Boulder
> > > Cooperative Institute for Research in Environmental Sciences
> > > NOAA/OAR/ESRL/Global Systems Division
> > > Boulder, CO
> > >
> > >
> >
> >
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>
>

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Thu May 23 15:23:11 2019

Well I am trying to use MODE-TD to compute a UH track climatology from
the
HRRR model. So I want to pull maximum or near-maximum UH magnitudes
from
each track. So it would be great to be able to get the 95th or 99th
percentile UH magnitude from each object, for example.

I tried adding the same parameter that exists in MODE,
inten_perc_value, to
the MTD config file but I'm getting mixed results. Sometimes MTD
crashes
citing a config file syntax error  and sometimes it runs successfully,
but
when it does I do not see the added percentile INTENSITY value added
to the
text output anywhere.

Jeff

On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:

> Jeff,
>
> As of met-8.1, the conv_radius setting defines the spatial smoothing
radius
> of influence.  The smoothing in time is currently hard coded as +/-
1 time
> step.  That means that the smoothing of data for time t is
influenced by
> times t-1 and t+1.  I agree that the amount of temporal smoothing
should be
> configurable.  In fact, here's an existing GitHub issue describing
this
> feature request:
>    https://github.com/NCAR/MET/issues/1084
>
> As for the intensity percentiles in MTD, it is limited to the 5 pre-
defined
> ones.
> By comparison, one of the inputs to the fuzzy logic engine is the a
ratio
> of the object intensities.  The user can select what intensity
percentile
> is used in that ratio computation.  And whatever percentile they
choose is
> included as a 6th intensity percentile value.
>
> What sort of flexibility are you looking for in extracting intensity
> percentile values?  How would it ideally work in your mind?
>
> Thanks,
> John
>
> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > Is there a way to extract an intensity percentile value other than
the 5
> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when trying
to add
> > "inten_perc_value" to the config file.
> >
> > Also, how does convolving in time work? It is not described in the
user's
> > manual. If I set conv_radius = 2.0, does that mean the convolution
window
> > is a 5 x 5 grid box window in space and a 5 time-slice window? If
I have
> > that right, can you change future versions of MTD so that you can
use
> > different convolution radii for the time dimension and spatial
> dimensions?
> > I don't want to smooth my data in time much, but definitely in
space. I
> > feel a lot of users will want that.
> >
> > Jeff
> >
> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Jeff,
> > >
> > > Good point.  In general, the MET tools do not print warnings for
items
> > that
> > > don't appear in the default configuration file.  That is by
design
> since
> > it
> > > gives the user more flexibility.  For example, you might define:
> > >
> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
> > > *wind_levels = [ "P500", "P850", "Z10" ];*
> > >
> > > And then refer to them later...
> > >
> > > *fcst = {*
> > > *  field = [*
> > > *      { name = "TMP"; level=tmp_levels; },*
> > > *      { name = "UGRD"; level=wind_levels; },*
> > > *      { name = "VGRD"; level=wind_levels; },*
> > > *      { name = "WIND"; level=wind_levels; }*
> > > *   ];*
> > > *}*
> > >
> > > And we wouldn't want to print a warning or error about
tmp_levels or
> > > wind_levels not appearing in the default config file.  There may
be
> some
> > > more complex logic to check for situations which are or are not
> > acceptable,
> > > but that hasn't risen to the top of the development priorities.
In
> > > general, we advise that users make a copy of the default config
file
> for
> > > the current version they're running and then edit it from there.
But I
> > > know plenty of DTC folks who don't do that.
> > >
> > > Lots of details to consider!
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > >
> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>
> > > >
> > > > Okay, seems sensible. Just want to add that MTD is not
throwing any
> > > errors
> > > > or warning messages when I use that code in the config file.
Perhaps
> > > such a
> > > > message could be added.
> > > >
> > > > Jeff
> > > >
> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Jeff,
> > > > >
> > > > > There is no "mask" option supported in MODE Time Domain.
Here's
> the
> > > > > default MTD config file:
> > > > > *
> > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > > <
> > > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > > >*
> > > > >
> > > > > I realize that mask is supported in MODE but it's not in
MTD.
> There
> > > are
> > > > > several options that fall into this category.
> > > > >
> > > > > And there is an underlying issue behind it.  In order to
make the
> > > > > convolution step in time and space as quick as possible, the
code
> > > assumes
> > > > > that there are no missing data values present.  Checking for
and
> > > dealing
> > > > > with missing data is time consuming.  But that's really what
> masking
> > > > > means... setting the values at some of the grid points to
missing
> > data.
> > > > >
> > > > > So MTD should probably be enhanced to deal with missing data
which
> > > would
> > > > > make supporting masking regions pretty easy.  The trick is
how to
> > keep
> > > > the
> > > > > processing as fast as possible.
> > > > >
> > > > > I believe that Randy is out of the office this week, but can
> > hopefully
> > > > > respond to these issues/discussion next week.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <
> met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > > > >
> > > > > > It also appears MODE-TD is ignoring my masking entry in
the
> config
> > > > file:
> > > > > >
> > > > > > mask = {
> > > > > >    grid      = "";
> > > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
> > > > > >    poly      = "${METBASE}/CONUS_east_of_rockies_mask.nc";
> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
> > > > > > }
> > > > > >
> > > > > > The outputs appear to cover the entire input domain, which
is not
> > > what
> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
> > > > > >
> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda
<jeffduda319 at gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Well I need to add some other potential bugs with MODE-
TD
> output.
> > > > Some
> > > > > > > columns appear to be all zeros when I don't think they
should:
> > > > > > >
> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > > > > > 3d_single_simple: CDIST_TRAVELED
> > > > > > >
> > > > > > > Jeff
> > > > > > >
> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > >> Hi Jeff and Randy,
> > > > > > >>
> > > > > > >> I took a look at the data you sent, and I suspect
you've
> > > uncovered a
> > > > > bug
> > > > > > >> in
> > > > > > >> the output of MTD.  As you've described...
> > > > > > >> (1) Lines 2 - 521 contain information about 2D slices
of the
> > > simple
> > > > > > >> forecast objects.
> > > > > > >> (2) Lines 522 - 796 contain information about 2D slices
of the
> > > > simple
> > > > > > >> observation objects.
> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain information about
2D
> slices
> > > of
> > > > > the
> > > > > > >> *CLUSTER* forecast objects.
> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain information about
2D
> slices
> > > of
> > > > > the
> > > > > > >> *CLUSTER* forecast objects.
> > > > > > >>
> > > > > > >> The problem in (3) and (4) is that the OBJECT_ID column
should
> > > begin
> > > > > > with
> > > > > > >> a
> > > > > > >> "C" to indicate that the info is for a cluster object.
> > > > > > >>
> > > > > > >> Looks like this bug is present in the output of met-
8.0,
> > met-8.1,
> > > > and
> > > > > > the
> > > > > > >> current development version.
> > > > > > >>
> > > > > > >> Randy, please take a look and confirm that this is the
case.
> > >  It'd
> > > > > > >> probably be wise to carefully review the contents of
the
> > OBJECT_ID
> > > > and
> > > > > > >> OBJECT_CAT columns across all the MTD output files.  If
> > confirmed,
> > > > > we'll
> > > > > > >> need a bugfix for this... and this will be our first
one after
> > > > > > >> transitioning to GitHub.
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> John
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT
<
> > > > > > met_help at ucar.edu
> > > > > > >> >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> >
> > > > > > >> > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > >
> > > > > > >> >
> > > > > > >> > Hi Jeff -
> > > > > > >> > I've passed this question on to Randy Bullock who
works on
> the
> > > > MODE
> > > > > > and
> > > > > > >> > the MODE-TD tools.
> > > > > > >> > I think he is out today and Monday, but should have a
chance
> > to
> > > > > follow
> > > > > > >> up
> > > > > > >> > early next week.
> > > > > > >> > thanks,
> > > > > > >> > David
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > > > --
> > > > > > > Jeff Duda, Research Scientist
> > > > > > > University of Colorado Boulder
> > > > > > > Cooperative Institute for Research in Environmental
Sciences
> > > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > > > Boulder, CO
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jeff Duda, Research Scientist
> > > > > > University of Colorado Boulder
> > > > > > Cooperative Institute for Research in Environmental
Sciences
> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > > Boulder, CO
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Jeff Duda, Research Scientist
> > > > University of Colorado Boulder
> > > > Cooperative Institute for Research in Environmental Sciences
> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > Boulder, CO
> > > >
> > > >
> > >
> > >
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
> >
>
>

--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Thu May 23 15:42:37 2019

I'll further add that I have been working on this UH track climatology
issue for a few years now. The problem I consistently run into is
dealing
with UH tracks from separate storms that cross each other because they
occur in the same spatial locations but at different moments in time.
I was
hoping that MODE-TD could do here what regular MODE can't by allowing
those
additional UH tracks that would otherwise cross a previous one to not
do so
in space-time since the tracks would be located at different time
index
values. Ideally I'd like to explore UH tracks of longer than 1 hour. I
had
initially chosen to use the pcp_combine utility to combine model-
derived
1-hour UH tracks by summing them into 3- or 6- (or whatever length you
want)-hour tracks. While that works in principle, it exacerbates the
issue
of crossing UH tracks. So I'm going back to using 1-hour output tracks
and
inserting them into MODE-TD. Also, even though the functionality to
insert
a 6th percentile value into the output from MODE is what I'm looking
for,
the MODE tool itself is not designed to handle this other issue. So,
coming
full circle, that's where I was hoping MODE-TD could come in and save
the
day, both with the ability to better control convolution filtering and
with
the ability to control percentile output.

Jeff

On Thu, May 23, 2019 at 3:22 PM Jeff Duda <jeffduda319 at gmail.com>
wrote:

> Well I am trying to use MODE-TD to compute a UH track climatology
from the
> HRRR model. So I want to pull maximum or near-maximum UH magnitudes
from
> each track. So it would be great to be able to get the 95th or 99th
> percentile UH magnitude from each object, for example.
>
> I tried adding the same parameter that exists in MODE,
inten_perc_value,
> to the MTD config file but I'm getting mixed results. Sometimes MTD
crashes
> citing a config file syntax error  and sometimes it runs
successfully, but
> when it does I do not see the added percentile INTENSITY value added
to the
> text output anywhere.
>
> Jeff
>
> On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> As of met-8.1, the conv_radius setting defines the spatial
smoothing
>> radius
>> of influence.  The smoothing in time is currently hard coded as +/-
1 time
>> step.  That means that the smoothing of data for time t is
influenced by
>> times t-1 and t+1.  I agree that the amount of temporal smoothing
should
>> be
>> configurable.  In fact, here's an existing GitHub issue describing
this
>> feature request:
>>    https://github.com/NCAR/MET/issues/1084
>>
>> As for the intensity percentiles in MTD, it is limited to the 5
>> pre-defined
>> ones.
>> By comparison, one of the inputs to the fuzzy logic engine is the a
ratio
>> of the object intensities.  The user can select what intensity
percentile
>> is used in that ratio computation.  And whatever percentile they
choose is
>> included as a 6th intensity percentile value.
>>
>> What sort of flexibility are you looking for in extracting
intensity
>> percentile values?  How would it ideally work in your mind?
>>
>> Thanks,
>> John
>>
>> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>> >
>> > Is there a way to extract an intensity percentile value other
than the 5
>> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when
trying to
>> add
>> > "inten_perc_value" to the config file.
>> >
>> > Also, how does convolving in time work? It is not described in
the
>> user's
>> > manual. If I set conv_radius = 2.0, does that mean the
convolution
>> window
>> > is a 5 x 5 grid box window in space and a 5 time-slice window? If
I have
>> > that right, can you change future versions of MTD so that you can
use
>> > different convolution radii for the time dimension and spatial
>> dimensions?
>> > I don't want to smooth my data in time much, but definitely in
space. I
>> > feel a lot of users will want that.
>> >
>> > Jeff
>> >
>> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT <
>> > met_help at ucar.edu>
>> > wrote:
>> >
>> > > Jeff,
>> > >
>> > > Good point.  In general, the MET tools do not print warnings
for items
>> > that
>> > > don't appear in the default configuration file.  That is by
design
>> since
>> > it
>> > > gives the user more flexibility.  For example, you might
define:
>> > >
>> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
>> > > *wind_levels = [ "P500", "P850", "Z10" ];*
>> > >
>> > > And then refer to them later...
>> > >
>> > > *fcst = {*
>> > > *  field = [*
>> > > *      { name = "TMP"; level=tmp_levels; },*
>> > > *      { name = "UGRD"; level=wind_levels; },*
>> > > *      { name = "VGRD"; level=wind_levels; },*
>> > > *      { name = "WIND"; level=wind_levels; }*
>> > > *   ];*
>> > > *}*
>> > >
>> > > And we wouldn't want to print a warning or error about
tmp_levels or
>> > > wind_levels not appearing in the default config file.  There
may be
>> some
>> > > more complex logic to check for situations which are or are not
>> > acceptable,
>> > > but that hasn't risen to the top of the development priorities.
In
>> > > general, we advise that users make a copy of the default config
file
>> for
>> > > the current version they're running and then edit it from
there.  But
>> I
>> > > know plenty of DTC folks who don't do that.
>> > >
>> > > Lots of details to consider!
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT
<met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>
>> > > >
>> > > > Okay, seems sensible. Just want to add that MTD is not
throwing any
>> > > errors
>> > > > or warning messages when I use that code in the config file.
Perhaps
>> > > such a
>> > > > message could be added.
>> > > >
>> > > > Jeff
>> > > >
>> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT <
>> > > > met_help at ucar.edu> wrote:
>> > > >
>> > > > > Jeff,
>> > > > >
>> > > > > There is no "mask" option supported in MODE Time Domain.
Here's
>> the
>> > > > > default MTD config file:
>> > > > > *
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
>> > > > > <
>> > > > >
>> > > >
>> > >
>> >
>>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
>> > > > > >*
>> > > > >
>> > > > > I realize that mask is supported in MODE but it's not in
MTD.
>> There
>> > > are
>> > > > > several options that fall into this category.
>> > > > >
>> > > > > And there is an underlying issue behind it.  In order to
make the
>> > > > > convolution step in time and space as quick as possible,
the code
>> > > assumes
>> > > > > that there are no missing data values present.  Checking
for and
>> > > dealing
>> > > > > with missing data is time consuming.  But that's really
what
>> masking
>> > > > > means... setting the values at some of the grid points to
missing
>> > data.
>> > > > >
>> > > > > So MTD should probably be enhanced to deal with missing
data which
>> > > would
>> > > > > make supporting masking regions pretty easy.  The trick is
how to
>> > keep
>> > > > the
>> > > > > processing as fast as possible.
>> > > > >
>> > > > > I believe that Randy is out of the office this week, but
can
>> > hopefully
>> > > > > respond to these issues/discussion next week.
>> > > > >
>> > > > > Thanks,
>> > > > > John
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <
>> met_help at ucar.edu>
>> > > > > wrote:
>> > > > >
>> > > > > >
>> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>> > > > > >
>> > > > > > It also appears MODE-TD is ignoring my masking entry in
the
>> config
>> > > > file:
>> > > > > >
>> > > > > > mask = {
>> > > > > >    grid      = "";
>> > > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or BOTH
>> > > > > >    poly      =
"${METBASE}/CONUS_east_of_rockies_mask.nc";
>> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or BOTH
>> > > > > > }
>> > > > > >
>> > > > > > The outputs appear to cover the entire input domain,
which is
>> not
>> > > what
>> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
>> > > > > >
>> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <
>> jeffduda319 at gmail.com>
>> > > > wrote:
>> > > > > >
>> > > > > > > Well I need to add some other potential bugs with MODE-
TD
>> output.
>> > > > Some
>> > > > > > > columns appear to be all zeros when I don't think they
should:
>> > > > > > >
>> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
>> > > > > > > 3d_single_simple: CDIST_TRAVELED
>> > > > > > >
>> > > > > > > Jeff
>> > > > > > >
>> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway via
RT <
>> > > > > > > met_help at ucar.edu> wrote:
>> > > > > > >
>> > > > > > >> Hi Jeff and Randy,
>> > > > > > >>
>> > > > > > >> I took a look at the data you sent, and I suspect
you've
>> > > uncovered a
>> > > > > bug
>> > > > > > >> in
>> > > > > > >> the output of MTD.  As you've described...
>> > > > > > >> (1) Lines 2 - 521 contain information about 2D slices
of the
>> > > simple
>> > > > > > >> forecast objects.
>> > > > > > >> (2) Lines 522 - 796 contain information about 2D
slices of
>> the
>> > > > simple
>> > > > > > >> observation objects.
>> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain information about
2D
>> slices
>> > > of
>> > > > > the
>> > > > > > >> *CLUSTER* forecast objects.
>> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain information about
2D
>> slices
>> > > of
>> > > > > the
>> > > > > > >> *CLUSTER* forecast objects.
>> > > > > > >>
>> > > > > > >> The problem in (3) and (4) is that the OBJECT_ID
column
>> should
>> > > begin
>> > > > > > with
>> > > > > > >> a
>> > > > > > >> "C" to indicate that the info is for a cluster object.
>> > > > > > >>
>> > > > > > >> Looks like this bug is present in the output of met-
8.0,
>> > met-8.1,
>> > > > and
>> > > > > > the
>> > > > > > >> current development version.
>> > > > > > >>
>> > > > > > >> Randy, please take a look and confirm that this is the
case.
>> > >  It'd
>> > > > > > >> probably be wise to carefully review the contents of
the
>> > OBJECT_ID
>> > > > and
>> > > > > > >> OBJECT_CAT columns across all the MTD output files.
If
>> > confirmed,
>> > > > > we'll
>> > > > > > >> need a bugfix for this... and this will be our first
one
>> after
>> > > > > > >> transitioning to GitHub.
>> > > > > > >>
>> > > > > > >> Thanks,
>> > > > > > >> John
>> > > > > > >>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via RT
<
>> > > > > > met_help at ucar.edu
>> > > > > > >> >
>> > > > > > >> wrote:
>> > > > > > >>
>> > > > > > >> >
>> > > > > > >> > <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>> > >
>> > > > > > >> >
>> > > > > > >> > Hi Jeff -
>> > > > > > >> > I've passed this question on to Randy Bullock who
works on
>> the
>> > > > MODE
>> > > > > > and
>> > > > > > >> > the MODE-TD tools.
>> > > > > > >> > I think he is out today and Monday, but should have
a
>> chance
>> > to
>> > > > > follow
>> > > > > > >> up
>> > > > > > >> > early next week.
>> > > > > > >> > thanks,
>> > > > > > >> > David
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >>
>> > > > > > >
>> > > > > > > --
>> > > > > > > Jeff Duda, Research Scientist
>> > > > > > > University of Colorado Boulder
>> > > > > > > Cooperative Institute for Research in Environmental
Sciences
>> > > > > > > NOAA/OAR/ESRL/Global Systems Division
>> > > > > > > Boulder, CO
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Jeff Duda, Research Scientist
>> > > > > > University of Colorado Boulder
>> > > > > > Cooperative Institute for Research in Environmental
Sciences
>> > > > > > NOAA/OAR/ESRL/Global Systems Division
>> > > > > > Boulder, CO
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > > --
>> > > > Jeff Duda, Research Scientist
>> > > > University of Colorado Boulder
>> > > > Cooperative Institute for Research in Environmental Sciences
>> > > > NOAA/OAR/ESRL/Global Systems Division
>> > > > Boulder, CO
>> > > >
>> > > >
>> > >
>> > >
>> >
>> > --
>> > Jeff Duda, Research Scientist
>> > University of Colorado Boulder
>> > Cooperative Institute for Research in Environmental Sciences
>> > NOAA/OAR/ESRL/Global Systems Division
>> > Boulder, CO
>> >
>> >
>>
>>
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>


--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: John Halley Gotway
Time: Fri May 24 10:38:45 2019

Jeff,

I asked Randy to read through this message history and get back to you
next
week on the issues/questions you've raised.

Have a nice weekend.

Thanks,
John

On Thu, May 23, 2019 at 3:42 PM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> I'll further add that I have been working on this UH track
climatology
> issue for a few years now. The problem I consistently run into is
dealing
> with UH tracks from separate storms that cross each other because
they
> occur in the same spatial locations but at different moments in
time. I was
> hoping that MODE-TD could do here what regular MODE can't by
allowing those
> additional UH tracks that would otherwise cross a previous one to
not do so
> in space-time since the tracks would be located at different time
index
> values. Ideally I'd like to explore UH tracks of longer than 1 hour.
I had
> initially chosen to use the pcp_combine utility to combine model-
derived
> 1-hour UH tracks by summing them into 3- or 6- (or whatever length
you
> want)-hour tracks. While that works in principle, it exacerbates the
issue
> of crossing UH tracks. So I'm going back to using 1-hour output
tracks and
> inserting them into MODE-TD. Also, even though the functionality to
insert
> a 6th percentile value into the output from MODE is what I'm looking
for,
> the MODE tool itself is not designed to handle this other issue. So,
coming
> full circle, that's where I was hoping MODE-TD could come in and
save the
> day, both with the ability to better control convolution filtering
and with
> the ability to control percentile output.
>
> Jeff
>
> On Thu, May 23, 2019 at 3:22 PM Jeff Duda <jeffduda319 at gmail.com>
wrote:
>
> > Well I am trying to use MODE-TD to compute a UH track climatology
from
> the
> > HRRR model. So I want to pull maximum or near-maximum UH
magnitudes from
> > each track. So it would be great to be able to get the 95th or
99th
> > percentile UH magnitude from each object, for example.
> >
> > I tried adding the same parameter that exists in MODE,
inten_perc_value,
> > to the MTD config file but I'm getting mixed results. Sometimes
MTD
> crashes
> > citing a config file syntax error  and sometimes it runs
successfully,
> but
> > when it does I do not see the added percentile INTENSITY value
added to
> the
> > text output anywhere.
> >
> > Jeff
> >
> > On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jeff,
> >>
> >> As of met-8.1, the conv_radius setting defines the spatial
smoothing
> >> radius
> >> of influence.  The smoothing in time is currently hard coded as
+/- 1
> time
> >> step.  That means that the smoothing of data for time t is
influenced by
> >> times t-1 and t+1.  I agree that the amount of temporal smoothing
should
> >> be
> >> configurable.  In fact, here's an existing GitHub issue
describing this
> >> feature request:
> >>    https://github.com/NCAR/MET/issues/1084
> >>
> >> As for the intensity percentiles in MTD, it is limited to the 5
> >> pre-defined
> >> ones.
> >> By comparison, one of the inputs to the fuzzy logic engine is the
a
> ratio
> >> of the object intensities.  The user can select what intensity
> percentile
> >> is used in that ratio computation.  And whatever percentile they
choose
> is
> >> included as a 6th intensity percentile value.
> >>
> >> What sort of flexibility are you looking for in extracting
intensity
> >> percentile values?  How would it ideally work in your mind?
> >>
> >> Thanks,
> >> John
> >>
> >> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >> >
> >> > Is there a way to extract an intensity percentile value other
than
> the 5
> >> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when
trying to
> >> add
> >> > "inten_perc_value" to the config file.
> >> >
> >> > Also, how does convolving in time work? It is not described in
the
> >> user's
> >> > manual. If I set conv_radius = 2.0, does that mean the
convolution
> >> window
> >> > is a 5 x 5 grid box window in space and a 5 time-slice window?
If I
> have
> >> > that right, can you change future versions of MTD so that you
can use
> >> > different convolution radii for the time dimension and spatial
> >> dimensions?
> >> > I don't want to smooth my data in time much, but definitely in
space.
> I
> >> > feel a lot of users will want that.
> >> >
> >> > Jeff
> >> >
> >> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT <
> >> > met_help at ucar.edu>
> >> > wrote:
> >> >
> >> > > Jeff,
> >> > >
> >> > > Good point.  In general, the MET tools do not print warnings
for
> items
> >> > that
> >> > > don't appear in the default configuration file.  That is by
design
> >> since
> >> > it
> >> > > gives the user more flexibility.  For example, you might
define:
> >> > >
> >> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
> >> > > *wind_levels = [ "P500", "P850", "Z10" ];*
> >> > >
> >> > > And then refer to them later...
> >> > >
> >> > > *fcst = {*
> >> > > *  field = [*
> >> > > *      { name = "TMP"; level=tmp_levels; },*
> >> > > *      { name = "UGRD"; level=wind_levels; },*
> >> > > *      { name = "VGRD"; level=wind_levels; },*
> >> > > *      { name = "WIND"; level=wind_levels; }*
> >> > > *   ];*
> >> > > *}*
> >> > >
> >> > > And we wouldn't want to print a warning or error about
tmp_levels or
> >> > > wind_levels not appearing in the default config file.  There
may be
> >> some
> >> > > more complex logic to check for situations which are or are
not
> >> > acceptable,
> >> > > but that hasn't risen to the top of the development
priorities.  In
> >> > > general, we advise that users make a copy of the default
config file
> >> for
> >> > > the current version they're running and then edit it from
there.
> But
> >> I
> >> > > know plenty of DTC folks who don't do that.
> >> > >
> >> > > Lots of details to consider!
> >> > >
> >> > > Thanks,
> >> > > John
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT <
> met_help at ucar.edu>
> >> > > wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >> > > >
> >> > > > Okay, seems sensible. Just want to add that MTD is not
throwing
> any
> >> > > errors
> >> > > > or warning messages when I use that code in the config
file.
> Perhaps
> >> > > such a
> >> > > > message could be added.
> >> > > >
> >> > > > Jeff
> >> > > >
> >> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via RT
<
> >> > > > met_help at ucar.edu> wrote:
> >> > > >
> >> > > > > Jeff,
> >> > > > >
> >> > > > > There is no "mask" option supported in MODE Time Domain.
Here's
> >> the
> >> > > > > default MTD config file:
> >> > > > > *
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> >> > > > > <
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> >> > > > > >*
> >> > > > >
> >> > > > > I realize that mask is supported in MODE but it's not in
MTD.
> >> There
> >> > > are
> >> > > > > several options that fall into this category.
> >> > > > >
> >> > > > > And there is an underlying issue behind it.  In order to
make
> the
> >> > > > > convolution step in time and space as quick as possible,
the
> code
> >> > > assumes
> >> > > > > that there are no missing data values present.  Checking
for and
> >> > > dealing
> >> > > > > with missing data is time consuming.  But that's really
what
> >> masking
> >> > > > > means... setting the values at some of the grid points to
> missing
> >> > data.
> >> > > > >
> >> > > > > So MTD should probably be enhanced to deal with missing
data
> which
> >> > > would
> >> > > > > make supporting masking regions pretty easy.  The trick
is how
> to
> >> > keep
> >> > > > the
> >> > > > > processing as fast as possible.
> >> > > > >
> >> > > > > I believe that Randy is out of the office this week, but
can
> >> > hopefully
> >> > > > > respond to these issues/discussion next week.
> >> > > > >
> >> > > > > Thanks,
> >> > > > > John
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <
> >> met_help at ucar.edu>
> >> > > > > wrote:
> >> > > > >
> >> > > > > >
> >> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> >
> >> > > > > >
> >> > > > > > It also appears MODE-TD is ignoring my masking entry in
the
> >> config
> >> > > > file:
> >> > > > > >
> >> > > > > > mask = {
> >> > > > > >    grid      = "";
> >> > > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or
BOTH
> >> > > > > >    poly      =
"${METBASE}/CONUS_east_of_rockies_mask.nc";
> >> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or
BOTH
> >> > > > > > }
> >> > > > > >
> >> > > > > > The outputs appear to cover the entire input domain,
which is
> >> not
> >> > > what
> >> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
> >> > > > > >
> >> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <
> >> jeffduda319 at gmail.com>
> >> > > > wrote:
> >> > > > > >
> >> > > > > > > Well I need to add some other potential bugs with
MODE-TD
> >> output.
> >> > > > Some
> >> > > > > > > columns appear to be all zeros when I don't think
they
> should:
> >> > > > > > >
> >> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> >> > > > > > > 3d_single_simple: CDIST_TRAVELED
> >> > > > > > >
> >> > > > > > > Jeff
> >> > > > > > >
> >> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway
via RT <
> >> > > > > > > met_help at ucar.edu> wrote:
> >> > > > > > >
> >> > > > > > >> Hi Jeff and Randy,
> >> > > > > > >>
> >> > > > > > >> I took a look at the data you sent, and I suspect
you've
> >> > > uncovered a
> >> > > > > bug
> >> > > > > > >> in
> >> > > > > > >> the output of MTD.  As you've described...
> >> > > > > > >> (1) Lines 2 - 521 contain information about 2D
slices of
> the
> >> > > simple
> >> > > > > > >> forecast objects.
> >> > > > > > >> (2) Lines 522 - 796 contain information about 2D
slices of
> >> the
> >> > > > simple
> >> > > > > > >> observation objects.
> >> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain information
about 2D
> >> slices
> >> > > of
> >> > > > > the
> >> > > > > > >> *CLUSTER* forecast objects.
> >> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain information
about 2D
> >> slices
> >> > > of
> >> > > > > the
> >> > > > > > >> *CLUSTER* forecast objects.
> >> > > > > > >>
> >> > > > > > >> The problem in (3) and (4) is that the OBJECT_ID
column
> >> should
> >> > > begin
> >> > > > > > with
> >> > > > > > >> a
> >> > > > > > >> "C" to indicate that the info is for a cluster
object.
> >> > > > > > >>
> >> > > > > > >> Looks like this bug is present in the output of met-
8.0,
> >> > met-8.1,
> >> > > > and
> >> > > > > > the
> >> > > > > > >> current development version.
> >> > > > > > >>
> >> > > > > > >> Randy, please take a look and confirm that this is
the
> case.
> >> > >  It'd
> >> > > > > > >> probably be wise to carefully review the contents of
the
> >> > OBJECT_ID
> >> > > > and
> >> > > > > > >> OBJECT_CAT columns across all the MTD output files.
If
> >> > confirmed,
> >> > > > > we'll
> >> > > > > > >> need a bugfix for this... and this will be our first
one
> >> after
> >> > > > > > >> transitioning to GitHub.
> >> > > > > > >>
> >> > > > > > >> Thanks,
> >> > > > > > >> John
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore via
RT <
> >> > > > > > met_help at ucar.edu
> >> > > > > > >> >
> >> > > > > > >> wrote:
> >> > > > > > >>
> >> > > > > > >> >
> >> > > > > > >> > <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> >> > >
> >> > > > > > >> >
> >> > > > > > >> > Hi Jeff -
> >> > > > > > >> > I've passed this question on to Randy Bullock who
works
> on
> >> the
> >> > > > MODE
> >> > > > > > and
> >> > > > > > >> > the MODE-TD tools.
> >> > > > > > >> > I think he is out today and Monday, but should
have a
> >> chance
> >> > to
> >> > > > > follow
> >> > > > > > >> up
> >> > > > > > >> > early next week.
> >> > > > > > >> > thanks,
> >> > > > > > >> > David
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Jeff Duda, Research Scientist
> >> > > > > > > University of Colorado Boulder
> >> > > > > > > Cooperative Institute for Research in Environmental
Sciences
> >> > > > > > > NOAA/OAR/ESRL/Global Systems Division
> >> > > > > > > Boulder, CO
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Jeff Duda, Research Scientist
> >> > > > > > University of Colorado Boulder
> >> > > > > > Cooperative Institute for Research in Environmental
Sciences
> >> > > > > > NOAA/OAR/ESRL/Global Systems Division
> >> > > > > > Boulder, CO
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > --
> >> > > > Jeff Duda, Research Scientist
> >> > > > University of Colorado Boulder
> >> > > > Cooperative Institute for Research in Environmental
Sciences
> >> > > > NOAA/OAR/ESRL/Global Systems Division
> >> > > > Boulder, CO
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> > --
> >> > Jeff Duda, Research Scientist
> >> > University of Colorado Boulder
> >> > Cooperative Institute for Research in Environmental Sciences
> >> > NOAA/OAR/ESRL/Global Systems Division
> >> > Boulder, CO
> >> >
> >> >
> >>
> >>
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
>
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>
>

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Mon Jun 03 14:15:07 2019

If possible, if the MET folks could just point me to the code where a
custom intensity percentile value could be added to MODE-TD and I
could
just recompile it myself on Jet, that might work for a temporary
solution
while I wait for a more major update.

Jeff

On Fri, May 24, 2019 at 10:38 AM John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jeff,
>
> I asked Randy to read through this message history and get back to
you next
> week on the issues/questions you've raised.
>
> Have a nice weekend.
>
> Thanks,
> John
>
> On Thu, May 23, 2019 at 3:42 PM Jeff Duda via RT <met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > I'll further add that I have been working on this UH track
climatology
> > issue for a few years now. The problem I consistently run into is
dealing
> > with UH tracks from separate storms that cross each other because
they
> > occur in the same spatial locations but at different moments in
time. I
> was
> > hoping that MODE-TD could do here what regular MODE can't by
allowing
> those
> > additional UH tracks that would otherwise cross a previous one to
not do
> so
> > in space-time since the tracks would be located at different time
index
> > values. Ideally I'd like to explore UH tracks of longer than 1
hour. I
> had
> > initially chosen to use the pcp_combine utility to combine model-
derived
> > 1-hour UH tracks by summing them into 3- or 6- (or whatever length
you
> > want)-hour tracks. While that works in principle, it exacerbates
the
> issue
> > of crossing UH tracks. So I'm going back to using 1-hour output
tracks
> and
> > inserting them into MODE-TD. Also, even though the functionality
to
> insert
> > a 6th percentile value into the output from MODE is what I'm
looking for,
> > the MODE tool itself is not designed to handle this other issue.
So,
> coming
> > full circle, that's where I was hoping MODE-TD could come in and
save the
> > day, both with the ability to better control convolution filtering
and
> with
> > the ability to control percentile output.
> >
> > Jeff
> >
> > On Thu, May 23, 2019 at 3:22 PM Jeff Duda <jeffduda319 at gmail.com>
wrote:
> >
> > > Well I am trying to use MODE-TD to compute a UH track
climatology from
> > the
> > > HRRR model. So I want to pull maximum or near-maximum UH
magnitudes
> from
> > > each track. So it would be great to be able to get the 95th or
99th
> > > percentile UH magnitude from each object, for example.
> > >
> > > I tried adding the same parameter that exists in MODE,
> inten_perc_value,
> > > to the MTD config file but I'm getting mixed results. Sometimes
MTD
> > crashes
> > > citing a config file syntax error  and sometimes it runs
successfully,
> > but
> > > when it does I do not see the added percentile INTENSITY value
added to
> > the
> > > text output anywhere.
> > >
> > > Jeff
> > >
> > > On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jeff,
> > >>
> > >> As of met-8.1, the conv_radius setting defines the spatial
smoothing
> > >> radius
> > >> of influence.  The smoothing in time is currently hard coded as
+/- 1
> > time
> > >> step.  That means that the smoothing of data for time t is
influenced
> by
> > >> times t-1 and t+1.  I agree that the amount of temporal
smoothing
> should
> > >> be
> > >> configurable.  In fact, here's an existing GitHub issue
describing
> this
> > >> feature request:
> > >>    https://github.com/NCAR/MET/issues/1084
> > >>
> > >> As for the intensity percentiles in MTD, it is limited to the 5
> > >> pre-defined
> > >> ones.
> > >> By comparison, one of the inputs to the fuzzy logic engine is
the a
> > ratio
> > >> of the object intensities.  The user can select what intensity
> > percentile
> > >> is used in that ratio computation.  And whatever percentile
they
> choose
> > is
> > >> included as a 6th intensity percentile value.
> > >>
> > >> What sort of flexibility are you looking for in extracting
intensity
> > >> percentile values?  How would it ideally work in your mind?
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT
<met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>
> > >> >
> > >> > Is there a way to extract an intensity percentile value other
than
> > the 5
> > >> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when
trying
> to
> > >> add
> > >> > "inten_perc_value" to the config file.
> > >> >
> > >> > Also, how does convolving in time work? It is not described
in the
> > >> user's
> > >> > manual. If I set conv_radius = 2.0, does that mean the
convolution
> > >> window
> > >> > is a 5 x 5 grid box window in space and a 5 time-slice
window? If I
> > have
> > >> > that right, can you change future versions of MTD so that you
can
> use
> > >> > different convolution radii for the time dimension and
spatial
> > >> dimensions?
> > >> > I don't want to smooth my data in time much, but definitely
in
> space.
> > I
> > >> > feel a lot of users will want that.
> > >> >
> > >> > Jeff
> > >> >
> > >> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT <
> > >> > met_help at ucar.edu>
> > >> > wrote:
> > >> >
> > >> > > Jeff,
> > >> > >
> > >> > > Good point.  In general, the MET tools do not print
warnings for
> > items
> > >> > that
> > >> > > don't appear in the default configuration file.  That is by
design
> > >> since
> > >> > it
> > >> > > gives the user more flexibility.  For example, you might
define:
> > >> > >
> > >> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
> > >> > > *wind_levels = [ "P500", "P850", "Z10" ];*
> > >> > >
> > >> > > And then refer to them later...
> > >> > >
> > >> > > *fcst = {*
> > >> > > *  field = [*
> > >> > > *      { name = "TMP"; level=tmp_levels; },*
> > >> > > *      { name = "UGRD"; level=wind_levels; },*
> > >> > > *      { name = "VGRD"; level=wind_levels; },*
> > >> > > *      { name = "WIND"; level=wind_levels; }*
> > >> > > *   ];*
> > >> > > *}*
> > >> > >
> > >> > > And we wouldn't want to print a warning or error about
tmp_levels
> or
> > >> > > wind_levels not appearing in the default config file.
There may
> be
> > >> some
> > >> > > more complex logic to check for situations which are or are
not
> > >> > acceptable,
> > >> > > but that hasn't risen to the top of the development
priorities.
> In
> > >> > > general, we advise that users make a copy of the default
config
> file
> > >> for
> > >> > > the current version they're running and then edit it from
there.
> > But
> > >> I
> > >> > > know plenty of DTC folks who don't do that.
> > >> > >
> > >> > > Lots of details to consider!
> > >> > >
> > >> > > Thanks,
> > >> > > John
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT <
> > met_help at ucar.edu>
> > >> > > wrote:
> > >> > >
> > >> > > >
> > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > >> > > >
> > >> > > > Okay, seems sensible. Just want to add that MTD is not
throwing
> > any
> > >> > > errors
> > >> > > > or warning messages when I use that code in the config
file.
> > Perhaps
> > >> > > such a
> > >> > > > message could be added.
> > >> > > >
> > >> > > > Jeff
> > >> > > >
> > >> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via
RT <
> > >> > > > met_help at ucar.edu> wrote:
> > >> > > >
> > >> > > > > Jeff,
> > >> > > > >
> > >> > > > > There is no "mask" option supported in MODE Time
Domain.
> Here's
> > >> the
> > >> > > > > default MTD config file:
> > >> > > > > *
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > >> > > > > <
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > >> > > > > >*
> > >> > > > >
> > >> > > > > I realize that mask is supported in MODE but it's not
in MTD.
> > >> There
> > >> > > are
> > >> > > > > several options that fall into this category.
> > >> > > > >
> > >> > > > > And there is an underlying issue behind it.  In order
to make
> > the
> > >> > > > > convolution step in time and space as quick as
possible, the
> > code
> > >> > > assumes
> > >> > > > > that there are no missing data values present.
Checking for
> and
> > >> > > dealing
> > >> > > > > with missing data is time consuming.  But that's really
what
> > >> masking
> > >> > > > > means... setting the values at some of the grid points
to
> > missing
> > >> > data.
> > >> > > > >
> > >> > > > > So MTD should probably be enhanced to deal with missing
data
> > which
> > >> > > would
> > >> > > > > make supporting masking regions pretty easy.  The trick
is how
> > to
> > >> > keep
> > >> > > > the
> > >> > > > > processing as fast as possible.
> > >> > > > >
> > >> > > > > I believe that Randy is out of the office this week,
but can
> > >> > hopefully
> > >> > > > > respond to these issues/discussion next week.
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > John
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <
> > >> met_help at ucar.edu>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > >
> > >> > > > > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > >
> > >> > > > > >
> > >> > > > > > It also appears MODE-TD is ignoring my masking entry
in the
> > >> config
> > >> > > > file:
> > >> > > > > >
> > >> > > > > > mask = {
> > >> > > > > >    grid      = "";
> > >> > > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS, or
BOTH
> > >> > > > > >    poly      =
"${METBASE}/CONUS_east_of_rockies_mask.nc";
> > >> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS, or
BOTH
> > >> > > > > > }
> > >> > > > > >
> > >> > > > > > The outputs appear to cover the entire input domain,
which
> is
> > >> not
> > >> > > what
> > >> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
> > >> > > > > >
> > >> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <
> > >> jeffduda319 at gmail.com>
> > >> > > > wrote:
> > >> > > > > >
> > >> > > > > > > Well I need to add some other potential bugs with
MODE-TD
> > >> output.
> > >> > > > Some
> > >> > > > > > > columns appear to be all zeros when I don't think
they
> > should:
> > >> > > > > > >
> > >> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > >> > > > > > > 3d_single_simple: CDIST_TRAVELED
> > >> > > > > > >
> > >> > > > > > > Jeff
> > >> > > > > > >
> > >> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley Gotway
via
> RT <
> > >> > > > > > > met_help at ucar.edu> wrote:
> > >> > > > > > >
> > >> > > > > > >> Hi Jeff and Randy,
> > >> > > > > > >>
> > >> > > > > > >> I took a look at the data you sent, and I suspect
you've
> > >> > > uncovered a
> > >> > > > > bug
> > >> > > > > > >> in
> > >> > > > > > >> the output of MTD.  As you've described...
> > >> > > > > > >> (1) Lines 2 - 521 contain information about 2D
slices of
> > the
> > >> > > simple
> > >> > > > > > >> forecast objects.
> > >> > > > > > >> (2) Lines 522 - 796 contain information about 2D
slices
> of
> > >> the
> > >> > > > simple
> > >> > > > > > >> observation objects.
> > >> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain information
about 2D
> > >> slices
> > >> > > of
> > >> > > > > the
> > >> > > > > > >> *CLUSTER* forecast objects.
> > >> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain information
about 2D
> > >> slices
> > >> > > of
> > >> > > > > the
> > >> > > > > > >> *CLUSTER* forecast objects.
> > >> > > > > > >>
> > >> > > > > > >> The problem in (3) and (4) is that the OBJECT_ID
column
> > >> should
> > >> > > begin
> > >> > > > > > with
> > >> > > > > > >> a
> > >> > > > > > >> "C" to indicate that the info is for a cluster
object.
> > >> > > > > > >>
> > >> > > > > > >> Looks like this bug is present in the output of
met-8.0,
> > >> > met-8.1,
> > >> > > > and
> > >> > > > > > the
> > >> > > > > > >> current development version.
> > >> > > > > > >>
> > >> > > > > > >> Randy, please take a look and confirm that this is
the
> > case.
> > >> > >  It'd
> > >> > > > > > >> probably be wise to carefully review the contents
of the
> > >> > OBJECT_ID
> > >> > > > and
> > >> > > > > > >> OBJECT_CAT columns across all the MTD output
files.  If
> > >> > confirmed,
> > >> > > > > we'll
> > >> > > > > > >> need a bugfix for this... and this will be our
first one
> > >> after
> > >> > > > > > >> transitioning to GitHub.
> > >> > > > > > >>
> > >> > > > > > >> Thanks,
> > >> > > > > > >> John
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore
via RT <
> > >> > > > > > met_help at ucar.edu
> > >> > > > > > >> >
> > >> > > > > > >> wrote:
> > >> > > > > > >>
> > >> > > > > > >> >
> > >> > > > > > >> > <URL:
> > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > >> > >
> > >> > > > > > >> >
> > >> > > > > > >> > Hi Jeff -
> > >> > > > > > >> > I've passed this question on to Randy Bullock
who works
> > on
> > >> the
> > >> > > > MODE
> > >> > > > > > and
> > >> > > > > > >> > the MODE-TD tools.
> > >> > > > > > >> > I think he is out today and Monday, but should
have a
> > >> chance
> > >> > to
> > >> > > > > follow
> > >> > > > > > >> up
> > >> > > > > > >> > early next week.
> > >> > > > > > >> > thanks,
> > >> > > > > > >> > David
> > >> > > > > > >> >
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Jeff Duda, Research Scientist
> > >> > > > > > > University of Colorado Boulder
> > >> > > > > > > Cooperative Institute for Research in Environmental
> Sciences
> > >> > > > > > > NOAA/OAR/ESRL/Global Systems Division
> > >> > > > > > > Boulder, CO
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > --
> > >> > > > > > Jeff Duda, Research Scientist
> > >> > > > > > University of Colorado Boulder
> > >> > > > > > Cooperative Institute for Research in Environmental
Sciences
> > >> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > >> > > > > > Boulder, CO
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > > --
> > >> > > > Jeff Duda, Research Scientist
> > >> > > > University of Colorado Boulder
> > >> > > > Cooperative Institute for Research in Environmental
Sciences
> > >> > > > NOAA/OAR/ESRL/Global Systems Division
> > >> > > > Boulder, CO
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> > --
> > >> > Jeff Duda, Research Scientist
> > >> > University of Colorado Boulder
> > >> > Cooperative Institute for Research in Environmental Sciences
> > >> > NOAA/OAR/ESRL/Global Systems Division
> > >> > Boulder, CO
> > >> >
> > >> >
> > >>
> > >>
> > >
> > > --
> > > Jeff Duda, Research Scientist
> > > University of Colorado Boulder
> > > Cooperative Institute for Research in Environmental Sciences
> > > NOAA/OAR/ESRL/Global Systems Division
> > > Boulder, CO
> > >
> >
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
> >
>
>

--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: Randy Bullock
Time: Tue Jun 04 15:00:41 2019

Hi Jeff -

The issue with the letter 'C' not appearing in the text output where
it
should in MTD has been fixed and will be available in the next bugfix
release of MET (ie, soon).

I've made tickets for your other MTD enhancement requests, and
hopefully
they will be available in the next release.

Randy



On Mon, Jun 3, 2019 at 2:15 PM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> If possible, if the MET folks could just point me to the code where
a
> custom intensity percentile value could be added to MODE-TD and I
could
> just recompile it myself on Jet, that might work for a temporary
solution
> while I wait for a more major update.
>
> Jeff
>
> On Fri, May 24, 2019 at 10:38 AM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jeff,
> >
> > I asked Randy to read through this message history and get back to
you
> next
> > week on the issues/questions you've raised.
> >
> > Have a nice weekend.
> >
> > Thanks,
> > John
> >
> > On Thu, May 23, 2019 at 3:42 PM Jeff Duda via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > >
> > > I'll further add that I have been working on this UH track
climatology
> > > issue for a few years now. The problem I consistently run into
is
> dealing
> > > with UH tracks from separate storms that cross each other
because they
> > > occur in the same spatial locations but at different moments in
time. I
> > was
> > > hoping that MODE-TD could do here what regular MODE can't by
allowing
> > those
> > > additional UH tracks that would otherwise cross a previous one
to not
> do
> > so
> > > in space-time since the tracks would be located at different
time index
> > > values. Ideally I'd like to explore UH tracks of longer than 1
hour. I
> > had
> > > initially chosen to use the pcp_combine utility to combine
> model-derived
> > > 1-hour UH tracks by summing them into 3- or 6- (or whatever
length you
> > > want)-hour tracks. While that works in principle, it exacerbates
the
> > issue
> > > of crossing UH tracks. So I'm going back to using 1-hour output
tracks
> > and
> > > inserting them into MODE-TD. Also, even though the functionality
to
> > insert
> > > a 6th percentile value into the output from MODE is what I'm
looking
> for,
> > > the MODE tool itself is not designed to handle this other issue.
So,
> > coming
> > > full circle, that's where I was hoping MODE-TD could come in and
save
> the
> > > day, both with the ability to better control convolution
filtering and
> > with
> > > the ability to control percentile output.
> > >
> > > Jeff
> > >
> > > On Thu, May 23, 2019 at 3:22 PM Jeff Duda
<jeffduda319 at gmail.com>
> wrote:
> > >
> > > > Well I am trying to use MODE-TD to compute a UH track
climatology
> from
> > > the
> > > > HRRR model. So I want to pull maximum or near-maximum UH
magnitudes
> > from
> > > > each track. So it would be great to be able to get the 95th or
99th
> > > > percentile UH magnitude from each object, for example.
> > > >
> > > > I tried adding the same parameter that exists in MODE,
> > inten_perc_value,
> > > > to the MTD config file but I'm getting mixed results.
Sometimes MTD
> > > crashes
> > > > citing a config file syntax error  and sometimes it runs
> successfully,
> > > but
> > > > when it does I do not see the added percentile INTENSITY value
added
> to
> > > the
> > > > text output anywhere.
> > > >
> > > > Jeff
> > > >
> > > > On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Jeff,
> > > >>
> > > >> As of met-8.1, the conv_radius setting defines the spatial
smoothing
> > > >> radius
> > > >> of influence.  The smoothing in time is currently hard coded
as +/-
> 1
> > > time
> > > >> step.  That means that the smoothing of data for time t is
> influenced
> > by
> > > >> times t-1 and t+1.  I agree that the amount of temporal
smoothing
> > should
> > > >> be
> > > >> configurable.  In fact, here's an existing GitHub issue
describing
> > this
> > > >> feature request:
> > > >>    https://github.com/NCAR/MET/issues/1084
> > > >>
> > > >> As for the intensity percentiles in MTD, it is limited to the
5
> > > >> pre-defined
> > > >> ones.
> > > >> By comparison, one of the inputs to the fuzzy logic engine is
the a
> > > ratio
> > > >> of the object intensities.  The user can select what
intensity
> > > percentile
> > > >> is used in that ratio computation.  And whatever percentile
they
> > choose
> > > is
> > > >> included as a 6th intensity percentile value.
> > > >>
> > > >> What sort of flexibility are you looking for in extracting
intensity
> > > >> percentile values?  How would it ideally work in your mind?
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT <
> met_help at ucar.edu>
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > >> >
> > > >> > Is there a way to extract an intensity percentile value
other than
> > > the 5
> > > >> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors when
trying
> > to
> > > >> add
> > > >> > "inten_perc_value" to the config file.
> > > >> >
> > > >> > Also, how does convolving in time work? It is not described
in the
> > > >> user's
> > > >> > manual. If I set conv_radius = 2.0, does that mean the
convolution
> > > >> window
> > > >> > is a 5 x 5 grid box window in space and a 5 time-slice
window? If
> I
> > > have
> > > >> > that right, can you change future versions of MTD so that
you can
> > use
> > > >> > different convolution radii for the time dimension and
spatial
> > > >> dimensions?
> > > >> > I don't want to smooth my data in time much, but definitely
in
> > space.
> > > I
> > > >> > feel a lot of users will want that.
> > > >> >
> > > >> > Jeff
> > > >> >
> > > >> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT <
> > > >> > met_help at ucar.edu>
> > > >> > wrote:
> > > >> >
> > > >> > > Jeff,
> > > >> > >
> > > >> > > Good point.  In general, the MET tools do not print
warnings for
> > > items
> > > >> > that
> > > >> > > don't appear in the default configuration file.  That is
by
> design
> > > >> since
> > > >> > it
> > > >> > > gives the user more flexibility.  For example, you might
define:
> > > >> > >
> > > >> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
> > > >> > > *wind_levels = [ "P500", "P850", "Z10" ];*
> > > >> > >
> > > >> > > And then refer to them later...
> > > >> > >
> > > >> > > *fcst = {*
> > > >> > > *  field = [*
> > > >> > > *      { name = "TMP"; level=tmp_levels; },*
> > > >> > > *      { name = "UGRD"; level=wind_levels; },*
> > > >> > > *      { name = "VGRD"; level=wind_levels; },*
> > > >> > > *      { name = "WIND"; level=wind_levels; }*
> > > >> > > *   ];*
> > > >> > > *}*
> > > >> > >
> > > >> > > And we wouldn't want to print a warning or error about
> tmp_levels
> > or
> > > >> > > wind_levels not appearing in the default config file.
There may
> > be
> > > >> some
> > > >> > > more complex logic to check for situations which are or
are not
> > > >> > acceptable,
> > > >> > > but that hasn't risen to the top of the development
priorities.
> > In
> > > >> > > general, we advise that users make a copy of the default
config
> > file
> > > >> for
> > > >> > > the current version they're running and then edit it from
there.
> > > But
> > > >> I
> > > >> > > know plenty of DTC folks who don't do that.
> > > >> > >
> > > >> > > Lots of details to consider!
> > > >> > >
> > > >> > > Thanks,
> > > >> > > John
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT <
> > > met_help at ucar.edu>
> > > >> > > wrote:
> > > >> > >
> > > >> > > >
> > > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> >
> > > >> > > >
> > > >> > > > Okay, seems sensible. Just want to add that MTD is not
> throwing
> > > any
> > > >> > > errors
> > > >> > > > or warning messages when I use that code in the config
file.
> > > Perhaps
> > > >> > > such a
> > > >> > > > message could be added.
> > > >> > > >
> > > >> > > > Jeff
> > > >> > > >
> > > >> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway via
RT <
> > > >> > > > met_help at ucar.edu> wrote:
> > > >> > > >
> > > >> > > > > Jeff,
> > > >> > > > >
> > > >> > > > > There is no "mask" option supported in MODE Time
Domain.
> > Here's
> > > >> the
> > > >> > > > > default MTD config file:
> > > >> > > > > *
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > >> > > > > <
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > >> > > > > >*
> > > >> > > > >
> > > >> > > > > I realize that mask is supported in MODE but it's not
in
> MTD.
> > > >> There
> > > >> > > are
> > > >> > > > > several options that fall into this category.
> > > >> > > > >
> > > >> > > > > And there is an underlying issue behind it.  In order
to
> make
> > > the
> > > >> > > > > convolution step in time and space as quick as
possible, the
> > > code
> > > >> > > assumes
> > > >> > > > > that there are no missing data values present.
Checking for
> > and
> > > >> > > dealing
> > > >> > > > > with missing data is time consuming.  But that's
really what
> > > >> masking
> > > >> > > > > means... setting the values at some of the grid
points to
> > > missing
> > > >> > data.
> > > >> > > > >
> > > >> > > > > So MTD should probably be enhanced to deal with
missing data
> > > which
> > > >> > > would
> > > >> > > > > make supporting masking regions pretty easy.  The
trick is
> how
> > > to
> > > >> > keep
> > > >> > > > the
> > > >> > > > > processing as fast as possible.
> > > >> > > > >
> > > >> > > > > I believe that Randy is out of the office this week,
but can
> > > >> > hopefully
> > > >> > > > > respond to these issues/discussion next week.
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > John
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <
> > > >> met_help at ucar.edu>
> > > >> > > > > wrote:
> > > >> > > > >
> > > >> > > > > >
> > > >> > > > > > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > >
> > > >> > > > > >
> > > >> > > > > > It also appears MODE-TD is ignoring my masking
entry in
> the
> > > >> config
> > > >> > > > file:
> > > >> > > > > >
> > > >> > > > > > mask = {
> > > >> > > > > >    grid      = "";
> > > >> > > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS,
or BOTH
> > > >> > > > > >    poly      =
"${METBASE}/CONUS_east_of_rockies_mask.nc
> ";
> > > >> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS,
or BOTH
> > > >> > > > > > }
> > > >> > > > > >
> > > >> > > > > > The outputs appear to cover the entire input
domain, which
> > is
> > > >> not
> > > >> > > what
> > > >> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
> > > >> > > > > >
> > > >> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <
> > > >> jeffduda319 at gmail.com>
> > > >> > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > Well I need to add some other potential bugs with
> MODE-TD
> > > >> output.
> > > >> > > > Some
> > > >> > > > > > > columns appear to be all zeros when I don't think
they
> > > should:
> > > >> > > > > > >
> > > >> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > >> > > > > > > 3d_single_simple: CDIST_TRAVELED
> > > >> > > > > > >
> > > >> > > > > > > Jeff
> > > >> > > > > > >
> > > >> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley
Gotway via
> > RT <
> > > >> > > > > > > met_help at ucar.edu> wrote:
> > > >> > > > > > >
> > > >> > > > > > >> Hi Jeff and Randy,
> > > >> > > > > > >>
> > > >> > > > > > >> I took a look at the data you sent, and I
suspect
> you've
> > > >> > > uncovered a
> > > >> > > > > bug
> > > >> > > > > > >> in
> > > >> > > > > > >> the output of MTD.  As you've described...
> > > >> > > > > > >> (1) Lines 2 - 521 contain information about 2D
slices
> of
> > > the
> > > >> > > simple
> > > >> > > > > > >> forecast objects.
> > > >> > > > > > >> (2) Lines 522 - 796 contain information about 2D
slices
> > of
> > > >> the
> > > >> > > > simple
> > > >> > > > > > >> observation objects.
> > > >> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain information
about
> 2D
> > > >> slices
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > >> *CLUSTER* forecast objects.
> > > >> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain information
about
> 2D
> > > >> slices
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > >> *CLUSTER* forecast objects.
> > > >> > > > > > >>
> > > >> > > > > > >> The problem in (3) and (4) is that the OBJECT_ID
column
> > > >> should
> > > >> > > begin
> > > >> > > > > > with
> > > >> > > > > > >> a
> > > >> > > > > > >> "C" to indicate that the info is for a cluster
object.
> > > >> > > > > > >>
> > > >> > > > > > >> Looks like this bug is present in the output of
> met-8.0,
> > > >> > met-8.1,
> > > >> > > > and
> > > >> > > > > > the
> > > >> > > > > > >> current development version.
> > > >> > > > > > >>
> > > >> > > > > > >> Randy, please take a look and confirm that this
is the
> > > case.
> > > >> > >  It'd
> > > >> > > > > > >> probably be wise to carefully review the
contents of
> the
> > > >> > OBJECT_ID
> > > >> > > > and
> > > >> > > > > > >> OBJECT_CAT columns across all the MTD output
files.  If
> > > >> > confirmed,
> > > >> > > > > we'll
> > > >> > > > > > >> need a bugfix for this... and this will be our
first
> one
> > > >> after
> > > >> > > > > > >> transitioning to GitHub.
> > > >> > > > > > >>
> > > >> > > > > > >> Thanks,
> > > >> > > > > > >> John
> > > >> > > > > > >>
> > > >> > > > > > >>
> > > >> > > > > > >>
> > > >> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David Fillmore
via RT
> <
> > > >> > > > > > met_help at ucar.edu
> > > >> > > > > > >> >
> > > >> > > > > > >> wrote:
> > > >> > > > > > >>
> > > >> > > > > > >> >
> > > >> > > > > > >> > <URL:
> > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > >> > >
> > > >> > > > > > >> >
> > > >> > > > > > >> > Hi Jeff -
> > > >> > > > > > >> > I've passed this question on to Randy Bullock
who
> works
> > > on
> > > >> the
> > > >> > > > MODE
> > > >> > > > > > and
> > > >> > > > > > >> > the MODE-TD tools.
> > > >> > > > > > >> > I think he is out today and Monday, but should
have a
> > > >> chance
> > > >> > to
> > > >> > > > > follow
> > > >> > > > > > >> up
> > > >> > > > > > >> > early next week.
> > > >> > > > > > >> > thanks,
> > > >> > > > > > >> > David
> > > >> > > > > > >> >
> > > >> > > > > > >>
> > > >> > > > > > >>
> > > >> > > > > > >
> > > >> > > > > > > --
> > > >> > > > > > > Jeff Duda, Research Scientist
> > > >> > > > > > > University of Colorado Boulder
> > > >> > > > > > > Cooperative Institute for Research in
Environmental
> > Sciences
> > > >> > > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > >> > > > > > > Boulder, CO
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > --
> > > >> > > > > > Jeff Duda, Research Scientist
> > > >> > > > > > University of Colorado Boulder
> > > >> > > > > > Cooperative Institute for Research in Environmental
> Sciences
> > > >> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > >> > > > > > Boulder, CO
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > Jeff Duda, Research Scientist
> > > >> > > > University of Colorado Boulder
> > > >> > > > Cooperative Institute for Research in Environmental
Sciences
> > > >> > > > NOAA/OAR/ESRL/Global Systems Division
> > > >> > > > Boulder, CO
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > --
> > > >> > Jeff Duda, Research Scientist
> > > >> > University of Colorado Boulder
> > > >> > Cooperative Institute for Research in Environmental
Sciences
> > > >> > NOAA/OAR/ESRL/Global Systems Division
> > > >> > Boulder, CO
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > > --
> > > > Jeff Duda, Research Scientist
> > > > University of Colorado Boulder
> > > > Cooperative Institute for Research in Environmental Sciences
> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > Boulder, CO
> > > >
> > >
> > >
> > > --
> > > Jeff Duda, Research Scientist
> > > University of Colorado Boulder
> > > Cooperative Institute for Research in Environmental Sciences
> > > NOAA/OAR/ESRL/Global Systems Division
> > > Boulder, CO
> > >
> > >
> >
> >
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>
>

------------------------------------------------
Subject: understanding text output from mode-td
From: Jeff Duda
Time: Tue Jun 25 09:07:36 2019

Do you have an approximate time table for when this next release
featuring
these changes may happen?

Jeff

On Tue, Jun 4, 2019 at 3:00 PM Randy Bullock via RT
<met_help at ucar.edu>
wrote:

> Hi Jeff -
>
> The issue with the letter 'C' not appearing in the text output where
it
> should in MTD has been fixed and will be available in the next
bugfix
> release of MET (ie, soon).
>
> I've made tickets for your other MTD enhancement requests, and
hopefully
> they will be available in the next release.
>
> Randy
>
>
>
> On Mon, Jun 3, 2019 at 2:15 PM Jeff Duda via RT <met_help at ucar.edu>
wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> >
> > If possible, if the MET folks could just point me to the code
where a
> > custom intensity percentile value could be added to MODE-TD and I
could
> > just recompile it myself on Jet, that might work for a temporary
solution
> > while I wait for a more major update.
> >
> > Jeff
> >
> > On Fri, May 24, 2019 at 10:38 AM John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jeff,
> > >
> > > I asked Randy to read through this message history and get back
to you
> > next
> > > week on the issues/questions you've raised.
> > >
> > > Have a nice weekend.
> > >
> > > Thanks,
> > > John
> > >
> > > On Thu, May 23, 2019 at 3:42 PM Jeff Duda via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
>
> > > >
> > > > I'll further add that I have been working on this UH track
> climatology
> > > > issue for a few years now. The problem I consistently run into
is
> > dealing
> > > > with UH tracks from separate storms that cross each other
because
> they
> > > > occur in the same spatial locations but at different moments
in
> time. I
> > > was
> > > > hoping that MODE-TD could do here what regular MODE can't by
allowing
> > > those
> > > > additional UH tracks that would otherwise cross a previous one
to not
> > do
> > > so
> > > > in space-time since the tracks would be located at different
time
> index
> > > > values. Ideally I'd like to explore UH tracks of longer than 1
hour.
> I
> > > had
> > > > initially chosen to use the pcp_combine utility to combine
> > model-derived
> > > > 1-hour UH tracks by summing them into 3- or 6- (or whatever
length
> you
> > > > want)-hour tracks. While that works in principle, it
exacerbates the
> > > issue
> > > > of crossing UH tracks. So I'm going back to using 1-hour
output
> tracks
> > > and
> > > > inserting them into MODE-TD. Also, even though the
functionality to
> > > insert
> > > > a 6th percentile value into the output from MODE is what I'm
looking
> > for,
> > > > the MODE tool itself is not designed to handle this other
issue. So,
> > > coming
> > > > full circle, that's where I was hoping MODE-TD could come in
and save
> > the
> > > > day, both with the ability to better control convolution
filtering
> and
> > > with
> > > > the ability to control percentile output.
> > > >
> > > > Jeff
> > > >
> > > > On Thu, May 23, 2019 at 3:22 PM Jeff Duda
<jeffduda319 at gmail.com>
> > wrote:
> > > >
> > > > > Well I am trying to use MODE-TD to compute a UH track
climatology
> > from
> > > > the
> > > > > HRRR model. So I want to pull maximum or near-maximum UH
magnitudes
> > > from
> > > > > each track. So it would be great to be able to get the 95th
or 99th
> > > > > percentile UH magnitude from each object, for example.
> > > > >
> > > > > I tried adding the same parameter that exists in MODE,
> > > inten_perc_value,
> > > > > to the MTD config file but I'm getting mixed results.
Sometimes MTD
> > > > crashes
> > > > > citing a config file syntax error  and sometimes it runs
> > successfully,
> > > > but
> > > > > when it does I do not see the added percentile INTENSITY
value
> added
> > to
> > > > the
> > > > > text output anywhere.
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Jeff,
> > > > >>
> > > > >> As of met-8.1, the conv_radius setting defines the spatial
> smoothing
> > > > >> radius
> > > > >> of influence.  The smoothing in time is currently hard
coded as
> +/-
> > 1
> > > > time
> > > > >> step.  That means that the smoothing of data for time t is
> > influenced
> > > by
> > > > >> times t-1 and t+1.  I agree that the amount of temporal
smoothing
> > > should
> > > > >> be
> > > > >> configurable.  In fact, here's an existing GitHub issue
describing
> > > this
> > > > >> feature request:
> > > > >>    https://github.com/NCAR/MET/issues/1084
> > > > >>
> > > > >> As for the intensity percentiles in MTD, it is limited to
the 5
> > > > >> pre-defined
> > > > >> ones.
> > > > >> By comparison, one of the inputs to the fuzzy logic engine
is the
> a
> > > > ratio
> > > > >> of the object intensities.  The user can select what
intensity
> > > > percentile
> > > > >> is used in that ratio computation.  And whatever percentile
they
> > > choose
> > > > is
> > > > >> included as a 6th intensity percentile value.
> > > > >>
> > > > >> What sort of flexibility are you looking for in extracting
> intensity
> > > > >> percentile values?  How would it ideally work in your mind?
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT <
> > met_help at ucar.edu>
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > > >> >
> > > > >> > Is there a way to extract an intensity percentile value
other
> than
> > > > the 5
> > > > >> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors
when
> trying
> > > to
> > > > >> add
> > > > >> > "inten_perc_value" to the config file.
> > > > >> >
> > > > >> > Also, how does convolving in time work? It is not
described in
> the
> > > > >> user's
> > > > >> > manual. If I set conv_radius = 2.0, does that mean the
> convolution
> > > > >> window
> > > > >> > is a 5 x 5 grid box window in space and a 5 time-slice
window?
> If
> > I
> > > > have
> > > > >> > that right, can you change future versions of MTD so that
you
> can
> > > use
> > > > >> > different convolution radii for the time dimension and
spatial
> > > > >> dimensions?
> > > > >> > I don't want to smooth my data in time much, but
definitely in
> > > space.
> > > > I
> > > > >> > feel a lot of users will want that.
> > > > >> >
> > > > >> > Jeff
> > > > >> >
> > > > >> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via RT
<
> > > > >> > met_help at ucar.edu>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Jeff,
> > > > >> > >
> > > > >> > > Good point.  In general, the MET tools do not print
warnings
> for
> > > > items
> > > > >> > that
> > > > >> > > don't appear in the default configuration file.  That
is by
> > design
> > > > >> since
> > > > >> > it
> > > > >> > > gives the user more flexibility.  For example, you
might
> define:
> > > > >> > >
> > > > >> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
> > > > >> > > *wind_levels = [ "P500", "P850", "Z10" ];*
> > > > >> > >
> > > > >> > > And then refer to them later...
> > > > >> > >
> > > > >> > > *fcst = {*
> > > > >> > > *  field = [*
> > > > >> > > *      { name = "TMP"; level=tmp_levels; },*
> > > > >> > > *      { name = "UGRD"; level=wind_levels; },*
> > > > >> > > *      { name = "VGRD"; level=wind_levels; },*
> > > > >> > > *      { name = "WIND"; level=wind_levels; }*
> > > > >> > > *   ];*
> > > > >> > > *}*
> > > > >> > >
> > > > >> > > And we wouldn't want to print a warning or error about
> > tmp_levels
> > > or
> > > > >> > > wind_levels not appearing in the default config file.
There
> may
> > > be
> > > > >> some
> > > > >> > > more complex logic to check for situations which are or
are
> not
> > > > >> > acceptable,
> > > > >> > > but that hasn't risen to the top of the development
> priorities.
> > > In
> > > > >> > > general, we advise that users make a copy of the
default
> config
> > > file
> > > > >> for
> > > > >> > > the current version they're running and then edit it
from
> there.
> > > > But
> > > > >> I
> > > > >> > > know plenty of DTC folks who don't do that.
> > > > >> > >
> > > > >> > > Lots of details to consider!
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > John
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT <
> > > > met_help at ucar.edu>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > >
> > > > >> > > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > >
> > > > >> > > >
> > > > >> > > > Okay, seems sensible. Just want to add that MTD is
not
> > throwing
> > > > any
> > > > >> > > errors
> > > > >> > > > or warning messages when I use that code in the
config file.
> > > > Perhaps
> > > > >> > > such a
> > > > >> > > > message could be added.
> > > > >> > > >
> > > > >> > > > Jeff
> > > > >> > > >
> > > > >> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway
via RT <
> > > > >> > > > met_help at ucar.edu> wrote:
> > > > >> > > >
> > > > >> > > > > Jeff,
> > > > >> > > > >
> > > > >> > > > > There is no "mask" option supported in MODE Time
Domain.
> > > Here's
> > > > >> the
> > > > >> > > > > default MTD config file:
> > > > >> > > > > *
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > >> > > > > <
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > >> > > > > >*
> > > > >> > > > >
> > > > >> > > > > I realize that mask is supported in MODE but it's
not in
> > MTD.
> > > > >> There
> > > > >> > > are
> > > > >> > > > > several options that fall into this category.
> > > > >> > > > >
> > > > >> > > > > And there is an underlying issue behind it.  In
order to
> > make
> > > > the
> > > > >> > > > > convolution step in time and space as quick as
possible,
> the
> > > > code
> > > > >> > > assumes
> > > > >> > > > > that there are no missing data values present.
Checking
> for
> > > and
> > > > >> > > dealing
> > > > >> > > > > with missing data is time consuming.  But that's
really
> what
> > > > >> masking
> > > > >> > > > > means... setting the values at some of the grid
points to
> > > > missing
> > > > >> > data.
> > > > >> > > > >
> > > > >> > > > > So MTD should probably be enhanced to deal with
missing
> data
> > > > which
> > > > >> > > would
> > > > >> > > > > make supporting masking regions pretty easy.  The
trick is
> > how
> > > > to
> > > > >> > keep
> > > > >> > > > the
> > > > >> > > > > processing as fast as possible.
> > > > >> > > > >
> > > > >> > > > > I believe that Randy is out of the office this
week, but
> can
> > > > >> > hopefully
> > > > >> > > > > respond to these issues/discussion next week.
> > > > >> > > > >
> > > > >> > > > > Thanks,
> > > > >> > > > > John
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT <
> > > > >> met_help at ucar.edu>
> > > > >> > > > > wrote:
> > > > >> > > > >
> > > > >> > > > > >
> > > > >> > > > > > <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > > >
> > > > >> > > > > >
> > > > >> > > > > > It also appears MODE-TD is ignoring my masking
entry in
> > the
> > > > >> config
> > > > >> > > > file:
> > > > >> > > > > >
> > > > >> > > > > > mask = {
> > > > >> > > > > >    grid      = "";
> > > > >> > > > > >    grid_flag = NONE; // Apply to NONE, FCST, OBS,
or
> BOTH
> > > > >> > > > > >    poly      = "${METBASE}/CONUS_east_of_
> rockies_mask.nc
> > ";
> > > > >> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST, OBS,
or
> BOTH
> > > > >> > > > > > }
> > > > >> > > > > >
> > > > >> > > > > > The outputs appear to cover the entire input
domain,
> which
> > > is
> > > > >> not
> > > > >> > > what
> > > > >> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
> > > > >> > > > > >
> > > > >> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <
> > > > >> jeffduda319 at gmail.com>
> > > > >> > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Well I need to add some other potential bugs
with
> > MODE-TD
> > > > >> output.
> > > > >> > > > Some
> > > > >> > > > > > > columns appear to be all zeros when I don't
think they
> > > > should:
> > > > >> > > > > > >
> > > > >> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > > >> > > > > > > 3d_single_simple: CDIST_TRAVELED
> > > > >> > > > > > >
> > > > >> > > > > > > Jeff
> > > > >> > > > > > >
> > > > >> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley
Gotway
> via
> > > RT <
> > > > >> > > > > > > met_help at ucar.edu> wrote:
> > > > >> > > > > > >
> > > > >> > > > > > >> Hi Jeff and Randy,
> > > > >> > > > > > >>
> > > > >> > > > > > >> I took a look at the data you sent, and I
suspect
> > you've
> > > > >> > > uncovered a
> > > > >> > > > > bug
> > > > >> > > > > > >> in
> > > > >> > > > > > >> the output of MTD.  As you've described...
> > > > >> > > > > > >> (1) Lines 2 - 521 contain information about 2D
slices
> > of
> > > > the
> > > > >> > > simple
> > > > >> > > > > > >> forecast objects.
> > > > >> > > > > > >> (2) Lines 522 - 796 contain information about
2D
> slices
> > > of
> > > > >> the
> > > > >> > > > simple
> > > > >> > > > > > >> observation objects.
> > > > >> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain
information
> about
> > 2D
> > > > >> slices
> > > > >> > > of
> > > > >> > > > > the
> > > > >> > > > > > >> *CLUSTER* forecast objects.
> > > > >> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain
information
> about
> > 2D
> > > > >> slices
> > > > >> > > of
> > > > >> > > > > the
> > > > >> > > > > > >> *CLUSTER* forecast objects.
> > > > >> > > > > > >>
> > > > >> > > > > > >> The problem in (3) and (4) is that the
OBJECT_ID
> column
> > > > >> should
> > > > >> > > begin
> > > > >> > > > > > with
> > > > >> > > > > > >> a
> > > > >> > > > > > >> "C" to indicate that the info is for a cluster
> object.
> > > > >> > > > > > >>
> > > > >> > > > > > >> Looks like this bug is present in the output
of
> > met-8.0,
> > > > >> > met-8.1,
> > > > >> > > > and
> > > > >> > > > > > the
> > > > >> > > > > > >> current development version.
> > > > >> > > > > > >>
> > > > >> > > > > > >> Randy, please take a look and confirm that
this is
> the
> > > > case.
> > > > >> > >  It'd
> > > > >> > > > > > >> probably be wise to carefully review the
contents of
> > the
> > > > >> > OBJECT_ID
> > > > >> > > > and
> > > > >> > > > > > >> OBJECT_CAT columns across all the MTD output
files.
> If
> > > > >> > confirmed,
> > > > >> > > > > we'll
> > > > >> > > > > > >> need a bugfix for this... and this will be our
first
> > one
> > > > >> after
> > > > >> > > > > > >> transitioning to GitHub.
> > > > >> > > > > > >>
> > > > >> > > > > > >> Thanks,
> > > > >> > > > > > >> John
> > > > >> > > > > > >>
> > > > >> > > > > > >>
> > > > >> > > > > > >>
> > > > >> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David
Fillmore via
> RT
> > <
> > > > >> > > > > > met_help at ucar.edu
> > > > >> > > > > > >> >
> > > > >> > > > > > >> wrote:
> > > > >> > > > > > >>
> > > > >> > > > > > >> >
> > > > >> > > > > > >> > <URL:
> > > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > > >> > >
> > > > >> > > > > > >> >
> > > > >> > > > > > >> > Hi Jeff -
> > > > >> > > > > > >> > I've passed this question on to Randy
Bullock who
> > works
> > > > on
> > > > >> the
> > > > >> > > > MODE
> > > > >> > > > > > and
> > > > >> > > > > > >> > the MODE-TD tools.
> > > > >> > > > > > >> > I think he is out today and Monday, but
should
> have a
> > > > >> chance
> > > > >> > to
> > > > >> > > > > follow
> > > > >> > > > > > >> up
> > > > >> > > > > > >> > early next week.
> > > > >> > > > > > >> > thanks,
> > > > >> > > > > > >> > David
> > > > >> > > > > > >> >
> > > > >> > > > > > >>
> > > > >> > > > > > >>
> > > > >> > > > > > >
> > > > >> > > > > > > --
> > > > >> > > > > > > Jeff Duda, Research Scientist
> > > > >> > > > > > > University of Colorado Boulder
> > > > >> > > > > > > Cooperative Institute for Research in
Environmental
> > > Sciences
> > > > >> > > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > >> > > > > > > Boulder, CO
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > --
> > > > >> > > > > > Jeff Duda, Research Scientist
> > > > >> > > > > > University of Colorado Boulder
> > > > >> > > > > > Cooperative Institute for Research in
Environmental
> > Sciences
> > > > >> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > >> > > > > > Boulder, CO
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > --
> > > > >> > > > Jeff Duda, Research Scientist
> > > > >> > > > University of Colorado Boulder
> > > > >> > > > Cooperative Institute for Research in Environmental
Sciences
> > > > >> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > >> > > > Boulder, CO
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> > --
> > > > >> > Jeff Duda, Research Scientist
> > > > >> > University of Colorado Boulder
> > > > >> > Cooperative Institute for Research in Environmental
Sciences
> > > > >> > NOAA/OAR/ESRL/Global Systems Division
> > > > >> > Boulder, CO
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > Jeff Duda, Research Scientist
> > > > > University of Colorado Boulder
> > > > > Cooperative Institute for Research in Environmental Sciences
> > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > Boulder, CO
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeff Duda, Research Scientist
> > > > University of Colorado Boulder
> > > > Cooperative Institute for Research in Environmental Sciences
> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > Boulder, CO
> > > >
> > > >
> > >
> > >
> >
> > --
> > Jeff Duda, Research Scientist
> > University of Colorado Boulder
> > Cooperative Institute for Research in Environmental Sciences
> > NOAA/OAR/ESRL/Global Systems Division
> > Boulder, CO
> >
> >
>
>

--
Jeff Duda, Research Scientist
University of Colorado Boulder
Cooperative Institute for Research in Environmental Sciences
NOAA/OAR/ESRL/Global Systems Division
Boulder, CO

------------------------------------------------
Subject: understanding text output from mode-td
From: Randy Bullock
Time: Tue Jun 25 14:56:40 2019

Hi Jeff -

Some of the issues you pointed out, like the composite object numbers
being
wrong, are slated for the next MET bugfix release (8.1.1) in a week or
two
(hopefully).  The other things will have to wait until the next
general
release near the end of the year.

Randy

On Tue, Jun 25, 2019 at 9:08 AM Jeff Duda via RT <met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
>
> Do you have an approximate time table for when this next release
featuring
> these changes may happen?
>
> Jeff
>
> On Tue, Jun 4, 2019 at 3:00 PM Randy Bullock via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Jeff -
> >
> > The issue with the letter 'C' not appearing in the text output
where it
> > should in MTD has been fixed and will be available in the next
bugfix
> > release of MET (ie, soon).
> >
> > I've made tickets for your other MTD enhancement requests, and
hopefully
> > they will be available in the next release.
> >
> > Randy
> >
> >
> >
> > On Mon, Jun 3, 2019 at 2:15 PM Jeff Duda via RT
<met_help at ucar.edu>
> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > >
> > > If possible, if the MET folks could just point me to the code
where a
> > > custom intensity percentile value could be added to MODE-TD and
I could
> > > just recompile it myself on Jet, that might work for a temporary
> solution
> > > while I wait for a more major update.
> > >
> > > Jeff
> > >
> > > On Fri, May 24, 2019 at 10:38 AM John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jeff,
> > > >
> > > > I asked Randy to read through this message history and get
back to
> you
> > > next
> > > > week on the issues/questions you've raised.
> > > >
> > > > Have a nice weekend.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Thu, May 23, 2019 at 3:42 PM Jeff Duda via RT
<met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244 >
> > > > >
> > > > > I'll further add that I have been working on this UH track
> > climatology
> > > > > issue for a few years now. The problem I consistently run
into is
> > > dealing
> > > > > with UH tracks from separate storms that cross each other
because
> > they
> > > > > occur in the same spatial locations but at different moments
in
> > time. I
> > > > was
> > > > > hoping that MODE-TD could do here what regular MODE can't by
> allowing
> > > > those
> > > > > additional UH tracks that would otherwise cross a previous
one to
> not
> > > do
> > > > so
> > > > > in space-time since the tracks would be located at different
time
> > index
> > > > > values. Ideally I'd like to explore UH tracks of longer than
1
> hour.
> > I
> > > > had
> > > > > initially chosen to use the pcp_combine utility to combine
> > > model-derived
> > > > > 1-hour UH tracks by summing them into 3- or 6- (or whatever
length
> > you
> > > > > want)-hour tracks. While that works in principle, it
exacerbates
> the
> > > > issue
> > > > > of crossing UH tracks. So I'm going back to using 1-hour
output
> > tracks
> > > > and
> > > > > inserting them into MODE-TD. Also, even though the
functionality to
> > > > insert
> > > > > a 6th percentile value into the output from MODE is what I'm
> looking
> > > for,
> > > > > the MODE tool itself is not designed to handle this other
issue.
> So,
> > > > coming
> > > > > full circle, that's where I was hoping MODE-TD could come in
and
> save
> > > the
> > > > > day, both with the ability to better control convolution
filtering
> > and
> > > > with
> > > > > the ability to control percentile output.
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Thu, May 23, 2019 at 3:22 PM Jeff Duda
<jeffduda319 at gmail.com>
> > > wrote:
> > > > >
> > > > > > Well I am trying to use MODE-TD to compute a UH track
climatology
> > > from
> > > > > the
> > > > > > HRRR model. So I want to pull maximum or near-maximum UH
> magnitudes
> > > > from
> > > > > > each track. So it would be great to be able to get the
95th or
> 99th
> > > > > > percentile UH magnitude from each object, for example.
> > > > > >
> > > > > > I tried adding the same parameter that exists in MODE,
> > > > inten_perc_value,
> > > > > > to the MTD config file but I'm getting mixed results.
Sometimes
> MTD
> > > > > crashes
> > > > > > citing a config file syntax error  and sometimes it runs
> > > successfully,
> > > > > but
> > > > > > when it does I do not see the added percentile INTENSITY
value
> > added
> > > to
> > > > > the
> > > > > > text output anywhere.
> > > > > >
> > > > > > Jeff
> > > > > >
> > > > > > On Thu, May 23, 2019 at 1:28 PM John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > >> Jeff,
> > > > > >>
> > > > > >> As of met-8.1, the conv_radius setting defines the
spatial
> > smoothing
> > > > > >> radius
> > > > > >> of influence.  The smoothing in time is currently hard
coded as
> > +/-
> > > 1
> > > > > time
> > > > > >> step.  That means that the smoothing of data for time t
is
> > > influenced
> > > > by
> > > > > >> times t-1 and t+1.  I agree that the amount of temporal
> smoothing
> > > > should
> > > > > >> be
> > > > > >> configurable.  In fact, here's an existing GitHub issue
> describing
> > > > this
> > > > > >> feature request:
> > > > > >>    https://github.com/NCAR/MET/issues/1084
> > > > > >>
> > > > > >> As for the intensity percentiles in MTD, it is limited to
the 5
> > > > > >> pre-defined
> > > > > >> ones.
> > > > > >> By comparison, one of the inputs to the fuzzy logic
engine is
> the
> > a
> > > > > ratio
> > > > > >> of the object intensities.  The user can select what
intensity
> > > > > percentile
> > > > > >> is used in that ratio computation.  And whatever
percentile they
> > > > choose
> > > > > is
> > > > > >> included as a 6th intensity percentile value.
> > > > > >>
> > > > > >> What sort of flexibility are you looking for in
extracting
> > intensity
> > > > > >> percentile values?  How would it ideally work in your
mind?
> > > > > >>
> > > > > >> Thanks,
> > > > > >> John
> > > > > >>
> > > > > >> On Thu, May 23, 2019 at 12:27 PM Jeff Duda via RT <
> > > met_help at ucar.edu>
> > > > > >> wrote:
> > > > > >>
> > > > > >> >
> > > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> >
> > > > > >> >
> > > > > >> > Is there a way to extract an intensity percentile value
other
> > than
> > > > > the 5
> > > > > >> > defaults (10, 25, 50, 75, 90) in MODE-TD? I get errors
when
> > trying
> > > > to
> > > > > >> add
> > > > > >> > "inten_perc_value" to the config file.
> > > > > >> >
> > > > > >> > Also, how does convolving in time work? It is not
described in
> > the
> > > > > >> user's
> > > > > >> > manual. If I set conv_radius = 2.0, does that mean the
> > convolution
> > > > > >> window
> > > > > >> > is a 5 x 5 grid box window in space and a 5 time-slice
window?
> > If
> > > I
> > > > > have
> > > > > >> > that right, can you change future versions of MTD so
that you
> > can
> > > > use
> > > > > >> > different convolution radii for the time dimension and
spatial
> > > > > >> dimensions?
> > > > > >> > I don't want to smooth my data in time much, but
definitely in
> > > > space.
> > > > > I
> > > > > >> > feel a lot of users will want that.
> > > > > >> >
> > > > > >> > Jeff
> > > > > >> >
> > > > > >> > On Wed, May 22, 2019 at 3:24 PM John Halley Gotway via
RT <
> > > > > >> > met_help at ucar.edu>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Jeff,
> > > > > >> > >
> > > > > >> > > Good point.  In general, the MET tools do not print
warnings
> > for
> > > > > items
> > > > > >> > that
> > > > > >> > > don't appear in the default configuration file.  That
is by
> > > design
> > > > > >> since
> > > > > >> > it
> > > > > >> > > gives the user more flexibility.  For example, you
might
> > define:
> > > > > >> > >
> > > > > >> > > *tmp_levels = [ "P500", "P800", "Z2" ];*
> > > > > >> > > *wind_levels = [ "P500", "P850", "Z10" ];*
> > > > > >> > >
> > > > > >> > > And then refer to them later...
> > > > > >> > >
> > > > > >> > > *fcst = {*
> > > > > >> > > *  field = [*
> > > > > >> > > *      { name = "TMP"; level=tmp_levels; },*
> > > > > >> > > *      { name = "UGRD"; level=wind_levels; },*
> > > > > >> > > *      { name = "VGRD"; level=wind_levels; },*
> > > > > >> > > *      { name = "WIND"; level=wind_levels; }*
> > > > > >> > > *   ];*
> > > > > >> > > *}*
> > > > > >> > >
> > > > > >> > > And we wouldn't want to print a warning or error
about
> > > tmp_levels
> > > > or
> > > > > >> > > wind_levels not appearing in the default config file.
There
> > may
> > > > be
> > > > > >> some
> > > > > >> > > more complex logic to check for situations which are
or are
> > not
> > > > > >> > acceptable,
> > > > > >> > > but that hasn't risen to the top of the development
> > priorities.
> > > > In
> > > > > >> > > general, we advise that users make a copy of the
default
> > config
> > > > file
> > > > > >> for
> > > > > >> > > the current version they're running and then edit it
from
> > there.
> > > > > But
> > > > > >> I
> > > > > >> > > know plenty of DTC folks who don't do that.
> > > > > >> > >
> > > > > >> > > Lots of details to consider!
> > > > > >> > >
> > > > > >> > > Thanks,
> > > > > >> > > John
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Wed, May 22, 2019 at 12:48 PM Jeff Duda via RT <
> > > > > met_help at ucar.edu>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > >
> > > > > >> > > > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > >
> > > > > >> > > >
> > > > > >> > > > Okay, seems sensible. Just want to add that MTD is
not
> > > throwing
> > > > > any
> > > > > >> > > errors
> > > > > >> > > > or warning messages when I use that code in the
config
> file.
> > > > > Perhaps
> > > > > >> > > such a
> > > > > >> > > > message could be added.
> > > > > >> > > >
> > > > > >> > > > Jeff
> > > > > >> > > >
> > > > > >> > > > On Wed, May 22, 2019 at 12:22 PM John Halley Gotway
via
> RT <
> > > > > >> > > > met_help at ucar.edu> wrote:
> > > > > >> > > >
> > > > > >> > > > > Jeff,
> > > > > >> > > > >
> > > > > >> > > > > There is no "mask" option supported in MODE Time
Domain.
> > > > Here's
> > > > > >> the
> > > > > >> > > > > default MTD config file:
> > > > > >> > > > > *
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > > >> > > > > <
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/master_v8.1/met/data/config/MTDConfig_default
> > > > > >> > > > > >*
> > > > > >> > > > >
> > > > > >> > > > > I realize that mask is supported in MODE but it's
not in
> > > MTD.
> > > > > >> There
> > > > > >> > > are
> > > > > >> > > > > several options that fall into this category.
> > > > > >> > > > >
> > > > > >> > > > > And there is an underlying issue behind it.  In
order to
> > > make
> > > > > the
> > > > > >> > > > > convolution step in time and space as quick as
possible,
> > the
> > > > > code
> > > > > >> > > assumes
> > > > > >> > > > > that there are no missing data values present.
Checking
> > for
> > > > and
> > > > > >> > > dealing
> > > > > >> > > > > with missing data is time consuming.  But that's
really
> > what
> > > > > >> masking
> > > > > >> > > > > means... setting the values at some of the grid
points
> to
> > > > > missing
> > > > > >> > data.
> > > > > >> > > > >
> > > > > >> > > > > So MTD should probably be enhanced to deal with
missing
> > data
> > > > > which
> > > > > >> > > would
> > > > > >> > > > > make supporting masking regions pretty easy.  The
trick
> is
> > > how
> > > > > to
> > > > > >> > keep
> > > > > >> > > > the
> > > > > >> > > > > processing as fast as possible.
> > > > > >> > > > >
> > > > > >> > > > > I believe that Randy is out of the office this
week, but
> > can
> > > > > >> > hopefully
> > > > > >> > > > > respond to these issues/discussion next week.
> > > > > >> > > > >
> > > > > >> > > > > Thanks,
> > > > > >> > > > > John
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > On Tue, May 21, 2019 at 7:11 PM Jeff Duda via RT
<
> > > > > >> met_help at ucar.edu>
> > > > > >> > > > > wrote:
> > > > > >> > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > <URL:
> > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > It also appears MODE-TD is ignoring my masking
entry
> in
> > > the
> > > > > >> config
> > > > > >> > > > file:
> > > > > >> > > > > >
> > > > > >> > > > > > mask = {
> > > > > >> > > > > >    grid      = "";
> > > > > >> > > > > >    grid_flag = NONE; // Apply to NONE, FCST,
OBS, or
> > BOTH
> > > > > >> > > > > >    poly      = "${METBASE}/CONUS_east_of_
> > rockies_mask.nc
> > > ";
> > > > > >> > > > > >    poly_flag = BOTH; // Apply to NONE, FCST,
OBS, or
> > BOTH
> > > > > >> > > > > > }
> > > > > >> > > > > >
> > > > > >> > > > > > The outputs appear to cover the entire input
domain,
> > which
> > > > is
> > > > > >> not
> > > > > >> > > what
> > > > > >> > > > > > "CONUS_east_of_rockies_mask.nc" contains.
> > > > > >> > > > > >
> > > > > >> > > > > > On Tue, May 21, 2019 at 3:13 PM Jeff Duda <
> > > > > >> jeffduda319 at gmail.com>
> > > > > >> > > > wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > Well I need to add some other potential bugs
with
> > > MODE-TD
> > > > > >> output.
> > > > > >> > > > Some
> > > > > >> > > > > > > columns appear to be all zeros when I don't
think
> they
> > > > > should:
> > > > > >> > > > > > >
> > > > > >> > > > > > > 3d_pair_simple: INTERSECTION_VOLUME
> > > > > >> > > > > > > 3d_single_simple: CDIST_TRAVELED
> > > > > >> > > > > > >
> > > > > >> > > > > > > Jeff
> > > > > >> > > > > > >
> > > > > >> > > > > > > On Fri, May 17, 2019 at 12:00 PM John Halley
Gotway
> > via
> > > > RT <
> > > > > >> > > > > > > met_help at ucar.edu> wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > >> Hi Jeff and Randy,
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> I took a look at the data you sent, and I
suspect
> > > you've
> > > > > >> > > uncovered a
> > > > > >> > > > > bug
> > > > > >> > > > > > >> in
> > > > > >> > > > > > >> the output of MTD.  As you've described...
> > > > > >> > > > > > >> (1) Lines 2 - 521 contain information about
2D
> slices
> > > of
> > > > > the
> > > > > >> > > simple
> > > > > >> > > > > > >> forecast objects.
> > > > > >> > > > > > >> (2) Lines 522 - 796 contain information
about 2D
> > slices
> > > > of
> > > > > >> the
> > > > > >> > > > simple
> > > > > >> > > > > > >> observation objects.
> > > > > >> > > > > > >> (3) Lines 797 - 849 *SHOULD* contain
information
> > about
> > > 2D
> > > > > >> slices
> > > > > >> > > of
> > > > > >> > > > > the
> > > > > >> > > > > > >> *CLUSTER* forecast objects.
> > > > > >> > > > > > >> (4) Lines 850 - 896 *SHOULD* contain
information
> > about
> > > 2D
> > > > > >> slices
> > > > > >> > > of
> > > > > >> > > > > the
> > > > > >> > > > > > >> *CLUSTER* forecast objects.
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> The problem in (3) and (4) is that the
OBJECT_ID
> > column
> > > > > >> should
> > > > > >> > > begin
> > > > > >> > > > > > with
> > > > > >> > > > > > >> a
> > > > > >> > > > > > >> "C" to indicate that the info is for a
cluster
> > object.
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> Looks like this bug is present in the output
of
> > > met-8.0,
> > > > > >> > met-8.1,
> > > > > >> > > > and
> > > > > >> > > > > > the
> > > > > >> > > > > > >> current development version.
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> Randy, please take a look and confirm that
this is
> > the
> > > > > case.
> > > > > >> > >  It'd
> > > > > >> > > > > > >> probably be wise to carefully review the
contents
> of
> > > the
> > > > > >> > OBJECT_ID
> > > > > >> > > > and
> > > > > >> > > > > > >> OBJECT_CAT columns across all the MTD output
files.
> > If
> > > > > >> > confirmed,
> > > > > >> > > > > we'll
> > > > > >> > > > > > >> need a bugfix for this... and this will be
our
> first
> > > one
> > > > > >> after
> > > > > >> > > > > > >> transitioning to GitHub.
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> Thanks,
> > > > > >> > > > > > >> John
> > > > > >> > > > > > >>
> > > > > >> > > > > > >>
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> On Fri, May 17, 2019 at 10:57 AM David
Fillmore via
> > RT
> > > <
> > > > > >> > > > > > met_help at ucar.edu
> > > > > >> > > > > > >> >
> > > > > >> > > > > > >> wrote:
> > > > > >> > > > > > >>
> > > > > >> > > > > > >> >
> > > > > >> > > > > > >> > <URL:
> > > > > >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90244
> > > > > >> > >
> > > > > >> > > > > > >> >
> > > > > >> > > > > > >> > Hi Jeff -
> > > > > >> > > > > > >> > I've passed this question on to Randy
Bullock who
> > > works
> > > > > on
> > > > > >> the
> > > > > >> > > > MODE
> > > > > >> > > > > > and
> > > > > >> > > > > > >> > the MODE-TD tools.
> > > > > >> > > > > > >> > I think he is out today and Monday, but
should
> > have a
> > > > > >> chance
> > > > > >> > to
> > > > > >> > > > > follow
> > > > > >> > > > > > >> up
> > > > > >> > > > > > >> > early next week.
> > > > > >> > > > > > >> > thanks,
> > > > > >> > > > > > >> > David
> > > > > >> > > > > > >> >
> > > > > >> > > > > > >>
> > > > > >> > > > > > >>
> > > > > >> > > > > > >
> > > > > >> > > > > > > --
> > > > > >> > > > > > > Jeff Duda, Research Scientist
> > > > > >> > > > > > > University of Colorado Boulder
> > > > > >> > > > > > > Cooperative Institute for Research in
Environmental
> > > > Sciences
> > > > > >> > > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > >> > > > > > > Boulder, CO
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > --
> > > > > >> > > > > > Jeff Duda, Research Scientist
> > > > > >> > > > > > University of Colorado Boulder
> > > > > >> > > > > > Cooperative Institute for Research in
Environmental
> > > Sciences
> > > > > >> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > >> > > > > > Boulder, CO
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > > --
> > > > > >> > > > Jeff Duda, Research Scientist
> > > > > >> > > > University of Colorado Boulder
> > > > > >> > > > Cooperative Institute for Research in Environmental
> Sciences
> > > > > >> > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > >> > > > Boulder, CO
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Jeff Duda, Research Scientist
> > > > > >> > University of Colorado Boulder
> > > > > >> > Cooperative Institute for Research in Environmental
Sciences
> > > > > >> > NOAA/OAR/ESRL/Global Systems Division
> > > > > >> > Boulder, CO
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Jeff Duda, Research Scientist
> > > > > > University of Colorado Boulder
> > > > > > Cooperative Institute for Research in Environmental
Sciences
> > > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > > Boulder, CO
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jeff Duda, Research Scientist
> > > > > University of Colorado Boulder
> > > > > Cooperative Institute for Research in Environmental Sciences
> > > > > NOAA/OAR/ESRL/Global Systems Division
> > > > > Boulder, CO
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Jeff Duda, Research Scientist
> > > University of Colorado Boulder
> > > Cooperative Institute for Research in Environmental Sciences
> > > NOAA/OAR/ESRL/Global Systems Division
> > > Boulder, CO
> > >
> > >
> >
> >
>
> --
> Jeff Duda, Research Scientist
> University of Colorado Boulder
> Cooperative Institute for Research in Environmental Sciences
> NOAA/OAR/ESRL/Global Systems Division
> Boulder, CO
>
>

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