[GFS V17] Add real-time tropical cyclone QC to v17

[DavidHuber-NOAA]

Description

This adds tropical cyclone QC as a real-time capability to version 17 GFS.
Resolves #4531
Refs #4623

Type of change

• Bug fix (fixes something broken)
• New feature (adds functionality)
• Maintenance (code refactor, clean-up, new CI test, etc.)

Change characteristics

• Is this change expected to change outputs YES
  • GFS
  • GEFS
  • SFS
  • GCAFS
• Is this a breaking change (a change in existing functionality)? NO
• Does this change require a documentation update? NO
• Does this change require an update to any of the following submodules? YES
  • GFS-utils Update the W3 interface in qctropcy and bring in a v16 fix for getjtbul gfs-utils#176

How has this been tested?

Tested in a near-real-time case in develop. This test will be repeated for this PR.

Checklist

• Any dependent changes have been merged and published
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have documented my code, including function, input, and output descriptions
• My changes generate no new warnings
• New and existing tests pass with my changes
• This change is covered by an existing CI test or a new one has been added

[DavidHuber-NOAA]

Noting that in dev/gfs.v17, the syndat products coming out of the syndat_qctropcy.sh script are identical to those from GFS v16 currently in operations.

I will run a C96C48mx500_S2SW_cyc_gfs test case and verify that the products are the same against develop after updating the gfs-utils hash, then open this for review.

[DavidHuber-NOAA]

Opening for review. All tests passed on WCOSS2 and B4B comparisons of GRIB2 products for the C96C48mx500_S2SW_gfs_cyc completed successfully.

[TravisElless-NOAA]

Matches changes that were merged into develop

[DavidHuber-NOAA]

@JessicaMeixner-NOAA @CatherineThomas-NOAA @RuiyuSun A critical finding: the tcvitals file that the tropical cyclone QC job reads from is updated in place (it's a DCOM file). This means that the timing at which the QC job runs determines whether the resulting outputs of the QC job match operations. Since we do not archive this file in the GDA or anywhere else, it is currently only read from operational DCOM, making comparisons difficult. Also, if the delay is too long (e.g. the real time case runs cycle 2026032300 when the DCOM is up to 2026032412), the QC job will provide data to the GSI that is out of date and will not be included in the analysis. Currently (or if this job is disabled) this job does not run, so the prep jobs will copy the operational GFS v16 file for the analysis.

With this in mind, I'm not sure if we should enable this job in the real time retro until we start running in a para space. We may be better off running it as needed for testing purposes until that time. What do you think? Either way, the changes to the J-Job, ush scripts, and gfs-utils should be brought in. This is only a question for the s2sw_realtime.yaml‎ option.

[RussTreadon-NOAA]

Question
If we run syndat_qctropcy.sh for a past case, will we reproduce the operational syndata.tcvitals.tm00 file?

I ran gdas_prep for 2026032312 using g-w develop at c0cab10 with PROCESS_TROPCYC="YES". The resulting gdas.t12z.syndata.tcvitals.tm00 for 2026032312 wound up with

JTWC 27P NARELLE   20260324 0000 158S 1248E 250 057 0996 1003 0333 18 138 0167 -999 -999 0185 M
JTWC 28P TWENTY-EI 20260324 0000 236S 1638E 170 088 0994 1006 0463 23 083 0093 0130 0093 0074 M

The operational gdas.t12z.syndata.tcvitals.tm00 contains

JTWC 27P NARELLE   20260323 1200 151S 1268E 250 062 0994 1003 0370 18 092 0222 -999 -999 0241 S
JTWC 28P TWENTY-EI 20260323 1200 201S 1629E 175 077 0990 1005 0444 23 055 0148 0185 0111 0074 M

The file I created is wrong. The 2026032312 file cannot contain information for 2026032400.

Maybe I missed a critical g-w config setting. I don't know.

[RussTreadon-NOAA]

Thank you @DavidHuber-NOAA : You answered my question 4 minutes before I asked!

[DavidHuber-NOAA]

@RussTreadon-NOAA No, we won't match a past case as is. This is because the input file is updated in place in operations, so it always has the latest data. I opened issue #4539 to archive this data. Until we have that archive, we won't be able to replicate.

[RussTreadon-NOAA]

Thank you @DavidHuber-NOAA for confirming that for the time being we need to rely on the GDA to ensure atmospheric DA uses the correct data.

[JessicaMeixner-NOAA]

Thank you @DavidHuber-NOAA for all of your work fixing this job's issues and for your findings. Your path forward makes sense to me, but @CatherineThomas-NOAA should confirm.

[CatherineThomas-NOAA]

Thanks for digging into this @DavidHuber-NOAA. It's a tricky finding.

I agree that it's a good idea to not run this in the real time for the time being while still merging in this code to the v17 branch (with the exception of setting PROCESS_TROPCY: "NO" in s2sw_realtime.yaml). Long term, we can pull this data to the GDA so we can replicate in the future.

[DavidHuber-NOAA]

OK, sounds good. I have disabled the tropical cycle QC by default in the real time.

[CatherineThomas-NOAA]

Looks good. Thanks @DavidHuber-NOAA!