1 |
edhill |
1.1 |
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> |
2 |
|
|
|
3 |
|
|
<article id="MITgcm-Development-HOWTO"> |
4 |
|
|
|
5 |
|
|
<articleinfo> |
6 |
|
|
<title>MITgcm Development HOWTO</title> |
7 |
|
|
|
8 |
|
|
<author> |
9 |
|
|
<firstname>Ed</firstname> |
10 |
|
|
<surname>Hill III</surname> |
11 |
|
|
<affiliation> |
12 |
|
|
<address><email>eh3@mit.edu</email></address> |
13 |
|
|
</affiliation> |
14 |
|
|
</author> |
15 |
|
|
|
16 |
|
|
<revhistory> |
17 |
|
|
<revision> |
18 |
|
|
<revnumber>0.01</revnumber> |
19 |
edhill |
1.2 |
<date>2003-08-07</date> |
20 |
edhill |
1.1 |
<authorinitials>eh3</authorinitials> |
21 |
|
|
<revremark> |
22 |
|
|
Initial version. |
23 |
|
|
</revremark> |
24 |
|
|
</revision> |
25 |
|
|
</revhistory> |
26 |
|
|
|
27 |
|
|
<abstract> |
28 |
|
|
<para>This document describes how to develop software for the |
29 |
|
|
MITgcm project.</para> |
30 |
|
|
</abstract> |
31 |
|
|
</articleinfo> |
32 |
|
|
|
33 |
|
|
<sect1 id="intro"> |
34 |
|
|
<title>Introduction</title> <para>The purpose of this document is |
35 |
|
|
to help new developers get "up to speed" with MITgcm |
36 |
|
|
development.</para> |
37 |
|
|
<sect2> |
38 |
|
|
<title>New Versions of This Document</title> <para>You can |
39 |
|
|
obtain the latest version of this document <ulink |
40 |
|
|
url="http://mitgcm.org/dev_docs/devel_HOWTO/">online</ulink> in |
41 |
|
|
various formats.</para> |
42 |
|
|
</sect2> |
43 |
|
|
<sect2> |
44 |
|
|
<title>Feedback and corrections</title> <para>If you have |
45 |
|
|
questions or comments about this document, please feel free to |
46 |
|
|
<ulink url="mailto:MITgcm-support@mitgcm.org">contact the |
47 |
|
|
authors</ulink>. |
48 |
|
|
</para> |
49 |
|
|
</sect2> |
50 |
|
|
</sect1> |
51 |
|
|
|
52 |
|
|
<sect1 id="background"> |
53 |
|
|
<title>Background</title> |
54 |
|
|
|
55 |
|
|
<sect2> |
56 |
|
|
<title>User Manual</title> |
57 |
|
|
|
58 |
edhill |
1.5 |
<para>Before jumping into development, please familiarize yourself with |
59 |
|
|
the <ulink url="http://mitgcm.org/docs.html"> MITgcm user manual |
60 |
|
|
</ulink>. This document contains volumes of useful information and is |
61 |
|
|
included here by reference.</para> |
62 |
edhill |
1.1 |
|
63 |
edhill |
1.5 |
<!-- |
64 |
|
|
<para>Also, a "snapshot" or <ulink |
65 |
edhill |
1.1 |
url="http://mitgcm.org/dev_docs/">development version</ulink> of |
66 |
|
|
the user manual may be available, though this is only put on the |
67 |
|
|
web for testing purposes.</para> |
68 |
edhill |
1.5 |
--> |
69 |
edhill |
1.1 |
</sect2> |
70 |
|
|
|
71 |
|
|
<sect2> |
72 |
|
|
<title>Prerequisites</title> <para>To develop for MITgcm project |
73 |
|
|
you will need a UNIX or UNIX-like set of build tools including |
74 |
|
|
the following:</para> |
75 |
|
|
<blockquote> |
76 |
|
|
<simplelist type="inline"> |
77 |
|
|
<member>CVS client</member> |
78 |
|
|
<member>make or (preferably) GNU make</member> |
79 |
|
|
<member>FORTRAN compiler</member> |
80 |
|
|
<member>C compiler</member> |
81 |
|
|
<member>[ba]sh and [t]csh shells</member> |
82 |
|
|
<member>PERL</member> |
83 |
|
|
<member>LaTeX and LaTeX2HTML</member> |
84 |
|
|
</simplelist> |
85 |
|
|
</blockquote> |
86 |
|
|
<para>Essentially all of the work described here has been tested |
87 |
|
|
on recent versions of Red Hat Linux (eg. 7.3 through 9). Except |
88 |
|
|
where noted, all shell commands will be provided using bash |
89 |
|
|
syntax. |
90 |
|
|
</para> |
91 |
|
|
</sect2> |
92 |
|
|
|
93 |
|
|
</sect1> |
94 |
|
|
|
95 |
|
|
<sect1 id="cvs"> |
96 |
|
|
<title>CVS Repository</title> |
97 |
|
|
<sect2> |
98 |
|
|
<title>Layout</title> |
99 |
|
|
|
100 |
|
|
<para>Unlike many open source projects, the MITgcm CVS tree does |
101 |
|
|
not follow a simple "src", "docs", "share", and "test" directory |
102 |
|
|
layout. Instead, there are multiple higher-level directories |
103 |
|
|
that each, to some extent, depend upon the presence of the |
104 |
|
|
others. The tree currently resembles:</para> |
105 |
|
|
|
106 |
|
|
<programlisting>gcmpack/ |
107 |
|
|
MITgcm-contrib contributed code |
108 |
|
|
CS-regrid goes into utils |
109 |
|
|
cvspolicy.html -save- |
110 |
|
|
CVSROOT -save- |
111 |
|
|
development experimental stuff |
112 |
|
|
manual -save- |
113 |
|
|
misc -?- |
114 |
|
|
|
115 |
|
|
MITgcm code |
116 |
|
|
adjoint fold into genmake |
117 |
|
|
bin stub for ecco build |
118 |
|
|
compare01 old from 20th century |
119 |
|
|
diags timeave f77 in pkgs now |
120 |
|
|
doc tags -- connect to real docs? |
121 |
|
|
eesupp cnh? |
122 |
|
|
exe ecco user build |
123 |
edhill |
1.4 |
,- jobs runtime shell scripts for |
124 |
edhill |
1.1 |
| various platforms |
125 |
|
|
| lsopt line search |
126 |
|
|
m| model main dynamics (core) |
127 |
|
|
e| optimization_drivers ? |
128 |
|
|
r| optim line search interface |
129 |
|
|
g| pkg alternate and optional numerics, etc. |
130 |
edhill |
1.4 |
e|- tools |
131 |
edhill |
1.1 |
?| tutorial_examples documented tests |
132 |
|
|
| only populated on release1 branch |
133 |
|
|
| and not validated during "testscript" |
134 |
edhill |
1.4 |
'- utils |
135 |
edhill |
1.1 |
verification std tests |
136 |
|
|
|
137 |
|
|
|
138 |
|
|
mitgcmdoc -> manual -remove- |
139 |
|
|
mitgcm.org build web site |
140 |
|
|
models -?- |
141 |
|
|
packages -?- |
142 |
|
|
preprocess -?- |
143 |
|
|
tmp -?- |
144 |
|
|
</programlisting> |
145 |
|
|
|
146 |
|
|
<para>Efforts are underway to reduce the complexity.</para> |
147 |
|
|
|
148 |
|
|
</sect2> |
149 |
|
|
|
150 |
|
|
<!-- |
151 |
|
|
<sect2> |
152 |
|
|
<title>Releases</title> <para>Currently, there are two main |
153 |
|
|
branches:</para> |
154 |
|
|
<itemizedlist mark="bullet"> |
155 |
|
|
<listitem> |
156 |
|
|
<para>Development</para> |
157 |
|
|
<itemizedlist mark="bullet"> |
158 |
|
|
<listitem> |
159 |
|
|
<para>MAIN</para> |
160 |
|
|
</listitem> |
161 |
|
|
<listitem> |
162 |
|
|
<para>ecco-branch</para> |
163 |
|
|
</listitem> |
164 |
|
|
</itemizedlist> |
165 |
|
|
</listitem> |
166 |
|
|
<listitem> |
167 |
|
|
<para>Production</para> |
168 |
|
|
<itemizedlist mark="bullet"> |
169 |
|
|
<listitem> |
170 |
|
|
<para>Release1</para> |
171 |
|
|
</listitem> |
172 |
|
|
<listitem> |
173 |
|
|
<para>Release2</para> |
174 |
|
|
</listitem> |
175 |
|
|
</itemizedlist> |
176 |
|
|
</listitem> |
177 |
|
|
</itemizedlist> |
178 |
|
|
</sect2> |
179 |
|
|
--> |
180 |
|
|
|
181 |
|
|
<sect2> |
182 |
|
|
<title>Branches</title> |
183 |
|
|
|
184 |
|
|
<para>As shown in the online <ulink |
185 |
|
|
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/doc/tag-index?graph=1.174">ViewCVS-generated |
186 |
|
|
tree</ulink>, the MITgcm codebase is split into to two branches |
187 |
|
|
or "lines" under which development proceeds. These two lines |
188 |
|
|
are referred to as the "MAIN" and "ecco" versions of the code. |
189 |
|
|
While not identical, the bulk of the MAIN and ecco lines are |
190 |
|
|
composed of files from the same codebase. |
191 |
|
|
</para> |
192 |
|
|
|
193 |
|
|
<para>Periodically, a "Release" branch is formed from the "MAIN" |
194 |
|
|
development branch. This is done in order to create a |
195 |
|
|
relatively stable reference point for both users and developers. |
196 |
|
|
The intent is that once a relese branch has been created, only |
197 |
|
|
bug-fixes will be added to it. Meanwhile, development (which |
198 |
|
|
might "break" or otherwise render invalid the documentation, |
199 |
|
|
tutorials, and/or examples contained within a release branch) is |
200 |
|
|
allowed to continue along the MAIN and ecco lines.</para> |
201 |
|
|
</sect2> |
202 |
|
|
|
203 |
|
|
<sect2> |
204 |
|
|
<title>Tagging</title> |
205 |
|
|
|
206 |
|
|
<para>The intent of tagging is to create "known-good" |
207 |
|
|
checkpoints that developers can use as references. |
208 |
|
|
Traditionally, MITgcm tagging has maintained the following |
209 |
|
|
conventions:</para> |
210 |
|
|
|
211 |
|
|
<orderedlist> |
212 |
|
|
<listitem> |
213 |
|
|
<para>Developer checks out code into a local CVS-managed |
214 |
|
|
directory, makes various changes/additions, tests these |
215 |
|
|
edits, and eventually reaches a point where (s)he is |
216 |
|
|
satisfied that the changes form a new "useful" point in the |
217 |
|
|
evolution of the code.</para> |
218 |
|
|
</listitem> |
219 |
|
|
|
220 |
|
|
<listitem> |
221 |
|
|
<para>The developer then runs the <ulink |
222 |
|
|
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/verification/testscript">testscript</ulink> |
223 |
|
|
shell script to see if any problems are introduced. While |
224 |
|
|
not intended to be exhaustive, the test cases within the |
225 |
|
|
verification directory do provide some indication whether |
226 |
|
|
gross errors have been introduced. |
227 |
|
|
</para> |
228 |
|
|
</listitem> |
229 |
|
|
|
230 |
|
|
<listitem> |
231 |
|
|
<para>Having satisfied him- or herself that the changes are |
232 |
|
|
ready to be committed to the CVS repository, the developer |
233 |
|
|
then:</para> |
234 |
|
|
<orderedlist> |
235 |
|
|
<listitem> |
236 |
|
|
<para>adds a "checkpointXY_pre" comment (where X is a |
237 |
|
|
checkpoint number and Y is a letter) to the <ulink |
238 |
|
|
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/doc/tag-index">tag-index</ulink> |
239 |
|
|
file and checks it into the CVS repository</para> |
240 |
|
|
</listitem> |
241 |
|
|
<listitem> |
242 |
|
|
<para>submits the set of changes to the CVS repository |
243 |
|
|
and adds comments to <filename>tag-index</filename> |
244 |
|
|
describing what the changes are along with a matching |
245 |
|
|
"checkpointXY_post" entry</para> |
246 |
|
|
</listitem> |
247 |
|
|
</orderedlist> |
248 |
|
|
</listitem> |
249 |
|
|
</orderedlist> |
250 |
|
|
|
251 |
|
|
<para>The result of this tagging procedure is a sequence of |
252 |
|
|
development checkpoints with comments which resembles:</para> |
253 |
|
|
|
254 |
|
|
<programlisting> |
255 |
|
|
checkpoint50e_post |
256 |
|
|
o make KPP work with PTRACERS |
257 |
|
|
- fix gad_calc_rhs to call new routine kpp_transport_ptr, which is |
258 |
|
|
nearly a copy of kpp_transport_s |
259 |
|
|
- there is no analogue to SurfaceTendencyS, so I have to use |
260 |
|
|
gPtr(of the surface layer) instead |
261 |
|
|
o add a new platform SunFire+mpi (SunFire 15000) to genmake |
262 |
|
|
checkpoint50e_pre |
263 |
|
|
|
264 |
|
|
checkpoint50d_post |
265 |
|
|
o change kpp output from multiple-record state files to single-record state |
266 |
|
|
files analogous to write_state.F |
267 |
|
|
o reduce the output frequency of cg3d-related stuff to the monitor frequency, |
268 |
|
|
analogous to the cg2d-related output. |
269 |
|
|
o fix small problem with in ptracers_write_checkpoint.F: len(suff)=512, |
270 |
|
|
so that writing to internal file fn (with length 512) fails. |
271 |
|
|
checkpoint50d_pre |
272 |
|
|
</programlisting> |
273 |
|
|
|
274 |
|
|
<para>This information can be used to refer to various stages of |
275 |
|
|
the code development. For example, bugs can be traced to |
276 |
|
|
individual sets of CVS checkins based upon their first |
277 |
|
|
appearance when comparing the results from different |
278 |
|
|
checkpoints.</para> |
279 |
|
|
|
280 |
|
|
</sect2> |
281 |
|
|
</sect1> |
282 |
|
|
|
283 |
|
|
|
284 |
|
|
<sect1 id="documentation"> |
285 |
|
|
<title>Editing the Documentation</title> |
286 |
|
|
|
287 |
|
|
<sect2 id="documentation_getting"> |
288 |
|
|
<title>Getting the Docs and Code</title> |
289 |
|
|
|
290 |
|
|
<para>The first step towards editing the documentation is to |
291 |
|
|
checkout a copy of code, docs, and build scripts from the CVS |
292 |
|
|
server using:</para> |
293 |
|
|
|
294 |
|
|
<screen> |
295 |
edhill |
1.5 |
$ export CVS_RSH=ssh |
296 |
|
|
$ export CVSROOT=':ext:auden.lcs.mit.edu:/u/u3/gcmpack' |
297 |
|
|
$ mkdir scratch |
298 |
|
|
$ cvs co MITgcm manual mitgcm.org |
299 |
edhill |
1.1 |
</screen> |
300 |
|
|
|
301 |
|
|
<para>These commands extract the necessary information from the |
302 |
|
|
CVS server and create a temporary (called |
303 |
|
|
<filename>scratch</filename>) directory for the storage of the |
304 |
|
|
HTML and other files that will be created. Please note that you |
305 |
|
|
must either create <filename>scratch</filename> as shown or edit |
306 |
|
|
the various <filename>Makefile</filename>s and scripts used to |
307 |
|
|
create the documentation.</para> |
308 |
|
|
</sect2> |
309 |
|
|
|
310 |
|
|
<sect2> |
311 |
edhill |
1.4 |
<title>Editing the Documentation</title> |
312 |
edhill |
1.1 |
|
313 |
|
|
<para>The documentation is contained in the |
314 |
|
|
<filename>manual</filename> directory in a raw LaTeX format. |
315 |
|
|
The main document is <filename>manual.tex</filename> and it uses |
316 |
|
|
<command>\input{}</command>s to include the chapters and |
317 |
|
|
subsections.</para> |
318 |
|
|
|
319 |
|
|
<para>Since the same LaTeX source is used to produce PostScript, |
320 |
|
|
PDF, and HTML output, care should be taken to follow certain |
321 |
|
|
conventions. Two of the most important are the usage of the |
322 |
|
|
<command>\filelink{}{}</command> and |
323 |
|
|
<command>\varlink{}{}</command> commands. Both of these |
324 |
|
|
commands have been defined to simplify the connection between |
325 |
|
|
the automatically generated ("code browser") HTML and the HTML |
326 |
|
|
version of the manual produced by LaTeX2HTML. They each take |
327 |
|
|
two arguments (corresponding to the contents of the two sets of |
328 |
|
|
curly braces) which are the text that the author wishes to be |
329 |
|
|
"wrapped" within the link, and a specially formatted link thats |
330 |
|
|
relative to the <filename>MITgcm</filename> directory within the |
331 |
|
|
CVS tree.</para> |
332 |
|
|
|
333 |
|
|
<para>The result is a command that resembles either</para> |
334 |
|
|
|
335 |
|
|
<orderedlist> |
336 |
|
|
<listitem> |
337 |
|
|
<para>a reference to a variable or subroutine name such as |
338 |
|
|
<command>\varlink{tRef}{tRef}</command>, or </para> |
339 |
|
|
</listitem> |
340 |
|
|
|
341 |
|
|
<listitem> |
342 |
|
|
<para>a reference to a file such as |
343 |
|
|
<command>\varlink{tRef}{path-to-the-file_name.F}</command> |
344 |
|
|
where the absolute path to the file is of the form |
345 |
|
|
<filename>/foo/MITgcm/path/to/the/file_name.F</filename></para> |
346 |
|
|
<para>(please note how the leading "/foo/MITgcm" |
347 |
|
|
component of the path is dropped leaving the path |
348 |
|
|
<emphasis>relative</emphasis> to the head of the code |
349 |
|
|
directory and each directory separator "/" is turned |
350 |
|
|
into a "-")</para> |
351 |
|
|
</listitem> |
352 |
|
|
</orderedlist> |
353 |
|
|
|
354 |
|
|
|
355 |
|
|
|
356 |
|
|
</sect2> |
357 |
|
|
|
358 |
|
|
<sect2> |
359 |
edhill |
1.4 |
<title>Building the Documentation</title> |
360 |
|
|
|
361 |
|
|
<para>Given the directory structure of <xref |
362 |
|
|
linkend="documentation_getting">, the entire documentation for the web |
363 |
|
|
site can be built using:</para> |
364 |
edhill |
1.1 |
|
365 |
|
|
<screen> |
366 |
edhill |
1.5 |
$ cd mitgcm.org/devel/buildweb |
367 |
|
|
$ make All |
368 |
edhill |
1.1 |
</screen> |
369 |
|
|
|
370 |
|
|
<para>Which builds the PDF from the LaTeX source, creates the |
371 |
|
|
HTML output from the LaTeX source, parses the FORTRAN code base |
372 |
|
|
to produce a hyperlinked HTML version of the source, and then |
373 |
|
|
determines the cross-linking between the various HTML |
374 |
|
|
components.</para> |
375 |
|
|
|
376 |
|
|
<para>If there are no errors, the result of the build process |
377 |
|
|
(which can take 30+ minutes on a P4/2.5Ghz) will be contained |
378 |
|
|
within a single directory called |
379 |
|
|
<filename>scratch/dev_docs</filename>. This is a freshly built |
380 |
|
|
version of the entire on-line users manual. If you have the |
381 |
|
|
correct permissions, it can be directly copied to the web server |
382 |
|
|
area:</para> |
383 |
|
|
|
384 |
|
|
<screen> |
385 |
edhill |
1.5 |
$ mv scratch/dev_docs /u/u0/httpd/html |
386 |
edhill |
1.1 |
</screen> |
387 |
|
|
|
388 |
|
|
<para>and the update is complete.</para> |
389 |
|
|
|
390 |
|
|
</sect2> |
391 |
|
|
|
392 |
|
|
</sect1> |
393 |
|
|
|
394 |
edhill |
1.2 |
<sect1 id="coding"> |
395 |
edhill |
1.3 |
<title>Coding for MITgcm</title> |
396 |
|
|
|
397 |
|
|
<sect2 id="build_tools"> |
398 |
|
|
<title>Build Tools</title> |
399 |
|
|
|
400 |
edhill |
1.4 |
<para>Many Open Source projects use the "GNU Autotools" to help streamline |
401 |
|
|
the build process for various Unix and Unix-like architectures. For a |
402 |
|
|
user, the result is the common "configure" (that is, |
403 |
|
|
"<filename>./configure && make && make install</filename>") commands. |
404 |
|
|
For MITgcm, the process is similar. Typical commands are:</para> |
405 |
edhill |
1.3 |
|
406 |
|
|
<screen> |
407 |
edhill |
1.5 |
$ genmake -mods=../code |
408 |
|
|
$ make depend |
409 |
|
|
$ make |
410 |
edhill |
1.3 |
</screen> |
411 |
|
|
|
412 |
edhill |
1.4 |
<para>The following sections describe the individual steps in the build |
413 |
|
|
process.</para> |
414 |
|
|
|
415 |
edhill |
1.3 |
<sect3 id="genmake"> |
416 |
|
|
<title>The <filename>genmake2</> Utility</title> |
417 |
|
|
|
418 |
edhill |
1.4 |
<para><emphasis>Please note that the older <filename>genmake</> is |
419 |
|
|
deprecated and will eventually be replaced by <filename>genmake2</>. |
420 |
|
|
This HOWTO only describes the newer tool.</emphasis></para> |
421 |
|
|
|
422 |
|
|
<para>The first step in any MITgcm build is to create a Unix-style |
423 |
|
|
<filename>Makefile</filename> which will be parsed by |
424 |
|
|
<filename>make</filename> to specify how to compile the MITgcm source |
425 |
|
|
files. For more detailed descriptions of what the make tools are and |
426 |
|
|
how they are used, please see:</para> |
427 |
edhill |
1.3 |
|
428 |
|
|
<itemizedlist> |
429 |
|
|
<listitem> |
430 |
edhill |
1.4 |
<para><ulink url="http://www.gnu.org/software/make/make.html"> |
431 |
|
|
http://www.gnu.org/software/make/make.html</></para> |
432 |
edhill |
1.3 |
</listitem> |
433 |
|
|
<listitem> |
434 |
edhill |
1.4 |
<para><ulink url="http://www.oreilly.com/catalog/make2/"> |
435 |
|
|
http://www.oreilly.com/catalog/make2/</></para> |
436 |
edhill |
1.3 |
</listitem> |
437 |
|
|
</itemizedlist> |
438 |
|
|
|
439 |
edhill |
1.4 |
<para>Genmake can often be invoked successfully with a command line as |
440 |
|
|
simple as:</para> |
441 |
|
|
|
442 |
|
|
<screen> |
443 |
edhill |
1.5 |
$ genmake2 -mods=../code |
444 |
edhill |
1.4 |
</screen> |
445 |
|
|
|
446 |
|
|
<para>However, some systems (particularly commercial Unixes that lack a |
447 |
|
|
more modern "/bin/sh" implementation or that have shells installed in |
448 |
|
|
odd locations) may require an explicit shell invocation such as one of |
449 |
|
|
the following: </para> |
450 |
|
|
|
451 |
|
|
<screen> |
452 |
edhill |
1.5 |
$ /usr/bin/sh genmake2 -make=gmake -mods=../code |
453 |
|
|
$ /opt/gnu/bin/bash genmake2 -ieee -make=/usr/local/bin/gmake -mods=../code |
454 |
edhill |
1.4 |
</screen> |
455 |
|
|
|
456 |
|
|
<para>The genmake2 code has been written in a Bourne and BASH (v1) |
457 |
|
|
compatible syntax so it should work with most "sh" and all recent "bash" |
458 |
|
|
implementations.</para> |
459 |
|
|
|
460 |
|
|
<para>As the name implies, <filename>genmake2</filename> generates a |
461 |
|
|
<filename>Makefile</filename>. It does so by first parsing the |
462 |
|
|
information supplied from the following sources</para> |
463 |
edhill |
1.3 |
|
464 |
|
|
<orderedlist> |
465 |
|
|
<listitem> |
466 |
|
|
<para>a <filename>gm_local</filename> file in the current |
467 |
edhill |
1.4 |
directory</para> |
468 |
edhill |
1.3 |
</listitem> |
469 |
|
|
<listitem> |
470 |
|
|
<para>directly from command-line options</para> |
471 |
|
|
</listitem> |
472 |
|
|
<listitem> |
473 |
edhill |
1.4 |
<para>an "options file" as specified by the command-line option |
474 |
|
|
<filename>-optfile='FILENAME'</filename></para> |
475 |
edhill |
1.3 |
</listitem> |
476 |
|
|
</orderedlist> |
477 |
|
|
|
478 |
edhill |
1.4 |
<para>then checking certain dependency rules (the package dependencies), |
479 |
|
|
and finally writing a <filename>Makefile</filename> based upon the |
480 |
|
|
source code that it finds. For convenience within various Unix |
481 |
|
|
shells, <filename>genmake2</> supports both "long"- and "short"-style |
482 |
|
|
options. A complete list of the available options can be obtained |
483 |
|
|
from:</para> |
484 |
edhill |
1.3 |
|
485 |
|
|
<screen> |
486 |
edhill |
1.5 |
$ genmake2 -help |
487 |
edhill |
1.3 |
</screen> |
488 |
|
|
|
489 |
edhill |
1.4 |
<para>The most important options for <filename>genmake2</> are:</para> |
490 |
edhill |
1.3 |
|
491 |
|
|
<variablelist> |
492 |
|
|
|
493 |
|
|
<varlistentry> |
494 |
|
|
<term><filename>--optfile=/PATH/FILENAME</></term> |
495 |
edhill |
1.4 |
|
496 |
edhill |
1.3 |
<listitem> |
497 |
edhill |
1.4 |
<para>This specifies the "options file" that should be used for a |
498 |
|
|
particular build. The options file is a convenient and |
499 |
|
|
machine-indepenent way of specifying parameters such as the |
500 |
|
|
FORTRAN compiler (<filename>FC=</>), FORTRAN compiler |
501 |
|
|
optimization flags (<filename>FFLAGS=</>), and the locations of |
502 |
|
|
various platform- and/or machine-specific tools |
503 |
|
|
(eg. <filename>MAKEDEPEND=</>). As with <filename>genmake2</>, |
504 |
|
|
all options files should be written to be compatible with |
505 |
|
|
Bourne--shell ("sh" or "BASH v1") syntax. Examples of various |
506 |
|
|
options files can be found in |
507 |
|
|
<filename>$ROOTDIR/tools/build_options</>.</para> |
508 |
|
|
|
509 |
|
|
<para>If no "optfile" is specified (either through the command lin |
510 |
|
|
or the environment variable), genmake2 will try to make a |
511 |
|
|
reasonable guess from the list provided in |
512 |
|
|
<filename>$ROOTDIR/tools/build_options</>. The method used for |
513 |
|
|
making this guess is to first determine the combination of |
514 |
|
|
operating system and hardware (eg. "linux_ia32") and then find a |
515 |
|
|
working Fortran compiler within the user's path. When these |
516 |
|
|
three items have been identified, genmake2 will try to find an |
517 |
|
|
optfile that has a matching name. </para> |
518 |
|
|
|
519 |
|
|
<para>Everyone is encouraged to submit their options files to the |
520 |
|
|
MITgcm project for inclusion (please send to |
521 |
|
|
<email>MITgcm-support@mitgcm.org</email>). We are particularly |
522 |
|
|
grateful for options files tested on new or unique |
523 |
|
|
platforms!</para> |
524 |
edhill |
1.3 |
</listitem> |
525 |
edhill |
1.4 |
|
526 |
edhill |
1.3 |
</varlistentry> |
527 |
|
|
|
528 |
|
|
<varlistentry> |
529 |
|
|
<term><filename>-pdepend=/PATH/FILENAME</></term> |
530 |
edhill |
1.4 |
|
531 |
edhill |
1.3 |
<listitem> |
532 |
edhill |
1.4 |
<para>This specifies the dependency file used for packages. If |
533 |
|
|
not specified, the default dependency file is |
534 |
|
|
<filename>$ROOTDIR/pkg/pkg_depend</>. The syntax for this file is |
535 |
|
|
parsed on a line-by-line basis where each line containes either a |
536 |
|
|
comment ("#") or a simple "PKGNAME1 (+|-)PKGNAME2" pairwise rule |
537 |
|
|
where the "+" or "-" symbol specifies a "must be used with" or a |
538 |
|
|
"must not be used with" relationship, respectively. If no rule is |
539 |
|
|
specified, then it is assumed that the two packages are compatible |
540 |
|
|
and will function either with or without each other.</para> |
541 |
edhill |
1.3 |
</listitem> |
542 |
|
|
</varlistentry> |
543 |
|
|
|
544 |
|
|
<varlistentry> |
545 |
|
|
<term><filename>-pdefault=PKG</></term> |
546 |
|
|
<term><filename>-pdefault='PKG1 [PKG2 PKG3 ...]'</></term> |
547 |
|
|
<listitem> |
548 |
|
|
<para>This option specifies the default set of packages |
549 |
|
|
to be used. If not set, the default package list will |
550 |
|
|
be read from |
551 |
|
|
<filename>$ROOTDIR/pkg/pkg_default</>.</para> |
552 |
|
|
</listitem> |
553 |
|
|
</varlistentry> |
554 |
|
|
|
555 |
|
|
<varlistentry> |
556 |
edhill |
1.5 |
<term><filename>-adof=/path/to/file</></term> |
557 |
|
|
<term><filename>-adoptfile=/path/to/file</></term> |
558 |
|
|
<listitem> |
559 |
|
|
<para>This option specifies the "adjoint" or automatic |
560 |
|
|
differentiation options file to be used. The file is analogous |
561 |
|
|
to the "optfile" defined above but it specifies information for |
562 |
|
|
the AD build process. The default file is located in <filename> |
563 |
|
|
$ROOTDIR/tools/adjoint_options/adjoint_default </> and it |
564 |
|
|
defines the "TAF" and "TAMC" compilers. An alternate version is |
565 |
|
|
also available at <filename> |
566 |
|
|
$ROOTDIR/tools/adjoint_options/adjoint_staf </> that selects the |
567 |
|
|
newer "STAF" compiler. As with any compilers, it is helpful to |
568 |
|
|
have their directories listed in your $PATH environment |
569 |
|
|
variable.</para> |
570 |
|
|
</listitem> |
571 |
|
|
</varlistentry> |
572 |
|
|
|
573 |
|
|
<varlistentry> |
574 |
edhill |
1.4 |
<term><filename>-mods=DIR</></term> |
575 |
|
|
<term><filename>-mods='DIR1 [DIR2 ...]'</></term> |
576 |
edhill |
1.3 |
<listitem> |
577 |
edhill |
1.4 |
<para>This option specifies a list of directories containing |
578 |
|
|
"modifications". These directories contain files with names |
579 |
|
|
that may (or may not) exist in the main MITgcm source tree but |
580 |
|
|
will be overridden by any identically-named sources within the |
581 |
|
|
"MODS" directories. The order of precedence for this |
582 |
|
|
"name-hiding" is as follows:</para> |
583 |
|
|
|
584 |
|
|
<itemizedlist> |
585 |
|
|
<listitem><para>"MODS" directories (in the order given) |
586 |
|
|
</para></listitem> |
587 |
|
|
<listitem><para>Packages either explicitly specified or |
588 |
|
|
provided by default (in the order given)</para></listitem> |
589 |
|
|
<listitem><para>Packages included due to package dependencies |
590 |
|
|
(in the order that that package dependencies are |
591 |
|
|
parsed)</para></listitem> |
592 |
|
|
<listitem><para>The "standard dirs" (which may have been |
593 |
|
|
specified by the "-standarddirs" option)</para></listitem> |
594 |
|
|
</itemizedlist> |
595 |
|
|
|
596 |
|
|
</listitem> |
597 |
|
|
</varlistentry> |
598 |
|
|
|
599 |
|
|
<varlistentry> |
600 |
|
|
<term><filename>-make=/path/to/gmake</></term> |
601 |
|
|
<listitem> |
602 |
|
|
<para>Due to the poor handling of soft-links and other bugs common |
603 |
|
|
with the <filename>make</> versions provided by commercial Unix |
604 |
|
|
vendors, GNU <filename>make</filename> (sometimes called |
605 |
|
|
<filename>gmake</filename>) should be preferred. This option |
606 |
|
|
provides a means for specifying the make program to be |
607 |
|
|
used.</para> |
608 |
edhill |
1.3 |
</listitem> |
609 |
|
|
</varlistentry> |
610 |
|
|
|
611 |
|
|
</variablelist> |
612 |
|
|
|
613 |
edhill |
1.4 |
<para>A successful run of <filename>genmake2</> will produce a |
614 |
|
|
<filename>Makefile</>, a <filename>PACKAGES_CONFIG.h</> file, and |
615 |
|
|
various convenience files used for the automatic differentiation |
616 |
|
|
process.</para> |
617 |
|
|
|
618 |
|
|
<para>In general, it is best to use <filename>genmake2</> on a "clean" |
619 |
|
|
directory that is free of all source (*.[F,f],*.[F,f]90) and header |
620 |
|
|
(*.h,*.inc) files. Generally, this can be accomplished in an |
621 |
|
|
"un-clean" directory by running "make CLEAN" followed by "make |
622 |
|
|
makefile".</para> |
623 |
edhill |
1.3 |
|
624 |
|
|
</sect3> |
625 |
|
|
|
626 |
|
|
<sect3 id="makefile_use"> |
627 |
edhill |
1.5 |
<title>Using the <filename>Makefile</></title> |
628 |
edhill |
1.3 |
|
629 |
edhill |
1.5 |
<para>Once a <filename>Makefile</> has been created using |
630 |
|
|
<filename>genmake2</>, one can build a "standard" (forward |
631 |
|
|
simulator) executable using:</para> |
632 |
edhill |
1.3 |
|
633 |
|
|
<screen> |
634 |
edhill |
1.5 |
$ make CLEAN |
635 |
|
|
$ make depend |
636 |
|
|
$ make |
637 |
edhill |
1.3 |
</screen> |
638 |
|
|
|
639 |
edhill |
1.4 |
<para>The "make CLEAN" step will remove any stale source files, include |
640 |
|
|
files, and links. It is strongly recommended for "un-clean" |
641 |
|
|
directories which may contain the (perhaps partial) results of |
642 |
|
|
previous builds. Such "debris" can interfere with the next stage of |
643 |
|
|
the build.</para> |
644 |
|
|
|
645 |
|
|
<para>The "make depend" step will create a large number of symbolic |
646 |
|
|
links from the local directory to the source file locations. It also |
647 |
|
|
parses these files and creates an extensive list of dependencies |
648 |
|
|
within the <filename>Makefile</> itself. The links that exist at this |
649 |
|
|
stage are mostly "large F" files (*.F and *.F90) that need to be |
650 |
|
|
processed by a C preprocessor ("CPP"). Since "make depend" edits the |
651 |
|
|
<filename>Makefile</>, it is important not to skip this step!</para> |
652 |
|
|
|
653 |
|
|
<para>The final "make" invokes the C preprocessor to produce the "little |
654 |
|
|
f" files (*.f and *.f90) and then compiles them to object code using |
655 |
|
|
the specified FORTRAN compiler and options. An intermediate script is |
656 |
|
|
often used during this stage to further process (usually, make simple |
657 |
|
|
substitutions) custom definitions such as variable types within the |
658 |
|
|
source files. This additional stage is necessary in order to overcome |
659 |
|
|
some of the inconsistencies in the sizes of objects (bytes) between |
660 |
edhill |
1.5 |
different compilers. The result of the build process is an executable |
661 |
|
|
with the name <filename>mitgcmuv</>.</para> |
662 |
|
|
|
663 |
|
|
<para>In addition to the forward simulator described above, the |
664 |
|
|
<filename>Makefile</> also has a number of targets that can be used to |
665 |
|
|
produce various adjoint and tangent-linear builds for optimization and |
666 |
|
|
other parameter-sensitivity problems. The additional targets within |
667 |
|
|
the <filename>Makefile</> are:</para> |
668 |
|
|
|
669 |
|
|
<variablelist> |
670 |
|
|
|
671 |
|
|
<varlistentry> |
672 |
|
|
<term><filename>make adall</></term> |
673 |
|
|
<listitem> |
674 |
|
|
<para>This target produces an <filename>mitgcmuv_ad</> executable |
675 |
|
|
using the <filename>taf</> or <filename>staf</> adjoint |
676 |
|
|
compiler. See the <filename>genmake2</> "-adof" option for |
677 |
|
|
compiler selection.</para> |
678 |
|
|
</listitem> |
679 |
|
|
</varlistentry> |
680 |
|
|
|
681 |
|
|
<varlistentry> |
682 |
|
|
<term><filename>make ftlall</></term> |
683 |
|
|
<listitem> |
684 |
|
|
<para>Similar to <filename>make adall</> above, this |
685 |
|
|
produces...</para> |
686 |
|
|
</listitem> |
687 |
|
|
</varlistentry> |
688 |
|
|
|
689 |
|
|
</variablelist> |
690 |
edhill |
1.3 |
|
691 |
edhill |
1.5 |
<para>Please report any compilation failures or other build problems to |
692 |
|
|
the <email>MITgcm-support@mitgcm.org</email> list.</para> |
693 |
edhill |
1.3 |
|
694 |
|
|
</sect3> |
695 |
|
|
|
696 |
|
|
</sect2> |
697 |
|
|
|
698 |
|
|
<sect2 id="verification"> |
699 |
|
|
<title>The Verification Suite</title> |
700 |
|
|
|
701 |
edhill |
1.4 |
<para>The MITgcm CVS tree (within the <filename>$ROOTDIR/verification/</> |
702 |
|
|
directory) includes more than a dozen examples intended for regression |
703 |
|
|
testing. Each one of these example directories contains "known-good" |
704 |
|
|
output files along with all the input (including both code and data |
705 |
|
|
files) required for their re-calculation. These example directories are |
706 |
|
|
further broken down into sets of subdirectories |
707 |
|
|
(eg. <filename>/input</>, <filename>/code</>) intended to expedite the |
708 |
|
|
testing process.</para> |
709 |
edhill |
1.3 |
|
710 |
|
|
<sect3 id="testreport"> |
711 |
|
|
<title>The <filename>testreport</> Utility</title> |
712 |
|
|
|
713 |
edhill |
1.4 |
<para>Also included in <filename>$ROOTDIR/verification/</> are shell |
714 |
|
|
scripts for automated testing. The newest script (which was written |
715 |
|
|
to work with <filename>genmake2</>) is called <filename>testreport</>. |
716 |
|
|
This script can be used to build different versions of the MITgcm |
717 |
|
|
code, run the various examples, compare the output, and (if specified) |
718 |
|
|
email the results of each one of these tests to a central |
719 |
|
|
repository.</para> |
720 |
|
|
|
721 |
|
|
<para>On some systems, the testreport script can be run with a command |
722 |
|
|
line as simple as:</para> |
723 |
|
|
|
724 |
|
|
<screen> |
725 |
edhill |
1.5 |
$ cd verification |
726 |
|
|
$ ./testreport -ieee |
727 |
edhill |
1.4 |
</screen> |
728 |
|
|
|
729 |
|
|
<para>However, some systems (those lacking or wiht a broken "/bin/sh") |
730 |
|
|
may require an explicit shell invocation such as:</para> |
731 |
|
|
|
732 |
|
|
<screen> |
733 |
edhill |
1.5 |
$ sh ./testreport -ieee -t 'exp0 exp4' |
734 |
|
|
$ /some/path/to/bash ./testreport -ieee -t 'ideal_2D_oce lab_sea natl_box' |
735 |
edhill |
1.4 |
</screen> |
736 |
edhill |
1.3 |
|
737 |
|
|
<para>The <filename>testreport</> script accepts a number of |
738 |
edhill |
1.4 |
command-line options which can be listed using the <filename>-help</> |
739 |
|
|
option. The most important ones are:</para> |
740 |
edhill |
1.3 |
|
741 |
|
|
<variablelist> |
742 |
|
|
|
743 |
|
|
<varlistentry> |
744 |
edhill |
1.4 |
<term><filename>-ieee</></term> |
745 |
|
|
<listitem> |
746 |
|
|
<para>If allowed by the compiler (as defined in the "optfile"), |
747 |
|
|
use IEEE arithmetic. This option, along with the GCC compiler, |
748 |
|
|
is how the standard results were produced.</para> |
749 |
|
|
</listitem> |
750 |
|
|
</varlistentry> |
751 |
|
|
|
752 |
|
|
<varlistentry> |
753 |
edhill |
1.3 |
<term><filename>-tdir TESTDIR</></term> |
754 |
|
|
<term><filename>-tdir 'TDIR1 TDIR2 [...]'</></term> |
755 |
|
|
<listitem> |
756 |
edhill |
1.4 |
<para>This option specifies the test directory or list of test |
757 |
|
|
directories that should be used. Each of these entries should |
758 |
|
|
exactly (note: they are case sensitive!) match the names of |
759 |
|
|
directries in <filename>$ROOTDIR/verification/</>. If this |
760 |
|
|
option is omitted, then all directories that are properly |
761 |
|
|
formatted (that is, containing an <filename>input</> |
762 |
|
|
sub-directory and a <filename>results/output.txt</> file) will |
763 |
|
|
be used.</para> |
764 |
edhill |
1.3 |
</listitem> |
765 |
|
|
</varlistentry> |
766 |
|
|
|
767 |
|
|
<varlistentry> |
768 |
|
|
<term><filename>-optfile=/PATH/FILENAME</></term> |
769 |
|
|
<term><filename>-optfile '/PATH/F1 [/PATH/F2 ...]'</></term> |
770 |
|
|
<listitem> |
771 |
edhill |
1.4 |
<para>This specifies a list of "options files" that will be passed |
772 |
|
|
to <filename>genmake2</>. If multiple options files are used |
773 |
|
|
(say, to test different compilers or different sets of options |
774 |
|
|
for the same compiler), then each options file will be used with |
775 |
|
|
each of the test directories.</para> |
776 |
edhill |
1.3 |
</listitem> |
777 |
|
|
</varlistentry> |
778 |
|
|
|
779 |
|
|
<varlistentry> |
780 |
|
|
<term><filename>-addr EMAIL</></term> |
781 |
|
|
<term><filename>-addr 'EMAIL1 EMAIL2 [...]'</></term> |
782 |
|
|
<listitem> |
783 |
|
|
<para>Send the results (namely, <filename>output.txt</>, |
784 |
edhill |
1.4 |
<filename>genmake_local</>, <filename>genmake_state</>, and |
785 |
|
|
<filename>Makefile</>) to the specified email addresses. The |
786 |
|
|
results are gzipped, placed in a tar file, MIME encoded, and |
787 |
|
|
sent to the specified address. If no email addresses are |
788 |
|
|
specified, no mail is sent.</para> |
789 |
|
|
</listitem> |
790 |
|
|
</varlistentry> |
791 |
|
|
|
792 |
|
|
<varlistentry> |
793 |
|
|
<term><filename>-mpi</></term> |
794 |
|
|
<listitem> |
795 |
|
|
<para>If the necessary files |
796 |
|
|
(<filename>TESTDIR/code/CPP_EEOPTIONS.h_mpi</> and |
797 |
|
|
<filename>TESTDIR/code/SIZE.h_mpi</>) exist, then use them for an |
798 |
|
|
MPI--enabled run. Note that the use of MPI typically requires a |
799 |
|
|
special command option (see "-command" below) to invoke the MPI |
800 |
|
|
executable. Examples of PBS scripts using MPI with testreport can be |
801 |
|
|
found in the <ulink |
802 |
|
|
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/test_scripts/"> |
803 |
|
|
MITgcm-contrib area</ulink></para> |
804 |
|
|
</listitem> |
805 |
|
|
</varlistentry> |
806 |
|
|
|
807 |
|
|
<varlistentry> |
808 |
|
|
<term><filename>-command='some command to run'</></term> |
809 |
|
|
<listitem> |
810 |
|
|
<para>For some tests, particularly MPI runs, the default "make |
811 |
|
|
output.txt" is not sufficient. This option allows a more general |
812 |
|
|
command (or shell script) to be invoked. Examples of PBS scripts |
813 |
|
|
using MPI with testreport can be found in the <ulink |
814 |
|
|
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/test_scripts/"> |
815 |
|
|
MITgcm-contrib area</ulink></para> |
816 |
edhill |
1.3 |
</listitem> |
817 |
|
|
</varlistentry> |
818 |
|
|
|
819 |
|
|
</variablelist> |
820 |
|
|
|
821 |
edhill |
1.4 |
<para>The <filename>testreport</> script will write progress to the |
822 |
|
|
screen (stdout) as it runs. In addition, it will create a |
823 |
|
|
<filename>tr_out.txt</> file that contains a brief comparison of the |
824 |
|
|
current output with the "known-good" output.</para> |
825 |
edhill |
1.3 |
|
826 |
|
|
</sect3> |
827 |
|
|
|
828 |
|
|
</sect2> |
829 |
edhill |
1.2 |
|
830 |
edhill |
1.4 |
|
831 |
edhill |
1.2 |
<sect2 id="packages"> |
832 |
edhill |
1.3 |
<title>Creating MITgcm Packages</title> |
833 |
edhill |
1.2 |
|
834 |
edhill |
1.4 |
<para>Optional parts of code have been separated from the MITgcmUV core |
835 |
|
|
driver code and organised into packages. The packaging structure |
836 |
|
|
provides a mechanism for maintaining suites of code, specific to |
837 |
|
|
particular classes of problems, in a way that is cleanly separated from |
838 |
|
|
the generic fluid dynamical engine.</para> |
839 |
|
|
|
840 |
|
|
<para>The MITgcmUV packaging structure is described below using generic |
841 |
|
|
package names ${pkg}. A concrete examples of a package is the code for |
842 |
|
|
implementing GM/Redi mixing. This code uses the package name</para> |
843 |
edhill |
1.2 |
|
844 |
|
|
</sect2> |
845 |
|
|
|
846 |
|
|
</sect1> |
847 |
|
|
|
848 |
|
|
<sect1> |
849 |
|
|
<title>Chris's Notes...</title> |
850 |
|
|
|
851 |
|
|
<programlisting> |
852 |
|
|
MITgcmUV Packages |
853 |
|
|
================= |
854 |
|
|
|
855 |
|
|
Optional parts of code are separated from |
856 |
|
|
the MITgcmUV core driver code and organised into |
857 |
|
|
packages. The packaging structure provides a mechanism for |
858 |
|
|
maintaining suites of code, specific to particular |
859 |
|
|
classes of problem, in a way that is cleanly |
860 |
|
|
separated from the generic fluid dynamical engine. |
861 |
|
|
|
862 |
|
|
The MITgcmUV packaging structure is describe |
863 |
|
|
below using generic package names ${pkg}. |
864 |
|
|
A concrete examples of a package is the code |
865 |
|
|
for implementing GM/Redi mixing. This code uses |
866 |
|
|
the package name |
867 |
|
|
* ${PKG} = GMREDI |
868 |
|
|
* ${pkg} = gmredi |
869 |
|
|
* ${Pkg} = gmRedi |
870 |
|
|
|
871 |
|
|
Package states |
872 |
|
|
============== |
873 |
|
|
|
874 |
|
|
Packages can be any one of four states, included, |
875 |
|
|
excluded, enabled, disabled as follows: |
876 |
|
|
|
877 |
|
|
included(excluded) compile time state which |
878 |
|
|
includes(excludes) package |
879 |
|
|
code and routine calls from |
880 |
|
|
compilation/linking etc... |
881 |
|
|
|
882 |
|
|
enabled(disabled) run-time state which |
883 |
|
|
enables(disables) package code |
884 |
|
|
execution. |
885 |
|
|
|
886 |
|
|
Every call to a ${pkg}_... routine from outside the package |
887 |
|
|
should be placed within both a |
888 |
|
|
#ifdef ALLOW_${PKG} ... block and a |
889 |
|
|
if ( use${Pkg} ) ... then block. |
890 |
|
|
Package states are generally not expected to change during |
891 |
|
|
a model run. |
892 |
|
|
|
893 |
|
|
Package structure |
894 |
|
|
================= |
895 |
|
|
|
896 |
|
|
o Each package gets its runtime configuration |
897 |
|
|
parameters from a file named "data.${pkg}" |
898 |
|
|
Package runtime config. options are imported |
899 |
|
|
into a common block held in a header file |
900 |
|
|
called "${PKG}.h". |
901 |
|
|
|
902 |
|
|
o The core driver part of the model can check |
903 |
|
|
for runtime enabling or disabling of individual packages |
904 |
|
|
through logical flags use${Pkg}. |
905 |
|
|
The information is loaded from a |
906 |
|
|
global package setup file called "data.pkg". |
907 |
|
|
The use${Pkg} flags are not used within |
908 |
|
|
individual packages. |
909 |
|
|
|
910 |
|
|
o Included in "${PKG}.h" is a logical flag |
911 |
|
|
called ${Pkg}IsOn. The "${PKG}.h" header file can be imported |
912 |
|
|
by other packages to check dependencies and requirements |
913 |
|
|
from other packages ( see "Package Boot Sequence" section). |
914 |
|
|
NOTE: This procedure is not presently implemented, |
915 |
|
|
----- neither for kpp nor for gmRedi. |
916 |
|
|
|
917 |
|
|
CPP Flags |
918 |
|
|
========= |
919 |
|
|
|
920 |
|
|
1. Within the core driver code flags of the form |
921 |
|
|
ALLOW_${PKG} are used to include or exclude |
922 |
|
|
whole packages. The ALLOW_${PKG} flags are included |
923 |
|
|
from a PKG_CPP_OPTIONS block which is currently |
924 |
|
|
held in-line in the CPP_OPTIONS.h header file. |
925 |
|
|
e.g. |
926 |
|
|
|
927 |
|
|
Core model code ..... |
928 |
|
|
|
929 |
|
|
#include "CPP_OPTIONS.h" |
930 |
|
|
: |
931 |
|
|
: |
932 |
|
|
: |
933 |
|
|
|
934 |
|
|
#ifdef ALLOW_${PKG} |
935 |
|
|
if ( use${Pkg} ) CALL ${PKG}_DO_SOMETHING(...) |
936 |
|
|
#endif |
937 |
|
|
|
938 |
|
|
2. Within an individual package a header file, |
939 |
|
|
"${PKG}_OPTIONS.h", is used to set CPP flags |
940 |
|
|
specific to that package. It is not recommended |
941 |
|
|
to include this file in "CPP_OPTIONS.h". |
942 |
|
|
|
943 |
|
|
|
944 |
|
|
Package Boot Sequence |
945 |
|
|
===================== |
946 |
|
|
|
947 |
|
|
Calls to package routines within the core code timestepping |
948 |
|
|
loop can vary. However, all packages follow a required |
949 |
|
|
"boot" sequence outlined here: |
950 |
|
|
|
951 |
|
|
1. S/R PACKAGES_BOOT() |
952 |
|
|
: |
953 |
|
|
CALL OPEN_COPY_DATA_FILE( 'data.pkg', 'PACKAGES_BOOT', ... ) |
954 |
|
|
|
955 |
|
|
|
956 |
|
|
2. S/R PACKAGES_READPARMS() |
957 |
|
|
: |
958 |
|
|
#ifdef ALLOW_${PKG} |
959 |
|
|
if ( use${Pkg} ) |
960 |
|
|
& CALL ${PKG}_READPARMS( retCode ) |
961 |
|
|
#endif |
962 |
|
|
|
963 |
|
|
2. S/R PACKAGES_CHECK() |
964 |
|
|
: |
965 |
|
|
#ifdef ALLOW_${PKG} |
966 |
|
|
if ( use${Pkg} ) |
967 |
|
|
& CALL ${PKG}_CHECK( retCode ) |
968 |
|
|
#else |
969 |
|
|
if ( use${Pkg} ) |
970 |
|
|
& CALL PACKAGES_CHECK_ERROR('${PKG}') |
971 |
|
|
#endif |
972 |
|
|
|
973 |
|
|
3. S/R PACKAGES_INIT() |
974 |
|
|
: |
975 |
|
|
#ifdef ALLOW_${PKG} |
976 |
|
|
if ( use${Pkg} ) |
977 |
|
|
& CALL ${PKG}_INIT( retCode ) |
978 |
|
|
#endif |
979 |
|
|
|
980 |
|
|
|
981 |
|
|
Description |
982 |
|
|
=========== |
983 |
|
|
|
984 |
|
|
- ${PKG}_READPARMS() |
985 |
|
|
is responsible for reading |
986 |
|
|
in the package parameters file data.${pkg}, and storing |
987 |
|
|
the package parameters in "${PKG}.h". |
988 |
|
|
-> called in INITIALISE_FIXED |
989 |
|
|
|
990 |
|
|
- ${PKG}_CHECK() |
991 |
|
|
is responsible for validating |
992 |
|
|
basic package setup and inter-package dependencies. |
993 |
|
|
${PKG}_CHECK can import other package parameters it may |
994 |
|
|
need to check. This is done through header files "${PKG}.h". |
995 |
|
|
It is assumed that parameters owned by other packages |
996 |
|
|
will not be reset during ${PKG}_CHECK(). |
997 |
|
|
-> called in INITIALISE_FIXED |
998 |
|
|
|
999 |
|
|
- ${PKG}_INIT() |
1000 |
|
|
is responsible for completing the |
1001 |
|
|
internal setup of a package. This routine is called after |
1002 |
|
|
the core model state has been completely initialised |
1003 |
|
|
but before the core model timestepping starts. |
1004 |
|
|
-> called in INITIALISE_VARIA |
1005 |
|
|
|
1006 |
|
|
Summary |
1007 |
|
|
======= |
1008 |
|
|
|
1009 |
|
|
- CPP options: |
1010 |
|
|
----------------------- |
1011 |
|
|
* ALLOW_${PKG} include/exclude package for compilation |
1012 |
|
|
|
1013 |
|
|
- FORTRAN logical: |
1014 |
|
|
----------------------- |
1015 |
|
|
* use${Pkg} enable package for execution at runtime |
1016 |
|
|
-> declared in PARAMS.h |
1017 |
|
|
* ${Pkg}IsOn for package cross-dependency check |
1018 |
|
|
-> declared in ${PKG}.h |
1019 |
|
|
N.B.: Not presently used! |
1020 |
|
|
|
1021 |
|
|
- header files |
1022 |
|
|
----------------------- |
1023 |
|
|
* ${PKG}_OPTIONS.h has further package-specific CPP options |
1024 |
|
|
* ${PKG}.h package-specific common block variables, fields |
1025 |
|
|
|
1026 |
|
|
- FORTRAN source files |
1027 |
|
|
----------------------- |
1028 |
|
|
* ${pkg}_readparms.F reads parameters from file data.${pkg} |
1029 |
|
|
* ${pkg}_check.F checks package dependencies and consistencies |
1030 |
|
|
* ${pkg}_init.F initialises package-related fields |
1031 |
|
|
* ${pkg}_... .F package source code |
1032 |
|
|
|
1033 |
|
|
- parameter file |
1034 |
|
|
----------------------- |
1035 |
|
|
* data.${pkg} parameter file |
1036 |
|
|
</programlisting> |
1037 |
|
|
|
1038 |
|
|
</sect1> |
1039 |
edhill |
1.1 |
|
1040 |
|
|
|
1041 |
|
|
</article> |
1042 |
|
|
|
1043 |
|
|
|