| 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 |
|
\section{Where to find information} |
| 19 |
|
\label{sect:whereToFindInfo} |
| 20 |
|
|
| 21 |
|
A web site is maintained for release 1 (Sealion) of MITgcm: |
| 22 |
|
\begin{verbatim} |
| 23 |
|
http://mitgcm.org/sealion |
| 24 |
|
\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 |
\vspace*{4mm} |
There is also a support news group for the model that you can email at |
| 31 |
|
\texttt{support@mitgcm.org} or browse at: |
|
\vspace*{3mm} {\large July 2001} |
|
|
\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: |
|
|
\begin{verbatim} |
|
|
http://mitgcm.org |
|
|
\end{verbatim} |
|
|
|
|
|
On this site, you can download the model as well as find useful information, |
|
|
some of which might overlap with what is written here. There is also a |
|
|
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 |
|
|
| 40 |
|
\section{Obtaining the code} |
| 41 |
|
\label{sect:obtainingCode} |
| 42 |
|
|
| 43 |
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 |
| 44 |
provides an efficient and elegant way of organizing your code and keeping |
provides an efficient and elegant way of organizing your code and keeping |
| 45 |
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 |
| 46 |
download a tar file. |
download a tar file. |
| 47 |
|
|
|
\subsubsection{using CVS} |
|
|
|
|
| 48 |
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 |
| 49 |
your .cshrc or .tcshrc: |
your .cshrc or .tcshrc: |
| 50 |
\begin{verbatim} |
\begin{verbatim} |
| 51 |
% setenv CVSROOT :pserver:cvsanon@mitgcm.org:/u/u0/gcmpack |
% setenv CVSROOT :pserver:cvsanon@mitgcm.org:/u/u0/gcmpack |
| 52 |
|
\end{verbatim} |
| 53 |
|
|
| 54 |
|
To start using CVS, "login" to the server using: |
| 55 |
|
\begin{verbatim} |
| 56 |
% cvs login ( CVS password: cvsanon ) |
% cvs login ( CVS password: cvsanon ) |
| 57 |
\end{verbatim} |
\end{verbatim} |
| 58 |
|
You only need to do ``cvs login'' once. |
| 59 |
|
|
| 60 |
You only need to do ``cvs login'' once. To obtain the latest source: |
To obtain the source for the release: |
| 61 |
\begin{verbatim} |
\begin{verbatim} |
| 62 |
% cvs co -d directory models/MITgcmUV |
% cvs co -d directory -P -r release1 MITgcmUV |
| 63 |
\end{verbatim} |
\end{verbatim} |
| 64 |
|
|
| 65 |
This creates a directory called \textit{directory}. If \textit{directory} |
This creates a directory called \textit{directory}. If \textit{directory} |
| 67 |
directory in the source tree contains a directory \textit{CVS}. This |
directory in the source tree contains a directory \textit{CVS}. This |
| 68 |
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 |
| 69 |
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}! To obtain a |
| 70 |
specific \textit{version} that is not the latest source: |
different \textit{version} that is not the latest source: |
| 71 |
|
\begin{verbatim} |
| 72 |
|
% cvs co -d directory -P -r version MITgcm |
| 73 |
|
\end{verbatim} |
| 74 |
|
or the latest development version: |
| 75 |
\begin{verbatim} |
\begin{verbatim} |
| 76 |
% cvs co -d directory -r version models/MITgcmUV |
% cvs co -d directory -P MITgcm |
| 77 |
\end{verbatim} |
\end{verbatim} |
| 78 |
|
|
| 79 |
\subsubsection{other methods} |
\paragraph*{Conventional download method} |
| 80 |
|
\label{sect:conventionalDownload} |
| 81 |
|
|
| 82 |
You can download the model as a tar file from the reference web site at: |
If you do not have CVS on your system, you can download the model as a |
| 83 |
|
tar file from the reference web site at: |
| 84 |
\begin{verbatim} |
\begin{verbatim} |
| 85 |
http://mitgcm.org/download/ |
http://mitgcm.org/download/ |
| 86 |
\end{verbatim} |
\end{verbatim} |
| 87 |
|
The tar file still contains CVS information which we urge you not to |
| 88 |
|
delete; even if you do not use CVS yourself the information can help |
| 89 |
|
us if you should need to send us your copy of the code. |
| 90 |
|
|
| 91 |
\subsection{Model and directory structure} |
\section{Model and directory structure} |
| 92 |
|
|
| 93 |
The ``numerical'' model is contained within a execution environment support |
The ``numerical'' model is contained within a execution environment support |
| 94 |
wrapper. This wrapper is designed to provide a general framework for |
wrapper. This wrapper is designed to provide a general framework for |
| 138 |
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. |
| 139 |
|
|
| 140 |
\item \textit{utils}: this directory contains various utilities. The |
\item \textit{utils}: this directory contains various utilities. The |
| 141 |
subdirectory \textit{knudsen2} contains code and a makefile that compute |
subdirectory \textit{knudsen2} contains code and a makefile that |
| 142 |
coefficients of the polynomial approximation to the knudsen formula for an |
compute coefficients of the polynomial approximation to the knudsen |
| 143 |
ocean nonlinear equation of state. The \textit{matlab} subdirectory contains |
formula for an ocean nonlinear equation of state. The \textit{matlab} |
| 144 |
matlab scripts for reading model output directly into matlab. \textit{scripts% |
subdirectory contains matlab scripts for reading model output directly |
| 145 |
} contains C-shell post-processing scripts for joining processor-based and |
into matlab. \textit{scripts} contains C-shell post-processing |
| 146 |
tiled-based model output. |
scripts for joining processor-based and tiled-based model output. |
| 147 |
|
|
| 148 |
\item \textit{verification}: this directory contains the model examples. See |
\item \textit{verification}: this directory contains the model examples. See |
| 149 |
below. |
section \ref{sect:modelExamples}. |
| 150 |
\end{itemize} |
\end{itemize} |
| 151 |
|
|
| 152 |
\subsection{Model examples} |
\section{Example experiments} |
| 153 |
|
\label{sect:modelExamples} |
| 154 |
|
|
| 155 |
Now that you have successfully downloaded the model code we recommend that |
Now that you have successfully downloaded the model code we recommend that |
| 156 |
you first try to run the examples provided with the base version. You will |
you first try to run the examples provided with the base version. You will |
| 159 |
the directory \textit{verification} and are briefly described below (a full |
the directory \textit{verification} and are briefly described below (a full |
| 160 |
description is given in section 2): |
description is given in section 2): |
| 161 |
|
|
| 162 |
\subsubsection{List of model examples} |
\subsection{List of model examples} |
| 163 |
|
|
| 164 |
\begin{itemize} |
\begin{itemize} |
| 165 |
\item \textit{exp0} - single layer, ocean double gyre (barotropic with |
\item \textit{exp0} - single layer, ocean double gyre (barotropic with |
| 213 |
\item \textit{adjustment.cs-32x32x1} |
\item \textit{adjustment.cs-32x32x1} |
| 214 |
\end{itemize} |
\end{itemize} |
| 215 |
|
|
| 216 |
\subsubsection{Directory structure of model examples} |
\subsection{Directory structure of model examples} |
| 217 |
|
|
| 218 |
Each example directory has the following subdirectories: |
Each example directory has the following subdirectories: |
| 219 |
|
|
| 265 |
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 |
| 266 |
the code. |
the code. |
| 267 |
|
|
| 268 |
\subsection{Compiling the code} |
\section{Building the code} |
| 269 |
|
\label{sect:buildingCode} |
| 270 |
|
|
| 271 |
|
To compile the code, we use the {\em make} program. This uses a file |
| 272 |
|
({\em Makefile}) that allows us to pre-process source files, specify |
| 273 |
|
compiler and optimization options and also figures out any file |
| 274 |
|
dependancies. We supply a script ({\em genmake}), described in section |
| 275 |
|
\ref{sect:genmake}, that automatically creates the {\em Makefile} for |
| 276 |
|
you. You then need to build the dependancies and compile the code. |
| 277 |
|
|
| 278 |
|
As an example, let's assume that you want to build and run experiment |
| 279 |
|
\textit{verification/exp2}. The are multiple ways and places to actually |
| 280 |
|
do this but here let's build the code in |
| 281 |
|
\textit{verification/exp2/input}: |
| 282 |
|
\begin{verbatim} |
| 283 |
|
% cd verification/exp2/input |
| 284 |
|
\end{verbatim} |
| 285 |
|
First, build the {\em Makefile}: |
| 286 |
|
\begin{verbatim} |
| 287 |
|
% ../../../tools/genmake -mods=../code |
| 288 |
|
\end{verbatim} |
| 289 |
|
The command line option tells {\em genmake} to override model source |
| 290 |
|
code with any files in the directory {\em ./code/}. |
| 291 |
|
|
| 292 |
|
If there is no \textit{.genmakerc} in the \textit{input} directory, you have |
| 293 |
|
to use the following options when invoking \textit{genmake}: |
| 294 |
|
\begin{verbatim} |
| 295 |
|
% ../../../tools/genmake -mods=../code |
| 296 |
|
\end{verbatim} |
| 297 |
|
|
| 298 |
|
Next, create the dependancies: |
| 299 |
|
\begin{verbatim} |
| 300 |
|
% make depend |
| 301 |
|
\end{verbatim} |
| 302 |
|
This modifies {\em Makefile} by attaching a [long] list of files on |
| 303 |
|
which other files depend. The purpose of this is to reduce |
| 304 |
|
re-compilation if and when you start to modify the code. {\tt make |
| 305 |
|
depend} also created links from the model source to this directory. |
| 306 |
|
|
| 307 |
|
Now compile the code: |
| 308 |
|
\begin{verbatim} |
| 309 |
|
% make |
| 310 |
|
\end{verbatim} |
| 311 |
|
The {\tt make} command creates an executable called \textit{mitgcmuv}. |
| 312 |
|
|
| 313 |
|
Now you are ready to run the model. General instructions for doing so are |
| 314 |
|
given in section \ref{sect:runModel}. Here, we can run the model with: |
| 315 |
|
\begin{verbatim} |
| 316 |
|
./mitgcmuv > output.txt |
| 317 |
|
\end{verbatim} |
| 318 |
|
where we are re-directing the stream of text output to the file {\em |
| 319 |
|
output.txt}. |
| 320 |
|
|
| 321 |
|
|
| 322 |
|
\subsection{Building/compiling the code elsewhere} |
| 323 |
|
|
| 324 |
|
In the example above (section \ref{sect:buildingCode}) we built the |
| 325 |
|
executable in the {\em input} directory of the experiment for |
| 326 |
|
convenience. You can also configure and compile the code in other |
| 327 |
|
locations, for example on a scratch disk with out having to copy the |
| 328 |
|
entire source tree. The only requirement to do so is you have {\tt |
| 329 |
|
genmake} in your path or you know the absolute path to {\tt genmake}. |
| 330 |
|
|
| 331 |
|
The following sections outline some possible methods of organizing you |
| 332 |
|
source and data. |
| 333 |
|
|
| 334 |
\subsubsection{The script \textit{genmake}} |
\subsubsection{Building from the {\em ../code directory}} |
| 335 |
|
|
| 336 |
|
This is just as simple as building in the {\em input/} directory: |
| 337 |
|
\begin{verbatim} |
| 338 |
|
% cd verification/exp2/code |
| 339 |
|
% ../../../tools/genmake |
| 340 |
|
% make depend |
| 341 |
|
% make |
| 342 |
|
\end{verbatim} |
| 343 |
|
However, to run the model the executable ({\em mitgcmuv}) and input |
| 344 |
|
files must be in the same place. If you only have one calculation to make: |
| 345 |
|
\begin{verbatim} |
| 346 |
|
% cd ../input |
| 347 |
|
% cp ../code/mitgcmuv ./ |
| 348 |
|
% ./mitgcmuv > output.txt |
| 349 |
|
\end{verbatim} |
| 350 |
|
or if you will be making muliple runs with the same executable: |
| 351 |
|
\begin{verbatim} |
| 352 |
|
% cd ../ |
| 353 |
|
% cp -r input run1 |
| 354 |
|
% cp code/mitgcmuv run1 |
| 355 |
|
% cd run1 |
| 356 |
|
% ./mitgcmuv > output.txt |
| 357 |
|
\end{verbatim} |
| 358 |
|
|
| 359 |
|
\subsubsection{Building from a new directory} |
| 360 |
|
|
| 361 |
|
Since the {\em input} directory contains input files it is often more |
| 362 |
|
useful to keep {\em input} prestine and build in a new directory |
| 363 |
|
within {\em verification/exp2/}: |
| 364 |
|
\begin{verbatim} |
| 365 |
|
% cd verification/exp2 |
| 366 |
|
% mkdir build |
| 367 |
|
% cd build |
| 368 |
|
% ../../../tools/genmake -mods=../code |
| 369 |
|
% make depend |
| 370 |
|
% make |
| 371 |
|
\end{verbatim} |
| 372 |
|
This builds the code exactly as before but this time you need to copy |
| 373 |
|
either the executable or the input files or both in order to run the |
| 374 |
|
model. For example, |
| 375 |
|
\begin{verbatim} |
| 376 |
|
% cp ../input/* ./ |
| 377 |
|
% ./mitgcmuv > output.txt |
| 378 |
|
\end{verbatim} |
| 379 |
|
or if you tend to make multiple runs with the same executable then |
| 380 |
|
running in a new directory each time might be more appropriate: |
| 381 |
|
\begin{verbatim} |
| 382 |
|
% cd ../ |
| 383 |
|
% mkdir run1 |
| 384 |
|
% cp build/mitgcmuv run1/ |
| 385 |
|
% cp input/* run1/ |
| 386 |
|
% cd run1 |
| 387 |
|
% ./mitgcmuv > output.txt |
| 388 |
|
\end{verbatim} |
| 389 |
|
|
| 390 |
|
\subsubsection{Building from on a scratch disk} |
| 391 |
|
|
| 392 |
|
Model object files and output data can use up large amounts of disk |
| 393 |
|
space so it is often the case that you will be operating on a large |
| 394 |
|
scratch disk. Assuming the model source is in {\em ~/MITgcm} then the |
| 395 |
|
following commands will build the model in {\em /scratch/exp2-run1}: |
| 396 |
|
\begin{verbatim} |
| 397 |
|
% cd /scratch/exp2-run1 |
| 398 |
|
% ~/MITgcm/tools/genmake -rootdir=~/MITgcm -mods=~/MITgcm/verification/exp2/code |
| 399 |
|
% make depend |
| 400 |
|
% make |
| 401 |
|
\end{verbatim} |
| 402 |
|
To run the model here, you'll need the input files: |
| 403 |
|
\begin{verbatim} |
| 404 |
|
% cp ~/MITgcm/verification/exp2/input/* ./ |
| 405 |
|
% ./mitgcmuv > output.txt |
| 406 |
|
\end{verbatim} |
| 407 |
|
|
| 408 |
|
As before, you could build in one directory and make multiple runs of |
| 409 |
|
the one experiment: |
| 410 |
|
\begin{verbatim} |
| 411 |
|
% cd /scratch/exp2 |
| 412 |
|
% mkdir build |
| 413 |
|
% cd build |
| 414 |
|
% ~/MITgcm/tools/genmake -rootdir=~/MITgcm -mods=~/MITgcm/verification/exp2/code |
| 415 |
|
% make depend |
| 416 |
|
% make |
| 417 |
|
% cd ../ |
| 418 |
|
% cp -r ~/MITgcm/verification/exp2/input run2 |
| 419 |
|
% cd run2 |
| 420 |
|
% ./mitgcmuv > output.txt |
| 421 |
|
\end{verbatim} |
| 422 |
|
|
| 423 |
|
|
| 424 |
|
|
| 425 |
|
\subsection{\textit{genmake}} |
| 426 |
|
\label{sect:genmake} |
| 427 |
|
|
| 428 |
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{% |
| 429 |
tools} directory. \textit{genmake} is a script that generates the makefile. |
tools} directory. \textit{genmake} is a script that generates the makefile. |
| 524 |
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 |
| 525 |
invoking \textit{genmake}. |
invoking \textit{genmake}. |
| 526 |
|
|
|
\subsubsection{Compiling} |
|
| 527 |
|
|
| 528 |
Let's assume that you want to run, say, example \textit{exp2} in the \textit{% |
\section{Running the model} |
| 529 |
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} |
|
| 530 |
|
|
| 531 |
If there is no \textit{.genmakerc} in the \textit{input} directory, you have |
If compilation finished succesfuully (section \ref{sect:buildModel}) |
| 532 |
to use the following options when invoking \textit{genmake}: |
then an executable called {\em mitgcmuv} will now exist in the local |
| 533 |
\begin{verbatim} |
directory. |
|
% ../../../tools/genmake -mods=../code |
|
|
\end{verbatim} |
|
| 534 |
|
|
| 535 |
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 |
| 536 |
again the case of \textit{exp2}, the full \textit{genmake} command will |
type: |
|
probably look like this: |
|
| 537 |
\begin{verbatim} |
\begin{verbatim} |
| 538 |
% ../../../tools/genmake -mods=../code -disable=kpp,gmredi,aim,... |
% ./mitgcmuv |
| 539 |
\end{verbatim} |
\end{verbatim} |
| 540 |
|
The ``./'' is a safe-guard to make sure you use the local executable |
| 541 |
The make command creates an executable called \textit{mitgcmuv}. |
in case you have others that exist in your path (surely odd if you |
| 542 |
|
do!). The above command will spew out many lines of text output to |
| 543 |
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 |
| 544 |
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, |
| 545 |
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 |
| 546 |
\textit{code}: |
normally re-direct the {\em stdout} stream as follows: |
| 547 |
\begin{verbatim} |
\begin{verbatim} |
| 548 |
% cd verification/exp2/code |
% ./mitgcmuv > output.txt |
|
% ../../../tools/genmake |
|
|
% make depend |
|
|
% make |
|
| 549 |
\end{verbatim} |
\end{verbatim} |
| 550 |
|
|
| 551 |
\subsection{Running the model} |
For the example experiments in {\em vericication}, an example of the |
| 552 |
|
output is kept in {\em results/output.txt} for comparison. You can compare |
| 553 |
|
your {\em output.txt} with this one to check that the set-up works. |
| 554 |
|
|
|
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. |
|
| 555 |
|
|
| 556 |
\subsubsection{Output files} |
|
| 557 |
|
\subsection{Output files} |
| 558 |
|
|
| 559 |
The model produces various output files. At a minimum, the instantaneous |
The model produces various output files. At a minimum, the instantaneous |
| 560 |
``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: |
| 605 |
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 |
| 606 |
output to save disk space during long integrations. |
output to save disk space during long integrations. |
| 607 |
|
|
| 608 |
\subsubsection{Looking at the output} |
\subsection{Looking at the output} |
| 609 |
|
|
| 610 |
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. |
| 611 |
Each variable is associated with two files with suffix names \textit{.data} |
Each variable is associated with two files with suffix names \textit{.data} |
| 619 |
\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 |
| 620 |
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. |
| 621 |
|
|
| 622 |
\section{Code structure} |
Some examples of reading and visualizing some output in {\em Matlab}: |
| 623 |
|
\begin{verbatim} |
| 624 |
|
% matlab |
| 625 |
|
>> H=rdmds('Depth'); |
| 626 |
|
>> contourf(H');colorbar; |
| 627 |
|
>> title('Depth of fluid as used by model'); |
| 628 |
|
|
| 629 |
|
>> eta=rdmds('Eta',10); |
| 630 |
|
>> imagesc(eta');axis ij;colorbar; |
| 631 |
|
>> title('Surface height at iter=10'); |
| 632 |
|
|
| 633 |
\section{Doing it yourself: customizing the code} |
>> eta=rdmds('Eta',[0:10:100]); |
| 634 |
|
>> for n=1:11; imagesc(eta(:,:,n)');axis ij;colorbar;pause(.5);end |
| 635 |
|
\end{verbatim} |
| 636 |
|
|
| 637 |
\subsection{\protect\bigskip Configuration and setup} |
\section{Doing it yourself: customizing the code} |
| 638 |
|
|
| 639 |
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 |
| 640 |
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 |
| 644 |
the ''execution environment'' part is covered in the parallel implementation |
the ''execution environment'' part is covered in the parallel implementation |
| 645 |
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. |
| 646 |
|
|
| 647 |
|
\subsection{Configuration and setup} |
| 648 |
|
|
| 649 |
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 |
| 650 |
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{% |
| 651 |
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 |
| 662 |
computational domain, the equations solved in the model, and the simulation |
computational domain, the equations solved in the model, and the simulation |
| 663 |
controls. |
controls. |
| 664 |
|
|
| 665 |
\subsubsection{Computational domain, geometry and time-discretization} |
\subsection{Computational domain, geometry and time-discretization} |
| 666 |
|
|
| 667 |
\begin{itemize} |
\begin{itemize} |
| 668 |
\item dimensions |
\item dimensions |
| 754 |
stagger baroclinic time stepping can be activated by setting the logical |
stagger baroclinic time stepping can be activated by setting the logical |
| 755 |
variable \textbf{staggerTimeStep }to '.\texttt{TRUE}.'. |
variable \textbf{staggerTimeStep }to '.\texttt{TRUE}.'. |
| 756 |
|
|
| 757 |
\subsubsection{Equation of state} |
\subsection{Equation of state} |
| 758 |
|
|
| 759 |
First, because the model equations are written in terms of perturbations, a |
First, because the model equations are written in terms of perturbations, a |
| 760 |
reference thermodynamic state needs to be specified. This is done through |
reference thermodynamic state needs to be specified. This is done through |
| 783 |
values of the vertical levels in \textit{knudsen2.f }so that they match |
values of the vertical levels in \textit{knudsen2.f }so that they match |
| 784 |
those of your configuration). \textit{\ } |
those of your configuration). \textit{\ } |
| 785 |
|
|
| 786 |
\subsubsection{Momentum equations} |
\subsection{Momentum equations} |
| 787 |
|
|
| 788 |
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 |
| 789 |
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. |
| 887 |
\texttt{TRUE}.' and the other to '.\texttt{FALSE}.' depending on how you |
\texttt{TRUE}.' and the other to '.\texttt{FALSE}.' depending on how you |
| 888 |
want to deal with the ocean upper or atmosphere lower boundary). |
want to deal with the ocean upper or atmosphere lower boundary). |
| 889 |
|
|
| 890 |
\subsubsection{Tracer equations} |
\subsection{Tracer equations} |
| 891 |
|
|
| 892 |
This section covers the tracer equations i.e. the potential temperature |
This section covers the tracer equations i.e. the potential temperature |
| 893 |
equation and the salinity (for the ocean) or specific humidity (for the |
equation and the salinity (for the ocean) or specific humidity (for the |
| 978 |
vertically due to static instabilities. Note that \textbf{cadjFreq }and |
vertically due to static instabilities. Note that \textbf{cadjFreq }and |
| 979 |
\textbf{ivdc\_kappa }can not both have non-zero value. |
\textbf{ivdc\_kappa }can not both have non-zero value. |
| 980 |
|
|
| 981 |
\subsubsection{Simulation controls} |
\subsection{Simulation controls} |
| 982 |
|
|
| 983 |
The model ''clock'' is defined by the variable \textbf{deltaTClock }(in s) |
The model ''clock'' is defined by the variable \textbf{deltaTClock }(in s) |
| 984 |
which determines the IO frequencies and is used in tagging output. |
which determines the IO frequencies and is used in tagging output. |