[Met_help] [rt.rap.ucar.edu #74039] History for Way to loop TC_pairs
John Halley Gotway via RT
met_help at ucar.edu
Tue Jan 26 12:11:47 MST 2016
----------------------------------------------------------------
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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Way to loop TC_pairs
From: Nicholas Leonardo
Time: Fri Dec 04 15:40:16 2015
Hello,
I have a new question about reading cxml files into MET_TC. The ECMWF
has
archived TC forecast tracks, but they are in cxml format (which I've
never
dealt with before). Is there a code that can convert cxml files back
into
the required .dat a-decks for MET to read? Thank you.
-Nick
On Thu, Nov 12, 2015 at 11:05 AM, Nicholas Leonardo <
nicholas.leonardo at stonybrook.edu> wrote:
> 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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: Way to loop TC_pairs
From: John Halley Gotway
Time: Fri Dec 04 16:13:01 2015
Nick,
I wasn't aware of any utilities for converting CXML to ATCF format.
In
fact, I wasn't familiar with the CXML format.
However, a quick google search for "cxml to atcf" turned up the
following
PERL script:
ftp://ftp.emc.ncep.noaa.gov/gc_wmb/mcharles/tigge/beta/xml2atcf/v1.2/xml2atcf.pl
Then I pulled a sample ECMWF CXML file from this data source:
ftp://tigge-
ldm.ecmwf.int/cxml/z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
And ran the utility:
chmod +x xml2atcf.pl
./xml2atcf.pl \
z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml \
z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
It extracted data for 159 storms... however the resulting ATCF file
does
not look good. Looks like it contains a lot of garbage.
Perhaps there are other, better supported utilities out there, or you
could
adapt this one to make it do what you need.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Fri, Dec 4, 2015 at 3:40 PM, Nicholas Leonardo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
>
> Hello,
> I have a new question about reading cxml files into MET_TC. The
ECMWF has
> archived TC forecast tracks, but they are in cxml format (which I've
never
> dealt with before). Is there a code that can convert cxml files
back into
> the required .dat a-decks for MET to read? Thank you.
> -Nick
>
> On Thu, Nov 12, 2015 at 11:05 AM, Nicholas Leonardo <
> nicholas.leonardo at stonybrook.edu> wrote:
>
> > 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
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Way to loop TC_pairs
From: Nicholas Leonardo
Time: Mon Dec 21 12:03:13 2015
Hello,
Can you provide me with a sample file of the messy output you got from
the
xml2atcf.pl script? Thank you.
-Nick
On Fri, Dec 4, 2015 at 6:13 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Nick,
>
> I wasn't aware of any utilities for converting CXML to ATCF format.
In
> fact, I wasn't familiar with the CXML format.
>
> However, a quick google search for "cxml to atcf" turned up the
following
> PERL script:
>
>
>
ftp://ftp.emc.ncep.noaa.gov/gc_wmb/mcharles/tigge/beta/xml2atcf/v1.2/xml2atcf.pl
>
> Then I pulled a sample ECMWF CXML file from this data source:
>
>
> ftp://tigge-
ldm.ecmwf.int/cxml/z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
>
> And ran the utility:
>
> chmod +x xml2atcf.pl
> ./xml2atcf.pl \
> z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml \
> z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
>
> It extracted data for 159 storms... however the resulting ATCF file
does
> not look good. Looks like it contains a lot of garbage.
>
> Perhaps there are other, better supported utilities out there, or
you could
> adapt this one to make it do what you need.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On Fri, Dec 4, 2015 at 3:40 PM, Nicholas Leonardo via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
> >
> > Hello,
> > I have a new question about reading cxml files into MET_TC. The
ECMWF
> has
> > archived TC forecast tracks, but they are in cxml format (which
I've
> never
> > dealt with before). Is there a code that can convert cxml files
back
> into
> > the required .dat a-decks for MET to read? Thank you.
> > -Nick
> >
> > On Thu, Nov 12, 2015 at 11:05 AM, Nicholas Leonardo <
> > nicholas.leonardo at stonybrook.edu> wrote:
> >
> > > 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
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: Way to loop TC_pairs
From: John Halley Gotway
Time: Mon Dec 21 12:58:38 2015
Nick,
The data I tried to send was too large for email. Instead, I posted
the
output I get when I run the following command to an anonymous ftp
site.
Command:
perl xml2atcf.pl
z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
FTP Site:
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/for_nick/
Thanks,
John
On Mon, Dec 21, 2015 at 12:54 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Nick,
>
> I've attached the output I get when I run the following command:
> perl xml2atcf.pl
> z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
>
> Hope that helps.
>
> Thanks,
> John
>
>
> On Mon, Dec 21, 2015 at 12:03 PM, Nicholas Leonardo via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
>>
>> Hello,
>> Can you provide me with a sample file of the messy output you got
from the
>> xml2atcf.pl script? Thank you.
>> -Nick
>>
>> On Fri, Dec 4, 2015 at 6:13 PM, John Halley Gotway via RT <
>> met_help at ucar.edu
>> > wrote:
>>
>> > Nick,
>> >
>> > I wasn't aware of any utilities for converting CXML to ATCF
format. In
>> > fact, I wasn't familiar with the CXML format.
>> >
>> > However, a quick google search for "cxml to atcf" turned up the
>> following
>> > PERL script:
>> >
>> >
>> >
>>
ftp://ftp.emc.ncep.noaa.gov/gc_wmb/mcharles/tigge/beta/xml2atcf/v1.2/xml2atcf.pl
>> >
>> > Then I pulled a sample ECMWF CXML file from this data source:
>> >
>> >
>> >
>> ftp://tigge-
ldm.ecmwf.int/cxml/z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
>> >
>> > And ran the utility:
>> >
>> > chmod +x xml2atcf.pl
>> > ./xml2atcf.pl \
>> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml \
>> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
>> >
>> > It extracted data for 159 storms... however the resulting ATCF
file does
>> > not look good. Looks like it contains a lot of garbage.
>> >
>> > Perhaps there are other, better supported utilities out there, or
you
>> could
>> > adapt this one to make it do what you need.
>> >
>> > Thanks,
>> > John Halley Gotway
>> > met_help at ucar.edu
>> >
>> > On Fri, Dec 4, 2015 at 3:40 PM, Nicholas Leonardo via RT <
>> > met_help at ucar.edu>
>> > wrote:
>> >
>> > >
>> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
>> > >
>> > > Hello,
>> > > I have a new question about reading cxml files into MET_TC.
The ECMWF
>> > has
>> > > archived TC forecast tracks, but they are in cxml format (which
I've
>> > never
>> > > dealt with before). Is there a code that can convert cxml
files back
>> > into
>> > > the required .dat a-decks for MET to read? Thank you.
>> > > -Nick
>> > >
>> > > On Thu, Nov 12, 2015 at 11:05 AM, Nicholas Leonardo <
>> > > nicholas.leonardo at stonybrook.edu> wrote:
>> > >
>> > > > 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
>> > > >> > > >
>> > > >> > > >
>> > > >> > >
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >>
>> > > >>
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: Way to loop TC_pairs
From: Nicholas Leonardo
Time: Tue Dec 22 15:59:00 2015
Thank you very much for your help. Does the code work for other xml
files? We can't run the code at all on our machines given we
apparently don't have the required modules for parsing
specific files (XML::LibXML, Getopt::Long). I've never dealt with
these
modules/libraries before. Thus, we figured we'd ask as much as we can
before trying to install these (in case we ultimately can't even get
the
code to work). Otherwise, I assume you have the latest versions of
these
modules already installed or had to install them.
On Mon, Dec 21, 2015 at 2:58 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Nick,
>
> The data I tried to send was too large for email. Instead, I posted
the
> output I get when I run the following command to an anonymous ftp
site.
>
> Command:
> perl xml2atcf.pl
> z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
>
> FTP Site:
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/for_nick/
>
> Thanks,
> John
>
> On Mon, Dec 21, 2015 at 12:54 PM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
>
> > Nick,
> >
> > I've attached the output I get when I run the following command:
> > perl xml2atcf.pl
> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
> >
> > Hope that helps.
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Dec 21, 2015 at 12:03 PM, Nicholas Leonardo via RT <
> > met_help at ucar.edu> wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
> >>
> >> Hello,
> >> Can you provide me with a sample file of the messy output you got
from
> the
> >> xml2atcf.pl script? Thank you.
> >> -Nick
> >>
> >> On Fri, Dec 4, 2015 at 6:13 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu
> >> > wrote:
> >>
> >> > Nick,
> >> >
> >> > I wasn't aware of any utilities for converting CXML to ATCF
format.
> In
> >> > fact, I wasn't familiar with the CXML format.
> >> >
> >> > However, a quick google search for "cxml to atcf" turned up the
> >> following
> >> > PERL script:
> >> >
> >> >
> >> >
> >>
>
ftp://ftp.emc.ncep.noaa.gov/gc_wmb/mcharles/tigge/beta/xml2atcf/v1.2/xml2atcf.pl
> >> >
> >> > Then I pulled a sample ECMWF CXML file from this data source:
> >> >
> >> >
> >> >
> >>
> ftp://tigge-
ldm.ecmwf.int/cxml/z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> >> >
> >> > And ran the utility:
> >> >
> >> > chmod +x xml2atcf.pl
> >> > ./xml2atcf.pl \
> >> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml \
> >> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
> >> >
> >> > It extracted data for 159 storms... however the resulting ATCF
file
> does
> >> > not look good. Looks like it contains a lot of garbage.
> >> >
> >> > Perhaps there are other, better supported utilities out there,
or you
> >> could
> >> > adapt this one to make it do what you need.
> >> >
> >> > Thanks,
> >> > John Halley Gotway
> >> > met_help at ucar.edu
> >> >
> >> > On Fri, Dec 4, 2015 at 3:40 PM, Nicholas Leonardo via RT <
> >> > met_help at ucar.edu>
> >> > wrote:
> >> >
> >> > >
> >> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039
>
> >> > >
> >> > > Hello,
> >> > > I have a new question about reading cxml files into MET_TC.
The
> ECMWF
> >> > has
> >> > > archived TC forecast tracks, but they are in cxml format
(which I've
> >> > never
> >> > > dealt with before). Is there a code that can convert cxml
files
> back
> >> > into
> >> > > the required .dat a-decks for MET to read? Thank you.
> >> > > -Nick
> >> > >
> >> > > On Thu, Nov 12, 2015 at 11:05 AM, Nicholas Leonardo <
> >> > > nicholas.leonardo at stonybrook.edu> wrote:
> >> > >
> >> > > > 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
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Way to loop TC_pairs
From: John Halley Gotway
Time: Wed Dec 23 09:53:20 2015
Nick,
I'm sorry, I really don't have any more info about it for you. It was
the
result of just searching online
(ftp://ftp.nhc.noaa.gov/atcf/archive/). As
I said, it doesn't actually "work" yet because the output doesn't look
correct. But it looks like it might be close.
For more info, you could try contacting "Mike Charles" at NOAA. His
name
is listed as the author in that PERL script. Looks like he's at
NOAA/CPC:
http://www.cpc.ncep.noaa.gov/information/personnel/index_staff.shtml#M
If I have my druthers, we would update the MET tc_pairs tool to read
track
data directly in ATCF, CXML, or Diamond7 (a format used in China
and/or
Japan). Unfortunately, we don't have funding to support that.
Thanks and happy holidays.
John
On Tue, Dec 22, 2015 at 3:59 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 very much for your help. Does the code work for other xml
> files? We can't run the code at all on our machines given we
> apparently don't have the required modules for parsing
> specific files (XML::LibXML, Getopt::Long). I've never dealt with
these
> modules/libraries before. Thus, we figured we'd ask as much as we
can
> before trying to install these (in case we ultimately can't even get
the
> code to work). Otherwise, I assume you have the latest versions of
these
> modules already installed or had to install them.
>
> On Mon, Dec 21, 2015 at 2:58 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Nick,
> >
> > The data I tried to send was too large for email. Instead, I
posted the
> > output I get when I run the following command to an anonymous ftp
site.
> >
> > Command:
> > perl xml2atcf.pl
> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
> >
> > FTP Site:
> > ftp://ftp.rap.ucar.edu/incoming/irap/met_help/for_nick/
> >
> > Thanks,
> > John
> >
> > On Mon, Dec 21, 2015 at 12:54 PM, John Halley Gotway
<johnhg at ucar.edu>
> > wrote:
> >
> > > Nick,
> > >
> > > I've attached the output I get when I run the following command:
> > > perl xml2atcf.pl
> > > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> > > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
> > >
> > > Hope that helps.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Mon, Dec 21, 2015 at 12:03 PM, Nicholas Leonardo via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >>
> > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
> > >>
> > >> Hello,
> > >> Can you provide me with a sample file of the messy output you
got from
> > the
> > >> xml2atcf.pl script? Thank you.
> > >> -Nick
> > >>
> > >> On Fri, Dec 4, 2015 at 6:13 PM, John Halley Gotway via RT <
> > >> met_help at ucar.edu
> > >> > wrote:
> > >>
> > >> > Nick,
> > >> >
> > >> > I wasn't aware of any utilities for converting CXML to ATCF
format.
> > In
> > >> > fact, I wasn't familiar with the CXML format.
> > >> >
> > >> > However, a quick google search for "cxml to atcf" turned up
the
> > >> following
> > >> > PERL script:
> > >> >
> > >> >
> > >> >
> > >>
> >
>
ftp://ftp.emc.ncep.noaa.gov/gc_wmb/mcharles/tigge/beta/xml2atcf/v1.2/xml2atcf.pl
> > >> >
> > >> > Then I pulled a sample ECMWF CXML file from this data source:
> > >> >
> > >> >
> > >> >
> > >>
> >
> ftp://tigge-
ldm.ecmwf.int/cxml/z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml
> > >> >
> > >> > And ran the utility:
> > >> >
> > >> > chmod +x xml2atcf.pl
> > >> > ./xml2atcf.pl \
> > >> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.xml \
> > >> > z_tigge_c_ecmf_20150925000000_ifs_glob_prod_all_glo.dat
> > >> >
> > >> > It extracted data for 159 storms... however the resulting
ATCF file
> > does
> > >> > not look good. Looks like it contains a lot of garbage.
> > >> >
> > >> > Perhaps there are other, better supported utilities out
there, or
> you
> > >> could
> > >> > adapt this one to make it do what you need.
> > >> >
> > >> > Thanks,
> > >> > John Halley Gotway
> > >> > met_help at ucar.edu
> > >> >
> > >> > On Fri, Dec 4, 2015 at 3:40 PM, Nicholas Leonardo via RT <
> > >> > met_help at ucar.edu>
> > >> > wrote:
> > >> >
> > >> > >
> > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=74039 >
> > >> > >
> > >> > > Hello,
> > >> > > I have a new question about reading cxml files into MET_TC.
The
> > ECMWF
> > >> > has
> > >> > > archived TC forecast tracks, but they are in cxml format
(which
> I've
> > >> > never
> > >> > > dealt with before). Is there a code that can convert cxml
files
> > back
> > >> > into
> > >> > > the required .dat a-decks for MET to read? Thank you.
> > >> > > -Nick
> > >> > >
> > >> > > On Thu, Nov 12, 2015 at 11:05 AM, Nicholas Leonardo <
> > >> > > nicholas.leonardo at stonybrook.edu> wrote:
> > >> > >
> > >> > > > 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