E. Overriding Observation Database

Despite the title of this section there are actually two fully implemented observation databases within GEOS ADAS: the satellite radiance database; and the ozone observations database. There is also a prototype database that aims at allowing for controlling the inflow of conventional observations in ADAS. The objective of these databases is to allow for detailed specification of the use of various instruments from various observing platforms over the course of the years covering the 40 years of MERRA-2 to the present.

Typical experiments with ADAS rarely fuss with the default settings of these database, but sporadically the choice of instruments and channels get revised mainly because GSI becomes enabled to handled such choices better than in earlier versions. For example, the relatively recent implementation of a methodology to account for inter-channel correlations in satellite radiances has allowed GMAO to revisit the choice of channels assimilated from the CrIS instrument on SNPP and NOAA-20 satellites. While experimenting with modified sets of channels the user should make a local copy of the corresponding database, edit it at will, and experiment with the new choices without affecting the default and any ongoing experiments expecting to use the default settings. Another example of when to have a user-specific version of specific databases applies to handling near-real-time changes to the database due to temporary (or permanent) failure of specific channels on specific platforms, or sometimes a whole platform outage. This latter example applies to the GMAO Forward Processing system and for how this system should implement a flexible database control set for its needs.

Before providing the information for how to handle a user-specific copy of the database it is important to know where to find the default version of these databases within a particular build of ADAS. In the CVS builds these database are mounted under:

FULLPATH/Linux/etc

in the Git build they are found under:

FULLPATH/GEOSadas/install/etc

The available databases are:

(i) gmao_convinfo.db (MKSICN_SIDB_ - prototype database handling the conventional observing system (not used at the moment)
(ii) gmao_satinfo.db (MKSI_SIDB) - satellite radiance observations
(iii) gmao_ozinfo.db (MKSIOZ_SIDB) - satellite ozone observations
(iv) gmao_pcscaling.db - scaling of satellite radiance bias correction (very recently introduced in ADAS)

As mentioned above the two main databases are (ii) and (iii). The names above are subdirectories of the build etc directory.

When the need for modifying one (or more of the) database arises, the user should copy the database of interest and define a corresponding env variable (names in parenthesis above) in the ADAS configuration file FVDAS_Run_Config (found under FVHOME/run directory or any experiment).

For example, say the user wants to investigate the consequences of adding channels 1-3 of AMSU-A from various platforms. A good place to put a copy of the gmao_satinfo.db database is FVHOME/run. In this case, the user should add the line:

setenv MKSI_SIDB $FVHOME/run/gmao_satinfo.db

to the bottom of the FVHOME/run/FVDAS_Run_Config.

WARNING: it is recommended the above settings be added to FVDAS_Run_Config rather than, say, to the main ADAS job script since other procedures also use the database, and if not env settings is not specified globally there will be inconsistency in how various procedures use the input dataset. For example, in case of adding user-specific settings to the main ADAS script, a hybrid system would run the ensemble inconsistently unless the user remembers to also add the same settings to the ensemble ADAS script (atm_ens.j). Similarly, if the user decides to exercise a standalone analysis for the experiment in consideration, to make it consistent with the database change, the standalone script would also need to be edited. To avoid unnecessary hurdles the best place to define these env settings is FVDAS_Run_Config since this is a file sourced by all ADAS procedures.