-
Notifications
You must be signed in to change notification settings - Fork 3
C. Running Standalone Analyses
In many cases it might be desirable to run the GEOS ADAS analysis in standalone mode. This is useful for developers of the analysis system when needing to run multiple tests to adjust a given implementation; many time these tests are done by the user running the same case over and over again. If the user has setup an ADAS experiment following the instruction above, the required script to run a standalone analysis can be found under:
FVHOME/anasa/g5anasa.j
If the user has cycled the ADAS for a few cycles, re-running any of the existing analysis can be accomplished easily by following these steps;
- cd FVHOME/anasa
- touch standalone.17760704_00z
- sbatch g5anasa.j
If the user wants to point to a case, or cases, other than the self experiment the following files need to be edited and adjusted to point to the proper experiment:
- FVHOME/run/bkg.acq
- FVHOME/run/satbias.acq
- FVHOME/anasa/atmens_replay.acq (in case of hybrid analysis)
For example if the user experiment is named myexp and it is expected to use backgrounds from the official x-experiment x0043, the user would need to edit the files above and make changes so as,
original in bkg.acq:
/archive/u/user/myexp/ana/Y%y4/M%m2/myexp.bkg.eta.%y4%m2%d2_%h2%n2z.nc4
modified:
/discover/nobackup/projects/gmao/dadev/dao_it/archive/x0043/ana/Y%y4/M%m2/x0043.bkg.eta.%y4%m2%d2_%h2%n2z.nc4 => myexp.bkg.eta.%y4%m2%d2_%h2%n2z.nc4
and similarly for all the remaining active (non-commented) lines in these acq files.
Once g5anasa.j has been submitted it will fetch the required backgrounds, observations and, in case of hybrid experiments, the corresponding ensemble of background fields forming the ensemble component of the background error covariance and it will archive the output with all files give "sa" identifiers to be distinguishable from files generated during the regular ADAS cycle.
The standalone analysis script can also be submitted by the date and time of the case-study explicit in the command line. This is done by:
- touch standalone.yyyymmdd_hhz
- sbatch --export=this_nymdhh=yyyymmdd_hh g5anasa.j
where yyyymmdd_hh is convention for 4-digit year, 2-digit month, 2-digit day, and 2-digit hour, e.g., 17760704_12z; hour here must be either 00, 06, 12, or 18. With this capability, it is also possible to run multiple standalone analyses, for different analysis intervals, simultaneously. Writing a little scrips might be useful to handle such cases, e.g.,
#!/bin/csh
set hh = 00
set yyyy = 1776
set mm = 07
foreach dd ( `seq -f %02g 4 5` )
set this_nymdhh = ${yyyy}${mm}${dd}_${hh}
touch standalone.${this_nymdhh}z
sbatch --export=this_nymdhh="${this_nymdhh}" g5anasa.j
end
In the example above, the script runs 2 instances of the analysis one for 17760704_00 and another for 17760705_00.
CAUTION: these parallel runs can take over the batch queue, especially if the user has high priority access, so be kind to others and do not submit more than about a few of these at a time (five or six).
Note that when the submission command line with the option this_nymdhh is used, the output of the standalone experiment will not be archived; the output will transfer from tmpdir to subdirectories of FVHOME.
For testing purposes it is many times useful to run only a single outer loop of GSI (i.e., adjusting the gsi.rc.tmpl or gist.rc.tmpl files). In such cases, please notice the following line should be placed in the g5anasa.j job script:
setenv USRMITER 1
Also remember the in this single outer loop context, to get ODS files out of the GSI diag output, users should replace edit the write_diag variables in the gsi.rc.tmpl accordingly, that is, replacing the default:
write_diag(1)=.true.,write_diag(2)=.false.,write_diag(3)=.true.,
to
write_diag(1)=.true.,write_diag(2)=.true.,write_diag(3)=.false.,
It is sometimes desirable to cycle the standalone analysis. A case in point is when a new instrument is added and one is trying to get a sense for how it OmB statistics will evolve in time, or to get OmBs and OmAs to derive a first estimate of relevant observation errors.
As it can be imagined, unlike the general setting of standalone analysis (above) that allows for various standalone analysis to run concurrently, when cycling is required, the parallel feature should not be exercise - indeed, it would not work. This is the sequence of how cycling should be done:
- just as above, choose a date/time for, now the initial analysis, and touch the standalone file in the nasa directory of FVHOME, that is,
- cd FVHOME/anasa
- touch standalone.17760704_00z
- sbatch g5anasa.j
- Wait for the job above to complete, then:
- cd FVHOME/anasa
- cp ../run/satbias.acq .
- edit the satbias.acq file and make a replacement of the form:
/full_path_of_archived_files/ana/Y%y4/M%m2/x0046d.anasa.satbias.%y4%m2%d2_%h2z.txt => x0046d.ana.satbias.%y4%m2%d2_%h2z.txt
/full_path_of_archived_files/ana/Y%y4/M%m2/x0046d.anasa.acftbias.%y4%m2%d2_%h2z.txt => x0046d.ana.acftbias.%y4%m2%d2_%h2z.txt
/full_path_of_archived_files/ana/Y%y4/M%m2/x0046d.anasa.satbiaspc.%y4%m2%d2_%h2z.txt => x0046d.ana.satbiaspc.%y4%m2%d2_%h2z.txt
-
Notice, in the above satbias.acq the anasa and ana names - this allows the bias coefficients generated by the standalone jobs to replace the original files from the original run.
-
Now, touch a sequence of standalone file in the FVHOME/anasa directory, as for example, continuing from the run in (1):
touch standalone.17760704_06z
touch standalone.17760704_12z
touch standalone.17760704_18z -
Finally, submit again the job script: g5anasa.j
A feature that's been available in GSI since roughly 2012 has been the ability to run, for example, an Ozone-only analysis. The only fields needed as input backgrounds would be ozone, surface pressure (to define the vertical eta coordinate system). Additionally, if a desire exists in studying the impact of temperature on ozone, virtual temperature and specific humidity would also be required to be present in the background file. Typically, the bkg.eta files produced within a regular ADAS can be used as inputs to GSI in this case. Unlike the full atmospheric analysis, GSI would not need the bkg.sfc and cbkg.eta files as part of the background. There is also no need to provide satellite bias coefficients as input data to GSI since GSI does not bias-correct ozone observations.
When an experiment is created with more recent versions of the ADAS, the user will find a directory FVHOME/o3anasa with contents related to the settings of such standalone ozone analysis. Files such as gsi.rc.tmpl, gmao_global_anavinfo.rc are placed in this directory and overwrite the default settings in FVHOME/run when exercising this standalone analysis. The control job script for the standalone analysis is still named g5anasa.j. Just as with the standalone analysis, before running this the user must touch a file with the date/time of the run. The steps for exercising this feature are not different than those explained above, with one addition:
- edit the file FVHOME/run/FVDAS_Run_Config and proceed as explained below
- cd FVHOME/anasa
- touch standalone.17760704_00z
- sbatch g5anasa.j
The additional step laid out above, requires the user to edit the file FVHOME/run/FVDAS_Run_Config and set a desirable ozone-related observing system via the env variable called OBSCLASS_O3 , as for example, add a line like this:
setenv OBSCLASS_O3 ncep_aura_omi_bufr,npp_ompsnm_bufr
The default settings perform a 3DVar analysis and rely on the bkg.eta file produced within the experiment itself to perform the run.
Specifically, the files used to control the run (and placed in FVHOME/o3anasa) are:
- gmao_global_anavinfo_rcov.rc
- gsi.rc.tmpl
- o3anasastorage.arc
- gmao_global_anavinfo.rc
- GSI_GridComp.rc.tmpl
- o3bkg.acq
Once the analysis is finished the output is left in FVHOME under various subdirectories, namely, ana, etc and obs. For example, the file expid.o3anasa.etc.yyyymmdd_hhz.nc4 will how the offline Ozone analysis.