Icarus 2.0 User's Guide: Difference between revisions
m Copied from Icarus 1.0 User's Guide, revision 3900 |
Update for Icarus-2_0 |
||
| Line 1: | Line 1: | ||
This page describes in detail how to set up and optimize a global model run of GEOS-5 Icarus | This page describes in detail how to set up and optimize a global model run of GEOS-5 Icarus 2.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 2.0 Quick Start]]. | ||
'''Back to [[GEOS-5 Documentation for Icarus | '''Back to [[GEOS-5 Documentation for Icarus 2.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>Icarus- | 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-2_0</code>, indicating the latest patch of version Icarus 2.0 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 40: | Line 40: | ||
Enter an Experiment Source Tag for History (Default: Icarus- | Enter an Experiment Source Tag for History (Default: Icarus-2_0): | ||
| Line 126: | Line 126: | ||
Hit ENTER to use Default Location: | Hit ENTER to use Default Location: | ||
---------------------------------- | ---------------------------------- | ||
Default: /discover/nobackup/mathomp4/Icarus- | Default: /discover/nobackup/mathomp4/Icarus-2_0 | ||
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/Icarus- | Build Directory: /discover/nobackup/mathomp4/Icarus-2_0 | ||
---------------- | ---------------- | ||
| 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/Icarus- | /discover/nobackup/mathomp4/Icarus-2_0/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 Icarus | Failing the above sources, you can convert restarts from different resolutions and model versions, or from MERRA2, as described in [[Regridding Restarts for Icarus 2.0]]. | ||
== What Happens During a Run == | == What Happens During a Run == | ||