Fortuna 2.4 Quick Start: Difference between revisions

(14 intermediate revisions by the same user not shown)

Line 1:

This page describes the minimum steps required to build and run GEOS-5 Fortuna 2.4 on NCCS discover and NAS pleiades. You should successfully complete the steps in these instructions before doing anything more complicated.

~~== Checking Out and Compiling~~ GEOS-5 ==

'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''

The following assumes that you know your way around Unix, have successfully logged into your cluster account and have an account on the source code repository with the proper <code>ssh</code> configuration -- see the progress repository quick start: https://progress.nccs.nasa.gov/trac/admin/wiki/CVSACL.

== How to Obtain GEOS-5 and Compile Source Code ==

There are two options for obtaining the model source code: from the CVS repository on the NCCS progress server, and from the SVN "public" repository on the trac server. Since the code on progress is more current, elgible users are strongly encouraged to obtain accounts from NCCS and use the progress repository.

=== Using the NCCS progress CVS code repository ===

The following assumes that you know your way around Unix, have successfully logged into your cluster account and have an account on the source code repository with the proper <code>ssh</code> configuration -- see the progress repository quick start: https://progress.nccs.nasa.gov/trac/admin/wiki/CVSACL. The link requires your NCCS username and password.

The commands below assume that your shell is <code>csh</code>. Since the scripts to build and run GEOS-5 tend to be written in the same, you shouldn't bother trying to import too much into an alternative shell. If you prefer a different shell, it is easiest just to open a <code>csh</code> process to build the model and your experiment.

Line 12:

Line 18:

setenv CVS_RSH ssh

setenv CVSROOT :ext:''USERID''@~~progressdirect.nccs.nasa.gov~~:/cvsroot/esma

setenv CVSROOT :ext:''USERID''@cvsacl:/cvsroot/esma

~~setenv BASEDIR /discover/nobackup/projects/gmao/share/dao_ops/Baselibs/v3~~.~~1.5_build1~~

where ''USERID'' is, of course, your repository username, which should be the same as your NASA and NCCS username. Then, issue the command:

cvs co -r Fortuna-2_4 Fortuna

~~where ''USERID'' is,~~ of ~~course, your~~ repository ~~username, which should be the same as your NASA~~ and ~~NCCS username~~. ~~Then, issue the command:~~

This should check out the latest stable version of the model from the repository and create a directory called <code>GEOSagcm</code>.

~~cvs co -r Fortuna-2_3 Fortuna~~

=== Compiling the Model ===

~~This should check out the latest stable version of the model from the repository and create a directory called <code>GEOSagcm</code>.~~ <code>cd</code> into <code>GEOSagcm/src</code> and <code>source</code> the file called <code>g5_modules</code>:

<code>cd</code> into <code>GEOSagcm/src</code> and <code>source</code> the file called <code>g5_modules</code>:

source g5_modules

If you then type

This will set up the build environment. If you then type

module list

Line 60:

Line 69:

The script produces an experiment directory (''EXPDIR'') in your space as <code>/discover/nobackup/''USERID''/''EXPID''</code>, which contains, among other things, the sub-directories:

*<code>post</code> (containing the post-processing job script)

*<code>post</code> (containing the incomplete post-processing job script and .rc file)

*<code>archive</code> (containing an incomplete archiving job script)

*<code>plot</code> (containing an incomplete plotting job script)

*<code>plot</code> (containing an incomplete plotting job script and .rc file)

The post-processing script will complete (i.e., add necessary commands to) the archiving and plotting scripts as it runs. The setup script that you ran also creates an experiment home directory (''HOMEDIR'') as <code>~''USERID''/geos5/''EXPID''</code> containing the run scripts and GEOS resource (<code>.rc</code>) files.

Line 72:

Line 81:

unlimit

limit stacksize unlimited

~~source ~/.g5_modules~~

set arch = `uname`

setenv LD_LIBRARY_PATH ${LIBRARY_PATH}:${BASEDIR}/${arch}/lib

~~where <code>.g5_modules</code> is simply a copy of the <code>g5_modules</code> that you ran earlier before compiling.~~ The <code>umask 022</code> is not strictly necessary, but it will make the various files readable to others, which will facilitate data sharing and user support. Your home directory <code>~''USERID''</code> is also inaccessible to others by default; running <code>chmod 755 ~</code> is helpful.

The <code>umask 022</code> is not strictly necessary, but it will make the various files readable to others, which will facilitate data sharing and user support. Your home directory <code>~''USERID''</code> is also inaccessible to others by default; running <code>chmod 755 ~</code> is helpful.

Copy the restart (initial condition) files and associated <code>cap_restart</code> into ''EXPDIR''. Keep the "originals" handy since if the job stumbles early in the run it might stop after having renamed them. The model expects restart filenames to end in "rst" but produces them with the date and time appended, so you may have to rename them. The <code>cap_restart</code> file is often provided with a set of restarts, but if not you can create it: is simply one line of text with the date of the restart files in the format ''YYYYMMDD''<space>''HHMMSS''. The boundary conditions/forcings are provided by symbolic links created by the run script.

Copy the restart (initial condition) files and associated <code>cap_restart</code> into ''EXPDIR''. Keep the "originals" handy since if the job stumbles early in the run it might stop after having renamed them. The model expects restart filenames to end in "rst" but produces them with the date and time appended, so you may have to rename them. The <code>cap_restart</code> file is simply one line of text with the date of the restart files in the format YYYYMMDD<space>HHMMSS. The boundary conditions/forcings are provided by symbolic links created by the run script. If you need an arbitrary set of restarts, you can copy them from <code>/archive/u/aeichman/restarts/Fortuna-~~2_2~~/</code>.

If you need an arbitrary set of restarts, you can copy them from <code>/archive/u/aeichman/restarts/Fortuna-2_4/</code>, where they are indexed by date and resolution.

The script you submit, <code>gcm_run.j</code>, is in ''HOMEDIR''. It should be ready to go as is. The parameter END_DATE in <code>CAP.rc</code> (previously in <code>gcm_run.j</code>) can be set to the date you want the run to stop ~~-- this works in Fortuna 2.3 where it did not in Fortuna 2.0. Also in Fortuna 2.3, you may edit the <code>.rc</code> files directly instead of template (<code>.tmpl</code>)~~. An alternative way to stop the run is by commenting out the line <code> if ( $capdate < $enddate ) qsub $HOMDIR/gcm_run.j</code> at the end of the script, which will prevent the script from being resubmitted, or rename the script file. You may eventually want to tune parameters in the <code>CAP.rc</code> file JOB_SGMT (the number of days per segment, the interval between saving restarts) and NUM_SGMT (the number of segments attempted in a job) to maximize your run time.

The script you submit, <code>gcm_run.j</code>, is in ''HOMEDIR''. It should be ready to go as is. The parameter END_DATE in <code>CAP.rc</code> (previously in <code>gcm_run.j</code>) can be set to the date you want the run to stop. An alternative way to stop the run is by commenting out the line <code> if ( $capdate < $enddate ) qsub $HOMDIR/gcm_run.j</code> at the end of the script, which will prevent the script from being resubmitted, or rename the script file. You may eventually want to tune parameters in the <code>CAP.rc</code> file JOB_SGMT (the number of days per segment, the interval between saving restarts) and NUM_SGMT (the number of segments attempted in a job) to maximize your run time.

Submit the job with <code>qsub gcm_run.j</code>. You can keep track of it with <code>qstat</code> or <code>qstat | grep ''USERID''</code>, or stdout with <code>tail -f /discover/pbs_spool/''JOBID''.OU</code>, ''JOBID'' being returned by <code>qsub</code> and displayed with <code>qstat</code>. Jobs can be killed with <code>qdel ''JOBID''</code>. The standard out and standard error will be delivered as files to the working directory at the time you submitted the job.

Submit the job with <code>qsub gcm_run.j</code>. You can keep track of it with <code>qstat</code> or <code>qstat | grep ''USERID''</code>, or follow stdout with <code>tail -f /discover/pbs_spool/''JOBID''.OU</code>, ''JOBID'' being returned by <code>qsub</code> and displayed with <code>qstat</code>. Jobs can be killed with <code>qdel ''JOBID''</code>. The standard out and standard error will be delivered as files to the working directory at the time you submitted the job.

== Output and Plots ==

Line 94:

Line 104:

plotting are: 1) if the month created was February or August, AND

2) there are at least 3 monthly average files, then a plotting job for

the seasons DJF or JJA will be issued. The plots are created as gifs in <code>''EXPDIR''/~~plots~~</code>.

the seasons DJF or JJA will be issued. The plots are created as gifs in <code>''EXPDIR''/plots_CLIM</code>.

The post-processing script can be found in:

Line 100:

Line 110:

The contents of the output files (including which variables get saved) may be configured in the <code>''HOMEDIR''/HISTORY.rc</code> -- a good description of this file may be found at http://modelingguru.nasa.gov/clearspace/docs/DOC-1190 .

'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''

@@ Line 1: / Line 1: @@
 This page describes the minimum steps required to build and run GEOS-5 Fortuna 2.4 on NCCS discover and NAS pleiades.  You should successfully complete the steps in these instructions before doing anything more complicated.
-== Checking Out and Compiling GEOS-5 ==
+'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''
-The following assumes that you know your way around Unix, have successfully logged into your cluster account and have an account on the source code repository with the proper <code>ssh</code> configuration -- see the progress repository quick  start: https://progress.nccs.nasa.gov/trac/admin/wiki/CVSACL.
+== How to Obtain GEOS-5 and Compile Source Code ==
+There are two options for obtaining the model source code: from the CVS repository on the NCCS progress server, and from the SVN "public" repository on the trac server.  Since the code on progress is more current, elgible users are strongly encouraged to obtain accounts from NCCS and use the progress repository.
+=== Using the NCCS progress CVS code repository ===
+The following assumes that you know your way around Unix, have successfully logged into your cluster account and have an account on the source code repository with the proper <code>ssh</code> configuration -- see the progress repository quick  start: https://progress.nccs.nasa.gov/trac/admin/wiki/CVSACL.  The link requires your NCCS username and password.
 The commands below assume that your shell is <code>csh</code>.  Since the scripts to build and run GEOS-5  tend to be written in the same, you shouldn't bother trying to import too much into an alternative shell.  If you prefer a different shell, it is easiest just to open a <code>csh</code> process to build the model and your experiment.
@@ Line 12: / Line 18: @@
   setenv CVS_RSH ssh
-  setenv CVSROOT :ext:''USERID''@progressdirect.nccs.nasa.gov:/cvsroot/esma
+  setenv CVSROOT :ext:''USERID''@cvsacl:/cvsroot/esma
-  setenv BASEDIR /discover/nobackup/projects/gmao/share/dao_ops/Baselibs/v3.1.5_build1
+where ''USERID'' is, of course, your repository username, which should be the same as your NASA and NCCS username.  Then, issue the command:
+ cvs co -r  Fortuna-2_4 Fortuna
-where ''USERID'' is, of course, your repository username, which should be the same as your NASA and NCCS username.  Then, issue the command:
+This should check out the latest stable version of the model from the repository and create a directory called <code>GEOSagcm</code>.
- cvs co -r  Fortuna-2_3 Fortuna
+=== Compiling the Model ===
-This should check out the latest stable version of the model from the repository and create a directory called <code>GEOSagcm</code>.  <code>cd</code> into <code>GEOSagcm/src</code> and <code>source</code> the file called <code>g5_modules</code>:
+<code>cd</code> into <code>GEOSagcm/src</code> and <code>source</code> the file called <code>g5_modules</code>:
   source g5_modules
-If you then type
+This will set up the build environment.  If you then type
   module list
@@ Line 60: / Line 69: @@
 The script produces an experiment directory (''EXPDIR'') in your space as <code>/discover/nobackup/''USERID''/''EXPID''</code>, which contains, among other things, the sub-directories:
-*<code>post</code>  (containing the post-processing job script)
+*<code>post</code>  (containing the incomplete post-processing job script and .rc file)
 *<code>archive</code>  (containing an incomplete archiving job script)
-*<code>plot</code>  (containing an incomplete plotting job script)
+*<code>plot</code>  (containing an incomplete plotting job script and .rc file)
 The post-processing script will complete (i.e., add necessary commands to) the archiving and plotting scripts as it runs.  The setup script that you ran also creates an experiment home directory (''HOMEDIR'') as <code>~''USERID''/geos5/''EXPID''</code>  containing the run scripts and GEOS resource (<code>.rc</code>) files.
@@ Line 72: / Line 81: @@
   unlimit
   limit stacksize unlimited
- source ~/.g5_modules
   set arch = `uname`
   setenv LD_LIBRARY_PATH ${LIBRARY_PATH}:${BASEDIR}/${arch}/lib
-where <code>.g5_modules</code> is simply a copy of the <code>g5_modules</code> that you ran earlier before compiling.  The <code>umask 022</code> is not strictly necessary, but it will make the various files readable to others, which will facilitate data sharing and user support.  Your home directory <code>~''USERID''</code> is also inaccessible to others by default; running <code>chmod 755 ~</code> is helpful.
+The <code>umask 022</code> is not strictly necessary, but it will make the various files readable to others, which will facilitate data sharing and user support.  Your home directory <code>~''USERID''</code> is also inaccessible to others by default; running <code>chmod 755 ~</code> is helpful.
+Copy the restart (initial condition) files and associated <code>cap_restart</code> into ''EXPDIR''.   Keep the "originals" handy since if the job stumbles early in the run it might stop after having renamed them.  The model expects restart filenames to end in "rst" but produces them with the date and time appended, so you may have to rename them.   The <code>cap_restart</code> file is often provided with a set of restarts, but if not you can create it: is simply one line of text with the date of the restart files in the format ''YYYYMMDD''<space>''HHMMSS''.  The boundary conditions/forcings are provided by symbolic links created by the run script.
-Copy the restart (initial condition) files and associated <code>cap_restart</code> into ''EXPDIR''.   Keep the "originals" handy since if the job stumbles early in the run it might stop after having renamed them.  The model expects restart filenames to end in "rst" but produces them with the date and time appended, so you may have to rename them.   The <code>cap_restart</code> file is simply one line of text with the date of the restart files in the format YYYYMMDD<space>HHMMSS.  The boundary conditions/forcings are provided by symbolic links created by the run script.  If you need an arbitrary set of restarts, you can copy them from <code>/archive/u/aeichman/restarts/Fortuna-2_2/</code>.
+If you need an arbitrary set of restarts, you can copy them from <code>/archive/u/aeichman/restarts/Fortuna-2_4/</code>, where they are indexed by date and resolution.
-The script you submit, <code>gcm_run.j</code>, is in ''HOMEDIR''.  It should be ready to go as is.  The parameter END_DATE in <code>CAP.rc</code> (previously in <code>gcm_run.j</code>) can be set to the date you want the run to stop -- this works in Fortuna 2.3 where it did not in Fortuna 2.0.  Also in Fortuna 2.3, you may edit the <code>.rc</code> files directly instead of template  (<code>.tmpl</code>).   An alternative way to stop the run is by commenting out the line <code> if ( $capdate < $enddate ) qsub $HOMDIR/gcm_run.j</code> at the end of the script, which will prevent the script from being resubmitted, or rename the script file.  You may eventually want to tune parameters in the <code>CAP.rc</code> file JOB_SGMT (the number of days per segment, the interval between saving restarts) and NUM_SGMT (the number of segments attempted in a job) to maximize your run time.
+The script you submit, <code>gcm_run.j</code>, is in ''HOMEDIR''.  It should be ready to go as is.  The parameter END_DATE in <code>CAP.rc</code> (previously in <code>gcm_run.j</code>) can be set to the date you want the run to stop.   An alternative way to stop the run is by commenting out the line <code> if ( $capdate < $enddate ) qsub $HOMDIR/gcm_run.j</code> at the end of the script, which will prevent the script from being resubmitted, or rename the script file.  You may eventually want to tune parameters in the <code>CAP.rc</code> file JOB_SGMT (the number of days per segment, the interval between saving restarts) and NUM_SGMT (the number of segments attempted in a job) to maximize your run time.
-Submit the job with <code>qsub gcm_run.j</code>.  You can keep track of it with <code>qstat</code> or <code>qstat | grep ''USERID''</code>, or stdout with <code>tail -f /discover/pbs_spool/''JOBID''.OU</code>, ''JOBID'' being returned by <code>qsub</code> and displayed with <code>qstat</code>.  Jobs can be killed with <code>qdel ''JOBID''</code>.  The standard out and standard error will be delivered as files to the working directory at the time you submitted the job.
+Submit the job with <code>qsub gcm_run.j</code>.  You can keep track of it with <code>qstat</code> or <code>qstat | grep ''USERID''</code>, or follow stdout with <code>tail -f /discover/pbs_spool/''JOBID''.OU</code>, ''JOBID'' being returned by <code>qsub</code> and displayed with <code>qstat</code>.  Jobs can be killed with <code>qdel ''JOBID''</code>.  The standard out and standard error will be delivered as files to the working directory at the time you submitted the job.
 == Output and Plots ==
@@ Line 94: / Line 104: @@
 plotting are:   1) if the month created was February or August,   AND
 ) there are at least 3 monthly average files, then a plotting job for
-the seasons DJF or JJA will be issued.  The plots are created as gifs in <code>''EXPDIR''/plots</code>.
+the seasons DJF or JJA will be issued.  The plots are created as gifs in <code>''EXPDIR''/plots_CLIM</code>.
 The post-processing script can be found in:
@@ Line 100: / Line 110: @@
 The contents of the output files (including which variables get saved) may be configured in the  <code>''HOMEDIR''/HISTORY.rc</code> -- a good description of this file may be found at http://modelingguru.nasa.gov/clearspace/docs/DOC-1190 .
+'''Back to [[GEOS-5 Documentation for Fortuna 2.4]]'''