GEOS-5

GEOS-5 Checkout and Build Instructions (Fortuna): Difference between revisions

← Older editNewer edit →
No edit summary
Line 181: Line 181:


This file doesn't exist here by default, so create it with your favorite editor.  It will have the model start date (ignore BEG_DATE in CAP.rc; if this file exists it supersedes that).  It should just specify YYYYMMDD HHMMSS start time of model run.  For example:
This file doesn't exist here by default, so create it with your favorite editor.  It will have the model start date (ignore BEG_DATE in CAP.rc; if this file exists it supersedes that).  It should just specify YYYYMMDD HHMMSS start time of model run.  For example:
  19991001 210000
  19991231 210000


'''An Optional Modification'''
'''An Optional Modification'''


For some applications it is desirable to have the model end on fixed dates of the month and resubmit.  For example, suppose we want restarts at the beginning and middle of the month.  I've added this functionality, but you need to make a few edits.  What works is to start your model run at the beginning of a month (e.g., cap_restart like the one above).  Then, we'll run the model to the middle of the month, stop it, and resubmit to run to the end of the month.  In practice, this works by running from the 1st of the month to the 17th, stopping, and then running from the 17th to the 1st of the next month.  Here's how: edit '''CAP.rc''' so that
For some applications it is desirable to have the model end on fixed dates of the month and resubmit.  For example, suppose we want restarts at the beginning and middle of the month.  I've added this functionality, but you need to make a few edits.  What works is to start your model run at the beginning of a month (e.g., cap_restart like the one above).  Then, we'll run the model to the middle of the month, stop it, and resubmit to run to the end of the month.  In practice, this works by running through the 17th of some month, stopping, and then running from the 17th to the 1st of the next month.  Here's how: edit '''CAP.rc''' so that
  END_DATE:    19991117 210000
  END_DATE:    20070101 210000
  JOB_SGMT:    00000016 000000
  JOB_SGMT:    00000017 000000
  NUM_SGMT:    1
  NUM_SGMT:    12
substituting the appropriate YYYYMM in END_DATE.
substituting the appropriate YYYYMM in END_DATE for the time you want your experiment to end.


Then:
Edit '''gcm_run.j''' so the following environment variables are set like this
cp CAP.rc CAP.1
cp gcm_run.j gcm_run.1
 
Edit '''gcm_run.1''' so the following environment variables are set like this
  set STOP_MID_MONTH = 1
  set STOP_MID_MONTH = 1
set STOP_DATE = 19991201
set SGMT_NUM = 1
  set DFLT_JOB_SGMT = 16
  set DFLT_JOB_SGMT = 16
where STOP_DATE is the actual date you want the model to be done with you experiment.  (By default, STOP_MID_MONTH = 0, which bypasses the logic here).  This should work provided you can run a half a month in a single job submission.  When it comes time to run, we will
(By default, STOP_MID_MONTH = 0, which bypasses the logic here).   
qsub gcm_run.1
 
and you can ignore '''gcm_run.j'''.  You will get updated files like '''gcm_run.2''' and '''CAP.2''', etc., for each submission of the model.
Here's what is happening: overall model control is handled by '''CAP.rc'''.  Here, we specify the model finish time with END_DATE.  As set up, JOB_SGMT is the number of days to run the model in a single per segment, and NUM_SGMT is the number of times (segments) to repeat that in a single queue submission.  With STOP_MID_MONTH set to '''1''' what happens is the JOB_SGMT environment variable is tweaked for each half-month of the model run.  That is, the first segment runs the initial number of days (in this case, 17) and the next segment runs for however many days are needed to complete the month.  (In this example, I'm presuming we're starting from an initial date of 19991231, which requires us to run for 17 days to cause the model to stop on 20000117, which is the desired monthly mid-point.)  What's really happening is that CAP.rc is being edited after each segment to specify the (hopefully) correct number of days to run the next segment.  Here, NUM_SGMT is set to '''12''', which will run the model for 6 months in a single queue submission (1/2 month per segment). This seems to fit conservatively for our resolution in a single 8-hour wallclock time request.


'''Running on Pleiades'''
'''Running on Pleiades'''
Line 208: Line 202:
This tag has successfully checked out, built, run, and archived results on NAS machine Pleiades.  There seem to be only two modifications to what is described to make, both to the '''gcm_run.j''' script.  First, the PIESA style emissions are located differently on Pleiades, so:
This tag has successfully checked out, built, run, and archived results on NAS machine Pleiades.  There seem to be only two modifications to what is described to make, both to the '''gcm_run.j''' script.  First, the PIESA style emissions are located differently on Pleiades, so:
  setenv CHMDIR  /nobackup/pcolarco/fvInput/AeroCom
  setenv CHMDIR  /nobackup/pcolarco/fvInput/AeroCom
Additionally, if you follow the '''Optional Modifcation''' above, look for the occurrence of the '''caladvance''' script call in '''gcm_run.j'''.  The path to that script is ''/u/pcolarco/bin/caladvance'' on Pleiades.  Don't forgot to copy your '''gcm_run.j''' to '''gcm_run.1''' and submit that job.


=== Setup the Experiment EXPDIR ===
=== Setup the Experiment EXPDIR ===
Retrieved from "https://geos5.org/wiki/index.php?title=GEOS-5_Checkout_and_Build_Instructions_(Fortuna)"