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