[Met_help] [rt.rap.ucar.edu #74039] History for Way to loop TC_pairs

John Halley Gotway via RT met_help at ucar.edu
Fri Nov 13 10:19:53 MST 2015


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

Hello,
I am a PhD student now working with MET v5.0 for TC verification.  I am
using the a-decks and b-decks archived under
ftp://ftp.nhc.noaa.gov/atcf/archive/
from 2007-2014 for storms over the North Atlantic.  Specifically, I am
analyzing the mean/spread in model error for individual storms over
different lead times, with the aim of objectively ranking which storms were
most problematic across recent history.

My question is whether  there is a function in MET or a separate code that
allows one to iteratively compute the stats across all models for each
individual forecast and initialization time.  For example, I want the
mean/spread in errors of several models computed for day 1/forecast hour
00, then separately for day 1/fhour 72, then day 2/fhour 48, etc.  It seems
that MET as is computes the stats over all times/models combined;
essentially lumping everything so you only get one mean/spread value.  This
would otherwise require me to manually change the configure files and
run met many times.

Also, I noticed that it's not reading the GFS tracks for some reason.  They
are definitely there in the a-decks I've looked at (eg. in aal012007) with
the title "AVNO" and I correctly specified them to be included within the
TC Pairs configure file.  In the end, they're simply not printed out (while
HWRF, GFDL, and others are computed just fine) and no errors are returned
to suggest why.
Thank you.
-Nick


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

Subject: Way to loop TC_pairs
From: John Halley Gotway
Time: Mon Nov 09 12:09:11 2015

Nick,

It sounds like you've been able to get the tc_pairs tool up and
running,
and that's great!

Let me address your second question first.  I believe there's a bit of
trickery here that causing the confusion, and it looks like we failed
to
document it the MET users's guide!  The GFS track data is a special
case,
and NHC instructed us to add the following functionality - when
reading
ATCF track data, the tc_pairs tool automatically replaces any
instances of
"AVN" with "GFS".  When you see "AVNO" in your input ATCF files,
you'll
need to refer to that in the MET config files as "GFSO".  Likewise,
for
AVNI use GFSI.  AVN is a legacy name from a long time ago that still
shows
up in track data files, but NHC wanted us to rename it to GFS.

I'll take a look at the documentation and look to see where we should
add
that detail.

To answer your first question, I think you'll find using the "-by
case"
option in tc_stat to be very helpful.  I've attached a sample output
file
from tc_pairs to this message.

Try running this job on the attached file:
   tc_stat -lookin alal2010.tcst -job summary -column TK_ERR

That reads all the track data and computes summary info for the TK_ERR
column using all the input data (1814 track lines).  It combining
results
across many models, storms, and lead times.

But now amend that job like this and rerun:
   tc_stat -lookin alal2010.tcst -job summary -column TK_ERR -by
AMODEL,LEAD

That'll run the same job, but do so separately for each unique
combination
of the values found in the AMODEL and LEAD columns.  Note that using
"-by
AMODEL,LEAD" is the same as "-by AMODEL -by LEAD".  Instead of getting
1
output line from tc_stat, you should get 123.

You're welcome to define that case information using whatever columns
of
data you'd like.  You can also "fix" some input columns to control the
type
of output you get.  For example, try this job:

   tc_stat -lookin alal2010.tcst -job summary -column
TK_ERR,AMAX_WIND-BMAX_WIND -by AMODEL,LEAD -amodel HWFI,GFSI -lead
24,48

Perhaps you're interested in track error and intensity differences for
the
24 and 48 hour lead times for the HWFI and GFSI models.  The job
listed
above should result in 8 output lines.

Hopefully that feature will enable you to slice and dice the data in
the
way you'd like.  Please let us know if any more issues or questions
arise
in your use of MET.

Thanks,
John Halley Gotway
met_help at ucar.edu


On Sun, Nov 8, 2015 at 6:57 PM, Nicholas Leonardo via RT
<met_help at ucar.edu>
wrote:

>
> Sun Nov 08 18:57:30 2015: Request 74039 was acted upon.
> Transaction: Ticket created by nicholas.leonardo at stonybrook.edu
>        Queue: met_help
>      Subject: Way to loop TC_pairs
>        Owner: Nobody
>   Requestors: nicholas.leonardo at stonybrook.edu
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
>
>
> Hello,
> I am a PhD student now working with MET v5.0 for TC verification.  I
am
> using the a-decks and b-decks archived under
> ftp://ftp.nhc.noaa.gov/atcf/archive/
> from 2007-2014 for storms over the North Atlantic.  Specifically, I
am
> analyzing the mean/spread in model error for individual storms over
> different lead times, with the aim of objectively ranking which
storms were
> most problematic across recent history.
>
> My question is whether  there is a function in MET or a separate
code that
> allows one to iteratively compute the stats across all models for
each
> individual forecast and initialization time.  For example, I want
the
> mean/spread in errors of several models computed for day 1/forecast
hour
> 00, then separately for day 1/fhour 72, then day 2/fhour 48, etc.
It seems
> that MET as is computes the stats over all times/models combined;
> essentially lumping everything so you only get one mean/spread
value.  This
> would otherwise require me to manually change the configure files
and
> run met many times.
>
> Also, I noticed that it's not reading the GFS tracks for some
reason.  They
> are definitely there in the a-decks I've looked at (eg. in
aal012007) with
> the title "AVNO" and I correctly specified them to be included
within the
> TC Pairs configure file.  In the end, they're simply not printed out
(while
> HWRF, GFDL, and others are computed just fine) and no errors are
returned
> to suggest why.
> Thank you.
> -Nick
>
>

------------------------------------------------
Subject: Way to loop TC_pairs
From: Nicholas Leonardo
Time: Wed Nov 11 15:16:19 2015

Thank you, it all worked just fine.  My only question now is regarding
the
GEFS perturbations.  In the -amodels option of the configure file, I
manually list all 20 of them to be verified (each as APXX, which are
listed
as such in the a-deck), and when I run it, the list has the 20
members,
but also two I am not sure of; named "AP0I" and "AP1I".  I thought
that
these might be the interpolated versions of GEFS, but if so, of which
members (the control/mean)?   Curiously, these are not listed as such
anywhere in the a-deck file.  As of now, I would only like to include
the
late models, such that I would like to exclude these two if possible.
Thank you again.
-Nick

On Mon, Nov 9, 2015 at 2:09 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:

> Nick,
>
> It sounds like you've been able to get the tc_pairs tool up and
running,
> and that's great!
>
> Let me address your second question first.  I believe there's a bit
of
> trickery here that causing the confusion, and it looks like we
failed to
> document it the MET users's guide!  The GFS track data is a special
case,
> and NHC instructed us to add the following functionality - when
reading
> ATCF track data, the tc_pairs tool automatically replaces any
instances of
> "AVN" with "GFS".  When you see "AVNO" in your input ATCF files,
you'll
> need to refer to that in the MET config files as "GFSO".  Likewise,
for
> AVNI use GFSI.  AVN is a legacy name from a long time ago that still
shows
> up in track data files, but NHC wanted us to rename it to GFS.
>
> I'll take a look at the documentation and look to see where we
should add
> that detail.
>
> To answer your first question, I think you'll find using the "-by
case"
> option in tc_stat to be very helpful.  I've attached a sample output
file
> from tc_pairs to this message.
>
> Try running this job on the attached file:
>    tc_stat -lookin alal2010.tcst -job summary -column TK_ERR
>
> That reads all the track data and computes summary info for the
TK_ERR
> column using all the input data (1814 track lines).  It combining
results
> across many models, storms, and lead times.
>
> But now amend that job like this and rerun:
>    tc_stat -lookin alal2010.tcst -job summary -column TK_ERR -by
> AMODEL,LEAD
>
> That'll run the same job, but do so separately for each unique
combination
> of the values found in the AMODEL and LEAD columns.  Note that using
"-by
> AMODEL,LEAD" is the same as "-by AMODEL -by LEAD".  Instead of
getting 1
> output line from tc_stat, you should get 123.
>
> You're welcome to define that case information using whatever
columns of
> data you'd like.  You can also "fix" some input columns to control
the type
> of output you get.  For example, try this job:
>
>    tc_stat -lookin alal2010.tcst -job summary -column
> TK_ERR,AMAX_WIND-BMAX_WIND -by AMODEL,LEAD -amodel HWFI,GFSI -lead
24,48
>
> Perhaps you're interested in track error and intensity differences
for the
> 24 and 48 hour lead times for the HWFI and GFSI models.  The job
listed
> above should result in 8 output lines.
>
> Hopefully that feature will enable you to slice and dice the data in
the
> way you'd like.  Please let us know if any more issues or questions
arise
> in your use of MET.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
> On Sun, Nov 8, 2015 at 6:57 PM, Nicholas Leonardo via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > Sun Nov 08 18:57:30 2015: Request 74039 was acted upon.
> > Transaction: Ticket created by nicholas.leonardo at stonybrook.edu
> >        Queue: met_help
> >      Subject: Way to loop TC_pairs
> >        Owner: Nobody
> >   Requestors: nicholas.leonardo at stonybrook.edu
> >       Status: new
> >  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
> >
> >
> > Hello,
> > I am a PhD student now working with MET v5.0 for TC verification.
I am
> > using the a-decks and b-decks archived under
> > ftp://ftp.nhc.noaa.gov/atcf/archive/
> > from 2007-2014 for storms over the North Atlantic.  Specifically,
I am
> > analyzing the mean/spread in model error for individual storms
over
> > different lead times, with the aim of objectively ranking which
storms
> were
> > most problematic across recent history.
> >
> > My question is whether  there is a function in MET or a separate
code
> that
> > allows one to iteratively compute the stats across all models for
each
> > individual forecast and initialization time.  For example, I want
the
> > mean/spread in errors of several models computed for day
1/forecast hour
> > 00, then separately for day 1/fhour 72, then day 2/fhour 48, etc.
It
> seems
> > that MET as is computes the stats over all times/models combined;
> > essentially lumping everything so you only get one mean/spread
value.
> This
> > would otherwise require me to manually change the configure files
and
> > run met many times.
> >
> > Also, I noticed that it's not reading the GFS tracks for some
reason.
> They
> > are definitely there in the a-decks I've looked at (eg. in
aal012007)
> with
> > the title "AVNO" and I correctly specified them to be included
within the
> > TC Pairs configure file.  In the end, they're simply not printed
out
> (while
> > HWRF, GFDL, and others are computed just fine) and no errors are
returned
> > to suggest why.
> > Thank you.
> > -Nick
> >
> >
>
>

------------------------------------------------
Subject: Way to loop TC_pairs
From: John Halley Gotway
Time: Wed Nov 11 19:58:31 2015

Nick,

Please take a look in your TCPairsConfig file at the "interp12" entry.
Try
setting that option to NONE and check to see if the "AP0I" and "AP1I"
models a removed from the output.

This is some special processing logic done at NHC to generated
"interpolated" model output.

Please let me know if that resolves the issue.

Thanks,
John

On Wed, Nov 11, 2015 at 3:16 PM, Nicholas Leonardo via RT
<met_help at ucar.edu
> wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
>
> Thank you, it all worked just fine.  My only question now is
regarding the
> GEFS perturbations.  In the -amodels option of the configure file, I
> manually list all 20 of them to be verified (each as APXX, which are
listed
> as such in the a-deck), and when I run it, the list has the 20
members,
> but also two I am not sure of; named "AP0I" and "AP1I".  I thought
that
> these might be the interpolated versions of GEFS, but if so, of
which
> members (the control/mean)?   Curiously, these are not listed as
such
> anywhere in the a-deck file.  As of now, I would only like to
include the
> late models, such that I would like to exclude these two if
possible.
> Thank you again.
> -Nick
>
> On Mon, Nov 9, 2015 at 2:09 PM, John Halley Gotway via RT <
> met_help at ucar.edu
> > wrote:
>
> > Nick,
> >
> > It sounds like you've been able to get the tc_pairs tool up and
running,
> > and that's great!
> >
> > Let me address your second question first.  I believe there's a
bit of
> > trickery here that causing the confusion, and it looks like we
failed to
> > document it the MET users's guide!  The GFS track data is a
special case,
> > and NHC instructed us to add the following functionality - when
reading
> > ATCF track data, the tc_pairs tool automatically replaces any
instances
> of
> > "AVN" with "GFS".  When you see "AVNO" in your input ATCF files,
you'll
> > need to refer to that in the MET config files as "GFSO".
Likewise, for
> > AVNI use GFSI.  AVN is a legacy name from a long time ago that
still
> shows
> > up in track data files, but NHC wanted us to rename it to GFS.
> >
> > I'll take a look at the documentation and look to see where we
should add
> > that detail.
> >
> > To answer your first question, I think you'll find using the "-by
case"
> > option in tc_stat to be very helpful.  I've attached a sample
output file
> > from tc_pairs to this message.
> >
> > Try running this job on the attached file:
> >    tc_stat -lookin alal2010.tcst -job summary -column TK_ERR
> >
> > That reads all the track data and computes summary info for the
TK_ERR
> > column using all the input data (1814 track lines).  It combining
results
> > across many models, storms, and lead times.
> >
> > But now amend that job like this and rerun:
> >    tc_stat -lookin alal2010.tcst -job summary -column TK_ERR -by
> > AMODEL,LEAD
> >
> > That'll run the same job, but do so separately for each unique
> combination
> > of the values found in the AMODEL and LEAD columns.  Note that
using "-by
> > AMODEL,LEAD" is the same as "-by AMODEL -by LEAD".  Instead of
getting 1
> > output line from tc_stat, you should get 123.
> >
> > You're welcome to define that case information using whatever
columns of
> > data you'd like.  You can also "fix" some input columns to control
the
> type
> > of output you get.  For example, try this job:
> >
> >    tc_stat -lookin alal2010.tcst -job summary -column
> > TK_ERR,AMAX_WIND-BMAX_WIND -by AMODEL,LEAD -amodel HWFI,GFSI -lead
24,48
> >
> > Perhaps you're interested in track error and intensity differences
for
> the
> > 24 and 48 hour lead times for the HWFI and GFSI models.  The job
listed
> > above should result in 8 output lines.
> >
> > Hopefully that feature will enable you to slice and dice the data
in the
> > way you'd like.  Please let us know if any more issues or
questions arise
> > in your use of MET.
> >
> > Thanks,
> > John Halley Gotway
> > met_help at ucar.edu
> >
> >
> > On Sun, Nov 8, 2015 at 6:57 PM, Nicholas Leonardo via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > >
> > > Sun Nov 08 18:57:30 2015: Request 74039 was acted upon.
> > > Transaction: Ticket created by nicholas.leonardo at stonybrook.edu
> > >        Queue: met_help
> > >      Subject: Way to loop TC_pairs
> > >        Owner: Nobody
> > >   Requestors: nicholas.leonardo at stonybrook.edu
> > >       Status: new
> > >  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039
> >
> > >
> > >
> > > Hello,
> > > I am a PhD student now working with MET v5.0 for TC
verification.  I am
> > > using the a-decks and b-decks archived under
> > > ftp://ftp.nhc.noaa.gov/atcf/archive/
> > > from 2007-2014 for storms over the North Atlantic.
Specifically, I am
> > > analyzing the mean/spread in model error for individual storms
over
> > > different lead times, with the aim of objectively ranking which
storms
> > were
> > > most problematic across recent history.
> > >
> > > My question is whether  there is a function in MET or a separate
code
> > that
> > > allows one to iteratively compute the stats across all models
for each
> > > individual forecast and initialization time.  For example, I
want the
> > > mean/spread in errors of several models computed for day
1/forecast
> hour
> > > 00, then separately for day 1/fhour 72, then day 2/fhour 48,
etc.  It
> > seems
> > > that MET as is computes the stats over all times/models
combined;
> > > essentially lumping everything so you only get one mean/spread
value.
> > This
> > > would otherwise require me to manually change the configure
files and
> > > run met many times.
> > >
> > > Also, I noticed that it's not reading the GFS tracks for some
reason.
> > They
> > > are definitely there in the a-decks I've looked at (eg. in
aal012007)
> > with
> > > the title "AVNO" and I correctly specified them to be included
within
> the
> > > TC Pairs configure file.  In the end, they're simply not printed
out
> > (while
> > > HWRF, GFDL, and others are computed just fine) and no errors are
> returned
> > > to suggest why.
> > > Thank you.
> > > -Nick
> > >
> > >
> >
> >
>
>

------------------------------------------------
Subject: Way to loop TC_pairs
From: Nicholas Leonardo
Time: Thu Nov 12 09:05:55 2015

Looks like that did the trick and everything's ready to go.  Thank you
so
much.
-Nick

On Wed, Nov 11, 2015 at 9:58 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Nick,
>
> Please take a look in your TCPairsConfig file at the "interp12"
entry.  Try
> setting that option to NONE and check to see if the "AP0I" and
"AP1I"
> models a removed from the output.
>
> This is some special processing logic done at NHC to generated
> "interpolated" model output.
>
> Please let me know if that resolves the issue.
>
> Thanks,
> John
>
> On Wed, Nov 11, 2015 at 3:16 PM, Nicholas Leonardo via RT <
> met_help at ucar.edu
> > wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
> >
> > Thank you, it all worked just fine.  My only question now is
regarding
> the
> > GEFS perturbations.  In the -amodels option of the configure file,
I
> > manually list all 20 of them to be verified (each as APXX, which
are
> listed
> > as such in the a-deck), and when I run it, the list has the 20
members,
> > but also two I am not sure of; named "AP0I" and "AP1I".  I thought
that
> > these might be the interpolated versions of GEFS, but if so, of
which
> > members (the control/mean)?   Curiously, these are not listed as
such
> > anywhere in the a-deck file.  As of now, I would only like to
include the
> > late models, such that I would like to exclude these two if
possible.
> > Thank you again.
> > -Nick
> >
> > On Mon, Nov 9, 2015 at 2:09 PM, John Halley Gotway via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > > Nick,
> > >
> > > It sounds like you've been able to get the tc_pairs tool up and
> running,
> > > and that's great!
> > >
> > > Let me address your second question first.  I believe there's a
bit of
> > > trickery here that causing the confusion, and it looks like we
failed
> to
> > > document it the MET users's guide!  The GFS track data is a
special
> case,
> > > and NHC instructed us to add the following functionality - when
reading
> > > ATCF track data, the tc_pairs tool automatically replaces any
instances
> > of
> > > "AVN" with "GFS".  When you see "AVNO" in your input ATCF files,
you'll
> > > need to refer to that in the MET config files as "GFSO".
Likewise, for
> > > AVNI use GFSI.  AVN is a legacy name from a long time ago that
still
> > shows
> > > up in track data files, but NHC wanted us to rename it to GFS.
> > >
> > > I'll take a look at the documentation and look to see where we
should
> add
> > > that detail.
> > >
> > > To answer your first question, I think you'll find using the "-
by case"
> > > option in tc_stat to be very helpful.  I've attached a sample
output
> file
> > > from tc_pairs to this message.
> > >
> > > Try running this job on the attached file:
> > >    tc_stat -lookin alal2010.tcst -job summary -column TK_ERR
> > >
> > > That reads all the track data and computes summary info for the
TK_ERR
> > > column using all the input data (1814 track lines).  It
combining
> results
> > > across many models, storms, and lead times.
> > >
> > > But now amend that job like this and rerun:
> > >    tc_stat -lookin alal2010.tcst -job summary -column TK_ERR -by
> > > AMODEL,LEAD
> > >
> > > That'll run the same job, but do so separately for each unique
> > combination
> > > of the values found in the AMODEL and LEAD columns.  Note that
using
> "-by
> > > AMODEL,LEAD" is the same as "-by AMODEL -by LEAD".  Instead of
getting
> 1
> > > output line from tc_stat, you should get 123.
> > >
> > > You're welcome to define that case information using whatever
columns
> of
> > > data you'd like.  You can also "fix" some input columns to
control the
> > type
> > > of output you get.  For example, try this job:
> > >
> > >    tc_stat -lookin alal2010.tcst -job summary -column
> > > TK_ERR,AMAX_WIND-BMAX_WIND -by AMODEL,LEAD -amodel HWFI,GFSI
-lead
> 24,48
> > >
> > > Perhaps you're interested in track error and intensity
differences for
> > the
> > > 24 and 48 hour lead times for the HWFI and GFSI models.  The job
listed
> > > above should result in 8 output lines.
> > >
> > > Hopefully that feature will enable you to slice and dice the
data in
> the
> > > way you'd like.  Please let us know if any more issues or
questions
> arise
> > > in your use of MET.
> > >
> > > Thanks,
> > > John Halley Gotway
> > > met_help at ucar.edu
> > >
> > >
> > > On Sun, Nov 8, 2015 at 6:57 PM, Nicholas Leonardo via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > Sun Nov 08 18:57:30 2015: Request 74039 was acted upon.
> > > > Transaction: Ticket created by
nicholas.leonardo at stonybrook.edu
> > > >        Queue: met_help
> > > >      Subject: Way to loop TC_pairs
> > > >        Owner: Nobody
> > > >   Requestors: nicholas.leonardo at stonybrook.edu
> > > >       Status: new
> > > >  Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039
> > >
> > > >
> > > >
> > > > Hello,
> > > > I am a PhD student now working with MET v5.0 for TC
verification.  I
> am
> > > > using the a-decks and b-decks archived under
> > > > ftp://ftp.nhc.noaa.gov/atcf/archive/
> > > > from 2007-2014 for storms over the North Atlantic.
Specifically, I
> am
> > > > analyzing the mean/spread in model error for individual storms
over
> > > > different lead times, with the aim of objectively ranking
which
> storms
> > > were
> > > > most problematic across recent history.
> > > >
> > > > My question is whether  there is a function in MET or a
separate code
> > > that
> > > > allows one to iteratively compute the stats across all models
for
> each
> > > > individual forecast and initialization time.  For example, I
want the
> > > > mean/spread in errors of several models computed for day
1/forecast
> > hour
> > > > 00, then separately for day 1/fhour 72, then day 2/fhour 48,
etc.  It
> > > seems
> > > > that MET as is computes the stats over all times/models
combined;
> > > > essentially lumping everything so you only get one mean/spread
value.
> > > This
> > > > would otherwise require me to manually change the configure
files and
> > > > run met many times.
> > > >
> > > > Also, I noticed that it's not reading the GFS tracks for some
reason.
> > > They
> > > > are definitely there in the a-decks I've looked at (eg. in
aal012007)
> > > with
> > > > the title "AVNO" and I correctly specified them to be included
within
> > the
> > > > TC Pairs configure file.  In the end, they're simply not
printed out
> > > (while
> > > > HWRF, GFDL, and others are computed just fine) and no errors
are
> > returned
> > > > to suggest why.
> > > > Thank you.
> > > > -Nick
> > > >
> > > >
> > >
> > >
> >
> >
>
>

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


More information about the Met_help mailing list