@DavidHuber-NOAA @TravisElless-NOAA - I see that the shfmt scan failed. I've looked into this but it doesn't appear related to this PR. Can you confirm if that's true or not.

I have previously run a case with all output on. To avoid having to re-run a forecast, I am copying over the com products folder to original.products after this completes, I will use the code here to re-run the meta tasks gfs_awips_20km_1p0deg to see the effect of these changes on a single cycle high resolution run.

Hopefully then we can finally have our answer about the SBN that is needed.

Do any files need to be deleted from the COM directory before this re-run for a successful re-run? Do others see other flaws in this test process?

@ChristopherHill-NOAA - You said you ran CI on this for technical testing, do you have the output of that to share?

@JessicaMeixner-NOAA You are correct. It's not related to this PR. I'll open a separate PR to resolve this.

Original products can be found in:
/lfs/h2/emc/ptmp/jessica.meixner/comroot/prod01/gfs.20260305/06/original.productsoriginal.products

Running with the two line change from Chris, the output can be found at:
/lfs/h2/emc/ptmp/jessica.meixner/comroot/prod01/gfs.20260305/06/products

All gfs_awips_20km_1p0deg were rerun.

9.1G original.products/atmos/wmo
9.0G products/atmos/wmo/

This at least has trended in the correct direction.

We do need to confirm that the packing was applied and that quality of the output is acceptable.

A spot check of output from the grib_util/bin/degrib2 function for the original and new products from cycle 2026030506 shows differences only with 1) Section 0 record size value, and 2) values within the Data Representation (or DRS) template - each of which is described in #4614. The degrib2 output includes minimum, maximum, and average values for each variable - with no differences observed with these values between the original and new versions of select products.

Sample degrib2 output for original.products/atmos/wmo/grib2.awpgfs_20km_conus_f072, products/atmos/wmo/grib2.awpgfs_20km_conus_f072

Values of the total volume of operational products for 2026030506 from v16.3, original products from v17, and newly generated products from v17 are shown below, and entered in this spreadsheet:

v16.3 9287.98 MB | orig. v17 9423.79 MB | new v17 9356.20 MB
The difference of product volume between new v17 from original v17: -67.59 MB
The difference of product volume between new v17 from v16.3: +68.22 MB

The greatest value of v16.3 SBN product volume observed over the past week was 9336.94 MB, from cycle 2026031012.

@ChristopherHill-NOAA - does your decrease in volume size also account for the files that are being removed? I believe we were going to have about 70 MB from removed files?

The total volume values include xtrn.awpgfs* files for v16.3, which are scheduled to be removed and are not being generating with v17. Assuming we are having to reduce SBN product volume for v17 against the same cycle for v16, then a further reduction of 70 MB would be needed in the case of 2026030506. If there is otherwise a hard limit volume (e.g. 9400 MB) to be met, that would be easier to reconcile.

As noted with #4614, I will try different versions of g2lib for potentially reducing product volume.

Our goal for SBN is to be neutral or decreased from GFSv16.

As discussed in #4614, the initially committed code change to exgfs_atmos_awips_20km_1p00.sh in this PR did not result in an adequate reduction of the SBN product volume and prompted additional action. The latest committed change restores the wgrib2 -set_grib_type same to the WGRIB2 generation of the product file and adds the wgrib2 -set_grib_type complex2 statement after product generation.

From a spot test of the relevant segment of code with F024 GRIB2 files generated by retrov17_01_realtime run of cycle 2026030506, the original, first commit, and second commit product file sizes (in bytes) are as follows:

product                       |  original |1st commit | 2nd commit
grib2.awpgfs_20km_ak_f024     |  13975428 |  13905757 |  13787115
grib2.awpgfs_20km_conus_f024  |  21132785 |  20969252 |  20768071
grib2.awpgfs_20km_pac_f024    | 122661267 | 122482405 | 121880110
grib2.awpgfs_20km_prico_f024  |  13642174 |  13013060 |  12893948
grib2.awpgfs024.003           |   6953598 |   6749455 |   6745135

When expanding these results to a hypothetical full forecast range for each product, which is 40 forecast hours for the '003' grid and 54 forecast hours for the other grids, the file size values (in MB) become:

product                       |  original |1st commit | 2nd commit
grib2.awpgfs_20km_ak_fFFF     |   719.712 |   716.124 |   710.015
grib2.awpgfs_20km_conus_fFFF  |  1088.305 |  1079.883 |  1069.523
grib2.awpgfs_20km_pac_fFFF    |  6316.861 |  6307.649 |  6276.632
grib2.awpgfs_20km_prico_fFFF  |   702.550 |   670.152 |   664.018
grib2.awpgfsFFF.003           |   265.259 |   257.471 |   257.306
						
total	                      |  9092.687 |  9031.280 |  8977.494
difference                    |           |   -61.407 |  -115.193

A partial workflow test, similar to one conducted on March 12, may help to confirm the volume reduction of a full cycle of SBN products that are stored to $COMROOT/{date}/{cycle}/products/atmos/wmo when incorporating the latest change to exgfs_atmos_awips_20km_1p00.sh.

According to degrib2 output, the addition of 'undefined' values for a PV-coordinate variables (and cloud-layer PRES) corresponds to an increase of the listed number of data points available for the variable to the maximum number available for any variable, but with no change to the calculated minimum, maximum, or average values.

In the case of the F024 CONUS grid product (grib.awpgfs_20km_conus_f024), the number of available data points for PV-coordinate variables is increased to the maximum of 94833.

The degrib2 output for the F024 sample of original products and new products are available here:

grib2_awpgfs_003_f024_new_degrib2.txt
grib2_awpgfs_003_f024_orig_degrib2.txt
grib2_awpgfs_20km_ak_f024_new_degrib2.txt
grib2_awpgfs_20km_ak_f024_orig_degrib2.txt
grib2_awpgfs_20km_conus_f024_new_degrib2.txt
grib2_awpgfs_20km_conus_f024_orig_degrib2.txt
grib2_awpgfs_20km_pac_f024_new_degrib2.txt
grib2_awpgfs_20km_pac_f024_orig_degrib2.txt
grib2_awpgfs_20km_prico_f024_new_degrib2.txt
grib2_awpgfs_20km_prico_f024_orig_degrib2.txt

@JessicaMeixner-NOAA Apologies for the multiple commits, as I should have made and pushed the changes from WCOSS. The most recent commit of code should be ready for your testing.

Updated output is here: /lfs/h2/emc/ptmp/jessica.meixner/comroot/prod01/gfs.20260305/06/products

The original v17 products are in original.products -- I forgot to copy over the first test of this PR, so I do not have that.

The SBN product size spreadsheet is updated to reflect the latest workflow test with the code changes newly committed to this PR. A summary of volume values (MB) for cycle 2026030506 is provided here:

totals
      v16      | v17 original  | v17 1st commit  | v17 2nd commit
  9287.95      |      9423.90  |        9356.31  |        9304.87
						
difference            +135.95  |         +68.36  |         +16.92
from v16

In addition to the grib2.awpsgfs* files ...

... the volume for v16 includes gfs_collective#.postsnd_{CC} files (178.95 MB), xtrn.awpgfs* files (70.93 MB), as well as gfs_500_hgt_tmp_nh_anl_{CC}.tif (0.11 MB) and tran.fbwnd_pacific.gfs_atmos_fbwind_{CC} (0.01 MB)

... the volumes for v17 include products/atmos/bufr/gfs_collective#.fil files (178.95 MB) and gfs_500_hgt_tmp_nh_anl_{CC}.tif (0.11 MB) and gfs.atmos.t{CC}z.fbwind.pacific.ascii (<0.01 MB)

.
The difference of +16.92 MB is significantly less than the standard deviation (68.87 MB) of the v16 product volume from 70 recent cycles.

@ChristopherHill-NOAA I suggest to combine compression switch with the interpolation process. You might also test the overall runtime, as these SBN data file generation could have impact data dissemination latency via SBN in GFS operation.

@ChristopherHill-NOAA Thanks for your work on this. I agree with @WenMeng-NOAA 's suggestion to combine the -set_grib_type complex2 command with the wgrib2 interpolation step - it should have the same effect as doing the compression in a separate command.

@ChristopherHill-NOAA - I will re-run after any code changes requested by @WenMeng-NOAA and @BenjaminBlake-NOAA

In the meantime, I wanted to let you know that the regression tests failed for one test due to large gempak log files which was also reported here: #3630 (comment)

I will not finish running the regression tests until the code changes have been confirmed. I'll also re-run the high resolution tests to confirm any code changes are not unintentionally changing output sizes.

I appreciate the review and comments provided by @WenMeng-NOAA.

Please note that the original code commit had attempted to constrain the setting of -set_grib_type complex2 to the existing call to wgrib2 within the 'opt1' and 'opt1uv' options, which resulted in approximately half the compression now afforded by the latest code commit that features a second call to wgrib2 with the complex2 attribute.

Does wgrib2 apply each of the options (opt1 ... opt28) to the data file in a sequential order, or all at once?

@ChristopherHill-NOAA Thanks for clarifying about the latest code commit which provides more compression.

I believe wgrib2 applies each of the options sequentially, in the order they are listed.

@BenjaminBlake-NOAA Thanks for your input.

@JessicaMeixner-NOAA I will perform another short offline test based on comments from @WenMeng-NOAA and @BenjaminBlake-NOAA to verify the effect of the proposed changes, and report back. I will update this PR again by 12pm.

I appreciate the review and comments provided by @WenMeng-NOAA.

Please note that the original code commit had attempted to constrain the setting of -set_grib_type complex2 to the existing call to wgrib2 within the 'opt1' and 'opt1uv' options, which resulted in approximately half the compression now afforded by the latest code commit that features a second call to wgrib2 with the complex2 attribute.

Does wgrib2 apply each of the options (opt1 ... opt28) to the data file in a sequential order, or all at once?

@ChristopherHill-NOAA Thanks for catching opt1, which keep the same compression from pgrb2 files. Would you try to modify opt1 as "-set_grib_type complex2" and no need opt28?

Thanks @ChristopherHill-NOAA - Just ping me when you are ready for me to re-test anything.

@ChristopherHill-NOAA Thanks for catching opt1, which keep the same compression from pgrb2 files. Would you try to modify opt1 as "-set_grib_type complex2" and no need opt28?

@WenMeng-NOAA Yes -- both opt1 and opt1uv were set with -set_grib_type complex2 in the first commit, and this configuration was tested in Jessica's workflow test on March 12, which revealed that compression of the GRIB2 SBN products was not sufficient. A second workflow test on March 19 used the current commit and featured a more optimal level of compression for the SBN products.

In my earlier testing, I did not try -set_grib_type complex2-bitmap as a wgrib2 option, and I am testing this option now.

@ChristopherHill-NOAA Thanks for catching opt1, which keep the same compression from pgrb2 files. Would you try to modify opt1 as "-set_grib_type complex2" and no need opt28?

@WenMeng-NOAA Yes -- both opt1 and opt1uv were set with -set_grib_type complex2 in the first commit, and this configuration was tested in Jessica's workflow test on March 12, which revealed that compression of the GRIB2 SBN products was not sufficient. A second workflow test on March 19 used the current commit and featured a more optimal level of compression for the SBN products.

In my earlier testing, I did not try -set_grib_type complex2-bitmap as a wgrib2 option, and I am testing this option now.

@ChristopherHill-NOAA The option 'complex2-bitmap' should pack additional bites than 'complex2', as bitmap applied.

After reviewing settings in this exgfs_atmos_awips_20km_1pdeg.sh, it appears to me that opt1uv is applied in CONUS and AK interpolations, and opt1 is applied to PNCO, PAC and 003 interpolations. Would you test to change compression in opt1 and optuv, as the goal is reducing overall data volume and keep the comparable data quality? The final solution may depend on testing.

A new series of offline tests was performed with GFSv17 F024 GRIB2 files from cycle 2026032200. SBN product files were generated with the 1st code commit and the "2nd" code commit. Product files were also generated from two new tests that invoke the wgrib2 option -set_grib_type complex2-bitmap 1) in a second call to wgrib2 after product file generation [c2b_test1] and 2) in the original call to wgrib2 to generate the product file [c2b_test2] . Product file sizes (bytes) are provided here in comparison to the v17 original v17 product size:

file size (btyes)
SBN product                   |  original |1st commit | 2nd commit | c2b_test1  | c2b_test2
grib2.awpgfs_20km_ak_f024     |  14349081 |  14297766 |  14207937  |  14312666  |  14297766
grib2.awpgfs_20km_conus_f024  |  20876547 |  20737602 |  20581263  |  20769533  |  20737602
grib2.awpgfs_20km_pac_f024    | 123658012 | 123657885 | 122999242  | 123876096  | 123657885
grib2.awpgfs_20km_prico_f024  |  13814806 |  13292298 |  13169899  |  13314444  |  13292298
grib2.awpgfs024.003           |   7067799 |   6844343 |   6840023  |   6840023  |   6844343
total                         | 179766245 | 178829894 | 177798364  | 179112762  | 178829894

file size difference (bytes) from original
SBN product                   |  original |1st commit | 2nd commit | c2b_test1  | c2b_test2
grib2.awpgfs_20km_ak_f024     |         0 |    -51315 |    -141144 |     -36415 |    -51315
grib2.awpgfs_20km_conus_f024  |         0 |   -138945 |    -295284 |    -107014 |   -138945
grib2.awpgfs_20km_pac_f024    |         0 |      -127 |    -658770 |     218084 |      -127
grib2.awpgfs_20km_prico_f024  |         0 |   -522508 |    -644907 |    -500362 |   -522508
grib2.awpgfs024.003           |         0 |   -223456 |    -227776 |    -227776 |   -223456
total                         |         0 |   -936351 |   -1967881 |    -653483 |   -936351

The use of -set_grib_type complex2-bitmap in the c2b_test1 and c2b_test2 cases provides some compression, with its application in the product-generating call [c2b_test2] to wgrib2 being more effective than in a second call to wgrib2 [c2b_test1]. The c2b_test1 provides less compression compared with the first code commit. However, the c2b_test2 provides only equivalent - and therefore inadequate - compression when compared with the first code commit.

From the limited results above, the current commit of code to this PR remains the most effective option to compress SBN product volume, and is recommended for satisfying NCO's requirement to reduce SBN product volume.

For thoroughness of testing, degrib2 output are included to represent all of the product files referenced above:
grib2_awpgfs_003_f024_c2b-test1_2026032200_degrib2.txt
grib2_awpgfs_003_f024_c2b-test2_2026032200_degrib2.txt
grib2_awpgfs_003_f024_cmt1_2026032200_degrib2.txt
grib2_awpgfs_003_f024_cmt2_2026032200_degrib2.txt
grib2_awpgfs_003_f024_orig_2026032200_degrib2.txt
grib2_awpgfs_20km_ak_f024_c2b-test1_2026032200_degrib2.txt
grib2_awpgfs_20km_ak_f024_c2b-test2_2026032200_degrib2.txt
grib2_awpgfs_20km_ak_f024_cmt1_2026032200_degrib2.txt
grib2_awpgfs_20km_ak_f024_cmt2_2026032200_degrib2.txt
grib2_awpgfs_20km_ak_f024_orig_2026032200_degrib2.txt
grib2_awpgfs_20km_conus_f024_c2b-test1_2026032200_degrib2.txt
grib2_awpgfs_20km_conus_f024_c2b-test2_2026032200_degrib2.txt
grib2_awpgfs_20km_conus_f024_cmt1_2026032200_degrib2.txt
grib2_awpgfs_20km_conus_f024_cmt2_2026032200_degrib2.txt
grib2_awpgfs_20km_conus_f024_orig_2026032200_degrib2.txt
grib2_awpgfs_20km_pac_f024_c2b-test1_2026032200_degrib2.txt
grib2_awpgfs_20km_pac_f024_c2b-test2_2026032200_degrib2.txt
grib2_awpgfs_20km_pac_f024_cmt1_2026032200_degrib2.txt
grib2_awpgfs_20km_pac_f024_cmt2_2026032200_degrib2.txt
grib2_awpgfs_20km_pac_f024_orig_2026032200_degrib2.txt
grib2_awpgfs_20km_prico_f024_c2b-test1_2026032200_degrib2.txt
grib2_awpgfs_20km_prico_f024_c2b-test2_2026032200_degrib2.txt
grib2_awpgfs_20km_prico_f024_cmt1_2026032200_degrib2.txt
grib2_awpgfs_20km_prico_f024_cmt2_2026032200_degrib2.txt
grib2_awpgfs_20km_prico_f024_orig_2026032200_degrib2.txt

It is observed from the degrib2 output that . . .
The use of -set_grib_type complex2-bitmap in a second call of wgrib2 [c2b_test1] has the effect of assigning undefined field values (specifically with PV-coordinate TMP and WEASD) with a bitmap representation, which causes an expansion of the product size.

Conversely, the use of -set_grib_type complex2 in a second call of wgrib2 [2nd commit] has the effect of removing the bitmap representation of undefined values for PV-coordinate HGT, PRES, UGRD, and VGRD fields and the time-averaged cloud level field, contributing to an overall decrease of the product size.

No changes are observed with the degrib2-calculated values of a field's minimum, maximum, or average from any file size modification performed with -set_grib_type.

@ChristopherHill-NOAA - I will wait for reviews from @BenjaminBlake-NOAA and @WenMeng-NOAA before either finishing the current set of CI testing or retesting CI + high res testing.

@ChristopherHill-NOAA Thanks for completing these tests. @JessicaMeixner-NOAA I suggest we go with Chris's recommendation as it is the most effective option for reducing the file sizes.

@ChristopherHill-NOAA Should we expect a new commit for review, or is the current commit sufficient?

@ChristopherHill-NOAA Should we expect a new commit for review, or is the current commit sufficient?

No other code commits are planned with this PR. The current commit is open to review.

I approved the PR, as no new commit has been made since 03/19/2026. I assume the current commit solves SBN data issue.

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C48_ATM_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202103231200        Done    Mar 20 2026 20:50:08    Mar 20 2026 22:05:40

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C48mx500_3DVarAOWCDA_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202103241800        Done    Mar 20 2026 20:50:14    Mar 20 2026 21:10:27
202103250000        Done    Mar 20 2026 20:50:14    Mar 20 2026 22:35:16

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C48mx500_hybAOWCDA_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202103241800        Done    Mar 20 2026 20:51:00    Mar 20 2026 21:15:55
202103250000        Done    Mar 20 2026 20:51:00    Mar 20 2026 22:45:59

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C48_S2SW_extended_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202103231200        Done    Mar 20 2026 20:50:48    Mar 20 2026 23:40:35
202103231800        Done    Mar 20 2026 20:50:48    Mar 20 2026 23:25:50

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C96_atm3DVar_extended_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202112201800        Done    Mar 20 2026 20:50:49    Mar 20 2026 21:15:43
202112210000        Done    Mar 20 2026 20:50:49    Mar 21 2026 01:55:46
202112210600        Done    Mar 20 2026 20:50:49    Mar 24 2026 13:33:54
202112211200        Done    Mar 20 2026 21:20:12    Mar 21 2026 04:15:52
202112211800        Done    Mar 21 2026 02:00:56    Mar 21 2026 06:55:40

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C96C48_hybatmDA_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202112201800        Done    Mar 20 2026 20:50:17    Mar 20 2026 21:15:22
202112210000        Done    Mar 20 2026 20:50:17    Mar 20 2026 23:15:33
202112210600        Done    Mar 20 2026 20:50:17    Mar 20 2026 23:15:33

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C96C48_hybatmsnowDA_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202112201200        Done    Mar 20 2026 20:50:19    Mar 20 2026 21:10:23
202112201800        Done    Mar 20 2026 20:50:19    Mar 20 2026 23:10:24
202112210000        Done    Mar 20 2026 20:50:19    Mar 20 2026 23:10:24

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C96C48_hybatmsoilDA_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202205150600        Done    Mar 20 2026 20:50:53    Mar 20 2026 21:16:02
202205151200        Done    Mar 20 2026 20:50:53    Mar 20 2026 23:45:38
202205151800        Done    Mar 20 2026 20:50:53    Mar 20 2026 23:35:47

******** /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/EXPDIR/C96C48mx500_S2SW_cyc_gfs_sbn00 ********
   CYCLE         STATE           ACTIVATED              DEACTIVATED     
202112201200        Done    Mar 20 2026 20:50:17    Mar 20 2026 21:15:20
202112201800        Done    Mar 20 2026 20:50:17    Mar 20 2026 23:50:31
202112210000        Done    Mar 20 2026 20:50:17    Mar 21 2026 00:10:26
202112211800        Done    Mar 20 2026 21:20:22    Mar 21 2026 00:20:29

CI testing on WCOSS2 completed after copying a few gempak logs that were too large to not be htar'd. I did not run on gaea as the job in question is just a wcoss2 job.

Thanks @JessicaMeixner-NOAA for your test. @ChristopherHill-NOAA can you check Jessica's test and confirm that the new sbn product size is satisfactory?
I did a quick check :
du -sh /lfs/h2/emc/couple/noscrub/jessica.meixner/pr4649/RUNTESTS/COMROOT/C96_atm3DVar_extended_sbn00/gfs.20211221/00/products/atmos/wmo:
7.0 G

Is this what is expected?
From what we have in GFSv16 ops right now:
du -sh /lfs/h1/ops/prod/com/gfs/v16.3/gfs.20260323/00/atmos/wmo/
8.9G

But I'm not sure if this is the exact apple to apple comparison. There have been so many emails and github comments on this issue that I have lost track of things. @ChristopherHill-NOAA Can you please provide a final report on what the SBN size is?

Thanks,
Saeideh

The CI test from @JessicaMeixner-NOAA demonstrates that the PR changes are not adversely affecting the system in a quickly-paced, low-resolution C96_atm3DVar_extended_sbn00 run of GFSv17. The resulting product files in products/atmos/wmo are relatively small due to the low resolution configuration of the model. The GEMPAK errors arising in the two of the gfs_gempak_f###-f###.log files from this CI test are being analyzed in support of #3630, and will be addressed there.

A full resolution (single cycle) test will demonstrate both the effectiveness of the compression and packing introduced by the PR as well as the wall time necessary for jgfs_atmos_awips_master.ecf to complete. The current time allocation of 10 minutes should be more than enough to allow for generation and compression of SBN products for each forecast hour increment.

The time needed to generate all 5 SBN products for F024 of 2026032200 in an offline test on an interactive node of WCOSS Cactus using the current commit changes to exgfs_atmos_awips_20km_1p0deg.sh was 22 seconds (or 13%) longer than was needed without the changes in a separate offline test. The first commit to this PR required no additional time to generate F024 products and to apply approximately half the level of compression provided by the current commit.

If it is considered necessary to balance faster job completion time with a reduced level of compression/packing for the SBN products, I will assist with that effort.

Thanks @ChristopherHill-NOAA for your response, I was sure I am missing something. So short answer is that this is not the test that will confirm the SBN size for v17, and you suggest a high res test to be conducted. Jessica has been kindly doing those tests for us but I am pretty sure that since this PR is only one file change in a script that is called by this job:

@sbanihash I have been performing offline tests with the segment of the script exgfs_atmos_awips_20km_1p0.sh that is affected by this PR, and reporting the resulting product volume changes, precisely because such tests can be completed quickly to meet the urgency of this issue. For the future, I will be sure to have a ready batch mode capability to test unabbreviated files of the workflow for which I am responsible.

The gfs_awips_20km_1p0deg_*.log files here: /lfs/h2/emc/ptmp/jessica.meixner/comroot/prod01/logs/2026030506 can also be used for timing calculations for high res.

I'd be good to have others look but it looks like we have about a 30 second increase, from about 1.5 min to 2min. This also looks like it's possibly calculating for more than 1 forecast hour. If we can confirm that that would be good.

The product data stored in
/lfs/h2/emc/ptmp/jessica.meixner/comroot/prod01/gfs.20260305/06/original.products/atmos/wmo
are recognized to result from workflow code not changed by this PR.
The total volume of the grib2.awpgfs* files stored in this directory is 9245.84 MB.

The product data in
/lfs/h2/emc/ptmp/jessica.meixner/comroot/prod01/gfs.20260305/06/products/atmos/wmo
result from use of the current commit of code from this PR.
The total volume of the grib2.awpgfs* files stored in this directory is 9120.44 MB.

The volume difference resulting from this PR is 9120.44 - 9245.84 = -125.40 MB.

Three versions of the gfs_awips_20km_10pdeg_f###-f###.log file are observed in $COMROOT/prod01/logs/2026030506.
The *.log.1 files result from no change to the workflow code.
The *.log.0 files result from the first commit of this PR.
The *.log files result from the current commit of this PR.

The job JGFS_ATMOS_AWIPS_20KM_1P0DEG executes the exgfs_atmos_awips_20km_1p0deg.sh script at every 3rd forecast hour. All grid products are generated for every 6th forecast hour, while products for grids ak, conus, pac, and prico are generated at every 3rd forecast hour from F000-F084. The log files feature one or two runs of JGFS_ATMOS_AWIPS_20KM_1P0DEG depending on the forecast hour range represented by the gfs_awips_20km_10pdeg_f###-f###.log file.

A query of grep ^End to each of the gfs_awips_20km_10pdeg_f###-f###.log* files provides the end time and the "time elapsed" for the job JGFS_ATMOS_AWIPS_20KM_1P0DEG to complete its processing of grid products for each of 55 forecast hours.

The maximum time needed for job completion by the current commit of code was 2 minutes, 18 seconds for F032-F035 (specifically F033) - representing a 46-second increase. The average increase of time for job completion for the 55 forecast hours processed for cycle 2026030506 was 26.36 seconds, with a standard deviation of 7.93 seconds.

When comparing the volume of 9120.44 MB for grib2.awpgfs* files generated from Jessica's latest with 9038.96 MB of those same files from GFSv16, the difference is 9120.44 - 9038.96 = +81.48 MB.

When accounting for the additional 70.93 MB volume from xtrn.awpgfs* files of GFSv16, the net difference of v17 vs v16 product volumes becomes +10.55 MB with this PR.