Add an OOPS-based application to recenter snow analysis

[CoryMartin-NOAA]

Closes #1097

This adds a new GDASApp utility that will:

• read deterministic guess
• read ensemble guess, compute ensemble mean
• read deterministic increment
• subtract ens mean from guess
• add this difference to the increment
• write out a new increment
  Effectively recentering the ensemble to the deterministic

This is just the recentering utility, the workflow will need to be modified to use fregrid to interpolate, and then the land-apply-inc code will need to be exercised on every member

[CoryMartin-NOAA]

This is what a YAML would look like for this app:

geometry:
  fms initialization:
    namelist filename: Data/fv3files/fmsmpp.nml
    field table filename: Data/fv3files/field_table_gfdl
  akbk: Data/fv3files/akbk127.nc4
  npx: 13
  npy: 13
  npz: 127
  field metadata override: Data/fieldmetadata/gfs-restart.yaml
date: "2020-12-15T00:00:00Z"
variables: [T]
deterministic increment:
  datetime: 2020-12-15T00:00:00Z
  filetype: fms restart
  datapath: ./inc/
  filename_core: 20201215.000000.fv_core.res.nc
  filename_trcr: 20201215.000000.fv_tracer.res.nc
  filename_sfcd: 20201215.000000.sfc_data.nc
  filename_sfcw: 20201215.000000.fv_srf_wnd.res.nc
  filename_cplr: 20201215.000000.coupler.res
deterministic background:
  datetime: 2020-12-15T00:00:00Z
  filetype: fms restart
  state variables: [u,v,ua,va,T,DELP,sphum,ice_wat,liq_wat,o3mr,phis,
                    slmsk,sheleg,tsea,vtype,stype,vfrac,stc,smc,snwdph,
                    u_srf,v_srf,f10m]
  datapath: ./bkg/bkg/
  filename_core: 20201215.000000.fv_core.res.nc
  filename_trcr: 20201215.000000.fv_tracer.res.nc
  filename_sfcd: 20201215.000000.sfc_data.nc
  filename_sfcw: 20201215.000000.fv_srf_wnd.res.nc
  filename_cplr: 20201215.000000.coupler.res
output increment:
  datapath: ./
  datetime: 2020-12-15T00:00:00Z
  filetype: fms restart
  filename_core: 20201215.000000.fv_core.res.nc
  filename_trcr: 20201215.000000.fv_tracer.res.nc
  filename_sfcd: 20201215.000000.sfc_data.nc
  filename_sfcw: 20201215.000000.fv_srf_wnd.res.nc
  filename_cplr: 20201215.000000.coupler.res
ensemble backgrounds:
  number of members: 3
  pattern: '%mem%'
  zero padding: 3
  template:
    datetime: 2020-12-15T00:00:00Z
    filetype: fms restart
    state variables: [u,v,ua,va,T,DELP,sphum,ice_wat,liq_wat,o3mr,phis,
                      slmsk,sheleg,tsea,vtype,stype,vfrac,stc,smc,snwdph,
                      u_srf,v_srf,f10m]
    datapath: ./bkg/mem%mem%/
    filename_core: 20201215.000000.fv_core.res.nc
    filename_trcr: 20201215.000000.fv_tracer.res.nc
    filename_sfcd: 20201215.000000.sfc_data.nc
    filename_sfcw: 20201215.000000.fv_srf_wnd.res.nc
    filename_cplr: 20201215.000000.coupler.res

[guillaumevernieres]

Looks good

[ClaraDraper-NOAA]

A few thoughts, that may or may not be relevant:

1. I don't see any land masks. In GFS, the land variables are defined (and usually zero) over non-land points. Is there any risk that this code could cause problems if we're not careful with the input files over non-land points?
2. If we're recentering the snow depth, we should really re-center the other variables too. Is there other code in place to do this?
   Also, see comment about making the routine names generic.

[CoryMartin-NOAA]

Thanks @ClaraDraper-NOAA .

For 1, I didn't consider a mask since this will write out an increment and presumably the apply increment code will handle the masking, but I can look into how to add a mask here and see how difficult it would be.

For 2, what other variables do you have in mind? The atmospheric fields will be recentered as part of the GSI Var/EnKF machinery. For land fields, we can add extra variables in the YAML with this executable. The original increment will be 0, but the recentering will give the ensemble an increment to be consistent with the deterministic.

[CoryMartin-NOAA]

@ClaraDraper-NOAA A quick look seems like through the magic of JEDI I can pretty easily read in time invariant fields and then I think I should be able to add to this utility something like:

mask field: slmsk
minvalue: 0.9
maxvalue: 1.1

or something like that to make it generic to zero out the increments where the mask value is between min and max

[jiaruidong2017]

For the increment file, we just have the surface file available. It is better to just keep the sfc_data files for the land recentering applications in the yaml file with bold font below.

datapath: ./inc/
filename_core: 20201215.000000.fv_core.res.nc
filename_trcr: 20201215.000000.fv_tracer.res.nc
> filename_sfcd: 20201215.000000.sfc_data.nc
filename_sfcw: 20201215.000000.fv_srf_wnd.res.nc
> filename_cplr: 20201215.000000.coupler.res

And the state variables in current JEDI based snow analysis are [snodl,vtype,slmsk] for the Noah-MP LSM.

state variables: [u,v,ua,va,T,DELP,sphum,ice_wat,liq_wat,o3mr,phis,
slmsk,sheleg,tsea,vtype,stype,vfrac,stc,smc,snwdph,
u_srf,v_srf,f10m]

[ClaraDraper-NOAA]

@ClaraDraper-NOAA A quick look seems like through the magic of JEDI I can pretty easily read in time invariant fields and then I think I should be able to add to this utility something like:

mask field: slmsk
minvalue: 0.9
maxvalue: 1.1

or something like that to make it generic to zero out the increments where the mask value is between min and max

If the masking can be done easily (1/2 a day), I think's it worth it, just to keep things neat. However, you're right that since you're writing out increments here, the code that adds the increments will take care of the masking.

[ClaraDraper-NOAA]

Thanks @ClaraDraper-NOAA .

For 1, I didn't consider a mask since this will write out an increment and presumably the apply increment code will handle the masking, but I can look into how to add a mask here and see how difficult it would be.

For 2, what other variables do you have in mind? The atmospheric fields will be recentered as part of the GSI Var/EnKF machinery. For land fields, we can add extra variables in the YAML with this executable. The original increment will be 0, but the recentering will give the ensemble an increment to be consistent with the deterministic.

I answered 1 below. For 2, when we meet tomorrow let's talk quickly about how this code would interact with the soil analysis code - which also requires recentering (which I haven't done). Long term, I think it'd be really useful if this code had the flexibility to recenter vars W and X without adding an increment (or adding a zero increment), while also recentering Y and Z with increments.

[CoryMartin-NOAA]

I think I've got the masking working:

Will push the changes now/soon.

[guillaumevernieres]

I don't want to approve a pr that ignores the ocean! But ...

[CoryMartin-NOAA]

@ClaraDraper-NOAA see if my latest additions match what you were thinking based on our discussion yesterday. I still want to do some quick spot checks to confirm its working as intended but otherwise I think this is ready for review again.

[ClaraDraper-NOAA]

Looks good to me. Thanks Cory.