1 |
% $Header: /u/gcmpack/manual/part3/getting_started.tex,v 1.32 2006/04/05 02:27:33 edhill Exp $ |
2 |
% $Name: $ |
3 |
|
4 |
%\section{Getting started} |
5 |
|
6 |
In this section, we describe how to use the model. In the first |
7 |
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 |
|
19 |
\section{Where to find information} |
20 |
\label{sect:whereToFindInfo} |
21 |
\begin{rawhtml} |
22 |
<!-- CMIREDIR:whereToFindInfo: --> |
23 |
\end{rawhtml} |
24 |
|
25 |
A web site is maintained for release 2 (``Pelican'') of MITgcm: |
26 |
\begin{rawhtml} <A href=http://mitgcm.org/pelican/ target="idontexist"> \end{rawhtml} |
27 |
\begin{verbatim} |
28 |
http://mitgcm.org/pelican |
29 |
\end{verbatim} |
30 |
\begin{rawhtml} </A> \end{rawhtml} |
31 |
Here you will find an on-line version of this document, a |
32 |
``browsable'' copy of the code and a searchable database of the model |
33 |
and site, as well as links for downloading the model and |
34 |
documentation, to data-sources, and other related sites. |
35 |
|
36 |
There is also a web-archived support mailing list for the model that |
37 |
you can email at \texttt{MITgcm-support@mitgcm.org} or browse at: |
38 |
\begin{rawhtml} <A href=http://mitgcm.org/mailman/listinfo/mitgcm-support/ target="idontexist"> \end{rawhtml} |
39 |
\begin{verbatim} |
40 |
http://mitgcm.org/mailman/listinfo/mitgcm-support/ |
41 |
http://mitgcm.org/pipermail/mitgcm-support/ |
42 |
\end{verbatim} |
43 |
\begin{rawhtml} </A> \end{rawhtml} |
44 |
Essentially all of the MITgcm web pages can be searched using a |
45 |
popular web crawler such as Google or through our own search facility: |
46 |
\begin{rawhtml} <A href=http://mitgcm.org/mailman/htdig/ target="idontexist"> \end{rawhtml} |
47 |
\begin{verbatim} |
48 |
http://mitgcm.org/htdig/ |
49 |
\end{verbatim} |
50 |
\begin{rawhtml} </A> \end{rawhtml} |
51 |
%%% http://www.google.com/search?q=hydrostatic+site%3Amitgcm.org |
52 |
|
53 |
|
54 |
|
55 |
\section{Obtaining the code} |
56 |
\label{sect:obtainingCode} |
57 |
\begin{rawhtml} |
58 |
<!-- CMIREDIR:obtainingCode: --> |
59 |
\end{rawhtml} |
60 |
|
61 |
MITgcm can be downloaded from our system by following |
62 |
the instructions below. As a courtesy we ask that you send e-mail to us at |
63 |
\begin{rawhtml} <A href=mailto:MITgcm-support@mitgcm.org> \end{rawhtml} |
64 |
MITgcm-support@mitgcm.org |
65 |
\begin{rawhtml} </A> \end{rawhtml} |
66 |
to enable us to keep track of who's using the model and in what application. |
67 |
You can download the model two ways: |
68 |
|
69 |
\begin{enumerate} |
70 |
\item Using CVS software. CVS is a freely available source code management |
71 |
tool. To use CVS you need to have the software installed. Many systems |
72 |
come with CVS pre-installed, otherwise good places to look for |
73 |
the software for a particular platform are |
74 |
\begin{rawhtml} <A href=http://www.cvshome.org/ target="idontexist"> \end{rawhtml} |
75 |
cvshome.org |
76 |
\begin{rawhtml} </A> \end{rawhtml} |
77 |
and |
78 |
\begin{rawhtml} <A href=http://www.wincvs.org/ target="idontexist"> \end{rawhtml} |
79 |
wincvs.org |
80 |
\begin{rawhtml} </A> \end{rawhtml} |
81 |
. |
82 |
|
83 |
\item Using a tar file. This method is simple and does not |
84 |
require any special software. However, this method does not |
85 |
provide easy support for maintenance updates. |
86 |
|
87 |
\end{enumerate} |
88 |
|
89 |
\subsection{Method 1 - Checkout from CVS} |
90 |
\label{sect:cvs_checkout} |
91 |
|
92 |
If CVS is available on your system, we strongly encourage you to use it. CVS |
93 |
provides an efficient and elegant way of organizing your code and keeping |
94 |
track of your changes. If CVS is not available on your machine, you can also |
95 |
download a tar file. |
96 |
|
97 |
Before you can use CVS, the following environment variable(s) should |
98 |
be set within your shell. For a csh or tcsh shell, put the following |
99 |
\begin{verbatim} |
100 |
% setenv CVSROOT :pserver:cvsanon@mitgcm.org:/u/gcmpack |
101 |
\end{verbatim} |
102 |
in your \texttt{.cshrc} or \texttt{.tcshrc} file. For bash or sh |
103 |
shells, put: |
104 |
\begin{verbatim} |
105 |
% export CVSROOT=':pserver:cvsanon@mitgcm.org:/u/gcmpack' |
106 |
\end{verbatim} |
107 |
in your \texttt{.profile} or \texttt{.bashrc} file. |
108 |
|
109 |
|
110 |
To get MITgcm through CVS, first register with the MITgcm CVS server |
111 |
using command: |
112 |
\begin{verbatim} |
113 |
% cvs login ( CVS password: cvsanon ) |
114 |
\end{verbatim} |
115 |
You only need to do a ``cvs login'' once. |
116 |
|
117 |
To obtain the latest sources type: |
118 |
\begin{verbatim} |
119 |
% cvs co MITgcm |
120 |
\end{verbatim} |
121 |
or to get a specific release type: |
122 |
\begin{verbatim} |
123 |
% cvs co -P -r checkpoint52i_post MITgcm |
124 |
\end{verbatim} |
125 |
The MITgcm web site contains further directions concerning the source |
126 |
code and CVS. It also contains a web interface to our CVS archive so |
127 |
that one may easily view the state of files, revisions, and other |
128 |
development milestones: |
129 |
\begin{rawhtml} <A href=''http://mitgcm.org/download'' target="idontexist"> \end{rawhtml} |
130 |
\begin{verbatim} |
131 |
http://mitgcm.org/source_code.html |
132 |
\end{verbatim} |
133 |
\begin{rawhtml} </A> \end{rawhtml} |
134 |
|
135 |
As a convenience, the MITgcm CVS server contains aliases which are |
136 |
named subsets of the codebase. These aliases can be especially |
137 |
helpful when used over slow internet connections or on machines with |
138 |
restricted storage space. Table \ref{tab:cvsModules} contains a list |
139 |
of CVS aliases |
140 |
\begin{table}[htb] |
141 |
\centering |
142 |
\begin{tabular}[htb]{|lp{3.25in}|}\hline |
143 |
\textbf{Alias Name} & \textbf{Information (directories) Contained} \\\hline |
144 |
\texttt{MITgcm\_code} & Only the source code -- none of the verification examples. \\ |
145 |
\texttt{MITgcm\_verif\_basic} |
146 |
& Source code plus a small set of the verification examples |
147 |
(\texttt{global\_ocean.90x40x15}, \texttt{aim.5l\_cs}, \texttt{hs94.128x64x5}, |
148 |
\texttt{front\_relax}, and \texttt{plume\_on\_slope}). \\ |
149 |
\texttt{MITgcm\_verif\_atmos} & Source code plus all of the atmospheric examples. \\ |
150 |
\texttt{MITgcm\_verif\_ocean} & Source code plus all of the oceanic examples. \\ |
151 |
\texttt{MITgcm\_verif\_all} & Source code plus all of the |
152 |
verification examples. \\\hline |
153 |
\end{tabular} |
154 |
\caption{MITgcm CVS Modules} |
155 |
\label{tab:cvsModules} |
156 |
\end{table} |
157 |
|
158 |
The checkout process creates a directory called \texttt{MITgcm}. If |
159 |
the directory \texttt{MITgcm} exists this command updates your code |
160 |
based on the repository. Each directory in the source tree contains a |
161 |
directory \texttt{CVS}. This information is required by CVS to keep |
162 |
track of your file versions with respect to the repository. Don't edit |
163 |
the files in \texttt{CVS}! You can also use CVS to download code |
164 |
updates. More extensive information on using CVS for maintaining |
165 |
MITgcm code can be found |
166 |
\begin{rawhtml} <A href=''http://mitgcm.org/usingcvstoget.html'' target="idontexist"> \end{rawhtml} |
167 |
here |
168 |
\begin{rawhtml} </A> \end{rawhtml} |
169 |
. |
170 |
It is important to note that the CVS aliases in Table |
171 |
\ref{tab:cvsModules} cannot be used in conjunction with the CVS |
172 |
\texttt{-d DIRNAME} option. However, the \texttt{MITgcm} directories |
173 |
they create can be changed to a different name following the check-out: |
174 |
\begin{verbatim} |
175 |
% cvs co MITgcm_verif_basic |
176 |
% mv MITgcm MITgcm_verif_basic |
177 |
\end{verbatim} |
178 |
|
179 |
|
180 |
\subsection{Method 2 - Tar file download} |
181 |
\label{sect:conventionalDownload} |
182 |
|
183 |
If you do not have CVS on your system, you can download the model as a |
184 |
tar file from the web site at: |
185 |
\begin{rawhtml} <A href=http://mitgcm.org/download target="idontexist"> \end{rawhtml} |
186 |
\begin{verbatim} |
187 |
http://mitgcm.org/download/ |
188 |
\end{verbatim} |
189 |
\begin{rawhtml} </A> \end{rawhtml} |
190 |
The tar file still contains CVS information which we urge you not to |
191 |
delete; even if you do not use CVS yourself the information can help |
192 |
us if you should need to send us your copy of the code. If a recent |
193 |
tar file does not exist, then please contact the developers through |
194 |
the |
195 |
\begin{rawhtml} <A href=''mailto:MITgcm-support@mitgcm.org"> \end{rawhtml} |
196 |
MITgcm-support@mitgcm.org |
197 |
\begin{rawhtml} </A> \end{rawhtml} |
198 |
mailing list. |
199 |
|
200 |
\subsubsection{Upgrading from an earlier version} |
201 |
|
202 |
If you already have an earlier version of the code you can ``upgrade'' |
203 |
your copy instead of downloading the entire repository again. First, |
204 |
``cd'' (change directory) to the top of your working copy: |
205 |
\begin{verbatim} |
206 |
% cd MITgcm |
207 |
\end{verbatim} |
208 |
and then issue the cvs update command such as: |
209 |
\begin{verbatim} |
210 |
% cvs -q update -r checkpoint52i_post -d -P |
211 |
\end{verbatim} |
212 |
This will update the ``tag'' to ``checkpoint52i\_post'', add any new |
213 |
directories (-d) and remove any empty directories (-P). The -q option |
214 |
means be quiet which will reduce the number of messages you'll see in |
215 |
the terminal. If you have modified the code prior to upgrading, CVS |
216 |
will try to merge your changes with the upgrades. If there is a |
217 |
conflict between your modifications and the upgrade, it will report |
218 |
that file with a ``C'' in front, e.g.: |
219 |
\begin{verbatim} |
220 |
C model/src/ini_parms.F |
221 |
\end{verbatim} |
222 |
If the list of conflicts scrolled off the screen, you can re-issue the |
223 |
cvs update command and it will report the conflicts. Conflicts are |
224 |
indicated in the code by the delimites ``$<<<<<<<$'', ``======='' and |
225 |
``$>>>>>>>$''. For example, |
226 |
{\small |
227 |
\begin{verbatim} |
228 |
<<<<<<< ini_parms.F |
229 |
& bottomDragLinear,myOwnBottomDragCoefficient, |
230 |
======= |
231 |
& bottomDragLinear,bottomDragQuadratic, |
232 |
>>>>>>> 1.18 |
233 |
\end{verbatim} |
234 |
} |
235 |
means that you added ``myOwnBottomDragCoefficient'' to a namelist at |
236 |
the same time and place that we added ``bottomDragQuadratic''. You |
237 |
need to resolve this conflict and in this case the line should be |
238 |
changed to: |
239 |
{\small |
240 |
\begin{verbatim} |
241 |
& bottomDragLinear,bottomDragQuadratic,myOwnBottomDragCoefficient, |
242 |
\end{verbatim} |
243 |
} |
244 |
and the lines with the delimiters ($<<<<<<$,======,$>>>>>>$) be deleted. |
245 |
Unless you are making modifications which exactly parallel |
246 |
developments we make, these types of conflicts should be rare. |
247 |
|
248 |
\paragraph*{Upgrading to the current pre-release version} |
249 |
|
250 |
We don't make a ``release'' for every little patch and bug fix in |
251 |
order to keep the frequency of upgrades to a minimum. However, if you |
252 |
have run into a problem for which ``we have already fixed in the |
253 |
latest code'' and we haven't made a ``tag'' or ``release'' since that |
254 |
patch then you'll need to get the latest code: |
255 |
\begin{verbatim} |
256 |
% cvs -q update -A -d -P |
257 |
\end{verbatim} |
258 |
Unlike, the ``check-out'' and ``update'' procedures above, there is no |
259 |
``tag'' or release name. The -A tells CVS to upgrade to the |
260 |
very latest version. As a rule, we don't recommend this since you |
261 |
might upgrade while we are in the processes of checking in the code so |
262 |
that you may only have part of a patch. Using this method of updating |
263 |
also means we can't tell what version of the code you are working |
264 |
with. So please be sure you understand what you're doing. |
265 |
|
266 |
\section{Model and directory structure} |
267 |
\begin{rawhtml} |
268 |
<!-- CMIREDIR:directory_structure: --> |
269 |
\end{rawhtml} |
270 |
|
271 |
The ``numerical'' model is contained within a execution environment |
272 |
support wrapper. This wrapper is designed to provide a general |
273 |
framework for grid-point models. MITgcmUV is a specific numerical |
274 |
model that uses the framework. Under this structure the model is split |
275 |
into execution environment support code and conventional numerical |
276 |
model code. The execution environment support code is held under the |
277 |
\texttt{eesupp} directory. The grid point model code is held under the |
278 |
\texttt{model} directory. Code execution actually starts in the |
279 |
\texttt{eesupp} routines and not in the \texttt{model} routines. For |
280 |
this reason the top-level \texttt{MAIN.F} is in the |
281 |
\texttt{eesupp/src} directory. In general, end-users should not need |
282 |
to worry about this level. The top-level routine for the numerical |
283 |
part of the code is in \texttt{model/src/THE\_MODEL\_MAIN.F}. Here is |
284 |
a brief description of the directory structure of the model under the |
285 |
root tree (a detailed description is given in section 3: Code |
286 |
structure). |
287 |
|
288 |
\begin{itemize} |
289 |
|
290 |
\item \texttt{bin}: this directory is initially empty. It is the |
291 |
default directory in which to compile the code. |
292 |
|
293 |
\item \texttt{diags}: contains the code relative to time-averaged |
294 |
diagnostics. It is subdivided into two subdirectories \texttt{inc} |
295 |
and \texttt{src} that contain include files (\texttt{*.h} files) and |
296 |
Fortran subroutines (\texttt{*.F} files), respectively. |
297 |
|
298 |
\item \texttt{doc}: contains brief documentation notes. |
299 |
|
300 |
\item \texttt{eesupp}: contains the execution environment source code. |
301 |
Also subdivided into two subdirectories \texttt{inc} and |
302 |
\texttt{src}. |
303 |
|
304 |
\item \texttt{exe}: this directory is initially empty. It is the |
305 |
default directory in which to execute the code. |
306 |
|
307 |
\item \texttt{model}: this directory contains the main source code. |
308 |
Also subdivided into two subdirectories \texttt{inc} and |
309 |
\texttt{src}. |
310 |
|
311 |
\item \texttt{pkg}: contains the source code for the packages. Each |
312 |
package corresponds to a subdirectory. For example, \texttt{gmredi} |
313 |
contains the code related to the Gent-McWilliams/Redi scheme, |
314 |
\texttt{aim} the code relative to the atmospheric intermediate |
315 |
physics. The packages are described in detail in section 3. |
316 |
|
317 |
\item \texttt{tools}: this directory contains various useful tools. |
318 |
For example, \texttt{genmake2} is a script written in csh (C-shell) |
319 |
that should be used to generate your makefile. The directory |
320 |
\texttt{adjoint} contains the makefile specific to the Tangent |
321 |
linear and Adjoint Compiler (TAMC) that generates the adjoint code. |
322 |
The latter is described in details in part V. |
323 |
|
324 |
\item \texttt{utils}: this directory contains various utilities. The |
325 |
subdirectory \texttt{knudsen2} contains code and a makefile that |
326 |
compute coefficients of the polynomial approximation to the knudsen |
327 |
formula for an ocean nonlinear equation of state. The |
328 |
\texttt{matlab} subdirectory contains matlab scripts for reading |
329 |
model output directly into matlab. \texttt{scripts} contains C-shell |
330 |
post-processing scripts for joining processor-based and tiled-based |
331 |
model output. |
332 |
|
333 |
\item \texttt{verification}: this directory contains the model |
334 |
examples. See section \ref{sect:modelExamples}. |
335 |
|
336 |
\end{itemize} |
337 |
|
338 |
\section[MITgcm Example Experiments]{Example experiments} |
339 |
\label{sect:modelExamples} |
340 |
\begin{rawhtml} |
341 |
<!-- CMIREDIR:modelExamples: --> |
342 |
\end{rawhtml} |
343 |
|
344 |
%% a set of twenty-four pre-configured numerical experiments |
345 |
|
346 |
The full MITgcm distribution comes with more than a dozen |
347 |
pre-configured numerical experiments. Some of these example |
348 |
experiments are tests of individual parts of the model code, but many |
349 |
are fully fledged numerical simulations. A few of the examples are |
350 |
used for tutorial documentation in sections \ref{sect:eg-baro} - |
351 |
\ref{sect:eg-global}. The other examples follow the same general |
352 |
structure as the tutorial examples. However, they only include brief |
353 |
instructions in a text file called {\it README}. The examples are |
354 |
located in subdirectories under the directory \texttt{verification}. |
355 |
Each example is briefly described below. |
356 |
|
357 |
\subsection{Full list of model examples} |
358 |
|
359 |
\begin{enumerate} |
360 |
|
361 |
\item \texttt{exp0} - single layer, ocean double gyre (barotropic with |
362 |
free-surface). This experiment is described in detail in section |
363 |
\ref{sect:eg-baro}. |
364 |
|
365 |
\item \texttt{exp1} - Four layer, ocean double gyre. This experiment |
366 |
is described in detail in section \ref{sect:eg-baroc}. |
367 |
|
368 |
\item \texttt{exp2} - 4x4 degree global ocean simulation with steady |
369 |
climatological forcing. This experiment is described in detail in |
370 |
section \ref{sect:eg-global}. |
371 |
|
372 |
\item \texttt{exp4} - Flow over a Gaussian bump in open-water or |
373 |
channel with open boundaries. |
374 |
|
375 |
\item \texttt{exp5} - Inhomogenously forced ocean convection in a |
376 |
doubly periodic box. |
377 |
|
378 |
\item \texttt{front\_relax} - Relaxation of an ocean thermal front (test for |
379 |
Gent/McWilliams scheme). 2D (Y-Z). |
380 |
|
381 |
\item \texttt{internal wave} - Ocean internal wave forced by open |
382 |
boundary conditions. |
383 |
|
384 |
\item \texttt{natl\_box} - Eastern subtropical North Atlantic with KPP |
385 |
scheme; 1 month integration |
386 |
|
387 |
\item \texttt{hs94.1x64x5} - Zonal averaged atmosphere using Held and |
388 |
Suarez '94 forcing. |
389 |
|
390 |
\item \texttt{hs94.128x64x5} - 3D atmosphere dynamics using Held and |
391 |
Suarez '94 forcing. |
392 |
|
393 |
\item \texttt{hs94.cs-32x32x5} - 3D atmosphere dynamics using Held and |
394 |
Suarez '94 forcing on the cubed sphere. |
395 |
|
396 |
\item \texttt{aim.5l\_zon-ave} - Intermediate Atmospheric physics. |
397 |
Global Zonal Mean configuration, 1x64x5 resolution. |
398 |
|
399 |
\item \texttt{aim.5l\_XZ\_Equatorial\_Slice} - Intermediate |
400 |
Atmospheric physics, equatorial Slice configuration. 2D (X-Z). |
401 |
|
402 |
\item \texttt{aim.5l\_Equatorial\_Channel} - Intermediate Atmospheric |
403 |
physics. 3D Equatorial Channel configuration. |
404 |
|
405 |
\item \texttt{aim.5l\_LatLon} - Intermediate Atmospheric physics. |
406 |
Global configuration, on latitude longitude grid with 128x64x5 grid |
407 |
points ($2.8^\circ$ resolution). |
408 |
|
409 |
\item \texttt{adjustment.128x64x1} Barotropic adjustment problem on |
410 |
latitude longitude grid with 128x64 grid points ($2.8^\circ$ resolution). |
411 |
|
412 |
\item \texttt{adjustment.cs-32x32x1} Barotropic adjustment problem on |
413 |
cube sphere grid with 32x32 points per face (roughly $2.8^\circ$ |
414 |
resolution). |
415 |
|
416 |
\item \texttt{advect\_cs} Two-dimensional passive advection test on |
417 |
cube sphere grid. |
418 |
|
419 |
\item \texttt{advect\_xy} Two-dimensional (horizontal plane) passive |
420 |
advection test on Cartesian grid. |
421 |
|
422 |
\item \texttt{advect\_yz} Two-dimensional (vertical plane) passive |
423 |
advection test on Cartesian grid. |
424 |
|
425 |
\item \texttt{carbon} Simple passive tracer experiment. Includes |
426 |
derivative calculation. Described in detail in section |
427 |
\ref{sect:eg-carbon-ad}. |
428 |
|
429 |
\item \texttt{flt\_example} Example of using float package. |
430 |
|
431 |
\item \texttt{global\_ocean.90x40x15} Global circulation with GM, flux |
432 |
boundary conditions and poles. |
433 |
|
434 |
\item \texttt{global\_ocean\_pressure} Global circulation in pressure |
435 |
coordinate (non-Boussinesq ocean model). Described in detail in |
436 |
section \ref{sect:eg-globalpressure}. |
437 |
|
438 |
\item \texttt{solid-body.cs-32x32x1} Solid body rotation test for cube |
439 |
sphere grid. |
440 |
|
441 |
\end{enumerate} |
442 |
|
443 |
\subsection{Directory structure of model examples} |
444 |
|
445 |
Each example directory has the following subdirectories: |
446 |
|
447 |
\begin{itemize} |
448 |
\item \texttt{code}: contains the code particular to the example. At a |
449 |
minimum, this directory includes the following files: |
450 |
|
451 |
\begin{itemize} |
452 |
\item \texttt{code/packages.conf}: declares the list of packages or |
453 |
package groups to be used. If not included, the default version |
454 |
is located in \texttt{pkg/pkg\_default}. Package groups are |
455 |
simply convenient collections of commonly used packages which are |
456 |
defined in \texttt{pkg/pkg\_default}. Some packages may require |
457 |
other packages or may require their absence (that is, they are |
458 |
incompatible) and these package dependencies are listed in |
459 |
\texttt{pkg/pkg\_depend}. |
460 |
|
461 |
\item \texttt{code/CPP\_EEOPTIONS.h}: declares CPP keys relative to |
462 |
the ``execution environment'' part of the code. The default |
463 |
version is located in \texttt{eesupp/inc}. |
464 |
|
465 |
\item \texttt{code/CPP\_OPTIONS.h}: declares CPP keys relative to |
466 |
the ``numerical model'' part of the code. The default version is |
467 |
located in \texttt{model/inc}. |
468 |
|
469 |
\item \texttt{code/SIZE.h}: declares size of underlying |
470 |
computational grid. The default version is located in |
471 |
\texttt{model/inc}. |
472 |
\end{itemize} |
473 |
|
474 |
In addition, other include files and subroutines might be present in |
475 |
\texttt{code} depending on the particular experiment. See Section 2 |
476 |
for more details. |
477 |
|
478 |
\item \texttt{input}: contains the input data files required to run |
479 |
the example. At a minimum, the \texttt{input} directory contains the |
480 |
following files: |
481 |
|
482 |
\begin{itemize} |
483 |
\item \texttt{input/data}: this file, written as a namelist, |
484 |
specifies the main parameters for the experiment. |
485 |
|
486 |
\item \texttt{input/data.pkg}: contains parameters relative to the |
487 |
packages used in the experiment. |
488 |
|
489 |
\item \texttt{input/eedata}: this file contains ``execution |
490 |
environment'' data. At present, this consists of a specification |
491 |
of the number of threads to use in $X$ and $Y$ under multithreaded |
492 |
execution. |
493 |
\end{itemize} |
494 |
|
495 |
In addition, you will also find in this directory the forcing and |
496 |
topography files as well as the files describing the initial state |
497 |
of the experiment. This varies from experiment to experiment. See |
498 |
section 2 for more details. |
499 |
|
500 |
\item \texttt{results}: this directory contains the output file |
501 |
\texttt{output.txt} produced by the simulation example. This file is |
502 |
useful for comparison with your own output when you run the |
503 |
experiment. |
504 |
\end{itemize} |
505 |
|
506 |
Once you have chosen the example you want to run, you are ready to |
507 |
compile the code. |
508 |
|
509 |
\section[Building MITgcm]{Building the code} |
510 |
\label{sect:buildingCode} |
511 |
\begin{rawhtml} |
512 |
<!-- CMIREDIR:buildingCode: --> |
513 |
\end{rawhtml} |
514 |
|
515 |
To compile the code, we use the \texttt{make} program. This uses a |
516 |
file (\texttt{Makefile}) that allows us to pre-process source files, |
517 |
specify compiler and optimization options and also figures out any |
518 |
file dependencies. We supply a script (\texttt{genmake2}), described |
519 |
in section \ref{sect:genmake}, that automatically creates the |
520 |
\texttt{Makefile} for you. You then need to build the dependencies and |
521 |
compile the code. |
522 |
|
523 |
As an example, assume that you want to build and run experiment |
524 |
\texttt{verification/exp2}. The are multiple ways and places to |
525 |
actually do this but here let's build the code in |
526 |
\texttt{verification/exp2/build}: |
527 |
\begin{verbatim} |
528 |
% cd verification/exp2/build |
529 |
\end{verbatim} |
530 |
First, build the \texttt{Makefile}: |
531 |
\begin{verbatim} |
532 |
% ../../../tools/genmake2 -mods=../code |
533 |
\end{verbatim} |
534 |
The command line option tells \texttt{genmake} to override model source |
535 |
code with any files in the directory \texttt{../code/}. |
536 |
|
537 |
On many systems, the \texttt{genmake2} program will be able to |
538 |
automatically recognize the hardware, find compilers and other tools |
539 |
within the user's path (``\texttt{echo \$PATH}''), and then choose an |
540 |
appropriate set of options from the files (``optfiles'') contained in |
541 |
the \texttt{tools/build\_options} directory. Under some |
542 |
circumstances, a user may have to create a new ``optfile'' in order to |
543 |
specify the exact combination of compiler, compiler flags, libraries, |
544 |
and other options necessary to build a particular configuration of |
545 |
MITgcm. In such cases, it is generally helpful to read the existing |
546 |
``optfiles'' and mimic their syntax. |
547 |
|
548 |
Through the MITgcm-support list, the MITgcm developers are willing to |
549 |
provide help writing or modifing ``optfiles''. And we encourage users |
550 |
to post new ``optfiles'' (particularly ones for new machines or |
551 |
architectures) to the |
552 |
\begin{rawhtml} <A href=''mailto:MITgcm-support@mitgcm.org"> \end{rawhtml} |
553 |
MITgcm-support@mitgcm.org |
554 |
\begin{rawhtml} </A> \end{rawhtml} |
555 |
list. |
556 |
|
557 |
To specify an optfile to \texttt{genmake2}, the syntax is: |
558 |
\begin{verbatim} |
559 |
% ../../../tools/genmake2 -mods=../code -of /path/to/optfile |
560 |
\end{verbatim} |
561 |
|
562 |
Once a \texttt{Makefile} has been generated, we create the |
563 |
dependencies with the command: |
564 |
\begin{verbatim} |
565 |
% make depend |
566 |
\end{verbatim} |
567 |
This modifies the \texttt{Makefile} by attaching a (usually, long) |
568 |
list of files upon which other files depend. The purpose of this is to |
569 |
reduce re-compilation if and when you start to modify the code. The |
570 |
{\tt make depend} command also creates links from the model source to |
571 |
this directory. It is important to note that the {\tt make depend} |
572 |
stage will occasionally produce warnings or errors since the |
573 |
dependency parsing tool is unable to find all of the necessary header |
574 |
files (\textit{eg.} \texttt{netcdf.inc}). In these circumstances, it |
575 |
is usually OK to ignore the warnings/errors and proceed to the next |
576 |
step. |
577 |
|
578 |
Next one can compile the code using: |
579 |
\begin{verbatim} |
580 |
% make |
581 |
\end{verbatim} |
582 |
The {\tt make} command creates an executable called \texttt{mitgcmuv}. |
583 |
Additional make ``targets'' are defined within the makefile to aid in |
584 |
the production of adjoint and other versions of MITgcm. On SMP |
585 |
(shared multi-processor) systems, the build process can often be sped |
586 |
up appreciably using the command: |
587 |
\begin{verbatim} |
588 |
% make -j 2 |
589 |
\end{verbatim} |
590 |
where the ``2'' can be replaced with a number that corresponds to the |
591 |
number of CPUs available. |
592 |
|
593 |
Now you are ready to run the model. General instructions for doing so are |
594 |
given in section \ref{sect:runModel}. Here, we can run the model by |
595 |
first creating links to all the input files: |
596 |
\begin{verbatim} |
597 |
ln -s ../input/* . |
598 |
\end{verbatim} |
599 |
and then calling the executable with: |
600 |
\begin{verbatim} |
601 |
./mitgcmuv > output.txt |
602 |
\end{verbatim} |
603 |
where we are re-directing the stream of text output to the file |
604 |
\texttt{output.txt}. |
605 |
|
606 |
|
607 |
\section[Running MITgcm]{Running the model in prognostic mode} |
608 |
\label{sect:runModel} |
609 |
\begin{rawhtml} |
610 |
<!-- CMIREDIR:runModel: --> |
611 |
\end{rawhtml} |
612 |
|
613 |
If compilation finished succesfully (section \ref{sect:buildingCode}) |
614 |
then an executable called \texttt{mitgcmuv} will now exist in the |
615 |
local directory. |
616 |
|
617 |
To run the model as a single process (\textit{ie.} not in parallel) |
618 |
simply type: |
619 |
\begin{verbatim} |
620 |
% ./mitgcmuv |
621 |
\end{verbatim} |
622 |
The ``./'' is a safe-guard to make sure you use the local executable |
623 |
in case you have others that exist in your path (surely odd if you |
624 |
do!). The above command will spew out many lines of text output to |
625 |
your screen. This output contains details such as parameter values as |
626 |
well as diagnostics such as mean Kinetic energy, largest CFL number, |
627 |
etc. It is worth keeping this text output with the binary output so we |
628 |
normally re-direct the \texttt{stdout} stream as follows: |
629 |
\begin{verbatim} |
630 |
% ./mitgcmuv > output.txt |
631 |
\end{verbatim} |
632 |
In the event that the model encounters an error and stops, it is very |
633 |
helpful to include the last few line of this \texttt{output.txt} file |
634 |
along with the (\texttt{stderr}) error message within any bug reports. |
635 |
|
636 |
For the example experiments in \texttt{verification}, an example of the |
637 |
output is kept in \texttt{results/output.txt} for comparison. You can |
638 |
compare your \texttt{output.txt} with the corresponding one for that |
639 |
experiment to check that the set-up works. |
640 |
|
641 |
|
642 |
|
643 |
\subsection{Output files} |
644 |
|
645 |
The model produces various output files and, when using \texttt{mnc}, |
646 |
sometimes even directories. Depending upon the I/O package(s) |
647 |
selected at compile time (either \texttt{mdsio} or \texttt{mnc} or |
648 |
both as determined by \texttt{code/packages.conf}) and the run-time |
649 |
flags set (in \texttt{input/data.pkg}), the following output may |
650 |
appear. |
651 |
|
652 |
|
653 |
\subsubsection{MDSIO output files} |
654 |
|
655 |
The ``traditional'' output files are generated by the \texttt{mdsio} |
656 |
package. At a minimum, the instantaneous ``state'' of the model is |
657 |
written out, which is made of the following files: |
658 |
|
659 |
\begin{itemize} |
660 |
\item \texttt{U.00000nIter} - zonal component of velocity field (m/s and $> |
661 |
0 $ eastward). |
662 |
|
663 |
\item \texttt{V.00000nIter} - meridional component of velocity field (m/s |
664 |
and $> 0$ northward). |
665 |
|
666 |
\item \texttt{W.00000nIter} - vertical component of velocity field (ocean: |
667 |
m/s and $> 0$ upward, atmosphere: Pa/s and $> 0$ towards increasing pressure |
668 |
i.e. downward). |
669 |
|
670 |
\item \texttt{T.00000nIter} - potential temperature (ocean: $^{0}$C, |
671 |
atmosphere: $^{0}$K). |
672 |
|
673 |
\item \texttt{S.00000nIter} - ocean: salinity (psu), atmosphere: water vapor |
674 |
(g/kg). |
675 |
|
676 |
\item \texttt{Eta.00000nIter} - ocean: surface elevation (m), atmosphere: |
677 |
surface pressure anomaly (Pa). |
678 |
\end{itemize} |
679 |
|
680 |
The chain \texttt{00000nIter} consists of ten figures that specify the |
681 |
iteration number at which the output is written out. For example, \texttt{% |
682 |
U.0000000300} is the zonal velocity at iteration 300. |
683 |
|
684 |
In addition, a ``pickup'' or ``checkpoint'' file called: |
685 |
|
686 |
\begin{itemize} |
687 |
\item \texttt{pickup.00000nIter} |
688 |
\end{itemize} |
689 |
|
690 |
is written out. This file represents the state of the model in a condensed |
691 |
form and is used for restarting the integration. If the C-D scheme is used, |
692 |
there is an additional ``pickup'' file: |
693 |
|
694 |
\begin{itemize} |
695 |
\item \texttt{pickup\_cd.00000nIter} |
696 |
\end{itemize} |
697 |
|
698 |
containing the D-grid velocity data and that has to be written out as well |
699 |
in order to restart the integration. Rolling checkpoint files are the same |
700 |
as the pickup files but are named differently. Their name contain the chain |
701 |
\texttt{ckptA} or \texttt{ckptB} instead of \texttt{00000nIter}. They can be |
702 |
used to restart the model but are overwritten every other time they are |
703 |
output to save disk space during long integrations. |
704 |
|
705 |
|
706 |
|
707 |
\subsubsection{MNC output files} |
708 |
|
709 |
Unlike the \texttt{mdsio} output, the \texttt{mnc}--generated output |
710 |
is usually (though not necessarily) placed within a subdirectory with |
711 |
a name such as \texttt{mnc\_test\_\${DATE}\_\${SEQ}}. The files |
712 |
within this subdirectory are all in the ``self-describing'' netCDF |
713 |
format and can thus be browsed and/or plotted using tools such as: |
714 |
\begin{itemize} |
715 |
\item \texttt{ncdump} is a utility which is typically included |
716 |
with every netCDF install: |
717 |
\begin{rawhtml} <A href="http://www.unidata.ucar.edu/packages/netcdf/"> \end{rawhtml} |
718 |
\begin{verbatim} |
719 |
http://www.unidata.ucar.edu/packages/netcdf/ |
720 |
\end{verbatim} |
721 |
\begin{rawhtml} </A> \end{rawhtml} and it converts the netCDF |
722 |
binaries into formatted ASCII text files. |
723 |
|
724 |
\item \texttt{ncview} utility is a very convenient and quick way |
725 |
to plot netCDF data and it runs on most OSes: |
726 |
\begin{rawhtml} <A href="http://meteora.ucsd.edu/~pierce/ncview_home_page.html"> \end{rawhtml} |
727 |
\begin{verbatim} |
728 |
http://meteora.ucsd.edu/~pierce/ncview_home_page.html |
729 |
\end{verbatim} |
730 |
\begin{rawhtml} </A> \end{rawhtml} |
731 |
|
732 |
\item MatLAB(c) and other common post-processing environments provide |
733 |
various netCDF interfaces including: |
734 |
\begin{rawhtml} <A href="http://woodshole.er.usgs.gov/staffpages/cdenham/public_html/MexCDF/nc4ml5.html"> \end{rawhtml} |
735 |
\begin{verbatim} |
736 |
http://woodshole.er.usgs.gov/staffpages/cdenham/public_html/MexCDF/nc4ml5.html |
737 |
\end{verbatim} |
738 |
\begin{rawhtml} </A> \end{rawhtml} |
739 |
\end{itemize} |
740 |
|
741 |
|
742 |
\subsection{Looking at the output} |
743 |
|
744 |
The ``traditional'' or mdsio model data are written according to a |
745 |
``meta/data'' file format. Each variable is associated with two files |
746 |
with suffix names \texttt{.data} and \texttt{.meta}. The |
747 |
\texttt{.data} file contains the data written in binary form |
748 |
(big\_endian by default). The \texttt{.meta} file is a ``header'' file |
749 |
that contains information about the size and the structure of the |
750 |
\texttt{.data} file. This way of organizing the output is particularly |
751 |
useful when running multi-processors calculations. The base version of |
752 |
the model includes a few matlab utilities to read output files written |
753 |
in this format. The matlab scripts are located in the directory |
754 |
\texttt{utils/matlab} under the root tree. The script \texttt{rdmds.m} |
755 |
reads the data. Look at the comments inside the script to see how to |
756 |
use it. |
757 |
|
758 |
Some examples of reading and visualizing some output in {\em Matlab}: |
759 |
\begin{verbatim} |
760 |
% matlab |
761 |
>> H=rdmds('Depth'); |
762 |
>> contourf(H');colorbar; |
763 |
>> title('Depth of fluid as used by model'); |
764 |
|
765 |
>> eta=rdmds('Eta',10); |
766 |
>> imagesc(eta');axis ij;colorbar; |
767 |
>> title('Surface height at iter=10'); |
768 |
|
769 |
>> eta=rdmds('Eta',[0:10:100]); |
770 |
>> for n=1:11; imagesc(eta(:,:,n)');axis ij;colorbar;pause(.5);end |
771 |
\end{verbatim} |
772 |
|
773 |
Similar scripts for netCDF output (\texttt{rdmnc.m}) are available and |
774 |
they are described in Section \ref{sec:pkg:mnc}. |
775 |
|