1 / 10

GEFS transition to EE

GEFS transition to EE. Draft 20130821 by Richard Wobus. GEFS transition to EE. There are two issues that need to be resolved before we work on updating GEFS to be tested and implemented under EE: References to libraries and global model components by GEFS

minowa
Download Presentation

GEFS transition to EE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GEFS transition to EE Draft 20130821 by Richard Wobus

  2. GEFS transition to EE There are two issues that need to be resolved before we work on updating GEFS to be tested and implemented under EE: • References to libraries and global model components by GEFS • Use of the $envir variable, which has to be changed to accommodate nwdev

  3. References to libraries and global model components by GEFS This is an incomplete list of directory trees and libraries that the GEFS is likely to need to point to: • GEFS • Global Spectral Model • Global Post • Global utilities: the directory tree containing global_chgres • System utilities: the directory trees containing wgrib2, copygb, cnvgrib, ndate • Libraries for compilation: w3nco, bacio, ip, sp, sigio, bufr

  4. References to libraries and global model components by GEFS Since a particular version of the GSM or the post is likely to have been compiled with particular versions of the libraries and to have been tested with particular versions of the utilities, which might be different from the versions tested with GEFS codes and scripts: Is there a way for GSM and post, as used by GEFS, to inherit the versions used by the GSM and post separately from the specification of versions to be used by GEFS itself?

  5. Use of the $envir variable, which has to be changed to accommodate nwdev Background: we use the following variables to control and identify our GEFS runs: • envir: set to prod, para, test (for NCO use) or dev (for EMC use) • RUN_ENVIR: dev (for EMC use, mainly under SMS), undefined (for NCO use) • gefsmachine: set to wcoss or zeus (or, potentially, to point to some other machine) • experiment ID; 4 letters, two to identify the user, and two to sequentially identify an experiment The use of $RUN_ENVIR and $gefsmachine, introduced at different times for different purposes by different programmers, has made many of our scripts, especially the j-jobs, excessively complicated and hard to debug.

  6. Use of the $envir variable, which has to be changed to accommodate nwdev For example, using $expid=rwcb as an example: Pre-CCS file locations ($envir=$expid): /global/save/wx20rw/s/nwrwcb/jobs etc. for source and scripts /ptmp/wx20rw/o/com/gens/rwcb/gefs.YYYYMMDD etc. for output Recent CCS and WCOSS locations ($expid used in prefix): /ensemble/save/Richard.Wobus/s/rwcb/nwdev/jobs etc. /ptmp/Richard.Wobus/o/rwcb/com/gens/dev/gefs.YYYYMMDD etc. WCOSS locations as used in WSR vertical structure: /ensemble/save/Richard.Wobus/s/rwcb/nwdev/v10.0.3/jobs etc. /ptmp/Richard.Wobus/o/rwcb/com/gens/dev/gefs.YYYYMMDD etc.

  7. Use of the $envir variable, which has to be changed to accommodate nwdev Proposal: since we have to change the use of “dev” anyway, and it is probably not a good idea to go back to the old practice of setting $envir to the experiment ID, we should make the $envir variable control all of the options now controlled by $envir, $RUN_ENVIR, and $gefsmachine: $envir meaning: prod NCO running production para NCO running parallel test NCO running test dev NCO and EMC collaborating on a parallel run deve EMC running on WCOSS under ecf devw EMC running on WCOSS under our control scripts devz EMC running on zeus under our control scripts

  8. Use of the $envir variable, which has to be changed to accommodate nwdev For example, using $expid=rwcb as an example: Pre-CCS file locations ($envir=$expid): /global/save/wx20rw/s/nwrwcb/jobs etc. for source and scripts /ptmp/wx20rw/o/com/gens/rwcb/gefs.YYYYMMDD etc. for output Recent CCS and WCOSS locations ($expid used in prefix): /ensemble/save/Richard.Wobus/s/rwcb/nwdev/jobs etc. /ptmp/Richard.Wobus/o/rwcb/com/gens/dev/gefs.YYYYMMDD etc. WCOSS locations as used in WSR vertical structure: /ensemble/save/Richard.Wobus/s/rwcb/nwdev/v10.0.3/jobs etc. /ptmp/Richard.Wobus/o/rwcb/com/gens/dev/gefs.YYYYMMDD etc. WCOSS locations in vertical structure with $envir=devw: /ensemble/save/Richard.Wobus/s/rwcb/nwdevw/v10.0.3/jobs etc. /ptmp/Richard.Wobus/o/rwcb/com/gens/devw/gefs.YYYYMMDD etc.

  9. Use of the $envir variable, which has to be changed to accommodate nwdev To make j-job scripts cleaner and easier to follow, all uses of $envir, $RUN_ENVIR, and $gefsmachine should be replaced by testing $envir in either an “if” statement: if [[ $envir = prod ]]; then {settings for production} elif [[ $envir = para ]] || \ [[ $envir = test ]]; then {settings for para or test} elif [[ $envir = dev ]]; then {settings for nwdev} elif [[ $envir = devw ]]; then {settings for EMC running on WCOSS} elif [[ $envir = devz ]]; then {settings for EMC running on zeus} else {optional error trap for unimplemented value of $envir} fi

  10. Use of the $envir variable, which has to be changed to accommodate nwdev or a “case” statement: case $envir in (prod) {settings for production} ;; (para) {settings for para} ;; (test) {settings for test} ;; (dev) {settings for nwdev} ;; (devw) {settings for EMC running on WCOSS} ;; (devz) {settings for EMC running on zeus} ;; (*) {optional error trap for unimplemented value of $envir} ;; esac

More Related