| 22 |
Initial version. |
Initial version. |
| 23 |
</revremark> |
</revremark> |
| 24 |
</revision> |
</revision> |
| 25 |
|
<revision> |
| 26 |
|
<revnumber>0.02</revnumber> |
| 27 |
|
<date>2010-01-21</date> |
| 28 |
|
<authorinitials>jmc</authorinitials> |
| 29 |
|
<revremark> |
| 30 |
|
update links. |
| 31 |
|
</revremark> |
| 32 |
|
</revision> |
| 33 |
|
<revision> |
| 34 |
|
<revnumber>0.03</revnumber> |
| 35 |
|
<date>2010-04-25</date> |
| 36 |
|
<authorinitials>jmc</authorinitials> |
| 37 |
|
<revremark> |
| 38 |
|
Add subsection "Developer settings" (under CVS Repository). |
| 39 |
|
</revremark> |
| 40 |
|
</revision> |
| 41 |
</revhistory> |
</revhistory> |
| 42 |
|
|
| 43 |
<abstract> |
<abstract> |
| 53 |
<sect2> |
<sect2> |
| 54 |
<title>New Versions of This Document</title> <para>You can |
<title>New Versions of This Document</title> <para>You can |
| 55 |
obtain the latest version of this document <ulink |
obtain the latest version of this document <ulink |
| 56 |
url="http://mitgcm.org/dev_docs/devel_HOWTO/">online</ulink> in |
url="http://mitgcm.org/public/docs.html">online</ulink> in |
| 57 |
various formats.</para> |
various formats.</para> |
| 58 |
</sect2> |
</sect2> |
| 59 |
<sect2> |
<sect2> |
| 72 |
<title>User Manual</title> |
<title>User Manual</title> |
| 73 |
|
|
| 74 |
<para>Before jumping into development, please familiarize yourself with |
<para>Before jumping into development, please familiarize yourself with |
| 75 |
the <ulink url="http://mitgcm.org/docs.html"> MITgcm user manual |
the <ulink url="http://mitgcm.org/public/docs.html"> MITgcm user manual |
| 76 |
</ulink>. This document contains volumes of useful information and is |
</ulink>. This document contains volumes of useful information and is |
| 77 |
included here by reference.</para> |
included here by reference.</para> |
| 78 |
|
|
| 110 |
|
|
| 111 |
<sect1 id="cvs"> |
<sect1 id="cvs"> |
| 112 |
<title>CVS Repository</title> |
<title>CVS Repository</title> |
| 113 |
|
|
| 114 |
<sect2> |
<sect2> |
| 115 |
<title>Layout</title> |
<title>Layout</title> |
| 116 |
|
|
| 121 |
others. The tree currently resembles:</para> |
others. The tree currently resembles:</para> |
| 122 |
|
|
| 123 |
<programlisting>gcmpack/ |
<programlisting>gcmpack/ |
|
MITgcm-contrib contributed code |
|
| 124 |
CS-regrid goes into utils |
CS-regrid goes into utils |
| 125 |
cvspolicy.html -save- |
CVSROOT -hidden- |
|
CVSROOT -save- |
|
|
development experimental stuff |
|
|
manual -save- |
|
|
misc -?- |
|
| 126 |
|
|
| 127 |
MITgcm code |
MITgcm code |
| 128 |
adjoint fold into genmake |
bin empty |
| 129 |
bin stub for ecco build |
doc basic developpment documentation |
| 130 |
compare01 old from 20th century |
eesupp execution environment support code (wrapper) |
| 131 |
diags timeave f77 in pkgs now |
exe empty |
| 132 |
doc tags -- connect to real docs? |
jobs runtime shell scripts for |
| 133 |
eesupp cnh? |
various platforms (not maintained) |
| 134 |
exe ecco user build |
lsopt line search |
| 135 |
,- jobs runtime shell scripts for |
model main dynamics (core) |
| 136 |
| various platforms |
optim line search interface |
| 137 |
| lsopt line search |
pkg alternate and optional numerics, etc. |
| 138 |
m| model main dynamics (core) |
tools scripts to build (and test) |
| 139 |
e| optimization_drivers ? |
utils pre/post processing tools (matlab, ..) |
| 140 |
r| optim line search interface |
verification standard regression tests + examples |
| 141 |
g| pkg alternate and optional numerics, etc. |
+ documented examples (tutorials) |
| 142 |
e|- tools |
tutorial_examples (only in release1 branch) |
|
?| tutorial_examples documented tests |
|
|
| only populated on release1 branch |
|
|
| and not validated during "testscript" |
|
|
'- utils |
|
|
verification std tests |
|
| 143 |
|
|
| 144 |
|
MITgcm_contrib contributed code |
| 145 |
|
|
| 146 |
mitgcmdoc -> manual -remove- |
acesgrid.org build acesgrid web site |
| 147 |
|
development experimental stuff |
| 148 |
|
gcmpack an old back-up copy ? |
| 149 |
|
gfd_lab -?- |
| 150 |
|
manual -save- |
| 151 |
|
misc -?- |
| 152 |
mitgcm.org build web site |
mitgcm.org build web site |
| 153 |
|
mitgcmdoc -> manual -remove- |
| 154 |
models -?- |
models -?- |
| 155 |
packages -?- |
packages -?- |
| 156 |
|
pdfs some pdfs |
| 157 |
|
planetinabottle.org unfinished web site |
| 158 |
preprocess -?- |
preprocess -?- |
| 159 |
tmp -?- |
tmp -?- |
| 160 |
|
www.ecco-group.org build ecco web site ? |
| 161 |
</programlisting> |
</programlisting> |
| 162 |
|
|
| 163 |
|
<!-- |
| 164 |
<para>Efforts are underway to reduce the complexity.</para> |
<para>Efforts are underway to reduce the complexity.</para> |
| 165 |
|
--> |
| 166 |
|
|
| 167 |
</sect2> |
</sect2> |
| 168 |
|
|
| 201 |
<title>Branches</title> |
<title>Branches</title> |
| 202 |
|
|
| 203 |
<para>As shown in the online <ulink |
<para>As shown in the online <ulink |
| 204 |
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/doc/tag-index?graph=1.174">ViewCVS-generated |
url="http://mitgcm.org/viewvc/MITgcm/MITgcm/model/src/forward_step.F?view=graph"> |
| 205 |
tree</ulink>, the MITgcm codebase is split into to two branches |
ViewCVS-generated tree</ulink>, the MITgcm codebase is split into to two |
| 206 |
or "lines" under which development proceeds. These two lines |
branches or "lines" under which development proceeds. These two lines are |
| 207 |
are referred to as the "MAIN" and "ecco" versions of the code. |
referred to as the "MAIN" and "ecco" versions of the code. While not |
| 208 |
While not identical, the bulk of the MAIN and ecco lines are |
identical, the bulk of the MAIN and ecco lines are composed of files from |
| 209 |
composed of files from the same codebase. |
the same codebase. |
| 210 |
</para> |
</para> |
| 211 |
|
|
| 212 |
<para>Periodically, a "Release" branch is formed from the "MAIN" |
<para>Periodically, a "Release" branch is formed from the "MAIN" |
| 213 |
development branch. This is done in order to create a |
development branch. This is done in order to create a relatively stable |
| 214 |
relatively stable reference point for both users and developers. |
reference point for both users and developers. The intent is that once a |
| 215 |
The intent is that once a relese branch has been created, only |
relese branch has been created, only bug-fixes will be added to it. |
| 216 |
bug-fixes will be added to it. Meanwhile, development (which |
Meanwhile, development (which might "break" or otherwise render invalid |
| 217 |
might "break" or otherwise render invalid the documentation, |
the documentation, tutorials, and/or examples contained within a release |
| 218 |
tutorials, and/or examples contained within a release branch) is |
branch) is allowed to continue along the MAIN and ecco lines.</para> |
|
allowed to continue along the MAIN and ecco lines.</para> |
|
| 219 |
</sect2> |
</sect2> |
| 220 |
|
|
| 221 |
<sect2> |
<sect2> |
| 222 |
<title>Tagging</title> |
<title> Developer settings </title> |
|
|
|
|
<para>The intent of tagging is to create "known-good" |
|
|
checkpoints that developers can use as references. |
|
|
Traditionally, MITgcm tagging has maintained the following |
|
|
conventions:</para> |
|
| 223 |
|
|
| 224 |
|
<para>CVS is a convenient tool to keep up-to-date a personal copy of the |
| 225 |
|
MITgcm code (see: <ulink url="http://mitgcm.org/public/using_cvs.html"> |
| 226 |
|
using CVS </ulink>). The same tool is used by developers to |
| 227 |
|
incorporate any change into the repository. However, this later |
| 228 |
|
function requires specific settings, as detailed here after:</para> |
| 229 |
<orderedlist> |
<orderedlist> |
| 230 |
<listitem> |
<listitem> |
| 231 |
<para>Developer checks out code into a local CVS-managed |
<para> You will need an account (loggin access) to the server |
| 232 |
directory, makes various changes/additions, tests these |
"mitgcm.org" with the proper group setting (e.g., |
| 233 |
edits, and eventually reaches a point where (s)he is |
group "gcmctrb" to add/modify code into MITgcm_contrib). |
| 234 |
satisfied that the changes form a new "useful" point in the |
This kind of account is granted only upon well motivated request. |
| 235 |
evolution of the code.</para> |
The access to the server mitgcm.org is through ssh-key authorization |
| 236 |
|
which will need to be set properly on both side (on your local machine |
| 237 |
|
and on your server account). You need to be able to |
| 238 |
|
to ssh to mitgcm.org (or <filename>ssh MY_USER_NAME@mitgcm.org</filename> |
| 239 |
|
in case of different user-name on both sides) to proceed further.</para> |
| 240 |
|
</listitem> |
| 241 |
|
|
| 242 |
|
<listitem> |
| 243 |
|
<para> You need to register to the |
| 244 |
|
<ulink url="http://mitgcm.org/mailman/listinfo/mitgcm-cvs"> |
| 245 |
|
mitgcm-cvs </ulink> mailing list. |
| 246 |
|
This ensures that other developers will receive email notification |
| 247 |
|
when you make changes; you will also receive as well such email |
| 248 |
|
when others make changes to the repository. |
| 249 |
|
</para> |
| 250 |
|
</listitem> |
| 251 |
|
|
| 252 |
|
<listitem> |
| 253 |
|
<para> It is highly recommended that you register also to the |
| 254 |
|
<ulink url="http://mitgcm.org/mailman/listinfo/mitgcm-devel"> |
| 255 |
|
mitgcm-devel </ulink> mailing list (expect a short delay for |
| 256 |
|
this request to be processed). |
| 257 |
|
This list is intended for developer discussions. |
| 258 |
|
</para> |
| 259 |
|
</listitem> |
| 260 |
|
|
| 261 |
|
<listitem> |
| 262 |
|
<para> The standard anonymous mode (using "cvsanon", as mentionned |
| 263 |
|
<ulink url="http://mitgcm.org/public/source_code.html"> |
| 264 |
|
here </ulink>) does not allow check-in ("cvs commit") permission. |
| 265 |
|
Instead, you will need to set our CVS environment as follow:</para> |
| 266 |
|
<screen> |
| 267 |
|
$ export CVS_RSH=ssh |
| 268 |
|
$ export CVSROOT=':ext:MY_USER_NAME@mitgcm.org:/u/gcmpack' |
| 269 |
|
</screen> |
| 270 |
|
<para> After downloading a directory, e.g.: <filename>myCopy</filename>, |
| 271 |
|
from the CVS repository (e.g., |
| 272 |
|
<filename>MITgcm_contrib/thisPart</filename>) using the command:</para> |
| 273 |
|
<screen> |
| 274 |
|
$ cvs co -P -d myCopy MITgcm_contrib/thisPart |
| 275 |
|
</screen> |
| 276 |
|
<para> the type of CVS environment which has been used |
| 277 |
|
is stored in the file <filename>myCopy/CVS/Root</filename> |
| 278 |
|
and makes it difficult to re-use, for cvs-commit purpose, |
| 279 |
|
a cvs local copy (<filename>myCopy</filename>) which was obtained |
| 280 |
|
using the CVS anonymous mode.</para> |
| 281 |
|
</listitem> |
| 282 |
|
|
| 283 |
|
<listitem> |
| 284 |
|
<para> At this stage, you should be able to send your modified source |
| 285 |
|
file (e.g., <filename>src_file</filename>) from your local copy directory |
| 286 |
|
(<filename>myCopy</filename>) to the CVS repository |
| 287 |
|
(<filename>MITgcm_contrib/thisPart</filename>) using the command |
| 288 |
|
"cvs commit":</para> |
| 289 |
|
<screen> |
| 290 |
|
$ cd myCopy |
| 291 |
|
$ cvs -n update (optional; check if new changes have been made) |
| 292 |
|
$ cvs diff src_file (optional; list your changes) |
| 293 |
|
$ cvs commit src_file |
| 294 |
|
</screen> |
| 295 |
|
<para> It is essential that you provide a short description of the |
| 296 |
|
changes you made to <filename>src_file</filename> as you check-in |
| 297 |
|
this file (the "cvs commit" command automatically opens your standard |
| 298 |
|
editor for this purpose).</para> |
| 299 |
|
</listitem> |
| 300 |
|
|
| 301 |
|
</orderedlist> |
| 302 |
|
|
| 303 |
|
</sect2> |
| 304 |
|
|
| 305 |
|
<sect2> |
| 306 |
|
<title>Main code development</title> |
| 307 |
|
<para>(formerly named "Tagging" ; this section needs an update)</para> |
| 308 |
|
|
| 309 |
|
<para>The intent of tagging is to create "known-good" checkpoints that |
| 310 |
|
developers can use as references. Traditionally, MITgcm tagging has |
| 311 |
|
maintained the following conventions:</para> |
| 312 |
|
|
| 313 |
|
<orderedlist> |
| 314 |
|
<listitem> |
| 315 |
|
<para>Developer checks out code into a local CVS-managed directory, |
| 316 |
|
makes various changes/additions, tests these edits, and eventually |
| 317 |
|
reaches a point where (s)he is satisfied that the changes form a new |
| 318 |
|
"useful" point in the evolution of the code.</para> |
| 319 |
</listitem> |
</listitem> |
| 320 |
|
|
| 321 |
<listitem> |
<listitem> |
| 322 |
<para>The developer then runs the <ulink |
<para>The developer then runs the <ulink |
| 323 |
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/verification/testscript">testscript</ulink> |
url="http://mitgcm.org/viewvc/MITgcm/MITgcm/verification/testreport"> |
| 324 |
shell script to see if any problems are introduced. While |
testreport</ulink> shell script to see if any problems are introduced. |
| 325 |
not intended to be exhaustive, the test cases within the |
While not intended to be exhaustive, the test cases within the |
| 326 |
verification directory do provide some indication whether |
verification directory do provide some indication whether gross errors |
| 327 |
gross errors have been introduced. |
have been introduced. |
| 328 |
</para> |
</para> |
| 329 |
</listitem> |
</listitem> |
| 330 |
|
|
| 334 |
then:</para> |
then:</para> |
| 335 |
<orderedlist> |
<orderedlist> |
| 336 |
<listitem> |
<listitem> |
| 337 |
<para>adds a "checkpointXY_pre" comment (where X is a |
<para>adds a "checkpointXY_pre" comment (where X is a checkpoint |
| 338 |
checkpoint number and Y is a letter) to the <ulink |
number and Y is a letter) to the <ulink |
| 339 |
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/doc/tag-index">tag-index</ulink> |
url="http://mitgcm.org/viewvc/MITgcm/MITgcm/doc/tag-index"> |
| 340 |
file and checks it into the CVS repository</para> |
tag-index</ulink> file and checks it into the CVS |
| 341 |
|
repository</para> |
| 342 |
</listitem> |
</listitem> |
| 343 |
<listitem> |
<listitem> |
| 344 |
<para>submits the set of changes to the CVS repository |
<para>submits the set of changes to the CVS repository and adds |
| 345 |
and adds comments to <filename>tag-index</filename> |
comments to <filename>tag-index</filename> describing what the |
| 346 |
describing what the changes are along with a matching |
changes are along with a matching "checkpointXY_post" entry</para> |
|
"checkpointXY_post" entry</para> |
|
| 347 |
</listitem> |
</listitem> |
| 348 |
</orderedlist> |
</orderedlist> |
| 349 |
</listitem> |
</listitem> |
| 350 |
</orderedlist> |
</orderedlist> |
| 351 |
|
|
| 352 |
<para>The result of this tagging procedure is a sequence of |
<para>The result of this tagging procedure is a sequence of development |
| 353 |
development checkpoints with comments which resembles:</para> |
checkpoints with comments which resembles:</para> |
| 354 |
|
|
| 355 |
<programlisting> |
<programlisting> |
| 356 |
checkpoint50e_post |
checkpoint50e_post |
| 372 |
checkpoint50d_pre |
checkpoint50d_pre |
| 373 |
</programlisting> |
</programlisting> |
| 374 |
|
|
| 375 |
<para>This information can be used to refer to various stages of |
<para>This information can be used to refer to various stages of the code |
| 376 |
the code development. For example, bugs can be traced to |
development. For example, bugs can be traced to individual sets of CVS |
| 377 |
individual sets of CVS checkins based upon their first |
checkins based upon their first appearance when comparing the results from |
| 378 |
appearance when comparing the results from different |
different checkpoints.</para> |
|
checkpoints.</para> |
|
| 379 |
|
|
| 380 |
</sect2> |
</sect2> |
| 381 |
</sect1> |
</sect1> |
| 382 |
|
|
| 383 |
|
|
|
<sect1 id="documentation"> |
|
|
<title>Editing the Documentation</title> |
|
|
|
|
|
<sect2 id="documentation_getting"> |
|
|
<title>Getting the Docs and Code</title> |
|
|
|
|
|
<para>The first step towards editing the documentation is to |
|
|
checkout a copy of code, docs, and build scripts from the CVS |
|
|
server using:</para> |
|
|
|
|
|
<screen> |
|
|
$ export CVS_RSH=ssh |
|
|
$ export CVSROOT=':ext:auden.lcs.mit.edu:/u/u3/gcmpack' |
|
|
$ mkdir scratch |
|
|
$ cvs co MITgcm manual mitgcm.org |
|
|
</screen> |
|
|
|
|
|
<para>These commands extract the necessary information from the |
|
|
CVS server and create a temporary (called |
|
|
<filename>scratch</filename>) directory for the storage of the |
|
|
HTML and other files that will be created. Please note that you |
|
|
must either create <filename>scratch</filename> as shown or edit |
|
|
the various <filename>Makefile</filename>s and scripts used to |
|
|
create the documentation.</para> |
|
|
</sect2> |
|
|
|
|
|
<sect2> |
|
|
<title>Editing the Documentation</title> |
|
|
|
|
|
<para>The documentation is contained in the |
|
|
<filename>manual</filename> directory in a raw LaTeX format. |
|
|
The main document is <filename>manual.tex</filename> and it uses |
|
|
<command>\input{}</command>s to include the chapters and |
|
|
subsections.</para> |
|
|
|
|
|
<para>Since the same LaTeX source is used to produce PostScript, |
|
|
PDF, and HTML output, care should be taken to follow certain |
|
|
conventions. Two of the most important are the usage of the |
|
|
<command>\filelink{}{}</command> and |
|
|
<command>\varlink{}{}</command> commands. Both of these |
|
|
commands have been defined to simplify the connection between |
|
|
the automatically generated ("code browser") HTML and the HTML |
|
|
version of the manual produced by LaTeX2HTML. They each take |
|
|
two arguments (corresponding to the contents of the two sets of |
|
|
curly braces) which are the text that the author wishes to be |
|
|
"wrapped" within the link, and a specially formatted link thats |
|
|
relative to the <filename>MITgcm</filename> directory within the |
|
|
CVS tree.</para> |
|
|
|
|
|
<para>The result is a command that resembles either</para> |
|
|
|
|
|
<orderedlist> |
|
|
<listitem> |
|
|
<para>a reference to a variable or subroutine name such as |
|
|
<command>\varlink{tRef}{tRef}</command>, or </para> |
|
|
</listitem> |
|
|
|
|
|
<listitem> |
|
|
<para>a reference to a file such as |
|
|
<command>\varlink{tRef}{path-to-the-file_name.F}</command> |
|
|
where the absolute path to the file is of the form |
|
|
<filename>/foo/MITgcm/path/to/the/file_name.F</filename></para> |
|
|
<para>(please note how the leading "/foo/MITgcm" |
|
|
component of the path is dropped leaving the path |
|
|
<emphasis>relative</emphasis> to the head of the code |
|
|
directory and each directory separator "/" is turned |
|
|
into a "-")</para> |
|
|
</listitem> |
|
|
</orderedlist> |
|
|
|
|
|
|
|
|
|
|
|
</sect2> |
|
|
|
|
|
<sect2> |
|
|
<title>Building the Documentation</title> |
|
|
|
|
|
<para>Given the directory structure of <xref |
|
|
linkend="documentation_getting">, the entire documentation for the web |
|
|
site can be built using:</para> |
|
|
|
|
|
<screen> |
|
|
$ cd mitgcm.org/devel/buildweb |
|
|
$ make All |
|
|
</screen> |
|
|
|
|
|
<para>Which builds the PDF from the LaTeX source, creates the |
|
|
HTML output from the LaTeX source, parses the FORTRAN code base |
|
|
to produce a hyperlinked HTML version of the source, and then |
|
|
determines the cross-linking between the various HTML |
|
|
components.</para> |
|
|
|
|
|
<para>If there are no errors, the result of the build process |
|
|
(which can take 30+ minutes on a P4/2.5Ghz) will be contained |
|
|
within a single directory called |
|
|
<filename>scratch/dev_docs</filename>. This is a freshly built |
|
|
version of the entire on-line users manual. If you have the |
|
|
correct permissions, it can be directly copied to the web server |
|
|
area:</para> |
|
|
|
|
|
<screen> |
|
|
$ mv scratch/dev_docs /u/u0/httpd/html |
|
|
</screen> |
|
|
|
|
|
<para>and the update is complete.</para> |
|
|
|
|
|
</sect2> |
|
|
|
|
|
</sect1> |
|
|
|
|
| 384 |
<sect1 id="coding"> |
<sect1 id="coding"> |
| 385 |
<title>Coding for MITgcm</title> |
<title>Coding for MITgcm</title> |
| 386 |
|
|
| 453 |
|
|
| 454 |
<orderedlist> |
<orderedlist> |
| 455 |
<listitem> |
<listitem> |
| 456 |
<para>a <filename>gm_local</filename> file in the current |
<para>a <filename>gemake_local</filename> file in the current |
| 457 |
directory</para> |
directory</para> |
| 458 |
</listitem> |
</listitem> |
| 459 |
<listitem> |
<listitem> |
| 789 |
special command option (see "-command" below) to invoke the MPI |
special command option (see "-command" below) to invoke the MPI |
| 790 |
executable. Examples of PBS scripts using MPI with testreport can be |
executable. Examples of PBS scripts using MPI with testreport can be |
| 791 |
found in the <ulink |
found in the <ulink |
| 792 |
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/test_scripts/"> |
url="http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/test_scripts/"> |
| 793 |
MITgcm-contrib area</ulink></para> |
MITgcm-contrib area</ulink></para> |
| 794 |
</listitem> |
</listitem> |
| 795 |
</varlistentry> |
</varlistentry> |
| 801 |
output.txt" is not sufficient. This option allows a more general |
output.txt" is not sufficient. This option allows a more general |
| 802 |
command (or shell script) to be invoked. Examples of PBS scripts |
command (or shell script) to be invoked. Examples of PBS scripts |
| 803 |
using MPI with testreport can be found in the <ulink |
using MPI with testreport can be found in the <ulink |
| 804 |
url="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/test_scripts/"> |
url="http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/test_scripts/"> |
| 805 |
MITgcm-contrib area</ulink></para> |
MITgcm-contrib area</ulink></para> |
| 806 |
</listitem> |
</listitem> |
| 807 |
</varlistentry> |
</varlistentry> |
| 828 |
the generic fluid dynamical engine.</para> |
the generic fluid dynamical engine.</para> |
| 829 |
|
|
| 830 |
<para>The MITgcmUV packaging structure is described below using generic |
<para>The MITgcmUV packaging structure is described below using generic |
| 831 |
package names ${pkg}. A concrete examples of a package is the code for |
package names ${pkg}. A concrete examples of a package is the code for |
| 832 |
implementing GM/Redi mixing. This code uses the package name</para> |
implementing GM/Redi mixing. This code uses the package name</para> |
| 833 |
|
|
| 834 |
</sect2> |
</sect2> |
| 888 |
Package runtime config. options are imported |
Package runtime config. options are imported |
| 889 |
into a common block held in a header file |
into a common block held in a header file |
| 890 |
called "${PKG}.h". |
called "${PKG}.h". |
| 891 |
|
Note: In some packages, the header file "${PKG}.h" is splitted |
| 892 |
|
into "${PKG}_PARAMS.h" that contains the package parameters and |
| 893 |
|
${PKG}_VARS.h" for the field arrays. |
| 894 |
|
|
| 895 |
o The core driver part of the model can check |
o The core driver part of the model can check |
| 896 |
for runtime enabling or disabling of individual packages |
for runtime enabling or disabling of individual packages |
| 913 |
1. Within the core driver code flags of the form |
1. Within the core driver code flags of the form |
| 914 |
ALLOW_${PKG} are used to include or exclude |
ALLOW_${PKG} are used to include or exclude |
| 915 |
whole packages. The ALLOW_${PKG} flags are included |
whole packages. The ALLOW_${PKG} flags are included |
| 916 |
from a PKG_CPP_OPTIONS block which is currently |
from a PACKAGES_CONFIG.h file that is automatically |
| 917 |
|
generated by genmake2 (see genmake2 section). |
| 918 |
held in-line in the CPP_OPTIONS.h header file. |
held in-line in the CPP_OPTIONS.h header file. |
| 919 |
e.g. |
e.g. |
| 920 |
|
|
| 921 |
Core model code ..... |
Core model code ..... |
| 922 |
|
|
| 923 |
|
#include "PACKAGES_CONFIG.h" |
| 924 |
#include "CPP_OPTIONS.h" |
#include "CPP_OPTIONS.h" |
| 925 |
: |
: |
| 926 |
: |
: |
| 932 |
|
|
| 933 |
2. Within an individual package a header file, |
2. Within an individual package a header file, |
| 934 |
"${PKG}_OPTIONS.h", is used to set CPP flags |
"${PKG}_OPTIONS.h", is used to set CPP flags |
| 935 |
specific to that package. It is not recommended |
specific to that package. It also includes |
| 936 |
to include this file in "CPP_OPTIONS.h". |
"PACKAGES_CONFIG.h" and "CPP_OPTIONS.h". |
| 937 |
|
|
| 938 |
|
|
| 939 |
Package Boot Sequence |
Package Boot Sequence |
| 955 |
& CALL ${PKG}_READPARMS( retCode ) |
& CALL ${PKG}_READPARMS( retCode ) |
| 956 |
#endif |
#endif |
| 957 |
|
|
| 958 |
2. S/R PACKAGES_CHECK() |
3. S/R PACKAGES_INIT_FIXED() |
| 959 |
|
: |
| 960 |
|
#ifdef ALLOW_${PKG} |
| 961 |
|
if ( use${Pkg} ) |
| 962 |
|
& CALL ${PKG}_INIT_FIXED( retCode ) |
| 963 |
|
#endif |
| 964 |
|
|
| 965 |
|
4. S/R PACKAGES_CHECK() |
| 966 |
: |
: |
| 967 |
#ifdef ALLOW_${PKG} |
#ifdef ALLOW_${PKG} |
| 968 |
if ( use${Pkg} ) |
if ( use${Pkg} ) |
| 972 |
& CALL PACKAGES_CHECK_ERROR('${PKG}') |
& CALL PACKAGES_CHECK_ERROR('${PKG}') |
| 973 |
#endif |
#endif |
| 974 |
|
|
| 975 |
3. S/R PACKAGES_INIT() |
5. S/R PACKAGES_INIT_VARIABLES() |
| 976 |
: |
: |
| 977 |
#ifdef ALLOW_${PKG} |
#ifdef ALLOW_${PKG} |
| 978 |
if ( use${Pkg} ) |
if ( use${Pkg} ) |
| 979 |
& CALL ${PKG}_INIT( retCode ) |
& CALL ${PKG}_INIT_VARIA( ) |
| 980 |
|
#endif |
| 981 |
|
|
| 982 |
|
Package Output |
| 983 |
|
============== |
| 984 |
|
6. S/R DO_THE_MODEL_IO |
| 985 |
|
|
| 986 |
|
#ifdef ALLOW_${PKG} |
| 987 |
|
if ( use${Pkg} ) |
| 988 |
|
& CALL ${PKG}_OUTPUT( ) |
| 989 |
#endif |
#endif |
| 990 |
|
|
| 991 |
|
7. S/R PACKAGES_WRITE_PICKUP() |
| 992 |
|
|
| 993 |
|
#ifdef ALLOW_${PKG} |
| 994 |
|
if ( use${Pkg} ) |
| 995 |
|
& CALL ${PKG}_WRITE_PICKUP( ) |
| 996 |
|
#endif |
| 997 |
|
|
| 998 |
Description |
Description |
| 999 |
=========== |
=========== |
| 1001 |
- ${PKG}_READPARMS() |
- ${PKG}_READPARMS() |
| 1002 |
is responsible for reading |
is responsible for reading |
| 1003 |
in the package parameters file data.${pkg}, and storing |
in the package parameters file data.${pkg}, and storing |
| 1004 |
the package parameters in "${PKG}.h". |
the package parameters in "${PKG}.h" (or in "${PKG}_PARAMS.h"). |
| 1005 |
-> called in INITIALISE_FIXED |
-> called from INITIALISE_FIXED in PACKAGES_READPARMS |
| 1006 |
|
|
| 1007 |
|
- ${PKG}_INIT_FIXED() |
| 1008 |
|
is responsible for completing the internal setup of a package. |
| 1009 |
|
-> called from INITIALISE_FIXED in PACKAGES_INIT_FIXED |
| 1010 |
|
note: 1) some pkg use instead: |
| 1011 |
|
CALL ${PKG}_INITIALISE ( or the old form CALL ${PKG}_INIT ) |
| 1012 |
|
2) for simple pkg setup, this part is done inside ${PKG}_READPARMS |
| 1013 |
|
|
| 1014 |
- ${PKG}_CHECK() |
- ${PKG}_CHECK() |
| 1015 |
is responsible for validating |
is responsible for validating |
| 1018 |
need to check. This is done through header files "${PKG}.h". |
need to check. This is done through header files "${PKG}.h". |
| 1019 |
It is assumed that parameters owned by other packages |
It is assumed that parameters owned by other packages |
| 1020 |
will not be reset during ${PKG}_CHECK(). |
will not be reset during ${PKG}_CHECK(). |
| 1021 |
-> called in INITIALISE_FIXED |
-> called from INITIALISE_FIXED in PACKAGES_CHECK |
| 1022 |
|
|
| 1023 |
- ${PKG}_INIT() |
- ${PKG}_INIT_VARIA() |
| 1024 |
is responsible for completing the |
is responsible for fill-in all package variables with an initial value. |
| 1025 |
internal setup of a package. This routine is called after |
Contains eventually a call to ${PKG}_READ_PICKUP that will read |
| 1026 |
the core model state has been completely initialised |
from a pickup file the package variables required to restart the model. |
| 1027 |
but before the core model timestepping starts. |
This routine is called after the core model state has been completely |
| 1028 |
-> called in INITIALISE_VARIA |
initialised but before the core model timestepping starts. |
| 1029 |
|
-> called from INITIALISE_VARIA in PACKAGES_INIT_VARIABLES |
| 1030 |
|
note: the name ${PKG}_INIT_VARIA is not yet standard and some pkg |
| 1031 |
|
use for e.g. ${PKG}_INI_VARS, ${PKG}_INIT_VARIABLES, or the old |
| 1032 |
|
form ${PKG}_INIT |
| 1033 |
|
|
| 1034 |
|
- ${PKG}_OUTPUT( ) |
| 1035 |
|
is responsible for writing time-average fields to output files |
| 1036 |
|
(but the cumulating step is done within the package main S/R). |
| 1037 |
|
Can also contain other diagnostics (.e.g. CALL ${PKG}_MONITOR) |
| 1038 |
|
and write snap-shot fields that are hold in common blocks. Other |
| 1039 |
|
temporary fields are directly dump to file where they are available. |
| 1040 |
|
NOTE: 1) the S/R old name ${PKG}_DIAGS is used in some packages |
| 1041 |
|
but is beeing replaced by ${PKG}_OUTPUT |
| 1042 |
|
to avoid confusion with pkg/diagnostics functionality. |
| 1043 |
|
2) the output part is not yet in a standard form and might still |
| 1044 |
|
evolve a lot. |
| 1045 |
|
-> called within DO_THE_MODEL_IO |
| 1046 |
|
|
| 1047 |
|
- ${PKG}_WRITE_PICKUP() |
| 1048 |
|
is responsible for writing a package pickup file when necessary for |
| 1049 |
|
a restart. (found also the old name: ${PKG}_WRITE_CHECKPOINT ) |
| 1050 |
|
-> called from FORWARD_STEP and THE_MODEL_MAIN in PACKAGES_WRITE_PICKUP |
| 1051 |
|
|
| 1052 |
Summary |
Summary |
| 1053 |
======= |
======= |
| 1068 |
----------------------- |
----------------------- |
| 1069 |
* ${PKG}_OPTIONS.h has further package-specific CPP options |
* ${PKG}_OPTIONS.h has further package-specific CPP options |
| 1070 |
* ${PKG}.h package-specific common block variables, fields |
* ${PKG}.h package-specific common block variables, fields |
| 1071 |
|
or ${PKG}_PARAMS.h package-specific common block parameters |
| 1072 |
|
and ${PKG}_VARS.h package-specific common block fields |
| 1073 |
|
|
| 1074 |
- FORTRAN source files |
- FORTRAN source files |
| 1075 |
----------------------- |
----------------------- |
| 1076 |
* ${pkg}_readparms.F reads parameters from file data.${pkg} |
* ${pkg}_readparms.F reads parameters from file data.${pkg} |
| 1077 |
* ${pkg}_check.F checks package dependencies and consistencies |
* ${pkg}_init_fixed.F complete the package setup |
| 1078 |
* ${pkg}_init.F initialises package-related fields |
* ${pkg}_check.F checks package dependencies and consistencies |
| 1079 |
* ${pkg}_... .F package source code |
* ${pkg}_init_varia.F initialises package-related fields |
| 1080 |
|
* ${pkg}_... .F package source code |
| 1081 |
|
* ${pkg}_output.F write output to file. |
| 1082 |
|
* ${pkg}_write_pickup.F write a package pickup file to restart the model |
| 1083 |
|
|
| 1084 |
|
New: Subroutine in one package (pkgA) that only contains code which |
| 1085 |
|
is connected to a 2nd package (pkgB) (e.g.: gmredi_diagnostics_init.F) |
| 1086 |
|
will be named: pkgA_pkgB_something.F |
| 1087 |
|
|
| 1088 |
- parameter file |
- parameter file |
| 1089 |
----------------------- |
----------------------- |
| 1093 |
</sect1> |
</sect1> |
| 1094 |
|
|
| 1095 |
|
|
| 1096 |
|
<sect1 id="documentation"> |
| 1097 |
|
<title>Editing the Documentation</title> |
| 1098 |
|
|
| 1099 |
|
<sect2 id="documentation_getting"> |
| 1100 |
|
<title>Getting the Docs and Code</title> |
| 1101 |
|
|
| 1102 |
|
<para>The first step towards editing the documentation is to checkout a |
| 1103 |
|
copy of code, docs, and build scripts from the CVS server using:</para> |
| 1104 |
|
|
| 1105 |
|
<screen> |
| 1106 |
|
$ export CVS_RSH=ssh |
| 1107 |
|
$ export CVSROOT=':ext:NAME@mitgcm.org:/u/gcmpack' |
| 1108 |
|
$ mkdir scratch |
| 1109 |
|
$ cvs co -P MITgcm manual mitgcm.org |
| 1110 |
|
</screen> |
| 1111 |
|
|
| 1112 |
|
<para>These commands extract the necessary information from the CVS server |
| 1113 |
|
and create a temporary (called <filename>scratch</filename>) directory for |
| 1114 |
|
the storage of the HTML and other files that will be created. Please note |
| 1115 |
|
that you must either create <filename>scratch</filename> as shown or edit |
| 1116 |
|
the various <filename>Makefile</filename>s and scripts used to create the |
| 1117 |
|
documentation.</para> |
| 1118 |
|
</sect2> |
| 1119 |
|
|
| 1120 |
|
<sect2> |
| 1121 |
|
<title>Editing the Documentation</title> |
| 1122 |
|
|
| 1123 |
|
<para>The documentation is contained in the <filename>manual</filename> |
| 1124 |
|
directory in a raw LaTeX format. The main document is |
| 1125 |
|
<filename>manual.tex</filename> and it uses <command>\input{}</command>s |
| 1126 |
|
to include the chapters and subsections.</para> |
| 1127 |
|
|
| 1128 |
|
<para>Since the same LaTeX source is used to produce PostScript, PDF, and |
| 1129 |
|
HTML output, care should be taken to follow certain conventions. Two of |
| 1130 |
|
the most important are the usage of the <command>\filelink{}{}</command> |
| 1131 |
|
and <command>\varlink{}{}</command> commands. Both of these commands have |
| 1132 |
|
been defined to simplify the connection between the automatically |
| 1133 |
|
generated ("code browser") HTML and the HTML version of the manual |
| 1134 |
|
produced by LaTeX2HTML. They each take two arguments (corresponding to |
| 1135 |
|
the contents of the two sets of curly braces) which are the text that the |
| 1136 |
|
author wishes to be "wrapped" within the link, and a specially formatted |
| 1137 |
|
link thats relative to the <filename>MITgcm</filename> directory within |
| 1138 |
|
the CVS tree.</para> |
| 1139 |
|
|
| 1140 |
|
<para>The result is a command that resembles either</para> |
| 1141 |
|
|
| 1142 |
|
<orderedlist> |
| 1143 |
|
<listitem> |
| 1144 |
|
<para>a reference to a variable or subroutine name such as |
| 1145 |
|
<command>\varlink{tRef}{tRef}</command>, or </para> |
| 1146 |
|
</listitem> |
| 1147 |
|
|
| 1148 |
|
<listitem> |
| 1149 |
|
<para>a reference to a file such as |
| 1150 |
|
<command>\varlink{tRef}{path-to-the-file_name.F}</command> |
| 1151 |
|
where the absolute path to the file is of the form |
| 1152 |
|
<filename>/foo/MITgcm/path/to/the/file_name.F</filename></para> |
| 1153 |
|
<para>(please note how the leading "/foo/MITgcm" |
| 1154 |
|
component of the path is dropped leaving the path |
| 1155 |
|
<emphasis>relative</emphasis> to the head of the code |
| 1156 |
|
directory and each directory separator "/" is turned |
| 1157 |
|
into a "-")</para> |
| 1158 |
|
</listitem> |
| 1159 |
|
</orderedlist> |
| 1160 |
|
|
| 1161 |
|
|
| 1162 |
|
|
| 1163 |
|
</sect2> |
| 1164 |
|
|
| 1165 |
|
<sect2> |
| 1166 |
|
<title>Building the Documentation</title> |
| 1167 |
|
|
| 1168 |
|
<para>Given the directory structure of <xref |
| 1169 |
|
linkend="documentation_getting">, the entire documentation for the web |
| 1170 |
|
site can be built using:</para> |
| 1171 |
|
|
| 1172 |
|
<screen> |
| 1173 |
|
$ cd mitgcm.org/devel/buildweb |
| 1174 |
|
$ make All |
| 1175 |
|
</screen> |
| 1176 |
|
|
| 1177 |
|
<para>Which builds the PDF from the LaTeX source, creates the HTML output |
| 1178 |
|
from the LaTeX source, parses the FORTRAN code base to produce a |
| 1179 |
|
hyperlinked HTML version of the source, and then determines the |
| 1180 |
|
cross-linking between the various HTML components.</para> |
| 1181 |
|
|
| 1182 |
|
<para>If there are no errors, the result of the build process (which can |
| 1183 |
|
take 30+ minutes on a P4/2.5Ghz) will be contained within a single |
| 1184 |
|
directory called <filename>scratch/dev_docs</filename>. This is a freshly |
| 1185 |
|
built version of the entire on-line users manual. If you have the correct |
| 1186 |
|
permissions, it can be directly copied to the web server area:</para> |
| 1187 |
|
|
| 1188 |
|
<screen> |
| 1189 |
|
$ mv scratch/dev_docs /u/u0/httpd/html |
| 1190 |
|
</screen> |
| 1191 |
|
|
| 1192 |
|
<para>and the update is complete.</para> |
| 1193 |
|
|
| 1194 |
|
</sect2> |
| 1195 |
|
|
| 1196 |
|
</sect1> |
| 1197 |
|
|
| 1198 |
</article> |
</article> |
| 1199 |
|
|
| 1200 |
|
|
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch