Icarus 2.0 User's Guide: Difference between revisions
Update for Icarus-2_0 |
m Update for Icarus-2_0_p1 |
||
| (One intermediate revision by the same user not shown) | |||
| 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_p1</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_p1): | ||
| 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_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/Icarus- | Build Directory: /discover/nobackup/mathomp4/Icarus-2_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/Icarus- | /discover/nobackup/mathomp4/Icarus-2_0_p1/Linux/bin/GEOSgcm.x | ||
| Line 192: | Line 192: | ||
Restart files provide the initial conditions for a run, and a set needs to be copied into a fresh experiment directory before running. This includes the file <code>cap_restart</code>, which provides the model starting date and time in text. Restart files themselves are resolution-specific and sometimes change between model versions. As of the current model version, they are now netcdf files with metadata instead of the previous flat binary files but typically have the same naming convention, so they tend to be stored together with restarts of the same provenance with the date either embedded in the filename or in an accompanying <code>cap_restart</code>, typically under a directory indicating the model version. If you have restarts from a previous model version it may be worthwhile to try running with them as the model will check to see if they are in netcdf format, and if not, convert them. | Restart files provide the initial conditions for a run, and a set needs to be copied into a fresh experiment directory before running. This includes the file <code>cap_restart</code>, which provides the model starting date and time in text. Restart files themselves are resolution-specific and sometimes change between model versions. As of the current model version, they are now netcdf files with metadata instead of the previous flat binary files but typically have the same naming convention, so they tend to be stored together with restarts of the same provenance with the date either embedded in the filename or in an accompanying <code>cap_restart</code>, typically under a directory indicating the model version. If you have restarts from a previous model version it may be worthwhile to try running with them as the model will check to see if they are in netcdf format, and if not, convert them. | ||
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- | 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-I10/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 2.0]]. | 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]]. | ||