TCpairs and TCStat module in MET TC

[drmohanthota]

Recently, we have started using MET for TC verification of our model forecasts.
In brief,
W_basin_tcpairs_tcst.txt
I have both "adeck" and "bdeck" files in ATCF format

When I run the tc_pairs module I have found the below warning, Since I am new to this MET diagnostic tool I am having difficulty in understanding this error.
##########################
WARNING: TrackInfo::add(const ATCFTrackLine &) -> skipping ATCFTrackLine since the valid time is not increasing (20191123_000000 < 20191126_000000):
############################
Also, the Along track error and cross-track error columns are showing "NA" in the entire.tcst file.
why it is not computing the ATRK and CTRK errors?

[JohnHalleyGotway]

@drmohanthota I see that you have some questions about the TC-Pairs tool in MET. Thanks for sending a sample TC-Pairs output file to demonstrate.

1. What does this WARNING message mean?

WARNING: TrackInfo::add(const ATCFTrackLine &) -> skipping ATCFTrackLine since the valid time is not increasing (20191123_000000 < 20191126_000000):

The TC-Pairs tool reads each ATCF input file line-by-line. It attempts to stitch together subsequent lines into coherent storm tracks. One wrinkle is that each track point may have data on 1, 2, or 3 ATCF lines, depending on whether 34, 50, and 64 kt wind radii information is provided. This TrackInfo::is_match() function contains the logic for deciding whether the current ATCF line should be tacked onto an existing track.

If that returns TRUE, then TC-Pairs tries to add the point to that track. BUT if the valid time of the new track point is earlier than the valid time of the last track point, then this warning message is printed and that point is skipped.

So the real question is WHY does TC-Pairs try to add track points to tracks that it shouldn't?

Looking at the output you sent, I'm wondering if this is being triggered by some of the INVEST lines? The lines where INIT = NA are of particular concern. The model initialization time is part of what determines which track points go together. If TC-Pairs can't distinguish between those times, it might lead to the behavior you're seeing.

One easy test would be rerunning with all the INVEST lines stripped out. For example,

egrep -v INVEST sample_adeck.dat > no_invest_adeck.dat

And then pass that as input to TC-Pairs. Have those warning messages gone away?

We'd need to look more closely at the ATCF data to determine where those INVEST lines with INIT = NA are coming from.

2. Why are the Along and Cross-Track errors (ALTK_ERR and CRTK_ERR columns) set to NA in the output?

This one is easier. The Along and Cross-Track errors can only be computed on tracks that consist of at least 2 points. The TOTAL column indicates the number of points in the current track. You'll notice that ALTK_ERR = CRTK_ERR = NA only when TOTAL = 1. So you shouldn't be concerned about those errors. Instead we should ask why TC-Pairs isn't creating tracks the way we expect. By way of example, the first 3 lines of the output you sent are pretty suspicious!

VERSION AMODEL BMODEL DESC STORM_ID BASIN CYCLONE STORM_NAME INIT            LEAD    VALID           ... TOTAL
V10.0.0 NCUM   BEST   NA   WP062019 WP    06      DANAS      20190716_000000 000000  20190716_000000 ...     1
V10.0.0 NCUM   BEST   NA   WP062019 WP    06      DANAS      20190716_060000 060000  20190716_120000 ...     1
V10.0.0 NCUM   BEST   NA   WP062019 WP    06      DANAS      20190716_120000 120000  20190717_000000 ...     1

TC-Pairs is interpreting this as 3 separate tracks, each consisting of a single point. Note that the timestamps in the INIT column each differ by 6 hours.

Like 1., I recommend taking a close look at the ADECK data you're passing as input. I strongly suspect these points should all have the same initialization time.

By way of example, here's ATCF track data from NOAA/NHC for the first hurricane of the 2021 season. And here's a few lines of ATCF data from that file:

AL, 01, 2021052000, 03,  CMC,   0, 304N,  558W,  28, 1016, XX,  34, NEQ,    0,    0,    0,    0,
AL, 01, 2021052000, 03,  CMC,   6, 324N,  545W,  33, 1011, XX,  34, NEQ,    0,    0,    0,    0,
AL, 01, 2021052000, 03,  CMC,  12, 339N,  545W,  42, 1008, XX,  34, NEQ,  210,    0,   26,   62,

Note that all 3 lines here have the same timestamp in the 3rd column, indicating this is data for forecast hours 0, 6, and 12 of the 2021052000 initialization.

So please take a close look at your ATCF input files to look for issues. If you're still stuck or have questions about the ATCF data, please send some sample files to investigate.

[drmohanthota]

@JohnHalleyGotway Thanks for your elaborative explanation. Let me check my ATCF files and I will get back to you, thanks again

[drmohanthota]

@JohnHalleyGotway Yes, my ATCF files that I am using for input has issue with the initial time, thanks for pointing out I have corrected now and it is fine.
I have one more question regarding the TCMPR output...
There is a column in the TCMPR output named A/BDEPTH, when I looked in the user doc, it was mentioned it is the depth of the system and categorised as D-deep, S-shallow, M-medium and X-unknown
How to interpret this particular variable , does this variable indicates the vertical extent of the system? or it is the depth from ocean surface. I understand that it maybe using the central pressure. How does it computes the depth of the system and categorise?

[georgemccabe]

The discussion for the follow up question asked here was moved to discussion #1637. I am going to lock this discussion to prevent future posts. Please feel free to submit another question in another discussion if you have any other questions.