[Met_help] [rt.rap.ucar.edu #76781] History for auto AVN replacement to GFS in tc_pairs and tc_stat
John Halley Gotway via RT
met_help at ucar.edu
Fri Sep 2 12:09:53 MDT 2016
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi John,
I've run into an issue with tc_pairs when trying to use a model name that
contains "AVN". We test various consensus products that are often named
according to the input models being excluded or included. Could the logic
of tc_pairs / tc_stat be changed such that "AVN" isn't automatically
replaced with "GFS"? We can definitely work around this issue by choosing
different names, but it would be great to be able to use "AVN".
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: auto AVN replacement to GFS in tc_pairs and tc_stat
From: John Halley Gotway
Time: Thu Jun 16 14:11:45 2016
Hi Andy,
It's funny that you mention that. I've always felt like that
conversion is
a bit contrived. But we were instructed to replicate the
functionality of
NHC and that's what their logic mandates.
Ideally, we'd be able to keep that conversion of AVN to GFS as the
default
behavior, but provide a way (likely through the config file) to
override it.
I can tell you that renaming is done in a single line of code... line
261
of the file atcf_line.cc:
253 ConcatString ATCFLine::technique() const {
254 ConcatString cs;
255
256 // Use Technique, if already set
257 if(Technique) cs = Technique;
258 else cs = get_item(TechniqueOffset);
259
260 // Replace instances of AVN with GFS
261 cs.replace("AVN", "GFS");
262
263 return(cs);
264 }
Commenting out that line and recompiling would provide a quick and
dirty
way to disable it for now.
I'll ask around about a better long term solution.
John
On Thu, Jun 16, 2016 at 1:57 PM, Andrew Penny - NOAA Affiliate via RT
<
met_help at ucar.edu> wrote:
>
> Thu Jun 16 13:57:22 2016: Request 76781 was acted upon.
> Transaction: Ticket created by andrew.penny at noaa.gov
> Queue: met_help
> Subject: auto AVN replacement to GFS in tc_pairs and tc_stat
> Owner: Nobody
> Requestors: andrew.penny at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76781 >
>
>
> Hi John,
>
> I've run into an issue with tc_pairs when trying to use a model name
that
> contains "AVN". We test various consensus products that are often
named
> according to the input models being excluded or included. Could the
logic
> of tc_pairs / tc_stat be changed such that "AVN" isn't automatically
> replaced with "GFS"? We can definitely work around this issue by
choosing
> different names, but it would be great to be able to use "AVN".
>
> 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: auto AVN replacement to GFS in tc_pairs and tc_stat
From: Andrew Penny - NOAA Affiliate
Time: Thu Jun 16 14:33:00 2016
Hi John,
Thanks for the workaround. One difference between the logic of
tc_pairs and
NHC's verification is that either "AVNI" or "GFSI" can be requested
and
verified (it knows to search for AVNI), it will just be output as
"GFSI".
Very confusing (and unnecessary in my opinion)!
Thanks and take care,
Andy
On Thu, Jun 16, 2016 at 4:11 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Hi Andy,
>
> It's funny that you mention that. I've always felt like that
conversion is
> a bit contrived. But we were instructed to replicate the
functionality of
> NHC and that's what their logic mandates.
>
> Ideally, we'd be able to keep that conversion of AVN to GFS as the
default
> behavior, but provide a way (likely through the config file) to
override
> it.
>
> I can tell you that renaming is done in a single line of code...
line 261
> of the file atcf_line.cc:
>
> 253 ConcatString ATCFLine::technique() const {
> 254 ConcatString cs;
> 255
> 256 // Use Technique, if already set
> 257 if(Technique) cs = Technique;
> 258 else cs = get_item(TechniqueOffset);
> 259
> 260 // Replace instances of AVN with GFS
> 261 cs.replace("AVN", "GFS");
> 262
> 263 return(cs);
> 264 }
>
> Commenting out that line and recompiling would provide a quick and
dirty
> way to disable it for now.
>
> I'll ask around about a better long term solution.
>
> John
>
>
> On Thu, Jun 16, 2016 at 1:57 PM, Andrew Penny - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > Thu Jun 16 13:57:22 2016: Request 76781 was acted upon.
> > Transaction: Ticket created by andrew.penny at noaa.gov
> > Queue: met_help
> > Subject: auto AVN replacement to GFS in tc_pairs and tc_stat
> > Owner: Nobody
> > Requestors: andrew.penny at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76781 >
> >
> >
> > Hi John,
> >
> > I've run into an issue with tc_pairs when trying to use a model
name that
> > contains "AVN". We test various consensus products that are often
named
> > according to the input models being excluded or included. Could
the logic
> > of tc_pairs / tc_stat be changed such that "AVN" isn't
automatically
> > replaced with "GFS"? We can definitely work around this issue by
choosing
> > different names, but it would be great to be able to use "AVN".
> >
> > 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
------------------------------------------------
More information about the Met_help
mailing list