| 1 |
% $Header$ |
% $Header$ |
| 2 |
% $Name$ |
% $Name$ |
| 3 |
|
|
| 4 |
|
%\section{Getting started} |
| 5 |
|
|
| 6 |
\begin{center} |
In this section, we describe how to use the model. In the first |
| 7 |
{\Large \textbf{Using the model}} |
section, we provide enough information to help you get started with |
| 8 |
|
the model. We believe the best way to familiarize yourself with the |
| 9 |
|
model is to run the case study examples provided with the base |
| 10 |
|
version. Information on how to obtain, compile, and run the code is |
| 11 |
|
found there as well as a brief description of the model structure |
| 12 |
|
directory and the case study examples. The latter and the code |
| 13 |
|
structure are described more fully in chapters |
| 14 |
|
\ref{chap:discretization} and \ref{chap:sarch}, respectively. Here, in |
| 15 |
|
this section, we provide information on how to customize the code when |
| 16 |
|
you are ready to try implementing the configuration you have in mind. |
| 17 |
|
|
| 18 |
\vspace*{4mm} |
\section{Where to find information} |
| 19 |
|
\label{sect:whereToFindInfo} |
| 20 |
|
|
| 21 |
\vspace*{3mm} {\large July 2001} |
A web site is maintained for release 1 (Sealion) of MITgcm: |
|
\end{center} |
|
|
|
|
|
In this part, we describe how to use the model. In the first section, we |
|
|
provide enough information to help you get started with the model. We |
|
|
believe the best way to familiarize yourself with the model is to run the |
|
|
case study examples provided with the base version. Information on how to |
|
|
obtain, compile, and run the code is found there as well as a brief |
|
|
description of the model structure directory and the case study examples. |
|
|
The latter and the code structure are described more fully in sections 2 and |
|
|
3, respectively. In section 4, we provide information on how to customize |
|
|
the code when you are ready to try implementing the configuration you have |
|
|
in mind. |
|
|
|
|
|
\section{Getting started} |
|
|
|
|
|
\subsection{Obtaining the code} |
|
|
|
|
|
The reference web site for the model is: |
|
| 22 |
\begin{verbatim} |
\begin{verbatim} |
| 23 |
http://mitgcm.org |
http://mitgcm.org/sealion |
| 24 |
\end{verbatim} |
\end{verbatim} |
| 25 |
|
Here you will find an on-line version of this document, a |
| 26 |
|
``browsable'' copy of the code and a searchable database of the model |
| 27 |
|
and site, as well as links for downloading the model and |
| 28 |
|
documentation, to data-sources and other related sites. |
| 29 |
|
|
| 30 |
On this site, you can download the model as well as find useful information, |
There is also a support news group for the model that you can email at |
| 31 |
some of which might overlap with what is written here. There is also a |
\texttt{MITgcm-support@mitgcm.org} or browse at: |
|
support news group for the model located at (send your message to \texttt{% |
|
|
support@mitgcm.org}): |
|
| 32 |
\begin{verbatim} |
\begin{verbatim} |
| 33 |
news://mitgcm.org/mitgcm.support |
news://mitgcm.org/mitgcm.support |
| 34 |
\end{verbatim} |
\end{verbatim} |
| 35 |
|
A mail to the email list will reach all the developers and be archived |
| 36 |
|
on the newsgroup. A users email list will be established at some time |
| 37 |
|
in the future. |
| 38 |
|
|
| 39 |
|
\section{Obtaining the code} |
| 40 |
|
\label{sect:obtainingCode} |
| 41 |
|
|
| 42 |
|
MITgcm can be downloaded from our system by following |
| 43 |
|
the instructions below. As a courtesy we ask that you send e-mail to us at |
| 44 |
|
\begin{rawhtml} <A href=mailto:MITgcm-support@mitgcm.org> \end{rawhtml} |
| 45 |
|
MITgcm-support@mitgcm.org |
| 46 |
|
\begin{rawhtml} </A> \end{rawhtml} |
| 47 |
|
to enable us to keep track of who's using the model and in what application. |
| 48 |
|
You can download the model two ways: |
| 49 |
|
|
| 50 |
|
\begin{enumerate} |
| 51 |
|
\item Using CVS software. CVS is a freely available source code management |
| 52 |
|
tool. To use CVS you need to have the software installed. Many systems |
| 53 |
|
come with CVS pre-installed, otherwise good places to look for |
| 54 |
|
the software for a particular platform are |
| 55 |
|
\begin{rawhtml} <A href=http://www.cvshome.org/ target="idontexist"> \end{rawhtml} |
| 56 |
|
cvshome.org |
| 57 |
|
\begin{rawhtml} </A> \end{rawhtml} |
| 58 |
|
and |
| 59 |
|
\begin{rawhtml} <A href=http://www.wincvs.org/ target="idontexist"> \end{rawhtml} |
| 60 |
|
wincvs.org |
| 61 |
|
\begin{rawhtml} </A> \end{rawhtml} |
| 62 |
|
. |
| 63 |
|
|
| 64 |
|
\item Using a tar file. This method is simple and does not |
| 65 |
|
require any special software. However, this method does not |
| 66 |
|
provide easy support for maintenance updates. |
| 67 |
|
|
| 68 |
|
\end{enumerate} |
| 69 |
|
|
| 70 |
If CVS is available on your system, we strongly encourage you to use it. CVS |
If CVS is available on your system, we strongly encourage you to use it. CVS |
| 71 |
provides an efficient and elegant way of organizing your code and keeping |
provides an efficient and elegant way of organizing your code and keeping |
| 72 |
track of your changes. If CVS is not available on your machine, you can also |
track of your changes. If CVS is not available on your machine, you can also |
| 73 |
download a tar file. |
download a tar file. |
| 74 |
|
|
|
\subsubsection{using CVS} |
|
|
|
|
| 75 |
Before you can use CVS, the following environment variable has to be set in |
Before you can use CVS, the following environment variable has to be set in |
| 76 |
your .cshrc or .tcshrc: |
your .cshrc or .tcshrc: |
| 77 |
\begin{verbatim} |
\begin{verbatim} |
| 78 |
% setenv CVSROOT :pserver:cvsanon@mitgcm.org:/u/u0/gcmpack |
% setenv CVSROOT :pserver:cvsanon@mitgcm.org:/u/u0/gcmpack |
| 79 |
|
\end{verbatim} |
| 80 |
|
|
| 81 |
|
To start using CVS, register with the MITgcm CVS server using command: |
| 82 |
|
\begin{verbatim} |
| 83 |
% cvs login ( CVS password: cvsanon ) |
% cvs login ( CVS password: cvsanon ) |
| 84 |
\end{verbatim} |
\end{verbatim} |
| 85 |
|
You only need to do ``cvs login'' once. |
| 86 |
|
|
| 87 |
You only need to do ``cvs login'' once. To obtain the latest source: |
To obtain the sources for release1 type: |
| 88 |
\begin{verbatim} |
\begin{verbatim} |
| 89 |
% cvs co -d directory models/MITgcmUV |
% cvs co -d directory -P -r release1_beta1 MITgcm |
| 90 |
\end{verbatim} |
\end{verbatim} |
| 91 |
|
|
| 92 |
This creates a directory called \textit{directory}. If \textit{directory} |
This creates a directory called \textit{directory}. If \textit{directory} |
| 93 |
exists this command updates your code based on the repository. Each |
exists this command updates your code based on the repository. Each |
| 94 |
directory in the source tree contains a directory \textit{CVS}. This |
directory in the source tree contains a directory \textit{CVS}. This |
| 95 |
information is required by CVS to keep track of your file versions with |
information is required by CVS to keep track of your file versions with |
| 96 |
respect to the repository. Don't edit the files in \textit{CVS}! To obtain a |
respect to the repository. Don't edit the files in \textit{CVS}! |
| 97 |
specific \textit{version} that is not the latest source: |
You can also use CVS to download code updates. More extensive |
| 98 |
\begin{verbatim} |
information on using CVS for maintaining MITgcm code can be found |
| 99 |
% cvs co -d directory -r version models/MITgcmUV |
\begin{rawhtml} <A href=http://mitgcm.org/usingcvstoget.html target="idontexist"> \end{rawhtml} |
| 100 |
\end{verbatim} |
here |
| 101 |
|
\begin{rawhtml} </A> \end{rawhtml} |
| 102 |
|
. |
| 103 |
|
|
|
\subsubsection{other methods} |
|
| 104 |
|
|
| 105 |
You can download the model as a tar file from the reference web site at: |
\paragraph*{Conventional download method} |
| 106 |
|
\label{sect:conventionalDownload} |
| 107 |
|
|
| 108 |
|
If you do not have CVS on your system, you can download the model as a |
| 109 |
|
tar file from the reference web site at: |
| 110 |
|
\begin{rawhtml} <A href=http://mitgcm.org/download target="idontexist"> \end{rawhtml} |
| 111 |
\begin{verbatim} |
\begin{verbatim} |
| 112 |
http://mitgcm.org/download/ |
http://mitgcm.org/download/ |
| 113 |
\end{verbatim} |
\end{verbatim} |
| 114 |
|
\begin{rawhtml} </A> \end{rawhtml} |
| 115 |
\subsection{Model and directory structure} |
The tar file still contains CVS information which we urge you not to |
| 116 |
|
delete; even if you do not use CVS yourself the information can help |
| 117 |
The ``numerical'' model is contained within a execution environment support |
us if you should need to send us your copy of the code. |
| 118 |
wrapper. This wrapper is designed to provide a general framework for |
|
| 119 |
grid-point models. MITgcmUV is a specific numerical model that uses the |
\paragraph*{Upgrading from an earlier version} |
| 120 |
framework. Under this structure the model is split into execution |
|
| 121 |
environment support code and conventional numerical model code. The |
If you already have an earlier version of the code you can ``upgrade'' |
| 122 |
execution environment support code is held under the \textit{eesupp} |
your copy instead of downloading the entire repository again. First, |
| 123 |
directory. The grid point model code is held under the \textit{model} |
``cd'' (change directory) to the top of your working copy: |
| 124 |
directory. Code execution actually starts in the \textit{eesupp} routines |
\begin{verbatim} |
| 125 |
and not in the \textit{model} routines. For this reason the top-level |
% cd MITgcm |
| 126 |
|
\end{verbatim} |
| 127 |
|
and then issue the cvs update command: |
| 128 |
|
\begin{verbatim} |
| 129 |
|
% cvs -q update -r release1_beta1 -d -P |
| 130 |
|
\end{verbatim} |
| 131 |
|
This will update the ``tag'' to ``release1\_beta1'', add any new |
| 132 |
|
directories (-d) and remove any empty directories (-P). The -q option |
| 133 |
|
means be quiet which will reduce the number of messages you'll see in |
| 134 |
|
the terminal. If you have modified the code prior to upgrading, CVS |
| 135 |
|
will try to merge your changes with the upgrades. If there is a |
| 136 |
|
conflict between your modifications and the upgrade, it will report |
| 137 |
|
that file with a ``C'' in front, e.g.: |
| 138 |
|
\begin{verbatim} |
| 139 |
|
C model/src/ini_parms.F |
| 140 |
|
\end{verbatim} |
| 141 |
|
If the list of conflicts scrolled off the screen, you can re-issue the |
| 142 |
|
cvs update command and it will report the conflicts. Conflicts are |
| 143 |
|
indicated in the code by the delimites ``<<<<<<<'', ``======='' and |
| 144 |
|
``>>>>>>>''. For example, |
| 145 |
|
\begin{verbatim} |
| 146 |
|
<<<<<<< ini_parms.F |
| 147 |
|
& bottomDragLinear,myOwnBottomDragCoefficient, |
| 148 |
|
======= |
| 149 |
|
& bottomDragLinear,bottomDragQuadratic, |
| 150 |
|
>>>>>>> 1.18 |
| 151 |
|
\end{verbatim} |
| 152 |
|
means that you added ``myOwnBottomDragCoefficient'' to a namelist at |
| 153 |
|
the same time and place that we added ``bottomDragQuadratic''. You |
| 154 |
|
need to resolve this conflict and in this case the line should be |
| 155 |
|
changed to: |
| 156 |
|
\begin{verbatim} |
| 157 |
|
& bottomDragLinear,bottomDragQuadratic,myOwnBottomDragCoefficient, |
| 158 |
|
\end{verbatim} |
| 159 |
|
and the lines with the delimiters (<<<<<<,======,>>>>>>) be deleted. |
| 160 |
|
Unless you are making modifications which exactly parallel |
| 161 |
|
developments we make, these types of conflicts should be rare. |
| 162 |
|
|
| 163 |
|
\paragraph*{Upgrading to the current pre-release version} |
| 164 |
|
|
| 165 |
|
We don't make a ``release'' for every little patch and bug fix in |
| 166 |
|
order to keep the frequency of upgrades to a minimum. However, if you |
| 167 |
|
have run into a problem for which ``we have already fixed in the |
| 168 |
|
latest code'' and we haven't made a ``tag'' or ``release'' since that |
| 169 |
|
patch then you'll need to get the latest code: |
| 170 |
|
\begin{verbatim} |
| 171 |
|
% cvs -q update -A -d -P |
| 172 |
|
\end{verbatim} |
| 173 |
|
Unlike, the ``check-out'' and ``update'' procedures above, there is no |
| 174 |
|
``tag'' or release name. The -A tells CVS to upgrade to the |
| 175 |
|
very latest version. As a rule, we don't recommend this since you |
| 176 |
|
might upgrade while we are in the processes of checking in the code so |
| 177 |
|
that you may only have part of a patch. Using this method of updating |
| 178 |
|
also means we can't tell what version of the code you are working |
| 179 |
|
with. So please be sure you understand what you're doing. |
| 180 |
|
|
| 181 |
|
\section{Model and directory structure} |
| 182 |
|
|
| 183 |
|
The ``numerical'' model is contained within a execution environment |
| 184 |
|
support wrapper. This wrapper is designed to provide a general |
| 185 |
|
framework for grid-point models. MITgcmUV is a specific numerical |
| 186 |
|
model that uses the framework. Under this structure the model is split |
| 187 |
|
into execution environment support code and conventional numerical |
| 188 |
|
model code. The execution environment support code is held under the |
| 189 |
|
\textit{eesupp} directory. The grid point model code is held under the |
| 190 |
|
\textit{model} directory. Code execution actually starts in the |
| 191 |
|
\textit{eesupp} routines and not in the \textit{model} routines. For |
| 192 |
|
this reason the top-level |
| 193 |
\textit{MAIN.F} is in the \textit{eesupp/src} directory. In general, |
\textit{MAIN.F} is in the \textit{eesupp/src} directory. In general, |
| 194 |
end-users should not need to worry about this level. The top-level routine |
end-users should not need to worry about this level. The top-level routine |
| 195 |
for the numerical part of the code is in \textit{model/src/THE\_MODEL\_MAIN.F% |
for the numerical part of the code is in \textit{model/src/THE\_MODEL\_MAIN.F% |
| 202 |
|
|
| 203 |
\item \textit{diags}: contains the code relative to time-averaged |
\item \textit{diags}: contains the code relative to time-averaged |
| 204 |
diagnostics. It is subdivided into two subdirectories \textit{inc} and |
diagnostics. It is subdivided into two subdirectories \textit{inc} and |
| 205 |
\textit{src} that contain include files (*.\textit{h} files) and fortran |
\textit{src} that contain include files (*.\textit{h} files) and Fortran |
| 206 |
subroutines (*.\textit{F} files), respectively. |
subroutines (*.\textit{F} files), respectively. |
| 207 |
|
|
| 208 |
\item \textit{doc}: contains brief documentation notes. |
\item \textit{doc}: contains brief documentation notes. |
| 229 |
generates the adjoint code. The latter is described in details in part V. |
generates the adjoint code. The latter is described in details in part V. |
| 230 |
|
|
| 231 |
\item \textit{utils}: this directory contains various utilities. The |
\item \textit{utils}: this directory contains various utilities. The |
| 232 |
subdirectory \textit{knudsen2} contains code and a makefile that compute |
subdirectory \textit{knudsen2} contains code and a makefile that |
| 233 |
coefficients of the polynomial approximation to the knudsen formula for an |
compute coefficients of the polynomial approximation to the knudsen |
| 234 |
ocean nonlinear equation of state. The \textit{matlab} subdirectory contains |
formula for an ocean nonlinear equation of state. The \textit{matlab} |
| 235 |
matlab scripts for reading model output directly into matlab. \textit{scripts% |
subdirectory contains matlab scripts for reading model output directly |
| 236 |
} contains C-shell post-processing scripts for joining processor-based and |
into matlab. \textit{scripts} contains C-shell post-processing |
| 237 |
tiled-based model output. |
scripts for joining processor-based and tiled-based model output. |
| 238 |
|
|
| 239 |
\item \textit{verification}: this directory contains the model examples. See |
\item \textit{verification}: this directory contains the model examples. See |
| 240 |
below. |
section \ref{sect:modelExamples}. |
| 241 |
\end{itemize} |
\end{itemize} |
| 242 |
|
|
| 243 |
\subsection{Model examples} |
\section{Example experiments} |
| 244 |
|
\label{sect:modelExamples} |
| 245 |
|
|
| 246 |
Now that you have successfully downloaded the model code we recommend that |
The MITgcm distribution comes with a set of twenty-four pre-configured |
| 247 |
you first try to run the examples provided with the base version. You will |
numerical experiments. Some of these examples experiments are tests of |
| 248 |
probably want to run the example that is the closest to the configuration |
individual parts of the model code, but many are fully fledged numerical |
| 249 |
you will use eventually. The examples are located in subdirectories under |
simulations. A few of the examples are used for tutorial documentation |
| 250 |
the directory \textit{verification} and are briefly described below (a full |
in sections \ref{sect:eg-baro} - \ref{sect:eg-global}. The other examples |
| 251 |
description is given in section 2): |
follow the same general structure as the tutorial examples. However, |
| 252 |
|
they only include brief instructions in a text file called {\it README}. |
| 253 |
|
The examples are located in subdirectories under |
| 254 |
|
the directory \textit{verification}. Each |
| 255 |
|
example is briefly described below. |
| 256 |
|
|
| 257 |
\subsubsection{List of model examples} |
\subsection{Full list of model examples} |
| 258 |
|
|
| 259 |
\begin{itemize} |
\begin{enumerate} |
| 260 |
\item \textit{exp0} - single layer, ocean double gyre (barotropic with |
\item \textit{exp0} - single layer, ocean double gyre (barotropic with |
| 261 |
free-surface). |
free-surface). This experiment is described in detail in section |
| 262 |
|
\ref{sect:eg-baro}. |
| 263 |
|
|
| 264 |
\item \textit{exp1} - 4 layers, ocean double gyre. |
\item \textit{exp1} - Four layer, ocean double gyre. This experiment is described in detail in section |
| 265 |
|
\ref{sect:eg-baroc}. |
| 266 |
|
|
| 267 |
\item \textit{exp2} - 4x4 degree global ocean simulation with steady |
\item \textit{exp2} - 4x4 degree global ocean simulation with steady |
| 268 |
climatological forcing. |
climatological forcing. This experiment is described in detail in section |
| 269 |
|
\ref{sect:eg-global}. |
| 270 |
|
|
| 271 |
\item \textit{exp4} - flow over a Gaussian bump in open-water or channel |
\item \textit{exp4} - Flow over a Gaussian bump in open-water or channel |
| 272 |
with open boundaries. |
with open boundaries. |
| 273 |
|
|
| 274 |
\item \textit{exp5} - inhomogenously forced ocean convection in a doubly |
\item \textit{exp5} - Inhomogenously forced ocean convection in a doubly |
| 275 |
periodic box. |
periodic box. |
| 276 |
|
|
| 277 |
\item \textit{front\_relax} - relaxation of an ocean thermal front (test for |
\item \textit{front\_relax} - Relaxation of an ocean thermal front (test for |
| 278 |
Gent/McWilliams scheme). 2D (Y-Z). |
Gent/McWilliams scheme). 2D (Y-Z). |
| 279 |
|
|
| 280 |
\item \textit{internal wave} - ocean internal wave forced by open boundary |
\item \textit{internal wave} - Ocean internal wave forced by open boundary |
| 281 |
conditions. |
conditions. |
| 282 |
|
|
| 283 |
\item \textit{natl\_box} - eastern subtropical North Atlantic with KPP |
\item \textit{natl\_box} - Eastern subtropical North Atlantic with KPP |
| 284 |
scheme; 1 month integration |
scheme; 1 month integration |
| 285 |
|
|
| 286 |
\item \textit{hs94.1x64x5} - zonal averaged atmosphere using Held and Suarez |
\item \textit{hs94.1x64x5} - Zonal averaged atmosphere using Held and Suarez |
| 287 |
'94 forcing. |
'94 forcing. |
| 288 |
|
|
| 289 |
\item \textit{hs94.128x64x5} - 3D atmosphere dynamics using Held and Suarez |
\item \textit{hs94.128x64x5} - 3D atmosphere dynamics using Held and Suarez |
| 292 |
\item \textit{hs94.cs-32x32x5} - 3D atmosphere dynamics using Held and |
\item \textit{hs94.cs-32x32x5} - 3D atmosphere dynamics using Held and |
| 293 |
Suarez '94 forcing on the cubed sphere. |
Suarez '94 forcing on the cubed sphere. |
| 294 |
|
|
| 295 |
\item \textit{aim.5l\_zon-ave} - Intermediate Atmospheric physics, 5 layers |
\item \textit{aim.5l\_zon-ave} - Intermediate Atmospheric physics. Global |
| 296 |
Molteni physics package. Global Zonal Mean configuration, 1x64x5 resolution. |
Zonal Mean configuration, 1x64x5 resolution. |
| 297 |
|
|
| 298 |
\item \textit{aim.5l\_XZ\_Equatorial\_Slice} - Intermediate Atmospheric |
\item \textit{aim.5l\_XZ\_Equatorial\_Slice} - Intermediate Atmospheric |
| 299 |
physics, 5 layers Molteni physics package. Equatorial Slice configuration. |
physics, equatorial Slice configuration. |
| 300 |
2D (X-Z). |
2D (X-Z). |
| 301 |
|
|
| 302 |
\item \textit{aim.5l\_Equatorial\_Channel} - Intermediate Atmospheric |
\item \textit{aim.5l\_Equatorial\_Channel} - Intermediate Atmospheric |
| 303 |
physics, 5 layers Molteni physics package. 3D Equatorial Channel |
physics. 3D Equatorial Channel configuration. |
|
configuration (not completely tested). |
|
| 304 |
|
|
| 305 |
\item \textit{aim.5l\_LatLon} - Intermediate Atmospheric physics, 5 layers |
\item \textit{aim.5l\_LatLon} - Intermediate Atmospheric physics. |
| 306 |
Molteni physics package. Global configuration, 128x64x5 resolution. |
Global configuration, on latitude longitude grid with 128x64x5 grid points |
| 307 |
|
($2.8^\circ{\rm degree}$ resolution). |
| 308 |
|
|
| 309 |
\item \textit{adjustment.128x64x1} |
\item \textit{adjustment.128x64x1} Barotropic adjustment |
| 310 |
|
problem on latitude longitude grid with 128x64 grid points ($2.8^\circ{\rm degree}$ resolution). |
| 311 |
|
|
| 312 |
\item \textit{adjustment.cs-32x32x1} |
\item \textit{adjustment.cs-32x32x1} |
| 313 |
\end{itemize} |
Barotropic adjustment |
| 314 |
|
problem on cube sphere grid with 32x32 points per face ( roughly |
| 315 |
|
$2.8^\circ{\rm degree}$ resolution). |
| 316 |
|
|
| 317 |
|
\item \textit{advect\_cs} Two-dimensional passive advection test on |
| 318 |
|
cube sphere grid. |
| 319 |
|
|
| 320 |
|
\item \textit{advect\_xy} Two-dimensional (horizontal plane) passive advection |
| 321 |
|
test on Cartesian grid. |
| 322 |
|
|
| 323 |
|
\item \textit{advect\_yz} Two-dimensional (vertical plane) passive advection test on Cartesian grid. |
| 324 |
|
|
| 325 |
|
\item \textit{carbon} Simple passive tracer experiment. Includes derivative |
| 326 |
|
calculation. Described in detail in section \ref{sect:eg-carbon-ad}. |
| 327 |
|
|
| 328 |
\subsubsection{Directory structure of model examples} |
\item \textit{flt\_example} Example of using float package. |
| 329 |
|
|
| 330 |
|
\item \textit{global\_ocean.90x40x15} Global circulation with |
| 331 |
|
GM, flux boundary conditions and poles. |
| 332 |
|
|
| 333 |
|
\item \textit{global\_ocean\_pressure} Global circulation in pressure |
| 334 |
|
coordinate (non-Boussinesq ocean model). Described in detail in |
| 335 |
|
section \ref{sect:eg-globalpressure}. |
| 336 |
|
|
| 337 |
|
\item \textit{solid-body.cs-32x32x1} Solid body rotation test for cube sphere |
| 338 |
|
grid. |
| 339 |
|
|
| 340 |
|
\end{enumerate} |
| 341 |
|
|
| 342 |
|
\subsection{Directory structure of model examples} |
| 343 |
|
|
| 344 |
Each example directory has the following subdirectories: |
Each example directory has the following subdirectories: |
| 345 |
|
|
| 364 |
code} depending on the particular experiment. See section 2 for more details. |
code} depending on the particular experiment. See section 2 for more details. |
| 365 |
|
|
| 366 |
\item \textit{input}: contains the input data files required to run the |
\item \textit{input}: contains the input data files required to run the |
| 367 |
example. At a mimimum, the \textit{input} directory contains the following |
example. At a minimum, the \textit{input} directory contains the following |
| 368 |
files: |
files: |
| 369 |
|
|
| 370 |
\begin{itemize} |
\begin{itemize} |
| 391 |
Once you have chosen the example you want to run, you are ready to compile |
Once you have chosen the example you want to run, you are ready to compile |
| 392 |
the code. |
the code. |
| 393 |
|
|
| 394 |
\subsection{Compiling the code} |
\section{Building the code} |
| 395 |
|
\label{sect:buildingCode} |
| 396 |
|
|
| 397 |
|
To compile the code, we use the {\em make} program. This uses a file |
| 398 |
|
({\em Makefile}) that allows us to pre-process source files, specify |
| 399 |
|
compiler and optimization options and also figures out any file |
| 400 |
|
dependencies. We supply a script ({\em genmake}), described in section |
| 401 |
|
\ref{sect:genmake}, that automatically creates the {\em Makefile} for |
| 402 |
|
you. You then need to build the dependencies and compile the code. |
| 403 |
|
|
| 404 |
|
As an example, let's assume that you want to build and run experiment |
| 405 |
|
\textit{verification/exp2}. The are multiple ways and places to actually |
| 406 |
|
do this but here let's build the code in |
| 407 |
|
\textit{verification/exp2/input}: |
| 408 |
|
\begin{verbatim} |
| 409 |
|
% cd verification/exp2/input |
| 410 |
|
\end{verbatim} |
| 411 |
|
First, build the {\em Makefile}: |
| 412 |
|
\begin{verbatim} |
| 413 |
|
% ../../../tools/genmake -mods=../code |
| 414 |
|
\end{verbatim} |
| 415 |
|
The command line option tells {\em genmake} to override model source |
| 416 |
|
code with any files in the directory {\em ./code/}. |
| 417 |
|
|
| 418 |
|
If there is no \textit{.genmakerc} in the \textit{input} directory, you have |
| 419 |
|
to use the following options when invoking \textit{genmake}: |
| 420 |
|
\begin{verbatim} |
| 421 |
|
% ../../../tools/genmake -mods=../code |
| 422 |
|
\end{verbatim} |
| 423 |
|
|
| 424 |
|
Next, create the dependencies: |
| 425 |
|
\begin{verbatim} |
| 426 |
|
% make depend |
| 427 |
|
\end{verbatim} |
| 428 |
|
This modifies {\em Makefile} by attaching a [long] list of files on |
| 429 |
|
which other files depend. The purpose of this is to reduce |
| 430 |
|
re-compilation if and when you start to modify the code. {\tt make |
| 431 |
|
depend} also created links from the model source to this directory. |
| 432 |
|
|
| 433 |
|
Now compile the code: |
| 434 |
|
\begin{verbatim} |
| 435 |
|
% make |
| 436 |
|
\end{verbatim} |
| 437 |
|
The {\tt make} command creates an executable called \textit{mitgcmuv}. |
| 438 |
|
|
| 439 |
|
Now you are ready to run the model. General instructions for doing so are |
| 440 |
|
given in section \ref{sect:runModel}. Here, we can run the model with: |
| 441 |
|
\begin{verbatim} |
| 442 |
|
./mitgcmuv > output.txt |
| 443 |
|
\end{verbatim} |
| 444 |
|
where we are re-directing the stream of text output to the file {\em |
| 445 |
|
output.txt}. |
| 446 |
|
|
| 447 |
|
|
| 448 |
|
\subsection{Building/compiling the code elsewhere} |
| 449 |
|
|
| 450 |
|
In the example above (section \ref{sect:buildingCode}) we built the |
| 451 |
|
executable in the {\em input} directory of the experiment for |
| 452 |
|
convenience. You can also configure and compile the code in other |
| 453 |
|
locations, for example on a scratch disk with out having to copy the |
| 454 |
|
entire source tree. The only requirement to do so is you have {\tt |
| 455 |
|
genmake} in your path or you know the absolute path to {\tt genmake}. |
| 456 |
|
|
| 457 |
\subsubsection{The script \textit{genmake}} |
The following sections outline some possible methods of organizing you |
| 458 |
|
source and data. |
| 459 |
|
|
| 460 |
|
\subsubsection{Building from the {\em ../code directory}} |
| 461 |
|
|
| 462 |
|
This is just as simple as building in the {\em input/} directory: |
| 463 |
|
\begin{verbatim} |
| 464 |
|
% cd verification/exp2/code |
| 465 |
|
% ../../../tools/genmake |
| 466 |
|
% make depend |
| 467 |
|
% make |
| 468 |
|
\end{verbatim} |
| 469 |
|
However, to run the model the executable ({\em mitgcmuv}) and input |
| 470 |
|
files must be in the same place. If you only have one calculation to make: |
| 471 |
|
\begin{verbatim} |
| 472 |
|
% cd ../input |
| 473 |
|
% cp ../code/mitgcmuv ./ |
| 474 |
|
% ./mitgcmuv > output.txt |
| 475 |
|
\end{verbatim} |
| 476 |
|
or if you will be making multiple runs with the same executable: |
| 477 |
|
\begin{verbatim} |
| 478 |
|
% cd ../ |
| 479 |
|
% cp -r input run1 |
| 480 |
|
% cp code/mitgcmuv run1 |
| 481 |
|
% cd run1 |
| 482 |
|
% ./mitgcmuv > output.txt |
| 483 |
|
\end{verbatim} |
| 484 |
|
|
| 485 |
|
\subsubsection{Building from a new directory} |
| 486 |
|
|
| 487 |
|
Since the {\em input} directory contains input files it is often more |
| 488 |
|
useful to keep {\em input} pristine and build in a new directory |
| 489 |
|
within {\em verification/exp2/}: |
| 490 |
|
\begin{verbatim} |
| 491 |
|
% cd verification/exp2 |
| 492 |
|
% mkdir build |
| 493 |
|
% cd build |
| 494 |
|
% ../../../tools/genmake -mods=../code |
| 495 |
|
% make depend |
| 496 |
|
% make |
| 497 |
|
\end{verbatim} |
| 498 |
|
This builds the code exactly as before but this time you need to copy |
| 499 |
|
either the executable or the input files or both in order to run the |
| 500 |
|
model. For example, |
| 501 |
|
\begin{verbatim} |
| 502 |
|
% cp ../input/* ./ |
| 503 |
|
% ./mitgcmuv > output.txt |
| 504 |
|
\end{verbatim} |
| 505 |
|
or if you tend to make multiple runs with the same executable then |
| 506 |
|
running in a new directory each time might be more appropriate: |
| 507 |
|
\begin{verbatim} |
| 508 |
|
% cd ../ |
| 509 |
|
% mkdir run1 |
| 510 |
|
% cp build/mitgcmuv run1/ |
| 511 |
|
% cp input/* run1/ |
| 512 |
|
% cd run1 |
| 513 |
|
% ./mitgcmuv > output.txt |
| 514 |
|
\end{verbatim} |
| 515 |
|
|
| 516 |
|
\subsubsection{Building from on a scratch disk} |
| 517 |
|
|
| 518 |
|
Model object files and output data can use up large amounts of disk |
| 519 |
|
space so it is often the case that you will be operating on a large |
| 520 |
|
scratch disk. Assuming the model source is in {\em ~/MITgcm} then the |
| 521 |
|
following commands will build the model in {\em /scratch/exp2-run1}: |
| 522 |
|
\begin{verbatim} |
| 523 |
|
% cd /scratch/exp2-run1 |
| 524 |
|
% ~/MITgcm/tools/genmake -rootdir=~/MITgcm -mods=~/MITgcm/verification/exp2/code |
| 525 |
|
% make depend |
| 526 |
|
% make |
| 527 |
|
\end{verbatim} |
| 528 |
|
To run the model here, you'll need the input files: |
| 529 |
|
\begin{verbatim} |
| 530 |
|
% cp ~/MITgcm/verification/exp2/input/* ./ |
| 531 |
|
% ./mitgcmuv > output.txt |
| 532 |
|
\end{verbatim} |
| 533 |
|
|
| 534 |
|
As before, you could build in one directory and make multiple runs of |
| 535 |
|
the one experiment: |
| 536 |
|
\begin{verbatim} |
| 537 |
|
% cd /scratch/exp2 |
| 538 |
|
% mkdir build |
| 539 |
|
% cd build |
| 540 |
|
% ~/MITgcm/tools/genmake -rootdir=~/MITgcm -mods=~/MITgcm/verification/exp2/code |
| 541 |
|
% make depend |
| 542 |
|
% make |
| 543 |
|
% cd ../ |
| 544 |
|
% cp -r ~/MITgcm/verification/exp2/input run2 |
| 545 |
|
% cd run2 |
| 546 |
|
% ./mitgcmuv > output.txt |
| 547 |
|
\end{verbatim} |
| 548 |
|
|
| 549 |
|
|
| 550 |
|
|
| 551 |
|
\subsection{\textit{genmake}} |
| 552 |
|
\label{sect:genmake} |
| 553 |
|
|
| 554 |
To compile the code, use the script \textit{genmake} located in the \textit{% |
To compile the code, use the script \textit{genmake} located in the \textit{% |
| 555 |
tools} directory. \textit{genmake} is a script that generates the makefile. |
tools} directory. \textit{genmake} is a script that generates the makefile. |
| 650 |
that particular example. In this way you don't need to type the options when |
that particular example. In this way you don't need to type the options when |
| 651 |
invoking \textit{genmake}. |
invoking \textit{genmake}. |
| 652 |
|
|
|
\subsubsection{Compiling} |
|
| 653 |
|
|
| 654 |
Let's assume that you want to run, say, example \textit{exp2} in the \textit{% |
\section{Running the model} |
| 655 |
input} directory. To compile the code, type the following commands from the |
\label{sect:runModel} |
|
model root tree: |
|
|
\begin{verbatim} |
|
|
% cd verification/exp2/input |
|
|
% ../../../tools/genmake |
|
|
% make depend |
|
|
% make |
|
|
\end{verbatim} |
|
| 656 |
|
|
| 657 |
If there is no \textit{.genmakerc} in the \textit{input} directory, you have |
If compilation finished succesfuully (section \ref{sect:buildModel}) |
| 658 |
to use the following options when invoking \textit{genmake}: |
then an executable called {\em mitgcmuv} will now exist in the local |
| 659 |
\begin{verbatim} |
directory. |
|
% ../../../tools/genmake -mods=../code |
|
|
\end{verbatim} |
|
| 660 |
|
|
| 661 |
In addition, you will probably want to disable some of the packages. Taking |
To run the model as a single process (ie. not in parallel) simply |
| 662 |
again the case of \textit{exp2}, the full \textit{genmake} command will |
type: |
|
probably look like this: |
|
| 663 |
\begin{verbatim} |
\begin{verbatim} |
| 664 |
% ../../../tools/genmake -mods=../code -disable=kpp,gmredi,aim,... |
% ./mitgcmuv |
| 665 |
\end{verbatim} |
\end{verbatim} |
| 666 |
|
The ``./'' is a safe-guard to make sure you use the local executable |
| 667 |
The make command creates an executable called \textit{mitgcmuv}. |
in case you have others that exist in your path (surely odd if you |
| 668 |
|
do!). The above command will spew out many lines of text output to |
| 669 |
Note that you can compile and run the code in another directory than \textit{% |
your screen. This output contains details such as parameter values as |
| 670 |
input}. You just need to make sure that you copy the input data files into |
well as diagnostics such as mean Kinetic energy, largest CFL number, |
| 671 |
the directory where you want to run the model. For example to compile from |
etc. It is worth keeping this text output with the binary output so we |
| 672 |
\textit{code}: |
normally re-direct the {\em stdout} stream as follows: |
| 673 |
\begin{verbatim} |
\begin{verbatim} |
| 674 |
% cd verification/exp2/code |
% ./mitgcmuv > output.txt |
|
% ../../../tools/genmake |
|
|
% make depend |
|
|
% make |
|
| 675 |
\end{verbatim} |
\end{verbatim} |
| 676 |
|
|
| 677 |
\subsection{Running the model} |
For the example experiments in {\em vericication}, an example of the |
| 678 |
|
output is kept in {\em results/output.txt} for comparison. You can compare |
| 679 |
|
your {\em output.txt} with this one to check that the set-up works. |
| 680 |
|
|
|
The first thing to do is to run the code by typing \textit{mitgcmuv} and see |
|
|
what happens. You can compare what you get with what is in the \textit{% |
|
|
results} directory. Unless noted otherwise, most examples are set up to run |
|
|
for a few time steps only so that you can quickly figure out whether the |
|
|
model is working or not. |
|
| 681 |
|
|
| 682 |
\subsubsection{Output files} |
|
| 683 |
|
\subsection{Output files} |
| 684 |
|
|
| 685 |
The model produces various output files. At a minimum, the instantaneous |
The model produces various output files. At a minimum, the instantaneous |
| 686 |
``state'' of the model is written out, which is made of the following files: |
``state'' of the model is written out, which is made of the following files: |
| 731 |
used to restart the model but are overwritten every other time they are |
used to restart the model but are overwritten every other time they are |
| 732 |
output to save disk space during long integrations. |
output to save disk space during long integrations. |
| 733 |
|
|
| 734 |
\subsubsection{Looking at the output} |
\subsection{Looking at the output} |
| 735 |
|
|
| 736 |
All the model data are written according to a ``meta/data'' file format. |
All the model data are written according to a ``meta/data'' file format. |
| 737 |
Each variable is associated with two files with suffix names \textit{.data} |
Each variable is associated with two files with suffix names \textit{.data} |
| 745 |
\textit{utils/matlab} under the root tree. The script \textit{rdmds.m} reads |
\textit{utils/matlab} under the root tree. The script \textit{rdmds.m} reads |
| 746 |
the data. Look at the comments inside the script to see how to use it. |
the data. Look at the comments inside the script to see how to use it. |
| 747 |
|
|
| 748 |
\section{Code structure} |
Some examples of reading and visualizing some output in {\em Matlab}: |
| 749 |
|
\begin{verbatim} |
| 750 |
|
% matlab |
| 751 |
|
>> H=rdmds('Depth'); |
| 752 |
|
>> contourf(H');colorbar; |
| 753 |
|
>> title('Depth of fluid as used by model'); |
| 754 |
|
|
| 755 |
|
>> eta=rdmds('Eta',10); |
| 756 |
|
>> imagesc(eta');axis ij;colorbar; |
| 757 |
|
>> title('Surface height at iter=10'); |
| 758 |
|
|
| 759 |
\section{Doing it yourself: customizing the code} |
>> eta=rdmds('Eta',[0:10:100]); |
| 760 |
|
>> for n=1:11; imagesc(eta(:,:,n)');axis ij;colorbar;pause(.5);end |
| 761 |
|
\end{verbatim} |
| 762 |
|
|
| 763 |
\subsection{\protect\bigskip Configuration and setup} |
\section{Doing it yourself: customizing the code} |
| 764 |
|
|
| 765 |
When you are ready to run the model in the configuration you want, the |
When you are ready to run the model in the configuration you want, the |
| 766 |
easiest thing is to use and adapt the setup of the case studies experiment |
easiest thing is to use and adapt the setup of the case studies experiment |
| 770 |
the ''execution environment'' part is covered in the parallel implementation |
the ''execution environment'' part is covered in the parallel implementation |
| 771 |
section) and on the variables and parameters that you are likely to change. |
section) and on the variables and parameters that you are likely to change. |
| 772 |
|
|
| 773 |
|
\subsection{Configuration and setup} |
| 774 |
|
|
| 775 |
The CPP keys relative to the ''numerical model'' part of the code are all |
The CPP keys relative to the ''numerical model'' part of the code are all |
| 776 |
defined and set in the file \textit{CPP\_OPTIONS.h }in the directory \textit{% |
defined and set in the file \textit{CPP\_OPTIONS.h }in the directory \textit{% |
| 777 |
model/inc }or in one of the \textit{code }directories of the case study |
model/inc }or in one of the \textit{code }directories of the case study |
| 788 |
computational domain, the equations solved in the model, and the simulation |
computational domain, the equations solved in the model, and the simulation |
| 789 |
controls. |
controls. |
| 790 |
|
|
| 791 |
\subsubsection{Computational domain, geometry and time-discretization} |
\subsection{Computational domain, geometry and time-discretization} |
| 792 |
|
|
| 793 |
\begin{itemize} |
\begin{itemize} |
| 794 |
\item dimensions |
\item dimensions |
| 871 |
\item time-discretization |
\item time-discretization |
| 872 |
\end{itemize} |
\end{itemize} |
| 873 |
|
|
| 874 |
The time steps are set through the real variables \textbf{deltaTMom }and |
The time steps are set through the real variables \textbf{deltaTMom} |
| 875 |
\textbf{deltaTtracer }(in s) which represent the time step for the momentum |
and \textbf{deltaTtracer} (in s) which represent the time step for the |
| 876 |
and tracer equations, respectively. For synchronous integrations, simply set |
momentum and tracer equations, respectively. For synchronous |
| 877 |
the two variables to the same value (or you can prescribe one time step only |
integrations, simply set the two variables to the same value (or you |
| 878 |
through the variable \textbf{deltaT}). The Adams-Bashforth stabilizing |
can prescribe one time step only through the variable |
| 879 |
parameter is set through the variable \textbf{abEps }(dimensionless). The |
\textbf{deltaT}). The Adams-Bashforth stabilizing parameter is set |
| 880 |
stagger baroclinic time stepping can be activated by setting the logical |
through the variable \textbf{abEps} (dimensionless). The stagger |
| 881 |
variable \textbf{staggerTimeStep }to '.\texttt{TRUE}.'. |
baroclinic time stepping can be activated by setting the logical |
| 882 |
|
variable \textbf{staggerTimeStep} to '.\texttt{TRUE}.'. |
| 883 |
\subsubsection{Equation of state} |
|
| 884 |
|
\subsection{Equation of state} |
| 885 |
First, because the model equations are written in terms of perturbations, a |
|
| 886 |
reference thermodynamic state needs to be specified. This is done through |
First, because the model equations are written in terms of |
| 887 |
the 1D arrays \textbf{tRef}\textit{\ }and \textbf{sRef}. \textbf{tRef }% |
perturbations, a reference thermodynamic state needs to be specified. |
| 888 |
specifies the reference potential temperature profile (in $^{o}$C for |
This is done through the 1D arrays \textbf{tRef} and \textbf{sRef}. |
| 889 |
the ocean and $^{o}$K for the atmosphere) starting from the level |
\textbf{tRef} specifies the reference potential temperature profile |
| 890 |
k=1. Similarly, \textbf{sRef}\textit{\ }specifies the reference salinity |
(in $^{o}$C for the ocean and $^{o}$K for the atmosphere) starting |
| 891 |
profile (in ppt) for the ocean or the reference specific humidity profile |
from the level k=1. Similarly, \textbf{sRef} specifies the reference |
| 892 |
(in g/kg) for the atmosphere. |
salinity profile (in ppt) for the ocean or the reference specific |
| 893 |
|
humidity profile (in g/kg) for the atmosphere. |
| 894 |
The form of the equation of state is controlled by the character variables |
|
| 895 |
\textbf{buoyancyRelation}\textit{\ }and \textbf{eosType}\textit{. }\textbf{% |
The form of the equation of state is controlled by the character |
| 896 |
buoyancyRelation}\textit{\ }is set to '\texttt{OCEANIC}' by default and |
variables \textbf{buoyancyRelation} and \textbf{eosType}. |
| 897 |
needs to be set to '\texttt{ATMOSPHERIC}' for atmosphere simulations. In |
\textbf{buoyancyRelation} is set to '\texttt{OCEANIC}' by default and |
| 898 |
this case, \textbf{eosType}\textit{\ }must be set to '\texttt{IDEALGAS}'. |
needs to be set to '\texttt{ATMOSPHERIC}' for atmosphere simulations. |
| 899 |
For the ocean, two forms of the equation of state are available: linear (set |
In this case, \textbf{eosType} must be set to '\texttt{IDEALGAS}'. |
| 900 |
\textbf{eosType}\textit{\ }to '\texttt{LINEAR}') and a polynomial |
For the ocean, two forms of the equation of state are available: |
| 901 |
approximation to the full nonlinear equation ( set \textbf{eosType}\textit{\ |
linear (set \textbf{eosType} to '\texttt{LINEAR}') and a polynomial |
| 902 |
}to '\texttt{POLYNOMIAL}'). In the linear case, you need to specify the |
approximation to the full nonlinear equation ( set |
| 903 |
thermal and haline expansion coefficients represented by the variables |
\textbf{eosType}\textit{\ }to '\texttt{POLYNOMIAL}'). In the linear |
| 904 |
\textbf{tAlpha}\textit{\ }(in K$^{-1}$) and \textbf{sBeta}\textit{\ }(in ppt$% |
case, you need to specify the thermal and haline expansion |
| 905 |
^{-1}$). For the nonlinear case, you need to generate a file of polynomial |
coefficients represented by the variables \textbf{tAlpha}\textit{\ |
| 906 |
coefficients called \textit{POLY3.COEFFS. }To do this, use the program |
}(in K$^{-1}$) and \textbf{sBeta} (in ppt$^{-1}$). For the nonlinear |
| 907 |
\textit{utils/knudsen2/knudsen2.f }under the model tree (a Makefile is |
case, you need to generate a file of polynomial coefficients called |
| 908 |
available in the same directory and you will need to edit the number and the |
\textit{POLY3.COEFFS}. To do this, use the program |
| 909 |
values of the vertical levels in \textit{knudsen2.f }so that they match |
\textit{utils/knudsen2/knudsen2.f} under the model tree (a Makefile is |
| 910 |
those of your configuration). \textit{\ } |
available in the same directory and you will need to edit the number |
| 911 |
|
and the values of the vertical levels in \textit{knudsen2.f} so that |
| 912 |
|
they match those of your configuration). |
| 913 |
|
|
| 914 |
|
There there are also higher polynomials for the equation of state: |
| 915 |
|
\begin{description} |
| 916 |
|
\item['\texttt{UNESCO}':] The UNESCO equation of state formula of |
| 917 |
|
Fofonoff and Millard \cite{fofonoff83}. This equation of state |
| 918 |
|
assumes in-situ temperature, which is not a model variable; \emph{its use |
| 919 |
|
is therefore discouraged, and it is only listed for completeness}. |
| 920 |
|
\item['\texttt{JMD95Z}':] A modified UNESCO formula by Jackett and |
| 921 |
|
McDougall \cite{jackett95}, which uses the model variable potential |
| 922 |
|
temperature as input. The '\texttt{Z}' indicates that this equation |
| 923 |
|
of state uses a horizontally and temporally constant pressure |
| 924 |
|
$p_{0}=-g\rho_{0}z$. |
| 925 |
|
\item['\texttt{JMD95P}':] A modified UNESCO formula by Jackett and |
| 926 |
|
McDougall \cite{jackett95}, which uses the model variable potential |
| 927 |
|
temperature as input. The '\texttt{P}' indicates that this equation |
| 928 |
|
of state uses the actual hydrostatic pressure of the last time |
| 929 |
|
step. Lagging the pressure in this way requires an additional pickup |
| 930 |
|
file for restarts. |
| 931 |
|
\item['\texttt{MDJWF}':] The new, more accurate and less expensive |
| 932 |
|
equation of state by McDougall et~al. \cite{mcdougall03}. It also |
| 933 |
|
requires lagging the pressure and therefore an additional pickup |
| 934 |
|
file for restarts. |
| 935 |
|
\end{description} |
| 936 |
|
For none of these options an reference profile of temperature or |
| 937 |
|
salinity is required. |
| 938 |
|
|
| 939 |
\subsubsection{Momentum equations} |
\subsection{Momentum equations} |
| 940 |
|
|
| 941 |
In this section, we only focus for now on the parameters that you are likely |
In this section, we only focus for now on the parameters that you are likely |
| 942 |
to change, i.e. the ones relative to forcing and dissipation for example. |
to change, i.e. the ones relative to forcing and dissipation for example. |
| 1040 |
\texttt{TRUE}.' and the other to '.\texttt{FALSE}.' depending on how you |
\texttt{TRUE}.' and the other to '.\texttt{FALSE}.' depending on how you |
| 1041 |
want to deal with the ocean upper or atmosphere lower boundary). |
want to deal with the ocean upper or atmosphere lower boundary). |
| 1042 |
|
|
| 1043 |
\subsubsection{Tracer equations} |
\subsection{Tracer equations} |
| 1044 |
|
|
| 1045 |
This section covers the tracer equations i.e. the potential temperature |
This section covers the tracer equations i.e. the potential temperature |
| 1046 |
equation and the salinity (for the ocean) or specific humidity (for the |
equation and the salinity (for the ocean) or specific humidity (for the |
| 1131 |
vertically due to static instabilities. Note that \textbf{cadjFreq }and |
vertically due to static instabilities. Note that \textbf{cadjFreq }and |
| 1132 |
\textbf{ivdc\_kappa }can not both have non-zero value. |
\textbf{ivdc\_kappa }can not both have non-zero value. |
| 1133 |
|
|
| 1134 |
\subsubsection{Simulation controls} |
\subsection{Simulation controls} |
| 1135 |
|
|
| 1136 |
The model ''clock'' is defined by the variable \textbf{deltaTClock }(in s) |
The model ''clock'' is defined by the variable \textbf{deltaTClock }(in s) |
| 1137 |
which determines the IO frequencies and is used in tagging output. |
which determines the IO frequencies and is used in tagging output. |
| 1167 |
The precision with which to write the binary data is controlled by the |
The precision with which to write the binary data is controlled by the |
| 1168 |
integer variable w\textbf{riteBinaryPrec }(set it to \texttt{32} or \texttt{% |
integer variable w\textbf{riteBinaryPrec }(set it to \texttt{32} or \texttt{% |
| 1169 |
64}). |
64}). |
| 1170 |
|
|
| 1171 |
|
%%% Local Variables: |
| 1172 |
|
%%% mode: latex |
| 1173 |
|
%%% TeX-master: t |
| 1174 |
|
%%% End: |
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch