Icarus 1.0 User's Guide: Difference between revisions
Copied from Heracles 5.4 User's Guide, revision 3772 |
Update for Icarus 1.0p1 |
||
| Line 1: | Line 1: | ||
This page describes in detail how to set up and optimize a global model run of GEOS-5 | This page describes in detail how to set up and optimize a global model run of GEOS-5 Icarus 1.0 on NCCS discover and NAS pleiades and generally make the model do what you want. It assumes that you have already run the model as described in [[Icarus 1.0 Quick Start]]. | ||
'''Back to [[GEOS-5 Documentation for | '''Back to [[GEOS-5 Documentation for Icarus 1.0]]''' | ||
== Compiling the Model == | == Compiling the Model == | ||
| Line 9: | Line 9: | ||
cvs co -r ''TAGNAME'' -d ''DIRECTORY'' GEOSagcm | cvs co -r ''TAGNAME'' -d ''DIRECTORY'' GEOSagcm | ||
where ''TAGNAME'' is the model "tag" (version). A tag in <code>cvs</code> marks the various versions of the source files in the repository that together make up a particular version of the model. A sample release tag is <code> | where ''TAGNAME'' is the model "tag" (version). A tag in <code>cvs</code> marks the various versions of the source files in the repository that together make up a particular version of the model. A sample release tag is <code>Icarus-1_0_p1</code>, indicating the latest patch of version Icarus 1.05.4 for general use. ''DIRECTORY'' is the directory that the source code tree will be created. If you are using a stock model tag it is reasonable to name the directory the same as the tag. This directory determines which model in presumably your space a particular experiment is using. Some scripts use the environment variable <code>ESMADIR</code>, which should be set to the absolute (full) pathname of this directory. | ||
When a modified version of some component of the model is saved to the repository, the tag it uses -- different from the standard model tag -- is supposed to be applied at most only to the directories with modified files. This means that if you need to use some variant tag of a gridded component, you will have to <code>cd</code> to that directory and update to the variant tag. So, for example, if you needed to apply updates to the SatSim gridded component, you would have to <code>cd</code> several levels down to the directory <code>GEOSsatsim_GridComp</code> and run | When a modified version of some component of the model is saved to the repository, the tag it uses -- different from the standard model tag -- is supposed to be applied at most only to the directories with modified files. This means that if you need to use some variant tag of a gridded component, you will have to <code>cd</code> to that directory and update to the variant tag. So, for example, if you needed to apply updates to the SatSim gridded component, you would have to <code>cd</code> several levels down to the directory <code>GEOSsatsim_GridComp</code> and run | ||
| Line 20: | Line 20: | ||
== Setting up a Global Model Run == | == Setting up a Global Model Run == | ||
The following describes how to set up a global model run. The procedure to set up a single column model run is described in [[ | The following describes how to set up a global model run. The procedure to set up a single column model run is described in [[Icarus Single Column Model]]. | ||
=== Using <code>gcm_setup</code> === | === Using <code>gcm_setup</code> === | ||
| Line 40: | Line 40: | ||
Enter an Experiment Source Tag for History (Default: | Enter an Experiment Source Tag for History (Default: Icarus-1_0_p1): | ||
| Line 126: | Line 126: | ||
Hit ENTER to use Default Location: | Hit ENTER to use Default Location: | ||
---------------------------------- | ---------------------------------- | ||
Default: /discover/nobackup/mathomp4/ | Default: /discover/nobackup/mathomp4/Icarus-1_0_p1 | ||
This determines which of your local builds is used to create the experiment. It defaults to the build of the script you are running, which is generally a good idea. | This determines which of your local builds is used to create the experiment. It defaults to the build of the script you are running, which is generally a good idea. | ||
| Line 165: | Line 165: | ||
----- | ----- | ||
Build Directory: /discover/nobackup/mathomp4/ | Build Directory: /discover/nobackup/mathomp4/Icarus-1_0_p1 | ||
---------------- | ---------------- | ||
| Line 171: | Line 171: | ||
The following executable has been placed in your Experiment Directory: | The following executable has been placed in your Experiment Directory: | ||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | ||
/discover/nobackup/mathomp4/ | /discover/nobackup/mathomp4/Icarus-1_0_p1/Linux/bin/GEOSgcm.x | ||
| Line 194: | Line 194: | ||
A cleanly completed model run will leave a set of restarts and the corresponding <code>cap_restart</code> in its experiment directory. Another source is <code>/discover/nobackup/mathomp4/Restarts-H10/nc4/</code> which are sample restarts for various resolutions and oceans on 2000-04-14 21z. Restarts are also left during runs in date-labeled tarballs in the <code>restarts</code> directory under the experiment directory before being transferred to the user's <code>/archive</code> space. You may have to create the <code>cap_restart</code>, which is simply one line of text with the date of the restart files in the format ''YYYYMMDD HHMMSS'' (with a space). | A cleanly completed model run will leave a set of restarts and the corresponding <code>cap_restart</code> in its experiment directory. Another source is <code>/discover/nobackup/mathomp4/Restarts-H10/nc4/</code> which are sample restarts for various resolutions and oceans on 2000-04-14 21z. Restarts are also left during runs in date-labeled tarballs in the <code>restarts</code> directory under the experiment directory before being transferred to the user's <code>/archive</code> space. You may have to create the <code>cap_restart</code>, which is simply one line of text with the date of the restart files in the format ''YYYYMMDD HHMMSS'' (with a space). | ||
Failing the above sources, you can convert restarts from different resolutions and model versions, or from MERRA2, as described in [[Regridding Restarts for | Failing the above sources, you can convert restarts from different resolutions and model versions, or from MERRA2, as described in [[Regridding Restarts for Icarus 1.0]]. | ||
== What Happens During a Run == | == What Happens During a Run == | ||
| Line 273: | Line 273: | ||
Setting <code>PRINTSPEC</code> to 3 will make the model send to standard output a list of exports available to <code>HISTORY.rc</code> in the model's current configuration, and then exit without integrating. The list includes each export's gridded component and short name (both necessary to include in <code>HISTORY.rc</code>), long (descriptive) name, units, and number of dimensions. Note that run-time options can affect the exports available, so see to it that you have those set as you intend. The other <code>PRINTSPEC</code> values are useful for debugging. | Setting <code>PRINTSPEC</code> to 3 will make the model send to standard output a list of exports available to <code>HISTORY.rc</code> in the model's current configuration, and then exit without integrating. The list includes each export's gridded component and short name (both necessary to include in <code>HISTORY.rc</code>), long (descriptive) name, units, and number of dimensions. Note that run-time options can affect the exports available, so see to it that you have those set as you intend. The other <code>PRINTSPEC</code> values are useful for debugging. | ||
While you can set <code>PRINTSPEC</code>, submit <code>sbatch gcm_run.j</code>, and get the export list as part of PBS standard output, there are quicker ways of obtaining the list. One way is to run it as a single column model on a single processor, as explained in [[ | While you can set <code>PRINTSPEC</code>, submit <code>sbatch gcm_run.j</code>, and get the export list as part of PBS standard output, there are quicker ways of obtaining the list. One way is to run it as a single column model on a single processor, as explained in [[Icarus Single Column Model]]. Another way is to run it in an existing experiment. In the <code>scratch</code> directory of an experiment that has already run, change <code>PRINTSPEC</code> in <code>CAP.rc</code> as above. Then, in the file <code>AGCM.rc</code>, change the values of <code>NX</code> and <code>NY</code> (near the beginning of the file) to 1. Then, from an interactive job (one processor will suffice), run the executable <code>GEOSgcm.x</code> in <code>scratch</code>. You will need to run <code>source src/g5_modules</code> in the model's build tree to set up the environment. The model executable will simply output the export list to <code>stdout</code>. | ||
===Outputting Derived Fields=== | ===Outputting Derived Fields=== | ||