Closed CoryMartin-NOAA closed 1 month ago
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
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.
@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
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 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.
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.
I think I've got the masking working:
Will push the changes now/soon.
@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.
Closes #1097
This adds a new GDASApp utility that will:
This is just the recentering utility, the workflow will need to be modified to use
fregrid
to interpolate, and then theland-apply-inc
code will need to be exercised on every member