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

Line 185: Line 185:
'''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 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
For some applications it is desirable to have the model stop running to generate restarts on fixed dates and then start up again.  (Each instance of the model running for some number of days and then stopping and generating restarts is called a ''segment''.) 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 ensure your model runs to the middle of the first month (in practice, the 17th of the month), stopping it, and then from that point to the 1st of the next month.  Here's how: edit '''CAP.rc''' so that
  END_DATE:    20070101 210000
  END_DATE:    20070101 210000
  JOB_SGMT:    00000017 000000
  JOB_SGMT:    00000017 000000
  NUM_SGMT:    12
  NUM_SGMT:    12
substituting the appropriate YYYYMM in END_DATE for the time you want your experiment to end.
substituting the appropriate YYYYMM in END_DATE for the overall time you want your experiment to end.


Edit '''gcm_run.j''' so the following environment variables are set like this
Edit '''gcm_run.j''' so the following environment variables are set like this
Line 196: Line 196:
(By default, STOP_MID_MONTH = 0, which bypasses the logic here).   
(By default, STOP_MID_MONTH = 0, which bypasses the logic here).   


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.
Here's what is happening: overall model control is handled by '''CAP.rc'''.  We specify the model finish time with END_DATE in '''CAP.rc'''.  As set up, JOB_SGMT is the number of days to run the model in a single segment, and NUM_SGMT is the number of segments to run in a single queue submission.  With STOP_MID_MONTH set to '''1''' what happens is that 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 reach the 1st of the next 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'''