/[MITgcm]/manual/s_getstarted/text/getting_started.tex
ViewVC logotype

Contents of /manual/s_getstarted/text/getting_started.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph


Revision 1.28 - (show annotations) (download) (as text)
Thu Oct 14 14:54:24 2004 UTC (20 years, 9 months ago) by cnh
Branch: MAIN
Changes since 1.27: +1 -390 lines
File MIME type: application/x-tex
More text moving to put advanced pieces after examples

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

  ViewVC Help
Powered by ViewVC 1.1.22