Suggest that we add a simple true/false switch to the TC-Pairs config file. However, we could implement it as a mapping of OLD ATCF ID to NEW ATCF ID, where the new track replaces any existing track for that ATCF ID/Storm/Init Time combination. That'd make adding additional replacement logic in the future very easy.
Below, I've listed the relevant contents of the met-help ticket:
I ran into another interesting aspect of verifying OFCL forecasts... it
turns out that occasionally a special forecast will be issued after the
normal advisory time if there's reason to believe a significant update to
the original forecast is needed. This ends up taking on the "OFCL" tag in
the ATCF, and the original forecast is moved to "OFCO". Up until this
point, I've simply been verifying all "OFCL" forecasts, and this isn't
correct. When there's an "OFCO", it should replace the "OFCL" for that
forecast and be verified instead. Is there any way to do this automatically
through MET-TC?
An example forecast at 2016093000 for Hurricane Matthew (AL142016) is
attached.
(1) NHC's operational forecast track is named using the AFCF ID "OFCL".
(2) If for whatever reason, NHC updates the official forecast track, they rename the original "OFCL" track as "OFCO" and name the updated track "OFCL".
(3) You would like to have the ability to verify only the original "OFCL" forecast tracks and ignore the updates.
One solution would be adding a new config file entry for the TC-Pairs tool. When turned on...
(1) For each "OFCL" track, check to see if an "OFCO" track exists for the same storm/initialization time.
(2) If so, delete the existing "OFCL" forecast and rename the "OFCO" track as "OFCL".
The reason we don't want to verify the updated forecasts is that it's not a
fair comparison when other guidance is included, since the updated forecast
was not available at the advisory time.
As far as naming goes, perhaps "use_special_OFCL" or something, with the
default being false.
[MET-803] created by johnhg
dwfncar
commented
7 years ago
This task is based on a request from Andy Penny via MET-Help:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80274
Suggest that we add a simple true/false switch to the TC-Pairs config file. However, we could implement it as a mapping of OLD ATCF ID to NEW ATCF ID, where the new track replaces any existing track for that ATCF ID/Storm/Init Time combination. That'd make adding additional replacement logic in the future very easy.
Below, I've listed the relevant contents of the met-help ticket:
I ran into another interesting aspect of verifying OFCL forecasts... it
turns out that occasionally a special forecast will be issued after the
normal advisory time if there's reason to believe a significant update to
the original forecast is needed. This ends up taking on the "OFCL" tag in
the ATCF, and the original forecast is moved to "OFCO". Up until this
point, I've simply been verifying all "OFCL" forecasts, and this isn't
correct. When there's an "OFCO", it should replace the "OFCL" for that
forecast and be verified instead. Is there any way to do this automatically
through MET-TC?
An example forecast at 2016093000 for Hurricane Matthew (AL142016) is
attached.
(1) NHC's operational forecast track is named using the AFCF ID "OFCL".
(2) If for whatever reason, NHC updates the official forecast track, they rename the original "OFCL" track as "OFCO" and name the updated track "OFCL".
(3) You would like to have the ability to verify only the original "OFCL" forecast tracks and ignore the updates.
One solution would be adding a new config file entry for the TC-Pairs tool. When turned on...
(1) For each "OFCL" track, check to see if an "OFCO" track exists for the same storm/initialization time.
(2) If so, delete the existing "OFCL" forecast and rename the "OFCO" track as "OFCL".
The reason we don't want to verify the updated forecasts is that it's not a
fair comparison when other guidance is included, since the updated forecast
was not available at the advisory time.
As far as naming goes, perhaps "use_special_OFCL" or something, with the
default being false. [MET-803] created by johnhg