1 |
molod |
1.6 |
% $Header: /u/gcmpack/manual/part6/packages.tex,v 1.5 2004/10/13 12:27:57 cnh Exp $ |
2 |
edhill |
1.1 |
% $Name: $ |
3 |
|
|
|
4 |
|
|
\section{Using MITgcm Packages} |
5 |
edhill |
1.4 |
\label{sec:pkg:using} |
6 |
|
|
\begin{rawhtml} |
7 |
|
|
<!-- CMIREDIR:package_using: --> |
8 |
|
|
\end{rawhtml} |
9 |
edhill |
1.1 |
|
10 |
|
|
The set of packages that will be used within a partiucular model can |
11 |
|
|
be configured using a combination of both ``compile--time'' and |
12 |
|
|
``run--time'' options. Compile--time options are those used to select |
13 |
|
|
which packages will be ``compiled in'' or implemented within the |
14 |
|
|
program. Packages excluded at compile time are completely absent from |
15 |
|
|
the executable program(s) and thus cannot be later activated by any |
16 |
|
|
set of subsequent run--time options. |
17 |
|
|
|
18 |
|
|
\subsection{Package Inclusion/Exclusion} |
19 |
|
|
|
20 |
|
|
There are numerous ways that one can specify compile--time package |
21 |
|
|
inclusion or exclusion and they are all implemented by the |
22 |
|
|
\texttt{genmake2} program which was previously described in Section |
23 |
|
|
\ref{sect:buildingCode}. The options are as follows: |
24 |
|
|
\begin{enumerate} |
25 |
|
|
\item Setting the \texttt{genamake2} options \texttt{--enable PKG} |
26 |
|
|
and/or \texttt{--disable PKG} specifies inclusion or exclusion. |
27 |
|
|
This method is intended as a convenient way to perform a single |
28 |
|
|
(perhaps for a quick test) compilation. |
29 |
|
|
|
30 |
|
|
\item By creating a text file with the name \texttt{packages.conf} in |
31 |
|
|
either the local build directory or the \texttt{-mods=DIR} |
32 |
|
|
directory, one can specify a list of packages (one package per line, |
33 |
|
|
with '\texttt{\#}' as the comment character) to be included. Since |
34 |
|
|
the \texttt{packages.conf} file can be saved, this is the preferred |
35 |
|
|
method for setting and recording (for future reference) the package |
36 |
|
|
configuration. |
37 |
|
|
|
38 |
|
|
\item For convenience, a list of ``standard'' package groups is |
39 |
|
|
contained in the \texttt{pkg/pkg\_groups} file. By selecting one of |
40 |
|
|
the package group names in the \texttt{packages.conf} file, one |
41 |
|
|
automatically obtains all packages in that group. |
42 |
|
|
|
43 |
|
|
\item By default (that is, if a \texttt{packages.conf} file is not |
44 |
|
|
found), the \texttt{genmake2} program will use the contents of the |
45 |
|
|
\texttt{pkg/pkg\_default} file to obtain a list of packages. |
46 |
|
|
|
47 |
|
|
\item To help prevent users from creating unusable package groups, the |
48 |
|
|
\texttt{genmake2} program will parse the contents of the |
49 |
|
|
\texttt{pkg/pkg\_depend} file to determine: |
50 |
|
|
\begin{itemize} |
51 |
|
|
\item whether any two requested packages cannot be simultaneously |
52 |
|
|
included (\textit{eg.} \textit{seaice} and \textit{thsice} are |
53 |
|
|
mutually exclusive), |
54 |
|
|
\item whether additional packages must be included in order to |
55 |
|
|
satisfy package dependencies (\textit{eg.} \textit{rw} depends |
56 |
|
|
upon functionality within the \textit{mdsio} package), and |
57 |
|
|
\item whether the set of all requested packages is compatible with |
58 |
|
|
the dependencies (and producing an error if they aren't). |
59 |
|
|
\end{itemize} |
60 |
|
|
Thus, as a result of the dependencies, additional packages may be |
61 |
|
|
added to those originally requested. |
62 |
|
|
|
63 |
|
|
\end{enumerate} |
64 |
|
|
|
65 |
|
|
|
66 |
|
|
\subsection{Package Activation} |
67 |
|
|
|
68 |
|
|
For run--time package control, MITgcm uses flags set through a |
69 |
|
|
\texttt{data.pkg} file. While some packages (\textit{eg.} |
70 |
edhill |
1.2 |
\texttt{debug}, \texttt{mnc}, \texttt{exch2}) may have their own usage |
71 |
|
|
conventions, most follow a simple flag naming convention of the form: |
72 |
edhill |
1.1 |
\begin{verbatim} |
73 |
|
|
usePackageName=.TRUE. |
74 |
|
|
\end{verbatim} |
75 |
|
|
where the \texttt{usePackageName} variable can activate or disable the |
76 |
edhill |
1.2 |
package at runtime. As mentioned previously, packages must be |
77 |
|
|
included in order to be activated. Generally, such mistakes will be |
78 |
|
|
detected and reported as errors by the code. However, users should |
79 |
|
|
still be aware of the dependency. |
80 |
edhill |
1.1 |
|
81 |
|
|
|
82 |
molod |
1.6 |
\subsection{Package Coding Standards} |
83 |
edhill |
1.2 |
|
84 |
|
|
The following sections describe how to modify and/or create new MITgcm |
85 |
|
|
packages. |
86 |
|
|
|
87 |
molod |
1.6 |
\subsubsection{Packages are Not Libraries} |
88 |
edhill |
1.2 |
|
89 |
|
|
To a beginner, the MITgcm packages may resemble libraries as used in |
90 |
|
|
myriad software projects. While future versions are likely to |
91 |
|
|
implement packages as libraries (perhaps using FORTRAN90/95 syntax) |
92 |
|
|
the current packages (FORTRAN77) are \textbf{not} based upon any |
93 |
|
|
concept of libraries. |
94 |
|
|
|
95 |
edhill |
1.3 |
\subsubsection{File Inclusion Rules} |
96 |
edhill |
1.2 |
|
97 |
|
|
Instead, packages should be viewed only as directories containing |
98 |
|
|
``sets of source files'' that are built using some simple mechanisms |
99 |
|
|
provided by \texttt{genmake2}. Conceptually, the build process adds |
100 |
|
|
files as they are found and proceeds according to the following rules: |
101 |
|
|
\begin{enumerate} |
102 |
|
|
\item \texttt{genmake2} locates a ``core'' or main set of source files |
103 |
|
|
(the \texttt{-standarddirs} option sets these locations and the |
104 |
|
|
default value contains the directories \texttt{eesupp} and |
105 |
|
|
\texttt{model}). |
106 |
|
|
|
107 |
|
|
\item \texttt{genmake2} then finds additional source files by |
108 |
|
|
inspecting the contents of each of the package directories: |
109 |
|
|
\begin{enumerate} |
110 |
|
|
\item As the new files are found, they are added to a list of source |
111 |
|
|
files. |
112 |
|
|
|
113 |
|
|
\item If there is a file name ``collision'' (that is, if one of the |
114 |
|
|
files in a package has the same name as one of the files |
115 |
|
|
previously encountered) then the file within the newer (more |
116 |
|
|
recently visited) package will superseed (or ``hide'') any |
117 |
|
|
previous file(s) with the same name. |
118 |
edhill |
1.3 |
|
119 |
edhill |
1.2 |
\item Packages are visited (and thus files discovered) {\it in the |
120 |
|
|
order that the packages are enabled} within \texttt{genmake2}. |
121 |
|
|
Thus, the files in \texttt{PackB} may superseed the files in |
122 |
edhill |
1.3 |
\texttt{PackA} if \texttt{PackA} is enabled before \texttt{PackB}. |
123 |
|
|
Thus, package ordering can be significant! For this reason, |
124 |
|
|
\texttt{genmake2} honors the order in which packages are |
125 |
|
|
specified. |
126 |
edhill |
1.2 |
\end{enumerate} |
127 |
|
|
\end{enumerate} |
128 |
|
|
|
129 |
|
|
These rules were adopted since they provide a relatively simple means |
130 |
|
|
for rapidly including (or ``hiding'') existing files with modified |
131 |
|
|
versions. |
132 |
|
|
|
133 |
|
|
\subsubsection{Conditional Compilation and \texttt{PACKAGES\_CONFIG.h}} |
134 |
|
|
|
135 |
|
|
Given that packages are simply groups of files that may be added or |
136 |
|
|
removed to form a whole, one may wonder how linking (that is, FORTRAN |
137 |
|
|
symbol resolution) is handled. This is the second way that |
138 |
|
|
\texttt{genmake2} supports the concept of packages. Basically, |
139 |
|
|
\texttt{genmake2} creates a \texttt{Makefile} that, in turn, is able |
140 |
|
|
to create a file called \texttt{PACKAGES\_CONFIG.h} that contains a set |
141 |
|
|
of C pre-processor (or ``CPP'') directives such as: |
142 |
|
|
\begin{verbatim} |
143 |
|
|
#undef ALLOW_KPP |
144 |
|
|
#undef ALLOW_LAND |
145 |
|
|
... |
146 |
|
|
#define ALLOW_GENERIC_ADVDIFF |
147 |
|
|
#define ALLOW_MDSIO |
148 |
|
|
... |
149 |
|
|
\end{verbatim} |
150 |
|
|
These CPP symbols are then used throughout the code to conditionally |
151 |
|
|
isolate variable definitions, function calls, or any other code that |
152 |
|
|
depends upon the presence or absence of any particular package. |
153 |
|
|
|
154 |
|
|
An example illustrating the use of these defines is: |
155 |
|
|
\begin{verbatim} |
156 |
|
|
#ifdef ALLOW_GMREDI |
157 |
|
|
IF (useGMRedi) CALL GMREDI_CALC_DIFF( |
158 |
|
|
I bi,bj,iMin,iMax,jMin,jMax,K, |
159 |
|
|
I maskUp, |
160 |
|
|
O KappaRT,KappaRS, |
161 |
|
|
I myThid) |
162 |
|
|
#endif |
163 |
|
|
\end{verbatim} |
164 |
|
|
which is included from the file |
165 |
|
|
\filelink{calc\_diffusivity.F}{model-src-calc_diffusivity.F} |
166 |
edhill |
1.3 |
and shows how both the compile--time \texttt{ALLOW\_GMREDI} flag and the |
167 |
|
|
run--time \texttt{useGMRedi} are nested. |
168 |
edhill |
1.2 |
|
169 |
edhill |
1.3 |
There are some benefits to using the technique described here. The |
170 |
|
|
first is that code snippets or subroutines associated with packages |
171 |
|
|
can be placed or called from almost anywhere else within the code. |
172 |
|
|
The second benefit is related to memory footprint and performance. |
173 |
|
|
Since unused code can be removed, there is no performance penalty due |
174 |
|
|
to unnecessary memory allocation, unused function calls, or extra |
175 |
|
|
run-time \texttt{IF (...)} conditions. The major problems with this |
176 |
|
|
approach are the potentially difficult-to-read and difficult-to-debug |
177 |
|
|
code caused by an overuse of CPP statements. So while it can be done, |
178 |
|
|
developers should exerecise some discipline and avoid unnecesarily |
179 |
|
|
``smearing'' their package implementation details across numerous |
180 |
|
|
files. |
181 |
|
|
|
182 |
|
|
|
183 |
|
|
\subsubsection{Package Startup or Boot Sequence} |
184 |
|
|
|
185 |
|
|
Calls to package routines within the core code timestepping loop can |
186 |
|
|
vary. However, all packages should follow a required "boot" sequence |
187 |
|
|
outlined here: |
188 |
edhill |
1.2 |
|
189 |
edhill |
1.3 |
{\footnotesize |
190 |
|
|
\begin{verbatim} |
191 |
|
|
1. S/R PACKAGES_BOOT() |
192 |
|
|
: |
193 |
|
|
CALL OPEN_COPY_DATA_FILE( 'data.pkg', 'PACKAGES_BOOT', ... ) |
194 |
|
|
|
195 |
|
|
|
196 |
|
|
2. S/R PACKAGES_READPARMS() |
197 |
|
|
: |
198 |
|
|
#ifdef ALLOW_${PKG} |
199 |
|
|
if ( use${Pkg} ) |
200 |
|
|
& CALL ${PKG}_READPARMS( retCode ) |
201 |
|
|
#endif |
202 |
|
|
|
203 |
|
|
3. S/R PACKAGES_INIT_FIXED() |
204 |
|
|
: |
205 |
|
|
#ifdef ALLOW_${PKG} |
206 |
|
|
if ( use${Pkg} ) |
207 |
|
|
& CALL ${PKG}_INIT_FIXED( retCode ) |
208 |
|
|
#endif |
209 |
|
|
|
210 |
|
|
4. S/R PACKAGES_CHECK() |
211 |
|
|
: |
212 |
|
|
#ifdef ALLOW_${PKG} |
213 |
|
|
if ( use${Pkg} ) |
214 |
|
|
& CALL ${PKG}_CHECK( retCode ) |
215 |
|
|
#else |
216 |
|
|
if ( use${Pkg} ) |
217 |
|
|
& CALL PACKAGES_CHECK_ERROR('${PKG}') |
218 |
|
|
#endif |
219 |
|
|
|
220 |
|
|
5. S/R PACKAGES_INIT_VARIABLES() |
221 |
|
|
: |
222 |
|
|
#ifdef ALLOW_${PKG} |
223 |
|
|
if ( use${Pkg} ) |
224 |
|
|
& CALL ${PKG}_INIT_VARIA( ) |
225 |
|
|
#endif |
226 |
|
|
|
227 |
|
|
6. S/R DO_THE_MODEL_IO |
228 |
|
|
|
229 |
|
|
#ifdef ALLOW_${PKG} |
230 |
|
|
if ( use${Pkg} ) |
231 |
|
|
& CALL ${PKG}_DIAGS( ) |
232 |
|
|
#endif |
233 |
|
|
|
234 |
|
|
7. S/R PACKAGES_WRITE_PICKUP() |
235 |
|
|
|
236 |
|
|
#ifdef ALLOW_${PKG} |
237 |
|
|
if ( use${Pkg} ) |
238 |
|
|
& CALL ${PKG}_WRITE_PICKUP( ) |
239 |
|
|
#endif\end{verbatim} |
240 |
|
|
} |
241 |
edhill |
1.2 |
|
242 |
|
|
|
243 |
cnh |
1.5 |
\subsubsection{Adding a package to PARAMS.h and packages\_boot()} |
244 |
|
|
|
245 |
|
|
An MITgcm package directory contains all the code needed for that package apart |
246 |
|
|
from one variable for each package. This variable is the {\tt use\$\{Pkg\} } |
247 |
|
|
flag. This flag, which is of type logical, {\bf must} be declared in the |
248 |
|
|
shared header file {\it PARAMS.h} in the {\it PARM\_PACKAGES} block. This |
249 |
|
|
convention is used to support a single runtime control file {\it data.pkg} |
250 |
|
|
which is read by the startup routine {\it packages\_boot()} and that sets a |
251 |
|
|
flag controlling the runtime use of a package. This routine needs to be able to |
252 |
|
|
read the flags for packages that were not built at compile time. Therefore |
253 |
|
|
when adding a new package, in addition to creating the per-package directory |
254 |
|
|
in the {\it pkg/} subdirectory a developer should add a {\tt use\$\{Pkg\} } |
255 |
|
|
flag to {\it PARAMS.h} and a {\tt use\$\{Pkg\} } entry to the |
256 |
|
|
{\it packages\_boot()} {\it PACKAGES} namelist. |
257 |
|
|
The only other package specific code that should appear outside the individual |
258 |
|
|
package directory are calls to the specific package API. |
259 |
|
|
|
260 |
edhill |
1.1 |
|