63 |
|
|
64 |
For run--time package control, MITgcm uses flags set through a |
For run--time package control, MITgcm uses flags set through a |
65 |
\texttt{data.pkg} file. While some packages (\textit{eg.} |
\texttt{data.pkg} file. While some packages (\textit{eg.} |
66 |
\texttt{debug}, \texttt{mnc}, \texttt{cost}) may have their own |
\texttt{debug}, \texttt{mnc}, \texttt{exch2}) may have their own usage |
67 |
conventions, most follow a simple flag naming convention of the |
conventions, most follow a simple flag naming convention of the form: |
|
form: |
|
68 |
\begin{verbatim} |
\begin{verbatim} |
69 |
usePackageName=.TRUE. |
usePackageName=.TRUE. |
70 |
\end{verbatim} |
\end{verbatim} |
71 |
where the \texttt{usePackageName} variable can activate or disable the |
where the \texttt{usePackageName} variable can activate or disable the |
72 |
package at runtime. |
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 |
%\subsection{Modifying or Creating Packages} |
\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 ``Hiding'' 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 |
119 |
|
\texttt{PackB}. Thus, package ordering can be significant! |
120 |
|
\end{enumerate} |
121 |
|
\end{enumerate} |
122 |
|
|
123 |
|
These rules were adopted since they provide a relatively simple means |
124 |
|
for rapidly including (or ``hiding'') existing files with modified |
125 |
|
versions. |
126 |
|
|
127 |
|
\subsubsection{Conditional Compilation and \texttt{PACKAGES\_CONFIG.h}} |
128 |
|
|
129 |
|
Given that packages are simply groups of files that may be added or |
130 |
|
removed to form a whole, one may wonder how linking (that is, FORTRAN |
131 |
|
symbol resolution) is handled. This is the second way that |
132 |
|
\texttt{genmake2} supports the concept of packages. Basically, |
133 |
|
\texttt{genmake2} creates a \texttt{Makefile} that, in turn, is able |
134 |
|
to create a file called \texttt{PACKAGES\_CONFIG.h} that contains a set |
135 |
|
of C pre-processor (or ``CPP'') directives such as: |
136 |
|
\begin{verbatim} |
137 |
|
#undef ALLOW_KPP |
138 |
|
#undef ALLOW_LAND |
139 |
|
... |
140 |
|
#define ALLOW_GENERIC_ADVDIFF |
141 |
|
#define ALLOW_MDSIO |
142 |
|
... |
143 |
|
\end{verbatim} |
144 |
|
These CPP symbols are then used throughout the code to conditionally |
145 |
|
isolate variable definitions, function calls, or any other code that |
146 |
|
depends upon the presence or absence of any particular package. |
147 |
|
|
148 |
|
An example illustrating the use of these defines is: |
149 |
|
\begin{verbatim} |
150 |
|
#ifdef ALLOW_GMREDI |
151 |
|
IF (useGMRedi) CALL GMREDI_CALC_DIFF( |
152 |
|
I bi,bj,iMin,iMax,jMin,jMax,K, |
153 |
|
I maskUp, |
154 |
|
O KappaRT,KappaRS, |
155 |
|
I myThid) |
156 |
|
#endif |
157 |
|
\end{verbatim} |
158 |
|
which is included from the file |
159 |
|
\filelink{calc\_diffusivity.F}{model-src-calc_diffusivity.F} |
160 |
|
|
161 |
|
There are some benefits to using this technique. The first is that |
162 |
|
code snippets or subroutines associated with packages can be placed or |
163 |
|
called from almost anywhere else within the code. The second benefit |
164 |
|
is related to the memory footprint and performance. Since unused code |
165 |
|
can be removed, there is no performance penalty due to unnecessary |
166 |
|
memory allocation or unused function calls. The major problems with |
167 |
|
this approach are difficult-to-read and difficult-to-test code caused |
168 |
|
by the numerous CPP statements. Developers should exerecise some |
169 |
|
discipline and avoid ``smearing'' implementation details across |
170 |
|
numerous files in a haphazard fashion. |
171 |
|
|
172 |
|
|
173 |
|
|
174 |
|
\subsection{Interfaces} |
175 |
|
|
176 |
|
|