METplus TCPairs problem with GSL track files

[mollybsmith-noaa]

Hi all,

I've been trying to set up a realtime workflow on Jet to use the METplus TCpairs wrapper to verify tracks from both the NHC and GSL's in-house models. With my current configuration, the NHC component is working fine, but the GSL tracks absolutely refuse to verify past FHR 000 for any day. Can you verify that there's nothing wrong about the track files? I'm not sure why the same configuration works for the NHC a-decks but not the GSL ones.

The NHC a-decks on Jet: /public/data/nhc/a-decks
The NHC b-decks on Jet: /public/data/nhc/btk
The NHC e-decks on Jet: /public/data/nhc/e-decks
The GSL a-decks on Jet: /home/rtfim/GFSv17p8_HFIP/tracks

My configuration for the GSL tracks is at /home/amb-verif/tcmet/config/metplus/TCPairs_gsl_jet_rt.conf, and the NHC one is at /home/amb-verif/tcmet/config/metplus/TCPairs_nhc_jet_rt.conf. If you diff them, the only difference is the TC_PAIRS_ADECK_TEMPLATE.

Thanks for any light you can shed on this! I've been trying all sorts of things over the last week, and am now extremely confused.

[JohnHalleyGotway]

Hi Molly, I took at look at this data on jet and have a guess as to what's going on.

In ~/John.H.Gotway/MET_Help/smith_data_20221005, I ran the following command:

tc_pairs -adeck tctrk.atcf.2022090800.gfp8.txt \
-bdeck 2022090800.bal052022.dat \
-config TCPairsConfig -v 10 -log run_tc_pairs.log

I realize that...

• tctrk.atcf.2022090800.gfp8.txt contains GFP8 forecast tracks initialized at time 2022090800. So the track for AL052022 is from 2022090800 through 2022091400.
• 2022090800.bal052022.dat contains best track data for AL052022 from 2022083012 (the beginning of the storm) through 2022090800.

So that ADECK/BDECK data we're passing to TC-Pairs only have 1 time in common, namely 2022090800, which corresponds to forecast hour 0.

I suspect the confusion is from the forecast file timestamp being the INIT TIME, while the best track file timestamp is the VALID TIME.

We can't verify forecast track points until we have the best track data sufficient to do so. Perhaps the logic could be this...

• Loop over a series of valid times.
• Run tc_pairs to pass in all best track files with the valid time in the filename. Also pass in all forecast tracks whose timestamp fall between that valid time and that valid time minus 144 hours (assuming that 144 hours is the maximum possible forecast time).
• Configure that tc_pairs run to only write output for the current valid time.

Would that work?

[mollybsmith-noaa]

Thanks for getting back to me! It sounds like this is a problem with my configuration, then.

What I'm doing is to set the time range as
INIT_BEG = <15 days before present>
INIT_END = <1 day before present>

TC_PAIRS_ADECK_TEMPLATE = tctrk.atcf.{init?fmt=%Y%m%d%H}.model.txt
TC_PAIRS_BDECK_TEMPLATE = {valid?fmt=%Y%m%d%H}.b{basin?fmt=%s}{cyclone?fmt=%s}{valid?fmt=%Y}.dat

TC_PAIRS_WRITE_VALID = <1 day before present>

From the documentation it looked like METplus would loop over that fourteen day range of init times and successfully match the a-decks, filed by init time, with the b-decks, filed by valid time, and then print the output at the specified valid time, but that doesn't seem to be the case. Will this work if I change the looping method to valid time? All of the valid times should be present in the fourteen days' model cycles, but perhaps it's not compiling them correctly?

[JohnHalleyGotway]

Sorry for the delay in responding @mollybsmith-noaa. I'd suggest scheduling a meeting with @georgemccabe and I do step through the details and clarify what is/is not working as expected. I think that'd be easier than stepping through the details in discussions.

Please feel free to schedule that if you think it'd be useful.

[mollybsmith-noaa]

Will do, then. Thanks!

[georgemccabe]

To follow up with this discussion, I met briefly with @mollybsmith-noaa. We were able to get some output and have a better idea how to adjust the configuration file to accomplish what is needed by this use case.

[mollybsmith-noaa]

Thanks to George's pointers I was able to catch the problem in the act: when the a-decks are in separate files, as with the GSL tracks, the different FHRs that come out of each a-deck overwrite each other in the output. When they’re in the same file, as with the NHC tracks, this does not appear to be an issue.