[Met_help] [rt.rap.ucar.edu #79776] History for issue with tc_pairs number of valid cases
John Halley Gotway via RT
met_help at ucar.edu
Fri Mar 10 13:34:59 MST 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi John,
When verifying EP162015, the number of valid cases is different between our
verification package run at NHC and MET-TC, and I'm not sure why! For
instance, there are values in the bdeck and adeck that should allow the
track error to be calculated for two cases at 12 h (including cases common
to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the track error, and
this results in 0 valid cases at 12 h when using tc_stat.
Would you mind looking into this to see why the track error is not being
computed? I've attached a few files that I've been testing that have been
thinned. Our verification package results in 4 cases at 0 h, and 2 cases at
12 h.
commands run:
tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat -config
./TCPairsConfig -out ./ep162015
tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
Thanks,
Andy
--
Andrew Penny
Hurricane Model Diagnostician
SRG / National Hurricane Center
11691 SW 17th Street
Miami, FL 33165-2149
phone: 305.229.4457
email: andrew.penny at noaa.gov
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: John Halley Gotway
Time: Thu Mar 09 15:06:23 2017
Andy,
Thanks for sending the test case. I ran it through met-5.2 on my
machine
and produced the exact same pair output you're getting from tc_pairs.
I chose to focus in a single problematic point and run tc_pairs
through the
debugger:
For model HCCA initialized at 2015092012
I found that the logic breaks down because of the irregular spacing of
the
BEST track data. Below I've listed the first 8 columns of the BEST
track:
EP, 16, 2015092018, , BEST, 0, 243N, 1137W,
EP, 16, 2015092100, , BEST, 0, 255N, 1134W,
EP, 16, 2015092104, 45, BEST, 0, 266N, 1131W,
EP, 16, 2015092106, , BEST, 0, 268N, 1130W,
EP, 16, 2015092112, , BEST, 0, 283N, 1125W,
EP, 16, 2015092113, 45, BEST, 0, 288N, 1123W,
EP, 16, 2015092115, , BEST, 0, 292N, 1122W,
The code looks for the *most common* time spacing of the BEST track.
It
computes the number of seconds from one time to the next and takes the
*mode* of those time steps. Then it uses that time step to progress
through the data. If you do the math, the time step is 4500 seconds
twice
and 21600 seconds twice. It must just be picking the first one of
those.
So it's stepping through the track points every 75 minutes and just
misses
the 12 hour forecast.
I suspect that the NHC code has hard-coded the BEST track time step as
6
hours.
To test this out, I removed those two 45-minute BEST track lines and
reran
to produce the expected output from TC-Stat:
COL_NAME: COLUMN AMODEL LEAD TOTAL VALID MEAN
SUMMARY: TK_ERR HCCA 0000000 4 4 10.51742
SUMMARY: TK_ERR HCCA 0120000 2 2 33.9373
SUMMARY: TK_ERR OFCL 0000000 4 4 10.51742
SUMMARY: TK_ERR OFCL 0120000 2 2 35.97311
SUMMARY: TK_ERR TVCN 0000000 4 4 10.51742
SUMMARY: TK_ERR TVCN 0120000 2 2 37.85669
So now that we understand the problem, how should we fix it?
We're actually using the FORTRAN code we got from NHC from computing
the
track errors. And that code assumes that all points are evenly spaced
in
time. So that's why we're paying attention to the time step.
Also, MET-TC can be used to compare any two arbitrary track data
sources.
Some might have 6-hour track spacing while other could have 3, or
perhaps
even 1. So I'm leary of hard-coding anything.
That being said, if we've parsed the name from the "BDECK" file as see
that
it's "BEST"... we could hard-code the timestep to 6 hours.
Any thoughts?
Thanks,
John
On Thu, Mar 9, 2017 at 12:29 PM, Andrew Penny - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:
>
> Thu Mar 09 12:29:42 2017: Request 79776 was acted upon.
> Transaction: Ticket created by andrew.penny at noaa.gov
> Queue: met_help
> Subject: issue with tc_pairs number of valid cases
> Owner: Nobody
> Requestors: andrew.penny at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
>
>
> Hi John,
>
> When verifying EP162015, the number of valid cases is different
between our
> verification package run at NHC and MET-TC, and I'm not sure why!
For
> instance, there are values in the bdeck and adeck that should allow
the
> track error to be calculated for two cases at 12 h (including cases
common
> to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the track
error, and
> this results in 0 valid cases at 12 h when using tc_stat.
>
> Would you mind looking into this to see why the track error is not
being
> computed? I've attached a few files that I've been testing that have
been
> thinned. Our verification package results in 4 cases at 0 h, and 2
cases at
> 12 h.
>
> commands run:
>
> tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat -config
> ./TCPairsConfig -out ./ep162015
> tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
>
>
> Thanks,
> Andy
>
>
> --
> Andrew Penny
> Hurricane Model Diagnostician
> SRG / National Hurricane Center
> 11691 SW 17th Street
> Miami, FL 33165-2149
> phone: 305.229.4457
> email: andrew.penny at noaa.gov
>
>
------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: John Halley Gotway
Time: Thu Mar 09 15:47:10 2017
Andy,
FYI, turning up the verbosity level in the call to tc_pairs, I see
this log
message which confirms what I described:
DEBUG 3: Computing track errors for 21 vaild times: 20150920_130000
to
20150921_140000 by 011500 increment.
I spoke with a scientist here and we decided that hard-coding the time
step
to 6 hours for BEST tracks is the simplest solution. If in the
future, the
BEST track contains output every 3 hours or 1 hour, we'd need to
modify the
code to handle that. So we could guess at more complex logic to
gracefully
handle that... but we decided not to fix problems that don't exist
yet.
Does that sound reasonable to you?
The required code change is around line 1467 of tc_pairs.cc. Here's
the
updated code:
// Determine the valid increment.
// For BEST tracks, use a constant time step.
// For non-BEST tracks, select the most common BDECK time step.
if(bdeck.is_best_track()) ut_inc = 21600;
else ut_inc = bdeck.valid_inc();
In version 6.0 of MET, I'm defining best_track_time_step = 21600 in
tc_pairs.h instead.
Do you need me to post an official patch for version 5.2... or do you
want
to manually patch it yourself... or do you just want to wait until
6.0?
Thanks,
John
On Thu, Mar 9, 2017 at 3:06 PM, The RT System itself via RT <
met_help at ucar.edu> wrote:
>
> Thu Mar 09 15:06:23 2017: Request 79776 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by RT_System
> Queue: met_help
> Subject: issue with tc_pairs number of valid cases
> Owner: johnhg
> Requestors: andrew.penny at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: Andrew Penny - NOAA Affiliate
Time: Fri Mar 10 10:50:24 2017
Hi John,
Thanks for looking into this issue.
I'm curious, why was it chosen to go through the bdeck at the most
common
time interval instead of simply processing all available times and
matching
according to valid time? I'm not too familiar with NHC's version of
the
code, but I don't think it follows the same logic. I could be wrong
though.
This could continue to be an issue for shorter-lived systems that have
a
few bdeck entries that are at off-synoptic times. Still, it's likely a
very
rare occurrence.
As far as fixes go, I think what you've suggested sounds good in
hard-coding the time interval to 6 h if we're comparing against the
best
track. However, if the first time in the bdeck is at an off-synoptic
time,
will this cause issues? Instead of specifying the time interval, could
the
00, 06, 12, and 18 UTC times be hard-coded?
Thanks,
Andy
On Thu, Mar 9, 2017 at 10:06 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Andy,
>
> Thanks for sending the test case. I ran it through met-5.2 on my
machine
> and produced the exact same pair output you're getting from
tc_pairs.
>
> I chose to focus in a single problematic point and run tc_pairs
through the
> debugger:
> For model HCCA initialized at 2015092012
>
> I found that the logic breaks down because of the irregular spacing
of the
> BEST track data. Below I've listed the first 8 columns of the BEST
track:
> EP, 16, 2015092018, , BEST, 0, 243N, 1137W,
> EP, 16, 2015092100, , BEST, 0, 255N, 1134W,
> EP, 16, 2015092104, 45, BEST, 0, 266N, 1131W,
> EP, 16, 2015092106, , BEST, 0, 268N, 1130W,
> EP, 16, 2015092112, , BEST, 0, 283N, 1125W,
> EP, 16, 2015092113, 45, BEST, 0, 288N, 1123W,
> EP, 16, 2015092115, , BEST, 0, 292N, 1122W,
>
> The code looks for the *most common* time spacing of the BEST track.
It
> computes the number of seconds from one time to the next and takes
the
> *mode* of those time steps. Then it uses that time step to progress
> through the data. If you do the math, the time step is 4500 seconds
twice
> and 21600 seconds twice. It must just be picking the first one of
those.
> So it's stepping through the track points every 75 minutes and just
misses
> the 12 hour forecast.
>
> I suspect that the NHC code has hard-coded the BEST track time step
as 6
> hours.
>
> To test this out, I removed those two 45-minute BEST track lines and
reran
> to produce the expected output from TC-Stat:
> COL_NAME: COLUMN AMODEL LEAD TOTAL VALID MEAN
> SUMMARY: TK_ERR HCCA 0000000 4 4 10.51742
> SUMMARY: TK_ERR HCCA 0120000 2 2 33.9373
> SUMMARY: TK_ERR OFCL 0000000 4 4 10.51742
> SUMMARY: TK_ERR OFCL 0120000 2 2 35.97311
> SUMMARY: TK_ERR TVCN 0000000 4 4 10.51742
> SUMMARY: TK_ERR TVCN 0120000 2 2 37.85669
>
> So now that we understand the problem, how should we fix it?
>
> We're actually using the FORTRAN code we got from NHC from computing
the
> track errors. And that code assumes that all points are evenly
spaced in
> time. So that's why we're paying attention to the time step.
>
> Also, MET-TC can be used to compare any two arbitrary track data
sources.
> Some might have 6-hour track spacing while other could have 3, or
perhaps
> even 1. So I'm leary of hard-coding anything.
>
> That being said, if we've parsed the name from the "BDECK" file as
see that
> it's "BEST"... we could hard-code the timestep to 6 hours.
>
> Any thoughts?
>
> Thanks,
> John
>
>
>
>
>
>
>
>
> On Thu, Mar 9, 2017 at 12:29 PM, Andrew Penny - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > Thu Mar 09 12:29:42 2017: Request 79776 was acted upon.
> > Transaction: Ticket created by andrew.penny at noaa.gov
> > Queue: met_help
> > Subject: issue with tc_pairs number of valid cases
> > Owner: Nobody
> > Requestors: andrew.penny at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
> >
> >
> > Hi John,
> >
> > When verifying EP162015, the number of valid cases is different
between
> our
> > verification package run at NHC and MET-TC, and I'm not sure why!
For
> > instance, there are values in the bdeck and adeck that should
allow the
> > track error to be calculated for two cases at 12 h (including
cases
> common
> > to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the track
error,
> and
> > this results in 0 valid cases at 12 h when using tc_stat.
> >
> > Would you mind looking into this to see why the track error is not
being
> > computed? I've attached a few files that I've been testing that
have been
> > thinned. Our verification package results in 4 cases at 0 h, and 2
cases
> at
> > 12 h.
> >
> > commands run:
> >
> > tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat -config
> > ./TCPairsConfig -out ./ep162015
> > tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
> >
> >
> > Thanks,
> > Andy
> >
> >
> > --
> > Andrew Penny
> > Hurricane Model Diagnostician
> > SRG / National Hurricane Center
> > 11691 SW 17th Street
> > Miami, FL 33165-2149
> > phone: 305.229.4457
> > email: andrew.penny at noaa.gov
> >
> >
>
>
--
Andrew Penny
Hurricane Model Diagnostician
SRG / National Hurricane Center
11691 SW 17th Street
Miami, FL 33165-2149
phone: 305.229.4457
email: andrew.penny at noaa.gov
------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: John Halley Gotway
Time: Fri Mar 10 13:09:09 2017
Andy,
The NHC tools were designed to compare forecast track data to BEST
track
files.
We designed MET-TC to compare forecast track to BEST tracks ***OR***
compare to other forecast tracks. And we don't know the track output
frequency users will choose (every 12 hours, 6, 3, or 1 all seem like
reasonable choices). MET-TC doesn't assume a 6-hour spacing and
instead
analyzes the data to figure the track spacing. All of this logic is
preparing track data to be passed to the FORTRAN subroutine for track
errors which assumes that the track points are evenly spaced in time.
However, the degenerate case you found proves that this logic isn't
sufficient. And hard-coding the track point spacing to 6 hours for
BEST
tracks is a simple solution.
I have it committed for both MET 6.0 and to the bugfix branch for MET
5.2.
Do you need the 5.2 patch or do you want to just wait for 6.0?
Thanks,
John
On Fri, Mar 10, 2017 at 10:50 AM, Andrew Penny - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
>
> Hi John,
>
> Thanks for looking into this issue.
>
> I'm curious, why was it chosen to go through the bdeck at the most
common
> time interval instead of simply processing all available times and
matching
> according to valid time? I'm not too familiar with NHC's version of
the
> code, but I don't think it follows the same logic. I could be wrong
though.
> This could continue to be an issue for shorter-lived systems that
have a
> few bdeck entries that are at off-synoptic times. Still, it's likely
a very
> rare occurrence.
>
> As far as fixes go, I think what you've suggested sounds good in
> hard-coding the time interval to 6 h if we're comparing against the
best
> track. However, if the first time in the bdeck is at an off-synoptic
time,
> will this cause issues? Instead of specifying the time interval,
could the
> 00, 06, 12, and 18 UTC times be hard-coded?
>
> Thanks,
> Andy
>
>
> On Thu, Mar 9, 2017 at 10:06 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Andy,
> >
> > Thanks for sending the test case. I ran it through met-5.2 on my
machine
> > and produced the exact same pair output you're getting from
tc_pairs.
> >
> > I chose to focus in a single problematic point and run tc_pairs
through
> the
> > debugger:
> > For model HCCA initialized at 2015092012
> >
> > I found that the logic breaks down because of the irregular
spacing of
> the
> > BEST track data. Below I've listed the first 8 columns of the
BEST
> track:
> > EP, 16, 2015092018, , BEST, 0, 243N, 1137W,
> > EP, 16, 2015092100, , BEST, 0, 255N, 1134W,
> > EP, 16, 2015092104, 45, BEST, 0, 266N, 1131W,
> > EP, 16, 2015092106, , BEST, 0, 268N, 1130W,
> > EP, 16, 2015092112, , BEST, 0, 283N, 1125W,
> > EP, 16, 2015092113, 45, BEST, 0, 288N, 1123W,
> > EP, 16, 2015092115, , BEST, 0, 292N, 1122W,
> >
> > The code looks for the *most common* time spacing of the BEST
track. It
> > computes the number of seconds from one time to the next and takes
the
> > *mode* of those time steps. Then it uses that time step to
progress
> > through the data. If you do the math, the time step is 4500
seconds
> twice
> > and 21600 seconds twice. It must just be picking the first one of
those.
> > So it's stepping through the track points every 75 minutes and
just
> misses
> > the 12 hour forecast.
> >
> > I suspect that the NHC code has hard-coded the BEST track time
step as 6
> > hours.
> >
> > To test this out, I removed those two 45-minute BEST track lines
and
> reran
> > to produce the expected output from TC-Stat:
> > COL_NAME: COLUMN AMODEL LEAD TOTAL VALID MEAN
> > SUMMARY: TK_ERR HCCA 0000000 4 4
10.51742
> > SUMMARY: TK_ERR HCCA 0120000 2 2 33.9373
> > SUMMARY: TK_ERR OFCL 0000000 4 4
10.51742
> > SUMMARY: TK_ERR OFCL 0120000 2 2
35.97311
> > SUMMARY: TK_ERR TVCN 0000000 4 4
10.51742
> > SUMMARY: TK_ERR TVCN 0120000 2 2
37.85669
> >
> > So now that we understand the problem, how should we fix it?
> >
> > We're actually using the FORTRAN code we got from NHC from
computing the
> > track errors. And that code assumes that all points are evenly
spaced in
> > time. So that's why we're paying attention to the time step.
> >
> > Also, MET-TC can be used to compare any two arbitrary track data
sources.
> > Some might have 6-hour track spacing while other could have 3, or
perhaps
> > even 1. So I'm leary of hard-coding anything.
> >
> > That being said, if we've parsed the name from the "BDECK" file as
see
> that
> > it's "BEST"... we could hard-code the timestep to 6 hours.
> >
> > Any thoughts?
> >
> > Thanks,
> > John
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Mar 9, 2017 at 12:29 PM, Andrew Penny - NOAA Affiliate via
RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Thu Mar 09 12:29:42 2017: Request 79776 was acted upon.
> > > Transaction: Ticket created by andrew.penny at noaa.gov
> > > Queue: met_help
> > > Subject: issue with tc_pairs number of valid cases
> > > Owner: Nobody
> > > Requestors: andrew.penny at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776
> >
> > >
> > >
> > > Hi John,
> > >
> > > When verifying EP162015, the number of valid cases is different
between
> > our
> > > verification package run at NHC and MET-TC, and I'm not sure
why! For
> > > instance, there are values in the bdeck and adeck that should
allow the
> > > track error to be calculated for two cases at 12 h (including
cases
> > common
> > > to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the track
error,
> > and
> > > this results in 0 valid cases at 12 h when using tc_stat.
> > >
> > > Would you mind looking into this to see why the track error is
not
> being
> > > computed? I've attached a few files that I've been testing that
have
> been
> > > thinned. Our verification package results in 4 cases at 0 h, and
2
> cases
> > at
> > > 12 h.
> > >
> > > commands run:
> > >
> > > tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat -config
> > > ./TCPairsConfig -out ./ep162015
> > > tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
> > >
> > >
> > > Thanks,
> > > Andy
> > >
> > >
> > > --
> > > Andrew Penny
> > > Hurricane Model Diagnostician
> > > SRG / National Hurricane Center
> > > 11691 SW 17th Street
> > > Miami, FL 33165-2149
> > > phone: 305.229.4457
> > > email: andrew.penny at noaa.gov
> > >
> > >
> >
> >
>
>
> --
> Andrew Penny
> Hurricane Model Diagnostician
> SRG / National Hurricane Center
> 11691 SW 17th Street
> Miami, FL 33165-2149
> phone: 305.229.4457
> email: andrew.penny at noaa.gov
>
>
------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: Andrew Penny - NOAA Affiliate
Time: Fri Mar 10 13:15:45 2017
Hi John,
Okay, thanks for explaining. Makes sense.
I'm fine making the update myself right now.
Question though... is this hard-coded fix dependent on the first time
in
the best track being at 00, 06, 12, or 18Z to work properly?
Thanks again for your help in tracking down the issue.
Have a good weekend,
Andy
On Fri, Mar 10, 2017 at 8:09 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Andy,
>
> The NHC tools were designed to compare forecast track data to BEST
track
> files.
>
> We designed MET-TC to compare forecast track to BEST tracks ***OR***
> compare to other forecast tracks. And we don't know the track
output
> frequency users will choose (every 12 hours, 6, 3, or 1 all seem
like
> reasonable choices). MET-TC doesn't assume a 6-hour spacing and
instead
> analyzes the data to figure the track spacing. All of this logic is
> preparing track data to be passed to the FORTRAN subroutine for
track
> errors which assumes that the track points are evenly spaced in
time.
>
> However, the degenerate case you found proves that this logic isn't
> sufficient. And hard-coding the track point spacing to 6 hours for
BEST
> tracks is a simple solution.
>
> I have it committed for both MET 6.0 and to the bugfix branch for
MET 5.2.
> Do you need the 5.2 patch or do you want to just wait for 6.0?
>
> Thanks,
> John
>
> On Fri, Mar 10, 2017 at 10:50 AM, Andrew Penny - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
> >
> > Hi John,
> >
> > Thanks for looking into this issue.
> >
> > I'm curious, why was it chosen to go through the bdeck at the most
common
> > time interval instead of simply processing all available times and
> matching
> > according to valid time? I'm not too familiar with NHC's version
of the
> > code, but I don't think it follows the same logic. I could be
wrong
> though.
> > This could continue to be an issue for shorter-lived systems that
have a
> > few bdeck entries that are at off-synoptic times. Still, it's
likely a
> very
> > rare occurrence.
> >
> > As far as fixes go, I think what you've suggested sounds good in
> > hard-coding the time interval to 6 h if we're comparing against
the best
> > track. However, if the first time in the bdeck is at an off-
synoptic
> time,
> > will this cause issues? Instead of specifying the time interval,
could
> the
> > 00, 06, 12, and 18 UTC times be hard-coded?
> >
> > Thanks,
> > Andy
> >
> >
> > On Thu, Mar 9, 2017 at 10:06 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Andy,
> > >
> > > Thanks for sending the test case. I ran it through met-5.2 on
my
> machine
> > > and produced the exact same pair output you're getting from
tc_pairs.
> > >
> > > I chose to focus in a single problematic point and run tc_pairs
through
> > the
> > > debugger:
> > > For model HCCA initialized at 2015092012
> > >
> > > I found that the logic breaks down because of the irregular
spacing of
> > the
> > > BEST track data. Below I've listed the first 8 columns of the
BEST
> > track:
> > > EP, 16, 2015092018, , BEST, 0, 243N, 1137W,
> > > EP, 16, 2015092100, , BEST, 0, 255N, 1134W,
> > > EP, 16, 2015092104, 45, BEST, 0, 266N, 1131W,
> > > EP, 16, 2015092106, , BEST, 0, 268N, 1130W,
> > > EP, 16, 2015092112, , BEST, 0, 283N, 1125W,
> > > EP, 16, 2015092113, 45, BEST, 0, 288N, 1123W,
> > > EP, 16, 2015092115, , BEST, 0, 292N, 1122W,
> > >
> > > The code looks for the *most common* time spacing of the BEST
track.
> It
> > > computes the number of seconds from one time to the next and
takes the
> > > *mode* of those time steps. Then it uses that time step to
progress
> > > through the data. If you do the math, the time step is 4500
seconds
> > twice
> > > and 21600 seconds twice. It must just be picking the first one
of
> those.
> > > So it's stepping through the track points every 75 minutes and
just
> > misses
> > > the 12 hour forecast.
> > >
> > > I suspect that the NHC code has hard-coded the BEST track time
step as
> 6
> > > hours.
> > >
> > > To test this out, I removed those two 45-minute BEST track lines
and
> > reran
> > > to produce the expected output from TC-Stat:
> > > COL_NAME: COLUMN AMODEL LEAD TOTAL VALID MEAN
> > > SUMMARY: TK_ERR HCCA 0000000 4 4
10.51742
> > > SUMMARY: TK_ERR HCCA 0120000 2 2
33.9373
> > > SUMMARY: TK_ERR OFCL 0000000 4 4
10.51742
> > > SUMMARY: TK_ERR OFCL 0120000 2 2
35.97311
> > > SUMMARY: TK_ERR TVCN 0000000 4 4
10.51742
> > > SUMMARY: TK_ERR TVCN 0120000 2 2
37.85669
> > >
> > > So now that we understand the problem, how should we fix it?
> > >
> > > We're actually using the FORTRAN code we got from NHC from
computing
> the
> > > track errors. And that code assumes that all points are evenly
spaced
> in
> > > time. So that's why we're paying attention to the time step.
> > >
> > > Also, MET-TC can be used to compare any two arbitrary track data
> sources.
> > > Some might have 6-hour track spacing while other could have 3,
or
> perhaps
> > > even 1. So I'm leary of hard-coding anything.
> > >
> > > That being said, if we've parsed the name from the "BDECK" file
as see
> > that
> > > it's "BEST"... we could hard-code the timestep to 6 hours.
> > >
> > > Any thoughts?
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Mar 9, 2017 at 12:29 PM, Andrew Penny - NOAA Affiliate
via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > Thu Mar 09 12:29:42 2017: Request 79776 was acted upon.
> > > > Transaction: Ticket created by andrew.penny at noaa.gov
> > > > Queue: met_help
> > > > Subject: issue with tc_pairs number of valid cases
> > > > Owner: Nobody
> > > > Requestors: andrew.penny at noaa.gov
> > > > Status: new
> > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=79776
> > >
> > > >
> > > >
> > > > Hi John,
> > > >
> > > > When verifying EP162015, the number of valid cases is
different
> between
> > > our
> > > > verification package run at NHC and MET-TC, and I'm not sure
why! For
> > > > instance, there are values in the bdeck and adeck that should
allow
> the
> > > > track error to be calculated for two cases at 12 h (including
cases
> > > common
> > > > to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the
track
> error,
> > > and
> > > > this results in 0 valid cases at 12 h when using tc_stat.
> > > >
> > > > Would you mind looking into this to see why the track error is
not
> > being
> > > > computed? I've attached a few files that I've been testing
that have
> > been
> > > > thinned. Our verification package results in 4 cases at 0 h,
and 2
> > cases
> > > at
> > > > 12 h.
> > > >
> > > > commands run:
> > > >
> > > > tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat -config
> > > > ./TCPairsConfig -out ./ep162015
> > > > tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
> > > >
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > >
> > > > --
> > > > Andrew Penny
> > > > Hurricane Model Diagnostician
> > > > SRG / National Hurricane Center
> > > > 11691 SW 17th Street
> > > > Miami, FL 33165-2149
> > > > phone: 305.229.4457
> > > > email: andrew.penny at noaa.gov
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Andrew Penny
> > Hurricane Model Diagnostician
> > SRG / National Hurricane Center
> > 11691 SW 17th Street
> > Miami, FL 33165-2149
> > phone: 305.229.4457
> > email: andrew.penny at noaa.gov
> >
> >
>
>
--
Andrew Penny
Hurricane Model Diagnostician
SRG / National Hurricane Center
11691 SW 17th Street
Miami, FL 33165-2149
phone: 305.229.4457
email: andrew.penny at noaa.gov
------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: John Halley Gotway
Time: Fri Mar 10 13:26:11 2017
Andy,
No, it shouldn't. Take a look at the next two lines of code in that
file:
// Determine the valid increment
// For BEST tracks, use a constant time step
// For non-BEST tracks, select the most common BDECK time step
if(bdeck.is_best_track()) ut_inc = best_track_time_step;
else ut_inc = bdeck.valid_inc();
// Round the valid times to the nearest valid increment
if(ut_min%ut_inc != 0) ut_min = (ut_min/ut_inc + 1)*ut_inc;
if(ut_max%ut_inc != 0) ut_max = (ut_max/ut_inc)*ut_inc;
In this code, "ut" stands for unixtime which is a count of the number
of
seconds since Jan 1, 1970. The computed ut_min and ut_max values are
the
earliest/latest times of the union of the ADECK and BDECK tracks. If
they
aren't divisible by the time step, these lines round ut_min *up* to
the
next time step increment and ut_max *down* to the previous one.
So the time of the first BEST track point should not matter.
John
On Fri, Mar 10, 2017 at 1:15 PM, Andrew Penny - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
>
> Hi John,
>
> Okay, thanks for explaining. Makes sense.
>
> I'm fine making the update myself right now.
>
> Question though... is this hard-coded fix dependent on the first
time in
> the best track being at 00, 06, 12, or 18Z to work properly?
>
> Thanks again for your help in tracking down the issue.
>
> Have a good weekend,
> Andy
>
> On Fri, Mar 10, 2017 at 8:09 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Andy,
> >
> > The NHC tools were designed to compare forecast track data to BEST
track
> > files.
> >
> > We designed MET-TC to compare forecast track to BEST tracks
***OR***
> > compare to other forecast tracks. And we don't know the track
output
> > frequency users will choose (every 12 hours, 6, 3, or 1 all seem
like
> > reasonable choices). MET-TC doesn't assume a 6-hour spacing and
instead
> > analyzes the data to figure the track spacing. All of this logic
is
> > preparing track data to be passed to the FORTRAN subroutine for
track
> > errors which assumes that the track points are evenly spaced in
time.
> >
> > However, the degenerate case you found proves that this logic
isn't
> > sufficient. And hard-coding the track point spacing to 6 hours
for BEST
> > tracks is a simple solution.
> >
> > I have it committed for both MET 6.0 and to the bugfix branch for
MET
> 5.2.
> > Do you need the 5.2 patch or do you want to just wait for 6.0?
> >
> > Thanks,
> > John
> >
> > On Fri, Mar 10, 2017 at 10:50 AM, Andrew Penny - NOAA Affiliate
via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
> > >
> > > Hi John,
> > >
> > > Thanks for looking into this issue.
> > >
> > > I'm curious, why was it chosen to go through the bdeck at the
most
> common
> > > time interval instead of simply processing all available times
and
> > matching
> > > according to valid time? I'm not too familiar with NHC's version
of the
> > > code, but I don't think it follows the same logic. I could be
wrong
> > though.
> > > This could continue to be an issue for shorter-lived systems
that have
> a
> > > few bdeck entries that are at off-synoptic times. Still, it's
likely a
> > very
> > > rare occurrence.
> > >
> > > As far as fixes go, I think what you've suggested sounds good in
> > > hard-coding the time interval to 6 h if we're comparing against
the
> best
> > > track. However, if the first time in the bdeck is at an off-
synoptic
> > time,
> > > will this cause issues? Instead of specifying the time interval,
could
> > the
> > > 00, 06, 12, and 18 UTC times be hard-coded?
> > >
> > > Thanks,
> > > Andy
> > >
> > >
> > > On Thu, Mar 9, 2017 at 10:06 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Andy,
> > > >
> > > > Thanks for sending the test case. I ran it through met-5.2 on
my
> > machine
> > > > and produced the exact same pair output you're getting from
tc_pairs.
> > > >
> > > > I chose to focus in a single problematic point and run
tc_pairs
> through
> > > the
> > > > debugger:
> > > > For model HCCA initialized at 2015092012
> > > >
> > > > I found that the logic breaks down because of the irregular
spacing
> of
> > > the
> > > > BEST track data. Below I've listed the first 8 columns of the
BEST
> > > track:
> > > > EP, 16, 2015092018, , BEST, 0, 243N, 1137W,
> > > > EP, 16, 2015092100, , BEST, 0, 255N, 1134W,
> > > > EP, 16, 2015092104, 45, BEST, 0, 266N, 1131W,
> > > > EP, 16, 2015092106, , BEST, 0, 268N, 1130W,
> > > > EP, 16, 2015092112, , BEST, 0, 283N, 1125W,
> > > > EP, 16, 2015092113, 45, BEST, 0, 288N, 1123W,
> > > > EP, 16, 2015092115, , BEST, 0, 292N, 1122W,
> > > >
> > > > The code looks for the *most common* time spacing of the BEST
track.
> > It
> > > > computes the number of seconds from one time to the next and
takes
> the
> > > > *mode* of those time steps. Then it uses that time step to
progress
> > > > through the data. If you do the math, the time step is 4500
seconds
> > > twice
> > > > and 21600 seconds twice. It must just be picking the first
one of
> > those.
> > > > So it's stepping through the track points every 75 minutes and
just
> > > misses
> > > > the 12 hour forecast.
> > > >
> > > > I suspect that the NHC code has hard-coded the BEST track time
step
> as
> > 6
> > > > hours.
> > > >
> > > > To test this out, I removed those two 45-minute BEST track
lines and
> > > reran
> > > > to produce the expected output from TC-Stat:
> > > > COL_NAME: COLUMN AMODEL LEAD TOTAL VALID MEAN
> > > > SUMMARY: TK_ERR HCCA 0000000 4 4
10.51742
> > > > SUMMARY: TK_ERR HCCA 0120000 2 2
33.9373
> > > > SUMMARY: TK_ERR OFCL 0000000 4 4
10.51742
> > > > SUMMARY: TK_ERR OFCL 0120000 2 2
35.97311
> > > > SUMMARY: TK_ERR TVCN 0000000 4 4
10.51742
> > > > SUMMARY: TK_ERR TVCN 0120000 2 2
37.85669
> > > >
> > > > So now that we understand the problem, how should we fix it?
> > > >
> > > > We're actually using the FORTRAN code we got from NHC from
computing
> > the
> > > > track errors. And that code assumes that all points are
evenly
> spaced
> > in
> > > > time. So that's why we're paying attention to the time step.
> > > >
> > > > Also, MET-TC can be used to compare any two arbitrary track
data
> > sources.
> > > > Some might have 6-hour track spacing while other could have 3,
or
> > perhaps
> > > > even 1. So I'm leary of hard-coding anything.
> > > >
> > > > That being said, if we've parsed the name from the "BDECK"
file as
> see
> > > that
> > > > it's "BEST"... we could hard-code the timestep to 6 hours.
> > > >
> > > > Any thoughts?
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Mar 9, 2017 at 12:29 PM, Andrew Penny - NOAA Affiliate
via
> RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > Thu Mar 09 12:29:42 2017: Request 79776 was acted upon.
> > > > > Transaction: Ticket created by andrew.penny at noaa.gov
> > > > > Queue: met_help
> > > > > Subject: issue with tc_pairs number of valid cases
> > > > > Owner: Nobody
> > > > > Requestors: andrew.penny at noaa.gov
> > > > > Status: new
> > > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=79776
> > > >
> > > > >
> > > > >
> > > > > Hi John,
> > > > >
> > > > > When verifying EP162015, the number of valid cases is
different
> > between
> > > > our
> > > > > verification package run at NHC and MET-TC, and I'm not sure
why!
> For
> > > > > instance, there are values in the bdeck and adeck that
should allow
> > the
> > > > > track error to be calculated for two cases at 12 h
(including cases
> > > > common
> > > > > to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the
track
> > error,
> > > > and
> > > > > this results in 0 valid cases at 12 h when using tc_stat.
> > > > >
> > > > > Would you mind looking into this to see why the track error
is not
> > > being
> > > > > computed? I've attached a few files that I've been testing
that
> have
> > > been
> > > > > thinned. Our verification package results in 4 cases at 0 h,
and 2
> > > cases
> > > > at
> > > > > 12 h.
> > > > >
> > > > > commands run:
> > > > >
> > > > > tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat
-config
> > > > > ./TCPairsConfig -out ./ep162015
> > > > > tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Andy
> > > > >
> > > > >
> > > > > --
> > > > > Andrew Penny
> > > > > Hurricane Model Diagnostician
> > > > > SRG / National Hurricane Center
> > > > > 11691 SW 17th Street
> > > > > Miami, FL 33165-2149
> > > > > phone: 305.229.4457
> > > > > email: andrew.penny at noaa.gov
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Andrew Penny
> > > Hurricane Model Diagnostician
> > > SRG / National Hurricane Center
> > > 11691 SW 17th Street
> > > Miami, FL 33165-2149
> > > phone: 305.229.4457
> > > email: andrew.penny at noaa.gov
> > >
> > >
> >
> >
>
>
> --
> Andrew Penny
> Hurricane Model Diagnostician
> SRG / National Hurricane Center
> 11691 SW 17th Street
> Miami, FL 33165-2149
> phone: 305.229.4457
> email: andrew.penny at noaa.gov
>
>
------------------------------------------------
Subject: issue with tc_pairs number of valid cases
From: Andrew Penny - NOAA Affiliate
Time: Fri Mar 10 13:27:58 2017
Okay, great. Thanks John.
Take care,
Andy
On Fri, Mar 10, 2017 at 8:26 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Andy,
>
> No, it shouldn't. Take a look at the next two lines of code in that
file:
>
> // Determine the valid increment
> // For BEST tracks, use a constant time step
> // For non-BEST tracks, select the most common BDECK time step
> if(bdeck.is_best_track()) ut_inc = best_track_time_step;
> else ut_inc = bdeck.valid_inc();
>
> // Round the valid times to the nearest valid increment
> if(ut_min%ut_inc != 0) ut_min = (ut_min/ut_inc + 1)*ut_inc;
> if(ut_max%ut_inc != 0) ut_max = (ut_max/ut_inc)*ut_inc;
>
> In this code, "ut" stands for unixtime which is a count of the
number of
> seconds since Jan 1, 1970. The computed ut_min and ut_max values
are the
> earliest/latest times of the union of the ADECK and BDECK tracks.
If they
> aren't divisible by the time step, these lines round ut_min *up* to
the
> next time step increment and ut_max *down* to the previous one.
>
> So the time of the first BEST track point should not matter.
>
> John
>
>
> On Fri, Mar 10, 2017 at 1:15 PM, Andrew Penny - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776 >
> >
> > Hi John,
> >
> > Okay, thanks for explaining. Makes sense.
> >
> > I'm fine making the update myself right now.
> >
> > Question though... is this hard-coded fix dependent on the first
time in
> > the best track being at 00, 06, 12, or 18Z to work properly?
> >
> > Thanks again for your help in tracking down the issue.
> >
> > Have a good weekend,
> > Andy
> >
> > On Fri, Mar 10, 2017 at 8:09 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Andy,
> > >
> > > The NHC tools were designed to compare forecast track data to
BEST
> track
> > > files.
> > >
> > > We designed MET-TC to compare forecast track to BEST tracks
***OR***
> > > compare to other forecast tracks. And we don't know the track
output
> > > frequency users will choose (every 12 hours, 6, 3, or 1 all seem
like
> > > reasonable choices). MET-TC doesn't assume a 6-hour spacing and
> instead
> > > analyzes the data to figure the track spacing. All of this
logic is
> > > preparing track data to be passed to the FORTRAN subroutine for
track
> > > errors which assumes that the track points are evenly spaced in
time.
> > >
> > > However, the degenerate case you found proves that this logic
isn't
> > > sufficient. And hard-coding the track point spacing to 6 hours
for
> BEST
> > > tracks is a simple solution.
> > >
> > > I have it committed for both MET 6.0 and to the bugfix branch
for MET
> > 5.2.
> > > Do you need the 5.2 patch or do you want to just wait for 6.0?
> > >
> > > Thanks,
> > > John
> > >
> > > On Fri, Mar 10, 2017 at 10:50 AM, Andrew Penny - NOAA Affiliate
via RT
> <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79776
>
> > > >
> > > > Hi John,
> > > >
> > > > Thanks for looking into this issue.
> > > >
> > > > I'm curious, why was it chosen to go through the bdeck at the
most
> > common
> > > > time interval instead of simply processing all available times
and
> > > matching
> > > > according to valid time? I'm not too familiar with NHC's
version of
> the
> > > > code, but I don't think it follows the same logic. I could be
wrong
> > > though.
> > > > This could continue to be an issue for shorter-lived systems
that
> have
> > a
> > > > few bdeck entries that are at off-synoptic times. Still, it's
likely
> a
> > > very
> > > > rare occurrence.
> > > >
> > > > As far as fixes go, I think what you've suggested sounds good
in
> > > > hard-coding the time interval to 6 h if we're comparing
against the
> > best
> > > > track. However, if the first time in the bdeck is at an off-
synoptic
> > > time,
> > > > will this cause issues? Instead of specifying the time
interval,
> could
> > > the
> > > > 00, 06, 12, and 18 UTC times be hard-coded?
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > >
> > > > On Thu, Mar 9, 2017 at 10:06 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Andy,
> > > > >
> > > > > Thanks for sending the test case. I ran it through met-5.2
on my
> > > machine
> > > > > and produced the exact same pair output you're getting from
> tc_pairs.
> > > > >
> > > > > I chose to focus in a single problematic point and run
tc_pairs
> > through
> > > > the
> > > > > debugger:
> > > > > For model HCCA initialized at 2015092012
> > > > >
> > > > > I found that the logic breaks down because of the irregular
spacing
> > of
> > > > the
> > > > > BEST track data. Below I've listed the first 8 columns of
the BEST
> > > > track:
> > > > > EP, 16, 2015092018, , BEST, 0, 243N, 1137W,
> > > > > EP, 16, 2015092100, , BEST, 0, 255N, 1134W,
> > > > > EP, 16, 2015092104, 45, BEST, 0, 266N, 1131W,
> > > > > EP, 16, 2015092106, , BEST, 0, 268N, 1130W,
> > > > > EP, 16, 2015092112, , BEST, 0, 283N, 1125W,
> > > > > EP, 16, 2015092113, 45, BEST, 0, 288N, 1123W,
> > > > > EP, 16, 2015092115, , BEST, 0, 292N, 1122W,
> > > > >
> > > > > The code looks for the *most common* time spacing of the
BEST
> track.
> > > It
> > > > > computes the number of seconds from one time to the next and
takes
> > the
> > > > > *mode* of those time steps. Then it uses that time step to
> progress
> > > > > through the data. If you do the math, the time step is 4500
> seconds
> > > > twice
> > > > > and 21600 seconds twice. It must just be picking the first
one of
> > > those.
> > > > > So it's stepping through the track points every 75 minutes
and just
> > > > misses
> > > > > the 12 hour forecast.
> > > > >
> > > > > I suspect that the NHC code has hard-coded the BEST track
time step
> > as
> > > 6
> > > > > hours.
> > > > >
> > > > > To test this out, I removed those two 45-minute BEST track
lines
> and
> > > > reran
> > > > > to produce the expected output from TC-Stat:
> > > > > COL_NAME: COLUMN AMODEL LEAD TOTAL VALID MEAN
> > > > > SUMMARY: TK_ERR HCCA 0000000 4 4
10.51742
> > > > > SUMMARY: TK_ERR HCCA 0120000 2 2
33.9373
> > > > > SUMMARY: TK_ERR OFCL 0000000 4 4
10.51742
> > > > > SUMMARY: TK_ERR OFCL 0120000 2 2
35.97311
> > > > > SUMMARY: TK_ERR TVCN 0000000 4 4
10.51742
> > > > > SUMMARY: TK_ERR TVCN 0120000 2 2
37.85669
> > > > >
> > > > > So now that we understand the problem, how should we fix it?
> > > > >
> > > > > We're actually using the FORTRAN code we got from NHC from
> computing
> > > the
> > > > > track errors. And that code assumes that all points are
evenly
> > spaced
> > > in
> > > > > time. So that's why we're paying attention to the time
step.
> > > > >
> > > > > Also, MET-TC can be used to compare any two arbitrary track
data
> > > sources.
> > > > > Some might have 6-hour track spacing while other could have
3, or
> > > perhaps
> > > > > even 1. So I'm leary of hard-coding anything.
> > > > >
> > > > > That being said, if we've parsed the name from the "BDECK"
file as
> > see
> > > > that
> > > > > it's "BEST"... we could hard-code the timestep to 6 hours.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 9, 2017 at 12:29 PM, Andrew Penny - NOAA
Affiliate via
> > RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > Thu Mar 09 12:29:42 2017: Request 79776 was acted upon.
> > > > > > Transaction: Ticket created by andrew.penny at noaa.gov
> > > > > > Queue: met_help
> > > > > > Subject: issue with tc_pairs number of valid cases
> > > > > > Owner: Nobody
> > > > > > Requestors: andrew.penny at noaa.gov
> > > > > > Status: new
> > > > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> > > Ticket/Display.html?id=79776
> > > > >
> > > > > >
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > When verifying EP162015, the number of valid cases is
different
> > > between
> > > > > our
> > > > > > verification package run at NHC and MET-TC, and I'm not
sure why!
> > For
> > > > > > instance, there are values in the bdeck and adeck that
should
> allow
> > > the
> > > > > > track error to be calculated for two cases at 12 h
(including
> cases
> > > > > common
> > > > > > to HCCA, OFCL, and TVCN), but tc_pairs fills in NA for the
track
> > > error,
> > > > > and
> > > > > > this results in 0 valid cases at 12 h when using tc_stat.
> > > > > >
> > > > > > Would you mind looking into this to see why the track
error is
> not
> > > > being
> > > > > > computed? I've attached a few files that I've been testing
that
> > have
> > > > been
> > > > > > thinned. Our verification package results in 4 cases at 0
h, and
> 2
> > > > cases
> > > > > at
> > > > > > 12 h.
> > > > > >
> > > > > > commands run:
> > > > > >
> > > > > > tc_pairs -adeck ./aep162015.dat -bdeck ./bep162015.dat
-config
> > > > > > ./TCPairsConfig -out ./ep162015
> > > > > > tc_stat -config TCStatConfig_TRK_ERR -lookin ep162015.tcst
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Andrew Penny
> > > > > > Hurricane Model Diagnostician
> > > > > > SRG / National Hurricane Center
> > > > > > 11691 SW 17th Street
> > > > > > Miami, FL 33165-2149
> > > > > > phone: 305.229.4457
> > > > > > email: andrew.penny at noaa.gov
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Andrew Penny
> > > > Hurricane Model Diagnostician
> > > > SRG / National Hurricane Center
> > > > 11691 SW 17th Street
> > > > Miami, FL 33165-2149
> > > > phone: 305.229.4457
> > > > email: andrew.penny at noaa.gov
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Andrew Penny
> > Hurricane Model Diagnostician
> > SRG / National Hurricane Center
> > 11691 SW 17th Street
> > Miami, FL 33165-2149
> > phone: 305.229.4457
> > email: andrew.penny at noaa.gov
> >
> >
>
>
--
Andrew Penny
Hurricane Model Diagnostician
SRG / National Hurricane Center
11691 SW 17th Street
Miami, FL 33165-2149
phone: 305.229.4457
email: andrew.penny at noaa.gov
------------------------------------------------
More information about the Met_help
mailing list