Fix the inconsistency for the NSST increment file (dftanl) between GSI

[emilyhcliu]

@RussTreadon-NOAA found the inconsistency of the nsst increment file (dtfanl) assignment between GSI scripts and the global cycle scripts. As a result, we are not passing NSST increments to global cycle.

See the details below from Russ:

There is a problem with the combination of an updated exglobal_atmos_analysis.sh and global_cycle in the EIB v16.3 parallel

The v16.3  exglobal_atmos_analysis.sh has 

    if [ $DONST = "YES" ]; then
        export NST_FILE=${NST_FILE:-$COMOUT/${APREFIX}[dtfanl.nc](http://dtfanl.nc/)}
    else
        export NST_FILE="NULL"
    fi

in the block which executes global_cycle.   In contrast, the operational gfs.v16.2.1 exglobal_atmos_analysis.sh has

    if [ $DONST = "YES" ]; then                                                                                                                          
        export NST_ANL=".true."
        export GSI_FILE=${GSI_FILE:-$COMOUT/${APREFIX}[dtfanl.nc](http://dtfanl.nc/)}
    else
        export NST_ANL=".false."
        export GSI_FILE="NULL"
    fi

The global_cycle.sh script used in both gfs.v16.2.1 operations and the v16.3 references GSI_FILE

#     GSI_FILE      GSI file on the gaussian grid containing NST increments.                                          
#                   Defaults to NULL (no file).        
..
GSI_FILE=${GSI_FILE:-"NULL"}
...
cat << EOF > fort.37                                                                                                  
 &NAMSFCD                                                                                                            
  GSI_FILE="$GSI_FILE",                                                                                              
 /                                                                                                                    
EOF      
.
For operations we properly set GSI_FILE.  For example, today's 00Z gdas_atmos_analysis_00 has

 &NAMSFCD
  GSI_FILE="/lfs/h1/ops/prod/com/gfs/v16.2/gdas.20220729/00/atmos/[gdas.t00z.dtfanl.nc](http://gdas.t00z.dtfanl.nc/)",
 /
1> fort.37
0.047 + mpiexec -l -n 6 -ppn 1 --cpu-bind depth --depth 128 /lfs/h1/ops/prod/packages/gfs.v16.2.1/exec/global_cycle '\
1>OUTPUT.204235' '2>errfile'
...
[nid001009.cactus.wcoss2.ncep.noaa.gov](http://nid001009.cactus.wcoss2.ncep.noaa.gov/) 0:  &NAMSFCD                                                                    
 GSI_FILE        = /lfs/h1/ops/prod/com/gfs/v16.2/gdas.20220729/00/atmos/[gdas.t00z.dtfanl.nc](http://gdas.t00z.dtfanl.nc/)    

whereas the v16.3 parallel has

 &NAMSFCD
  GSI_FILE="NULL",
 /
1> fort.37
0.099 + mpiexec -l -n 6 -ppn 1 --cpu-bind depth --depth 128 /lfs/h2/emc/global/noscrub/lin.gan/para/packages/gfs.v16.3.0/exec/global_cycle '1>OUTPUT.175299' '2>errfile'
...
[nid001022.cactus.wcoss2.ncep.noaa.gov](http://nid001022.cactus.wcoss2.ncep.noaa.gov/) 0:  &NAMSFCD                                                                    
 GSI_FILE        = NULL                                                                                              \

The same mismatch occurs in exgdas_enkf_sfc.sh (j-job JGDAS_ENKF_SFC).

We are not passing the NSST increment to global_cycle in the v16.3 parallel.   Instead we are passing GSI_FILE=NULL.

[emilyhcliu]

@ADCollard Please feel free to add your aircraft change via this PR.

[ADCollard]

Changes look good to me. I will add the aircraft change in a separate pull request after this is merged.

[XuLi-NOAA]

The changes look good to me.

[emilyhcliu]

Link to Issue #449