Fortuna 2.4 User's Guide: Difference between revisions

Line 187:

When the script <code>gcm_run.j</code> starts running, it creates a directory called <code>scratch</code> and copies or links into it the model executable, rc files, restarts and boundary conditions necessary to run the model. It also creates a directory for each of the output collections (in the default setup with the suffix <code>geosgcm_</code>) in the directory <code>holding</code> for before post-processing, and in the experiment directory for after post-processing. It also tars the restarts and moves the tarball to the <code>restarts</code> directory.

Then the executable <code>GEOSgcm.x</code> is run in the <code>scratch</code> directory for the length of a segment.

Then the executable <code>GEOSgcm.x</code> is run in the <code>scratch</code> directory for the length of a segment, starting with the date in <code>cap_restart</code> .

As explained above, the contents of the <code>cap_restart</code> file determine the start of the model run in model time, which determines boundary conditions and the times stamps of the output. The end time may be set in <code>CAP.rc</code> with the property <code>END_DATE</code> (format ''YYYYMMDD HHMMSS'', with a space), though integration is usually leisurely enough that one can just kill the job or rename the run script <code>gcm_run.j</code> so that it is not resubmitted to the job queue.

Most of the other properties in <code>CAP.rc</code> are discussed elsewhere, but two that are importat for understanding how the batch jobs work are JOB_SGMT: NUM_SGMT:

[[Image:F2.5-job-diagram002.png]]

@@ Line 187: / Line 187: @@
 When the script <code>gcm_run.j</code> starts running, it creates a directory called  <code>scratch</code> and copies or links into it the model executable, rc files, restarts and boundary conditions necessary to run the model.  It also creates a directory for each of the output collections (in the default setup with the suffix <code>geosgcm_</code>) in the directory <code>holding</code> for before post-processing, and in the experiment directory for after post-processing.  It also tars the restarts and moves the tarball to the <code>restarts</code> directory.
-Then the executable  <code>GEOSgcm.x</code> is run in the <code>scratch</code> directory for the length of a segment.
+Then the executable  <code>GEOSgcm.x</code> is run in the <code>scratch</code> directory for the length of a segment, starting with the date in  <code>cap_restart</code> .
+As explained above, the contents of the <code>cap_restart</code> file determine the start of the model run in model time, which determines boundary conditions and the times stamps of the output.  The end time may be set in <code>CAP.rc</code> with the property <code>END_DATE</code>  (format ''YYYYMMDD HHMMSS'', with a space), though integration is usually leisurely enough that one can just kill the job or rename the run script <code>gcm_run.j</code> so that it is not resubmitted to the job queue.
+Most of the other properties in <code>CAP.rc</code> are discussed elsewhere, but two that are importat for understanding how the batch jobs work are JOB_SGMT: NUM_SGMT:
 [[Image:F2.5-job-diagram002.png]]