Skip to content

A. 3D‐FGAT

rtodling edited this page Mar 15, 2024 · 1 revision

There are at least two ways of implementing FGAT in JEDI. The one way (that has been employed by one of us for a while) exercises the 4D-Var cost with a PSEUDO model; the other way is to (supposedly) use the 3D-FGAT cost function. The latter seems to be the flavor used at EMC: https://github.com/NOAA-EMC/GDASApp/blob/develop/parm/soca/variational/3dvarfgat.yaml - unfortunately, this fails for GEOS - there seems to be some issue with the winds and the fact that (ud,vd) is needed but note traded between the increment and the model (or something like it).

After some struggle a choice was made to move away from the 3D-FGAT cost - as a matter of fact, looking at least one of the examples in fv3-jedi/test using this flavor with GFS fields, it seems suspicious to say the least: the background is nailed at the initial time of the var window; in a proper FGAT one would expect the background to be templated so that the fields can be read from different files as the time clock ticks (but no true model propagates anything). Indeed, there is yet another attempt to FGAT using the 4D-Var cost function for the aerosol application (https://github.com/JCSDA-internal/fv3-jedi/blob/develop/test/testinput/hyb-fgat_gfs_aero.yaml); but this too seems incorrect as the background again does not seems to vary in time. The 4D-Var cost approach works for GEOS, but it must be implemented differently than what's found in the fv3-jedi tests.

SWELL therefore implements the knob 4D-Var knob that has been used by one of us outside the context of SWELL. One thing that needs to be pointed out with this is that the code writes out "4d-analyse", but only writes the increment with a time stamp at the start of the window. This is, in principle correct - in FGAT, the inner loop deals w/ only a single time instance of the increment, because there is no true model propagation, the increment is thus valid at anytime within the var window. With this, the code can graceful time stamp the increment as it wishes; because the cost under utilization corresponds to the strong constraint 4D-Var it is absolutely correct to time-stamp the file at the initial time.

Clone this wiki locally