[Met_help] [rt.rap.ucar.edu #70731] History for

John Halley Gotway via RT met_help at ucar.edu
Wed Feb 18 13:13:46 MST 2015


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

Dear MET-TC,

I'm having a problem reading ATCF files for a custom model (H4HW). I have
one A-DECK ATCF file per storm. For some ATCF files (but oddly, not all of
them), TC_PAIRS is throwing an error relating to the valid time. As an
example, see this snip from my terminal window:

[image: Inline image 2]

In this particular case (EP14 - initiated on 2014090312 - Forecast Hr 000),
TC_PAIRS thinks that the valid time is not increasing. However, this is
confusing to me since is the first entry for this particular initial time
(forecast hour 000). Consequently, TC_PAIRS gives this warning for all
entries in this particular ATCF file. As a result, none of the ATCF lines
make it into the TC_PAIRS output for EP14. The EP14 ATCF file is sorted by
"initial time", and then by "forecast hour", so I'm confused about where I
went wrong. I have attached the EP14 ATCF file in question for your
reference.

On the other hand, TC_PAIRS has no problem reading the ATCF file for
another case (EP18). All of the paired ATCF lines for EP18 are printed to
the output file. I should note that I used the same merging program to
create both of these ATCF files, so there should be no structural
differences between the working case and the non-working case. I have
attached the EP18 ATCF file in question for your reference.

The B-DECK files are the BEST TRACK files from the NHC ftp site. I have
included the B-DECK ATCF files for both EP14 and EP18.

I tried to attach the TC_PAIRS output, but it exceeded the 5Mb limit. If
you'd like to see this output, I have it available so just let me know how
to get it to you.


Do you know what is causing this error? I greatly appreciate any help you
can provide on this issue. I'm not sure if it is user error or a bug in
MET-TC...

Thank you,
Gus Alaka


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

Subject: 
From: Ghassan Alaka - NOAA Affiliate
Time: Tue Feb 17 09:41:46 2015

Good morning,

I realized that I left the subject line blank in my Friday e-mail.
I've
included the appropriate subject. Sorry for the confusion.

Here is the original message:


Dear MET-TC,

I'm having a problem reading ATCF files for a custom model (H4HW). I
have
one A-DECK ATCF file per storm. For some ATCF files (but oddly, not
all of
them), TC_PAIRS is throwing an error relating to the valid time. As an
example, see this snip from my terminal window:

[image: Inline image 2]

In this particular case (EP14 - initiated on 2014090312 - Forecast Hr
000),
TC_PAIRS thinks that the valid time is not increasing. However, this
is
confusing to me since is the first entry for this particular initial
time
(forecast hour 000). Consequently, TC_PAIRS gives this warning for all
entries in this particular ATCF file. As a result, none of the ATCF
lines
make it into the TC_PAIRS output for EP14. The EP14 ATCF file is
sorted by
"initial time", and then by "forecast hour", so I'm confused about
where I
went wrong. I have attached the EP14 ATCF file in question for your
reference.

On the other hand, TC_PAIRS has no problem reading the ATCF file for
another case (EP18). All of the paired ATCF lines for EP18 are printed
to
the output file. I should note that I used the same merging program to
create both of these ATCF files, so there should be no structural
differences between the working case and the non-working case. I have
attached the EP18 ATCF file in question for your reference.

The B-DECK files are the BEST TRACK files from the NHC ftp site. I
have
included the B-DECK ATCF files for both EP14 and EP18.

Finally, I have attached the TC_PAIRS output, for your reference. As
you
can see from this output, TC_PAIRS is able to read the A-DECK ATCF
files
for EP14 for 2 other models (H3HW,HWRF) without issue.


Do you know what is causing this error? I greatly appreciate any help
you
can provide on this issue. I'm not sure if it is user error or a bug
in
MET-TC...

Thank you,
Gus Alaka

------------------------------------------------
Subject: 
From: John Halley Gotway
Time: Tue Feb 17 12:39:37 2015

Hello Gus,

Sorry for the delay in responding.  I was out of the office on Friday
and
Monday.

I ran tc_pairs with the data you sent but was unable to reproduce the
warning message you're seeing.  I tested with MET versions: 4.1
original,
4.1 + patches, 5.0 original, and 5.0 + patches.  None of them resulted
in a
WARNING message.

Have you made any changes to the source code?  What version of MET are
you
using?  Is it METv5.0 plus the latest set of patches?

Here's the command I ran and I've attached the config file I used, the
output log file, and the output tcst file:

met-5.0/bin/tc_pairs \
-adeck aep142014.h4hw.dat \
-bdeck bep142014.dat \
-config TCPairsConfig_v5.0 \
-out tc_pairs_v5.0_patch \
-log tc_pairs_v5.0_patch.log \
-v 3

Sorry I don't have a quick, easy solution for you.  We should check to
see
how the config file I used compares to yours and make sure we're
testing
the same version of the code.  After that, we could add some
additional
debug statements to the code to zero in on the problem.

Thanks,
John

On Tue, Feb 17, 2015 at 9:41 AM, Ghassan Alaka - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=70731 >
>
> Good morning,
>
> I realized that I left the subject line blank in my Friday e-mail.
I've
> included the appropriate subject. Sorry for the confusion.
>
> Here is the original message:
>
>
> Dear MET-TC,
>
> I'm having a problem reading ATCF files for a custom model (H4HW). I
have
> one A-DECK ATCF file per storm. For some ATCF files (but oddly, not
all of
> them), TC_PAIRS is throwing an error relating to the valid time. As
an
> example, see this snip from my terminal window:
>
> [image: Inline image 2]
>
> In this particular case (EP14 - initiated on 2014090312 - Forecast
Hr
> 000),
> TC_PAIRS thinks that the valid time is not increasing. However, this
is
> confusing to me since is the first entry for this particular initial
time
> (forecast hour 000). Consequently, TC_PAIRS gives this warning for
all
> entries in this particular ATCF file. As a result, none of the ATCF
lines
> make it into the TC_PAIRS output for EP14. The EP14 ATCF file is
sorted by
> "initial time", and then by "forecast hour", so I'm confused about
where I
> went wrong. I have attached the EP14 ATCF file in question for your
> reference.
>
> On the other hand, TC_PAIRS has no problem reading the ATCF file for
> another case (EP18). All of the paired ATCF lines for EP18 are
printed to
> the output file. I should note that I used the same merging program
to
> create both of these ATCF files, so there should be no structural
> differences between the working case and the non-working case. I
have
> attached the EP18 ATCF file in question for your reference.
>
> The B-DECK files are the BEST TRACK files from the NHC ftp site. I
have
> included the B-DECK ATCF files for both EP14 and EP18.
>
> Finally, I have attached the TC_PAIRS output, for your reference. As
you
> can see from this output, TC_PAIRS is able to read the A-DECK ATCF
files
> for EP14 for 2 other models (H3HW,HWRF) without issue.
>
>
> Do you know what is causing this error? I greatly appreciate any
help you
> can provide on this issue. I'm not sure if it is user error or a bug
in
> MET-TC...
>
> Thank you,
> Gus Alaka
>
>

------------------------------------------------
Subject: 
From: Ghassan Alaka - NOAA Affiliate
Time: Tue Feb 17 13:48:57 2015

Hi John,

I just did some testing and have a bit more information about this
problem.

I am using METv5.0. I am not sure if the latest set of patches are
included, as I did not install MET-TC myself. How can I check if I
have the
latest patches? I did not make any changes to the source code.

So, I ran TC_PAIRS for the H4HW model only, and I did not receive any
warning messages (like the one I sent to you earlier). However, when I
add
in another model (e.g., H3HW) from a different ATCF file, TC_PAIRS
gives
the same WARNING message that I sent to you. So, my best guess is that
there is something about these two ATCF A-DECK files that results in a
disagreement. It seems like at least some of the H4HW entries make it
into
the TCST output, but I'm not sure if these entries have been analyzed
correctly by TC_PAIRS...

I have provided the A-DECK ATCF files, the B-DECK file, the config
file,
the TCST output, and a log file. The storm ID in this case is
AL032014. I
had to compress one of the A-DECK files to fit under the attachment
limits.

What do you think?

Best,
Gus

On Tue, Feb 17, 2015 at 2:39 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Hello Gus,
>
> Sorry for the delay in responding.  I was out of the office on
Friday and
> Monday.
>
> I ran tc_pairs with the data you sent but was unable to reproduce
the
> warning message you're seeing.  I tested with MET versions: 4.1
original,
> 4.1 + patches, 5.0 original, and 5.0 + patches.  None of them
resulted in a
> WARNING message.
>
> Have you made any changes to the source code?  What version of MET
are you
> using?  Is it METv5.0 plus the latest set of patches?
>
> Here's the command I ran and I've attached the config file I used,
the
> output log file, and the output tcst file:
>
> met-5.0/bin/tc_pairs \
> -adeck aep142014.h4hw.dat \
> -bdeck bep142014.dat \
> -config TCPairsConfig_v5.0 \
> -out tc_pairs_v5.0_patch \
> -log tc_pairs_v5.0_patch.log \
> -v 3
>
> Sorry I don't have a quick, easy solution for you.  We should check
to see
> how the config file I used compares to yours and make sure we're
testing
> the same version of the code.  After that, we could add some
additional
> debug statements to the code to zero in on the problem.
>
> Thanks,
> John
>
> On Tue, Feb 17, 2015 at 9:41 AM, Ghassan Alaka - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=70731 >
> >
> > Good morning,
> >
> > I realized that I left the subject line blank in my Friday e-mail.
I've
> > included the appropriate subject. Sorry for the confusion.
> >
> > Here is the original message:
> >
> >
> > Dear MET-TC,
> >
> > I'm having a problem reading ATCF files for a custom model (H4HW).
I have
> > one A-DECK ATCF file per storm. For some ATCF files (but oddly,
not all
> of
> > them), TC_PAIRS is throwing an error relating to the valid time.
As an
> > example, see this snip from my terminal window:
> >
> > [image: Inline image 2]
> >
> > In this particular case (EP14 - initiated on 2014090312 - Forecast
Hr
> > 000),
> > TC_PAIRS thinks that the valid time is not increasing. However,
this is
> > confusing to me since is the first entry for this particular
initial time
> > (forecast hour 000). Consequently, TC_PAIRS gives this warning for
all
> > entries in this particular ATCF file. As a result, none of the
ATCF lines
> > make it into the TC_PAIRS output for EP14. The EP14 ATCF file is
sorted
> by
> > "initial time", and then by "forecast hour", so I'm confused about
where
> I
> > went wrong. I have attached the EP14 ATCF file in question for
your
> > reference.
> >
> > On the other hand, TC_PAIRS has no problem reading the ATCF file
for
> > another case (EP18). All of the paired ATCF lines for EP18 are
printed to
> > the output file. I should note that I used the same merging
program to
> > create both of these ATCF files, so there should be no structural
> > differences between the working case and the non-working case. I
have
> > attached the EP18 ATCF file in question for your reference.
> >
> > The B-DECK files are the BEST TRACK files from the NHC ftp site. I
have
> > included the B-DECK ATCF files for both EP14 and EP18.
> >
> > Finally, I have attached the TC_PAIRS output, for your reference.
As you
> > can see from this output, TC_PAIRS is able to read the A-DECK ATCF
files
> > for EP14 for 2 other models (H3HW,HWRF) without issue.
> >
> >
> > Do you know what is causing this error? I greatly appreciate any
help you
> > can provide on this issue. I'm not sure if it is user error or a
bug in
> > MET-TC...
> >
> > Thank you,
> > Gus Alaka
> >
> >
>
>

------------------------------------------------
Subject: 
From: John Halley Gotway
Time: Tue Feb 17 16:18:28 2015

Gus,

That's great.  Thanks for sending me all that data.  I am now able to
reproduce the warning messages you're seeing.  Here's an example of
the
first one:

   WARNING: TrackInfo::add(const ATCFLine &) -> skipping ATCFLine
since the
valid time is not increasing (20140801_000000 < 20140806_060000):
   WARNING: AL, 03, 2014080100, 03, H4HW, 000, 120N,  547W,  38, 1009,
XX,
34, NEQ, 0084, 0000, 0000, 0083,  -99,  -99,  59,   0,   0,    ,   0,
,   0,   0,

As a sanity check, the MET-TC code makes sure that the valid time of
the
track data doesn't go backwards in time.  This warning tells you
that's
occurring.  The very likely reason for this is that you are probably
passing tc_pairs duplicate track data.

Using grep, I see that the same track data shows up in
"aal032014.h4hw.dat"
and "aal032014_hfip_d2014_BERTHA.dat".  Try this:
   grep H4HW aal*.dat | grep 2014080100 | grep ", 000,"

aal032014.h4hw.dat:AL, 03, 2014080100, 03, H4HW, 000, 120N,  547W,
38,
1009, XX,  34, NEQ, 0084, 0000, 0000, 0083,  -99,  -99,  59,   0,   0,
,   0,    ,   0,   0,           ,  ,   ,    ,   0,   0,   0,   0,
THERMO PARAMS,   -9999,   -9999,   -9999, Y, 10, DT, -999
aal032014_hfip_d2014_BERTHA.dat:AL, 03, 2014080100, 03, H4HW, 000,
120N,
547W,  38, 1009, XX,  34, NEQ, 0084, 0000, 0000, 0083,  -99,  -99,
59,
0,   0,    ,   0,    ,   0,   0,           ,  ,   ,    ,   0,   0,
0,
0,         THERMOPARAMS, -9999 ,-9999 ,-9999 ,Y ,10 ,DT ,-999

Those 2 lines are nearly identical, except for the spelling of "THERMO
PARAMS" vs "THERMOPARAMS".

Passing tc_pairs duplicate track data results in this sort of warning.
We
actually had this same sort of problem in the DTC when setting up a
real-time verification system.  The same track data was making its way
into
multiple ATCF files.

If this really is duplicate track data, I'd suggest working on your
logic
for where/how to store the track data.  However, if the H4HW data in
the
first file actually differs from that in the second file, you do have
another option.  You can specify a model suffix to be used for each
ADECK
source, as in this example (suffix=_EXP):

/d1/johnhg/MET/MET_releases/met-5.0/bin/tc_pairs \
-adeck aal032014.h4hw.dat suffix=_EXP \
-adeck aal032014_hfip_d2014_BERTHA.dat \
-bdeck bal032014.dat \
-config TCPairsConfig_match \
-out tc_pairs_v5.0_patch \
-log tc_pairs_v5.0_patch.log -v 3

Any model names found in "aal032014.h4hw.dat" will now have _EXP
tacked
onto the end.  Note that if you're specifying a list of model names in
the
TCPairsConfig file, you'd need to also include the _EXP variants to
get
them to show up in the output.

That'll get rid of the warnings because we're storing the track data
from
the first source using a slightly different model name.  We added this
feature for users who are testing multiple versions of a model on the
same
set of storms.  They might be using the same ATCF ID in all their
output.
But this enables them to distinguish the output in tc_pairs.

Hopefully that helps clarify.

Thanks,
John



On Tue, Feb 17, 2015 at 1:48 PM, Ghassan Alaka - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=70731 >
>
> Hi John,
>
> I just did some testing and have a bit more information about this
problem.
>
> I am using METv5.0. I am not sure if the latest set of patches are
> included, as I did not install MET-TC myself. How can I check if I
have the
> latest patches? I did not make any changes to the source code.
>
> So, I ran TC_PAIRS for the H4HW model only, and I did not receive
any
> warning messages (like the one I sent to you earlier). However, when
I add
> in another model (e.g., H3HW) from a different ATCF file, TC_PAIRS
gives
> the same WARNING message that I sent to you. So, my best guess is
that
> there is something about these two ATCF A-DECK files that results in
a
> disagreement. It seems like at least some of the H4HW entries make
it into
> the TCST output, but I'm not sure if these entries have been
analyzed
> correctly by TC_PAIRS...
>
> I have provided the A-DECK ATCF files, the B-DECK file, the config
file,
> the TCST output, and a log file. The storm ID in this case is
AL032014. I
> had to compress one of the A-DECK files to fit under the attachment
limits.
>
> What do you think?
>
> Best,
> Gus
>
> On Tue, Feb 17, 2015 at 2:39 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Hello Gus,
> >
> > Sorry for the delay in responding.  I was out of the office on
Friday and
> > Monday.
> >
> > I ran tc_pairs with the data you sent but was unable to reproduce
the
> > warning message you're seeing.  I tested with MET versions: 4.1
original,
> > 4.1 + patches, 5.0 original, and 5.0 + patches.  None of them
resulted
> in a
> > WARNING message.
> >
> > Have you made any changes to the source code?  What version of MET
are
> you
> > using?  Is it METv5.0 plus the latest set of patches?
> >
> > Here's the command I ran and I've attached the config file I used,
the
> > output log file, and the output tcst file:
> >
> > met-5.0/bin/tc_pairs \
> > -adeck aep142014.h4hw.dat \
> > -bdeck bep142014.dat \
> > -config TCPairsConfig_v5.0 \
> > -out tc_pairs_v5.0_patch \
> > -log tc_pairs_v5.0_patch.log \
> > -v 3
> >
> > Sorry I don't have a quick, easy solution for you.  We should
check to
> see
> > how the config file I used compares to yours and make sure we're
testing
> > the same version of the code.  After that, we could add some
additional
> > debug statements to the code to zero in on the problem.
> >
> > Thanks,
> > John
> >
> > On Tue, Feb 17, 2015 at 9:41 AM, Ghassan Alaka - NOAA Affiliate
via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=70731 >
> > >
> > > Good morning,
> > >
> > > I realized that I left the subject line blank in my Friday e-
mail. I've
> > > included the appropriate subject. Sorry for the confusion.
> > >
> > > Here is the original message:
> > >
> > >
> > > Dear MET-TC,
> > >
> > > I'm having a problem reading ATCF files for a custom model
(H4HW). I
> have
> > > one A-DECK ATCF file per storm. For some ATCF files (but oddly,
not all
> > of
> > > them), TC_PAIRS is throwing an error relating to the valid time.
As an
> > > example, see this snip from my terminal window:
> > >
> > > [image: Inline image 2]
> > >
> > > In this particular case (EP14 - initiated on 2014090312 -
Forecast Hr
> > > 000),
> > > TC_PAIRS thinks that the valid time is not increasing. However,
this is
> > > confusing to me since is the first entry for this particular
initial
> time
> > > (forecast hour 000). Consequently, TC_PAIRS gives this warning
for all
> > > entries in this particular ATCF file. As a result, none of the
ATCF
> lines
> > > make it into the TC_PAIRS output for EP14. The EP14 ATCF file is
sorted
> > by
> > > "initial time", and then by "forecast hour", so I'm confused
about
> where
> > I
> > > went wrong. I have attached the EP14 ATCF file in question for
your
> > > reference.
> > >
> > > On the other hand, TC_PAIRS has no problem reading the ATCF file
for
> > > another case (EP18). All of the paired ATCF lines for EP18 are
printed
> to
> > > the output file. I should note that I used the same merging
program to
> > > create both of these ATCF files, so there should be no
structural
> > > differences between the working case and the non-working case. I
have
> > > attached the EP18 ATCF file in question for your reference.
> > >
> > > The B-DECK files are the BEST TRACK files from the NHC ftp site.
I have
> > > included the B-DECK ATCF files for both EP14 and EP18.
> > >
> > > Finally, I have attached the TC_PAIRS output, for your
reference. As
> you
> > > can see from this output, TC_PAIRS is able to read the A-DECK
ATCF
> files
> > > for EP14 for 2 other models (H3HW,HWRF) without issue.
> > >
> > >
> > > Do you know what is causing this error? I greatly appreciate any
help
> you
> > > can provide on this issue. I'm not sure if it is user error or a
bug in
> > > MET-TC...
> > >
> > > Thank you,
> > > Gus Alaka
> > >
> > >
> >
> >
>
>

------------------------------------------------
Subject: 
From: Ghassan Alaka - NOAA Affiliate
Time: Wed Feb 18 11:08:51 2015

Hi John,

Thank you so much! That makes complete sense. I thought I did a check
for
"H4HW" in the 2nd ATCF file (aal032014_hfip_d2014_BERTHA.dat), to make
sure
that particular model ID was not taken. Looks like I missed it.

Have a good one,
Gus

On Tue, Feb 17, 2015 at 6:18 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Gus,
>
> That's great.  Thanks for sending me all that data.  I am now able
to
> reproduce the warning messages you're seeing.  Here's an example of
the
> first one:
>
>    WARNING: TrackInfo::add(const ATCFLine &) -> skipping ATCFLine
since the
> valid time is not increasing (20140801_000000 < 20140806_060000):
>    WARNING: AL, 03, 2014080100, 03, H4HW, 000, 120N,  547W,  38,
1009, XX,
> 34, NEQ, 0084, 0000, 0000, 0083,  -99,  -99,  59,   0,   0,    ,
0,
> ,   0,   0,
>
> As a sanity check, the MET-TC code makes sure that the valid time of
the
> track data doesn't go backwards in time.  This warning tells you
that's
> occurring.  The very likely reason for this is that you are probably
> passing tc_pairs duplicate track data.
>
> Using grep, I see that the same track data shows up in
"aal032014.h4hw.dat"
> and "aal032014_hfip_d2014_BERTHA.dat".  Try this:
>    grep H4HW aal*.dat | grep 2014080100 | grep ", 000,"
>
> aal032014.h4hw.dat:AL, 03, 2014080100, 03, H4HW, 000, 120N,  547W,
38,
> 1009, XX,  34, NEQ, 0084, 0000, 0000, 0083,  -99,  -99,  59,   0,
0,
> ,   0,    ,   0,   0,           ,  ,   ,    ,   0,   0,   0,   0,
> THERMO PARAMS,   -9999,   -9999,   -9999, Y, 10, DT, -999
> aal032014_hfip_d2014_BERTHA.dat:AL, 03, 2014080100, 03, H4HW, 000,
120N,
> 547W,  38, 1009, XX,  34, NEQ, 0084, 0000, 0000, 0083,  -99,  -99,
59,
> 0,   0,    ,   0,    ,   0,   0,           ,  ,   ,    ,   0,   0,
0,
> 0,         THERMOPARAMS, -9999 ,-9999 ,-9999 ,Y ,10 ,DT ,-999
>
> Those 2 lines are nearly identical, except for the spelling of
"THERMO
> PARAMS" vs "THERMOPARAMS".
>
> Passing tc_pairs duplicate track data results in this sort of
warning.  We
> actually had this same sort of problem in the DTC when setting up a
> real-time verification system.  The same track data was making its
way into
> multiple ATCF files.
>
> If this really is duplicate track data, I'd suggest working on your
logic
> for where/how to store the track data.  However, if the H4HW data in
the
> first file actually differs from that in the second file, you do
have
> another option.  You can specify a model suffix to be used for each
ADECK
> source, as in this example (suffix=_EXP):
>
> /d1/johnhg/MET/MET_releases/met-5.0/bin/tc_pairs \
> -adeck aal032014.h4hw.dat suffix=_EXP \
> -adeck aal032014_hfip_d2014_BERTHA.dat \
> -bdeck bal032014.dat \
> -config TCPairsConfig_match \
> -out tc_pairs_v5.0_patch \
> -log tc_pairs_v5.0_patch.log -v 3
>
> Any model names found in "aal032014.h4hw.dat" will now have _EXP
tacked
> onto the end.  Note that if you're specifying a list of model names
in the
> TCPairsConfig file, you'd need to also include the _EXP variants to
get
> them to show up in the output.
>
> That'll get rid of the warnings because we're storing the track data
from
> the first source using a slightly different model name.  We added
this
> feature for users who are testing multiple versions of a model on
the same
> set of storms.  They might be using the same ATCF ID in all their
output.
> But this enables them to distinguish the output in tc_pairs.
>
> Hopefully that helps clarify.
>
> Thanks,
> John
>
>
>
> On Tue, Feb 17, 2015 at 1:48 PM, Ghassan Alaka - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=70731 >
> >
> > Hi John,
> >
> > I just did some testing and have a bit more information about this
> problem.
> >
> > I am using METv5.0. I am not sure if the latest set of patches are
> > included, as I did not install MET-TC myself. How can I check if I
have
> the
> > latest patches? I did not make any changes to the source code.
> >
> > So, I ran TC_PAIRS for the H4HW model only, and I did not receive
any
> > warning messages (like the one I sent to you earlier). However,
when I
> add
> > in another model (e.g., H3HW) from a different ATCF file, TC_PAIRS
gives
> > the same WARNING message that I sent to you. So, my best guess is
that
> > there is something about these two ATCF A-DECK files that results
in a
> > disagreement. It seems like at least some of the H4HW entries make
it
> into
> > the TCST output, but I'm not sure if these entries have been
analyzed
> > correctly by TC_PAIRS...
> >
> > I have provided the A-DECK ATCF files, the B-DECK file, the config
file,
> > the TCST output, and a log file. The storm ID in this case is
AL032014. I
> > had to compress one of the A-DECK files to fit under the
attachment
> limits.
> >
> > What do you think?
> >
> > Best,
> > Gus
> >
> > On Tue, Feb 17, 2015 at 2:39 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Hello Gus,
> > >
> > > Sorry for the delay in responding.  I was out of the office on
Friday
> and
> > > Monday.
> > >
> > > I ran tc_pairs with the data you sent but was unable to
reproduce the
> > > warning message you're seeing.  I tested with MET versions: 4.1
> original,
> > > 4.1 + patches, 5.0 original, and 5.0 + patches.  None of them
resulted
> > in a
> > > WARNING message.
> > >
> > > Have you made any changes to the source code?  What version of
MET are
> > you
> > > using?  Is it METv5.0 plus the latest set of patches?
> > >
> > > Here's the command I ran and I've attached the config file I
used, the
> > > output log file, and the output tcst file:
> > >
> > > met-5.0/bin/tc_pairs \
> > > -adeck aep142014.h4hw.dat \
> > > -bdeck bep142014.dat \
> > > -config TCPairsConfig_v5.0 \
> > > -out tc_pairs_v5.0_patch \
> > > -log tc_pairs_v5.0_patch.log \
> > > -v 3
> > >
> > > Sorry I don't have a quick, easy solution for you.  We should
check to
> > see
> > > how the config file I used compares to yours and make sure we're
> testing
> > > the same version of the code.  After that, we could add some
additional
> > > debug statements to the code to zero in on the problem.
> > >
> > > Thanks,
> > > John
> > >
> > > On Tue, Feb 17, 2015 at 9:41 AM, Ghassan Alaka - NOAA Affiliate
via RT
> <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=70731
>
> > > >
> > > > Good morning,
> > > >
> > > > I realized that I left the subject line blank in my Friday e-
mail.
> I've
> > > > included the appropriate subject. Sorry for the confusion.
> > > >
> > > > Here is the original message:
> > > >
> > > >
> > > > Dear MET-TC,
> > > >
> > > > I'm having a problem reading ATCF files for a custom model
(H4HW). I
> > have
> > > > one A-DECK ATCF file per storm. For some ATCF files (but
oddly, not
> all
> > > of
> > > > them), TC_PAIRS is throwing an error relating to the valid
time. As
> an
> > > > example, see this snip from my terminal window:
> > > >
> > > > [image: Inline image 2]
> > > >
> > > > In this particular case (EP14 - initiated on 2014090312 -
Forecast
> Hr
> > > > 000),
> > > > TC_PAIRS thinks that the valid time is not increasing.
However, this
> is
> > > > confusing to me since is the first entry for this particular
initial
> > time
> > > > (forecast hour 000). Consequently, TC_PAIRS gives this warning
for
> all
> > > > entries in this particular ATCF file. As a result, none of the
ATCF
> > lines
> > > > make it into the TC_PAIRS output for EP14. The EP14 ATCF file
is
> sorted
> > > by
> > > > "initial time", and then by "forecast hour", so I'm confused
about
> > where
> > > I
> > > > went wrong. I have attached the EP14 ATCF file in question for
your
> > > > reference.
> > > >
> > > > On the other hand, TC_PAIRS has no problem reading the ATCF
file for
> > > > another case (EP18). All of the paired ATCF lines for EP18 are
> printed
> > to
> > > > the output file. I should note that I used the same merging
program
> to
> > > > create both of these ATCF files, so there should be no
structural
> > > > differences between the working case and the non-working case.
I have
> > > > attached the EP18 ATCF file in question for your reference.
> > > >
> > > > The B-DECK files are the BEST TRACK files from the NHC ftp
site. I
> have
> > > > included the B-DECK ATCF files for both EP14 and EP18.
> > > >
> > > > Finally, I have attached the TC_PAIRS output, for your
reference. As
> > you
> > > > can see from this output, TC_PAIRS is able to read the A-DECK
ATCF
> > files
> > > > for EP14 for 2 other models (H3HW,HWRF) without issue.
> > > >
> > > >
> > > > Do you know what is causing this error? I greatly appreciate
any help
> > you
> > > > can provide on this issue. I'm not sure if it is user error or
a bug
> in
> > > > MET-TC...
> > > >
> > > > Thank you,
> > > > Gus Alaka
> > > >
> > > >
> > >
> > >
> >
> >
>
>

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


More information about the Met_help mailing list