/[MITgcm]/MITgcm/doc/devel_HOWTO.sgml

Diff of /MITgcm/doc/devel_HOWTO.sgml

Parent Directory | Revision Log | View Revision Graph Revision Graph | View Patch Patch

-revision 1.10 by jmc,
Thu Jan 21 23:59:17 2010 UTC
+revision 1.14 by jmc,
Fri May 28 01:47:32 2010 UTC
 Line 1
  <!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+ <!--
+  $Header$
+  $Name$
+ -->
  <article id="MITgcm-Development-HOWTO">
-Line 30
+Line 34
            update links.
          </revremark>
        </revision>
+       <revision>
+         <revnumber>0.03</revnumber>
+         <date>2010-04-25</date>
+         <authorinitials>jmc</authorinitials>
+         <revremark>
+           Add subsection "Developer settings" (under CVS Repository).
+         </revremark>
+       </revision>
      </revhistory>
      <abstract>
-Line 102
+Line 114
    <sect1 id="cvs">
      <title>CVS Repository</title>
      <sect2>
        <title>Layout</title>
-Line 112
+Line 125
        others.  The tree currently resembles:</para>
  <programlisting>gcmpack/
-   MITgcm-contrib        contributed code
+   CVSROOT               -hidden-
-   CS-regrid             goes into utils
-   cvspolicy.html        -save-
-   CVSROOT               -save-
-   development           experimental stuff
-   manual                -save-
-   misc                  -?-
    MITgcm                code
-        adjoint                  fold into genmake
+        bin                      empty
-        bin                      stub for ecco build
+        doc                      basic developpment documentation
-        compare01                old from 20th century
+        eesupp                   execution environment support code (wrapper)
-        diags                    timeave f77 in pkgs now
+        exe                      empty
-        doc                      tags -- connect to real docs?
+        jobs                     runtime shell scripts for
-        eesupp                   cnh?
+                                   various platforms (not maintained)
-        exe                      ecco user build
+        lsopt                    line search
-     ,- jobs                     runtime shell scripts for
+        model                    main dynamics (core)
-     |                             various platforms
+        optim                    line search interface
-     |  lsopt                    line search
+        pkg                      alternate and optional numerics, etc.
-    m|  model                    main dynamics (core)
+        tools                    scripts to build (and test)
-    e|    optimization_drivers   ?
+        utils                    pre/post processing tools (matlab, ..)
-    r|  optim                    line search interface
+        verification             standard regression tests + examples
-    g|  pkg                      alternate and optional numerics, etc.
+                                       + documented examples (tutorials)
-    e|- tools
+        tutorial_examples        (only in release1 branch)
-    ?|  tutorial_examples        documented tests
-     |                             only populated on release1 branch
-     |                             and not validated during "testreport"
-     '- utils
-        verification             std tests
+   MITgcm_contrib        contributed code
-   mitgcmdoc -> manual   -remove-
+   acesgrid.org          build acesgrid web site
+   development           experimental stuff
+   gfd_lab               -?-
+   manual                source of MITgcm documentation
    mitgcm.org            build web site
-   models                -?-
+   old_develop           old and early development source
-   packages              -?-
+        misc                 -?-
-   preprocess            -?-
+        models               -?-
-   tmp                   -?-
+        packages             -?-
+        preprocess           -?-
+   pdfs                  some pdfs
+   planetinabottle.org   unfinished web site
+   www.ecco-group.org    build ecco web site ?
  </programlisting>
+  <!--
        <para>Efforts are underway to reduce the complexity.</para>
+ -->
      </sect2>
-Line 190
+Line 202
        <title>Branches</title>
        <para>As shown in the online <ulink
-       url="http://mitgcm.org/viewvc/MITgcm/MITgcm/doc/tag-index?view=graph">
+       url="http://mitgcm.org/viewvc/MITgcm/MITgcm/model/src/forward_step.F?view=graph">
-       ViewCVS-generated tree</ulink>, the MITgcm codebase is split into to two
+       ViewCVS-generated tree</ulink>, the MITgcm codebase is split into
-       branches or "lines" under which development proceeds.  These two lines are
+       branches or "lines" under which development proceeds.  The main line
-       referred to as the "MAIN" and "ecco" versions of the code.  While not
+       of development is referred to as the "MAIN" version of the code.
-       identical, the bulk of the MAIN and ecco lines are composed of files from
-       the same codebase.
        </para>
        <para>Periodically, a "Release" branch is formed from the "MAIN"
        development branch.  This is done in order to create a relatively stable
        reference point for both users and developers.  The intent is that once a
-       relese branch has been created, only bug-fixes will be added to it.
+       release branch has been created, only bug-fixes will be added to it.
        Meanwhile, development (which might "break" or otherwise render invalid
        the documentation, tutorials, and/or examples contained within a release
-       branch) is allowed to continue along the MAIN and ecco lines.</para>
+       branch) is allowed to continue along the MAIN line.</para>
      </sect2>
      <sect2>
-       <title>Tagging</title>
+       <title> Developer settings </title>
+       <para>CVS is a convenient tool to keep up-to-date a personal copy of the
+       MITgcm code (see: <ulink url="http://mitgcm.org/public/using_cvs.html">
+       using CVS </ulink>). The same tool is used by developers to
+       incorporate any change into the repository. However, this later
+       function requires specific settings, as detailed here after:</para>
+       <orderedlist>
+         <listitem>
+           <para> You will need an account (loggin access) to the server
+            "mitgcm.org" with the proper group setting (e.g.,
+             group "gcmctrb" to add/modify code into MITgcm_contrib).
+             This kind of account is granted only upon well motivated request.
+             The access to the server mitgcm.org is through ssh-key authorization
+             which will need to be set properly on both side (on your local machine
+             and on your server account). You need to be able to
+             to ssh to mitgcm.org (or <filename>ssh MY_USER_NAME@mitgcm.org</filename>
+             in case of different user-name on both sides) to proceed further.</para>
+         </listitem>
+         <listitem>
+           <para> You need to register to the
+         <ulink url="http://mitgcm.org/mailman/listinfo/mitgcm-cvs">
+       mitgcm-cvs </ulink> mailing list.
+           This ensures that other developers will receive email notification
+            when you make changes; you will also receive as well such email
+            when others make changes to the repository.
+           </para>
+         </listitem>
+         <listitem>
+           <para> It is highly recommended that you register also to the
+         <ulink url="http://mitgcm.org/mailman/listinfo/mitgcm-devel">
+       mitgcm-devel </ulink> mailing list (expect a short delay for
+        this request to be processed).
+           This list is intended for developer discussions.
+           </para>
+         </listitem>
+         <listitem>
+           <para> The standard anonymous mode (using "cvsanon", as mentionned
+         <ulink url="http://mitgcm.org/public/source_code.html">
+       here </ulink>) does not allow check-in ("cvs commit") permission.
+          Instead, you will need to set our CVS environment as follow:</para>
+ <screen>
+   $ export CVS_RSH=ssh
+   $ export CVSROOT=':ext:MY_USER_NAME@mitgcm.org:/u/gcmpack'
+ </screen>
+           <para> After downloading a directory, e.g.: <filename>myCopy</filename>,
+            from the CVS repository (e.g.,
+             <filename>MITgcm_contrib/thisPart</filename>) using the command:</para>
+ <screen>
+   $ cvs co -P -d myCopy MITgcm_contrib/thisPart
+ </screen>
+           <para> the type of CVS environment which has been used
+            is stored in the file <filename>myCopy/CVS/Root</filename>
+            and makes it difficult to re-use, for cvs-commit purpose,
+            a cvs local copy (<filename>myCopy</filename>) which was obtained
+            using the CVS anonymous mode.</para>
+         </listitem>
+         <listitem>
+           <para> At this stage, you should be able to send your modified source
+           file (e.g., <filename>src_file</filename>) from your local copy directory
+           (<filename>myCopy</filename>) to the CVS repository
+           (<filename>MITgcm_contrib/thisPart</filename>) using the command
+           "cvs commit":</para>
+ <screen>
+   $ cd myCopy
+   $ cvs -n update        (optional; check if new changes have been made)
+   $ cvs diff src_file    (optional; list your changes)
+   $ cvs commit src_file
+ </screen>
+           <para> It is essential that you provide a short description of the
+           changes you made to <filename>src_file</filename> as you check-in
+           this file (the "cvs commit" command automatically opens your standard
+           editor for this purpose).</para>
+         </listitem>
+       </orderedlist>
+     </sect2>
+     <sect2>
+       <title>Main code development</title>
+       <para><emphasis>(formerly named "Tagging" ; this section needs an update)
+         </emphasis></para>
        <para>The intent of tagging is to create "known-good" checkpoints that
        developers can use as references.  Traditionally, MITgcm tagging has
-Line 285 
 checkpoint50d_pre
+Line 381 
 checkpoint50d_pre
    </sect1>
-   <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:NAME@mitgcm.org:/u/gcmpack'
-   $ mkdir scratch
-   $ cvs co -P 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>
    <sect1 id="coding">
      <title>Coding for MITgcm</title>
-Line 400 
 checkpoint50d_pre
+Line 394 
 checkpoint50d_pre
          For MITgcm, the process is similar.  Typical commands are:</para>
  <screen>
-   $ genmake -mods=../code
+   $ genmake2 -mods=../code
    $ make depend
    $ make
  </screen>
-Line 411 
 checkpoint50d_pre
+Line 405 
 checkpoint50d_pre
        <sect3 id="genmake">
          <title>The <filename>genmake2</> Utility</title>
-         <para><emphasis>Please note that the older <filename>genmake</> is
+         <para><emphasis>(Note: the older <filename>genmake</>
-             deprecated and will eventually be replaced by <filename>genmake2</>.
+             has been replaced by <filename>genmake2</>)</emphasis></para>
-             This HOWTO only describes the newer tool.</emphasis></para>
          <para>The first step in any MITgcm build is to create a Unix-style
            <filename>Makefile</filename> which will be parsed by
-Line 469 
 checkpoint50d_pre
+Line 462 
 checkpoint50d_pre
              <para>an "options file" as specified by the command-line option
                <filename>-optfile='FILENAME'</filename></para>
            </listitem>
+           <listitem>
+             <para> a <filename>packages.conf</filename> file (in the current
+               directory or in one of the "MODS" directories, see below)
+               which contains the specific list of packages to compile
+             </para>
+           </listitem>
          </orderedlist>
          <para>then checking certain dependency rules (the package dependencies),
-Line 522 
 checkpoint50d_pre
+Line 521 
 checkpoint50d_pre
            </varlistentry>
            <varlistentry>
-             <term><filename>-pdepend=/PATH/FILENAME</></term>
-             <listitem>
-               <para>This specifies the dependency file used for packages.  If
-               not specified, the default dependency file is
-               <filename>$ROOTDIR/pkg/pkg_depend</>.  The syntax for this file is
-               parsed on a line-by-line basis where each line containes either a
-               comment ("#") or a simple "PKGNAME1 (+|-)PKGNAME2" pairwise rule
-               where the "+" or "-" symbol specifies a "must be used with" or a
-               "must not be used with" relationship, respectively.  If no rule is
-               specified, then it is assumed that the two packages are compatible
-               and will function either with or without each other.</para>
-             </listitem>
-           </varlistentry>
-           <varlistentry>
-             <term><filename>-pdefault=PKG</></term>
-             <term><filename>-pdefault='PKG1 [PKG2 PKG3 ...]'</></term>
-             <listitem>
-               <para>This option specifies the default set of packages
-               to be used.  If not set, the default package list will
-               be read from
-               <filename>$ROOTDIR/pkg/pkg_default</>.</para>
-             </listitem>
-           </varlistentry>
-           <varlistentry>
              <term><filename>-adof=/path/to/file</></term>
              <term><filename>-adoptfile=/path/to/file</></term>
              <listitem>
-Line 576 
 checkpoint50d_pre
+Line 548 
 checkpoint50d_pre
                  will be overridden by any identically-named sources within the
                  "MODS" directories.  The order of precedence for this
                  "name-hiding" is as follows:</para>
                <itemizedlist>
                  <listitem><para>"MODS" directories (in the order given)
                    </para></listitem>
-Line 588 
 checkpoint50d_pre
+Line 559 
 checkpoint50d_pre
                  <listitem><para>The "standard dirs" (which may have been
                      specified by the "-standarddirs" option)</para></listitem>
                </itemizedlist>
+             </listitem>
+           </varlistentry>
+           <varlistentry>
+             <term><filename>-pgroups=/PATH/FILENAME</></term>
+             <listitem>
+               <para>This option specifies the file where package groups are
+               defined.  If not set, the package-groups definition will
+               be read from
+               <filename>$ROOTDIR/pkg/pkg_groups</>.</para>
+               <para>
+               It also contains the default list of packages (defined
+               as the group <filename>"default_pkg_list"</>) which is used
+               when no specific package list (file: <filename>packages.conf</>)
+               is found in current directory or in any "MODS" directory.
+               </para>
+             </listitem>
+           </varlistentry>
+           <varlistentry>
+             <term><filename>-pdepend=/PATH/FILENAME</></term>
+             <listitem>
+               <para>This specifies the dependency file used for packages.  If
+               not specified, the default dependency file is
+               <filename>$ROOTDIR/pkg/pkg_depend</>.  The syntax for this file is
+               parsed on a line-by-line basis where each line containes either a
+               comment ("#") or a simple "PKGNAME1 (+|-)PKGNAME2" pairwise rule
+               where the "+" or "-" symbol specifies a "must be used with" or a
+               "must not be used with" relationship, respectively.  If no rule is
+               specified, then it is assumed that the two packages are compatible
+               and will function either with or without each other.</para>
              </listitem>
            </varlistentry>
-Line 614 
 checkpoint50d_pre
+Line 616 
 checkpoint50d_pre
          <para>In general, it is best to use <filename>genmake2</> on a "clean"
            directory that is free of all source (*.[F,f],*.[F,f]90) and header
            (*.h,*.inc) files.  Generally, this can be accomplished in an
-           "un-clean" directory by running "make CLEAN" followed by "make
+           "un-clean" directory by running "make Clean" followed by "make
            makefile".</para>
        </sect3>
-Line 627 
 checkpoint50d_pre
+Line 629 
 checkpoint50d_pre
            simulator) executable using:</para>
  <screen>
-   $ make CLEAN
+   $ make Clean
    $ make depend
    $ make
  </screen>
-         <para>The "make CLEAN" step will remove any stale source files, include
+         <para>The "make Clean" step will remove any stale source files, include
            files, and links.  It is strongly recommended for "un-clean"
            directories which may contain the (perhaps partial) results of
-           previous builds.  Such "debris" can interfere with the next stage of
+           previous builds. Such "debris" can interfere with the next stage of
-           the build.</para>
+           the build.
+           A more agressive cleaning option, "make CLEAN", can be used to also
+           remove the executable and output files from a previous run.</para>
          <para>The "make depend" step will create a large number of symbolic
            links from the local directory to the source file locations.  It also
-Line 834 
 checkpoint50d_pre
+Line 838 
 checkpoint50d_pre
          the generic fluid dynamical engine.</para>
        <para>The MITgcmUV packaging structure is described below using generic
-         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
          implementing GM/Redi mixing. This code uses the package name</para>
      </sect2>
-Line 1099 
 Summary
+Line 1103 
 Summary
    </sect1>
+   <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:NAME@mitgcm.org:/u/gcmpack'
+   $ mkdir scratch
+   $ cvs co -P 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>
  </article>

 Legend:



Removed from v.1.10
 


changed lines


 
Added in v.1.14
 Legend:



Removed from v.1.10
 


changed lines


 
Added in v.1.14
-Removed from v.1.10
+Added in v.1.14

	ViewVC Help
Powered by ViewVC 1.1.22