Maintaining global fix files moving forward

[RussTreadon-NOAA]

Issue #48 documents the fact that we need to add gps 768 to global_convinfo_2mObs.txt to keep it in sync with global_confinfo.txt. This can certainly be done. It does, however, raise important questions to consider, discuss, and decide upon. What's our strategy for maintaining global GSI fix files moving forward?

Some things to consider

1. Multiple copies of similar files
   Instead of maintaining separate global_convinfo.txt and global_convinfo_2mObs.txt we could merge the two files into one. We could do the same for global_anavinfo_allhydro.l127.tx and global_anavinfo_soilanal.l127.txt. One challenge, though, is that GFS v17 uses global_anavinfo_soilanal.l127.txt and generates a convinfo similar to global_convinfo_2mObs.txt. In contrast, GFS v16 uses global_anavinfo_allhydro.l127.txt and global_convinfo.txt. GFS v16 can't exercise some of the features included in GFS v17.

2. Static or dynamically generated info files
   build-gsinfo-fix allows us to dynamically build convinfo, ozinfo, and satinfo. This ability could be leveraged to address the GFS v16 -vs- v17 issue. (Note: builid_gsinfo-fix also dynamically creates the GSI OBS_INPUT namelist.) GSI-fix contains build_gsinfo-fix as a submodule. It also contains static copies of convinfo, ozinfo, and satinfo files. Do we maintain info fix files using both approaches (both repositories)? The global-workflow currently support both approaches. Do we stick with the static and dynamic approaches or pivot to dynamic only?

3. Other considerations?

[RussTreadon-NOAA]

Tagging @CatherineThomas-NOAA , @CoryMartin-NOAA , @ClaraDraper-NOAA , @ADCollard , @jswhit , @danholdaway , @ilianagenkova .

[ClaraDraper-NOAA]

Thanks for pulling all of this together @RussTreadon-NOAA. For my 2c worth:

It might be simpler to re-frame these two sets of files as v16 and v17, where v17 has soil analysis turned on in anavinfo and 2m obs included in convinfo.

Maintaining two options seems likely to repeat the issue of them getting out of synch. If we pivoted to only dynamic, the use2mobs flag used by build-gsinfo-fix allows us to switch between v16 and v17 for the convinfo file. We will also need to match this with a similar switch for selecting (generating?) an appropriate anavinfo file (with/without soil variables and extra states for 2m h(x)).

One question: do we expect to need to update the v17 convinfo files going forward?

[ilianagenkova]

What led to introducing global_convinfo**_2mObs**.txt ?
Will global_convinfo*.txt or something like it exist in JEDI?
Column "type" (a.k.a "kx" in GSI) is a 3 digit value and there is limit to how many more data sets could be added.
If users would like to keep it (and define new values for it in GSI) could it be expanded to 4 digits?

[ClaraDraper-NOAA]

What led to introducing global_convinfo**_2mObs**.txt ? Will global_convinfo*.txt or something like it exist in JEDI?

I added the 2mObs files while we were testing the new soil analysis, which includes the addition of the 2m obs. We now use these file in place of the global_convinfo.txt in GFSv17.

[ilianagenkova]

@ClaraDraper-NOAA, thanks, so it will replace global_convinfo.txt in GSFv17 and afterwards?

[ClaraDraper-NOAA]

@ClaraDraper-NOAA, thanks, so it will replace global_convinfo.txt in GSFv17 and afterwards?

Yes.