gfs.v16.3.0 Implementation: Increasing NSST biases observed in gfs.v16.3.0 retrospective parallel - issue, diagnostics, solution, and test

[emilyhcliu]

Issue and Diagnostics:

gfsv16.3.0 retrospective parallel is running on Cactus starting from 20211015 18Z

- After 3-week assimilation, the Northern Hemisphere anomaly correlation score shows significant negative impact.

- Increasing bias and standard deviation(O-F without bias correction) are also observed in the time series of AVHRR MetOp-B channel 3

- Larger temperature bias and standard deviation at and near the surface can be seen in the 6-hour forecast verified against conventional data.

- Foundation temperature bias and rms compared to operational GFS and OSTIA increase with time

(Figure provided by @XuanliLi-NOAA)

Cause:

@RussTreadon-NOAA found that the NSST increment file created in GSI does not pass to the surface component of the global cycle properly. 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'
...
&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'
...
&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.

Solution and Results:

Code changes: PR #448

Run gfs.v16.3.0 real-time parallel with the bug fix (PR #448) - starting from 2022061918z ....currently running 2022062600

Check the 6-hour forecast against conventional data:


The temperature bias and rms are much reduced near the surface and are improved compared to the operatinoal run.

The radiance monitoring page will be posted later (still in processing)
Here is the link to the MetPlut verification page:
https://www.emc.ncep.noaa.gov/gc_wmb/eliu/v163ctl/

[emilyhcliu]

Note that in the real-time parallel, the TMBR (radiance) values in the BUFR are all missing values.
Please see ObsProc Issue #64

As a result, no VIIRS data is currently assimilated in the real-time parallel (v163ctl).

[XuLi-NOAA]

Based on the RMS and Bias of the NSST Tf analysis in v163ctl to OSTIA one, it is as expected now (better than operational NSST Tf analysis) globally, but is less significant than the cycling runs previously done, probably due to the missing of VIIRS. Note the RMS and Bias of CMC to OSTIA is shown as well.

[XuLi-NOAA]

However, over northern high latitude area, v163ctl becomes slightly further away from OSTIA than the operational one. It maybe caused by the missing of VIIRS data, which helps a better observation coverage, particularly near Northern pole area, where the water body may have a small spatial scale due to the complicated water, sea ice and land surface pattern, and often requires smaller thinning boxes to provide the enough obs coverage to support a good analysis (a constant 50 km thinning is adopted currently in v163ctl) with a smaller correlation length (reduced from 100 km in operational to about 25 km at this area).