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 | 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'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''' |