[MITgcm-support] Re: MITgcm beginner's questions

[Martin Losch]

Rene,

my personal view of where to make changes in the code:

You probably saw that all the verification-experiment-directories have 
the same set of subdirectories (build,input,code,result). The "code" 
directory is where local code is kept. This directory needs to be 
specified, when you call genmake2 with -mods=../code. You can have 
multiple code-directories: -mods="../mycode ../someothercode".

If I want to make changes that are specific to a particular experiment 
configuration (typically hard-wire some boundary conditions or some 
forcing in external_forcing.F), I copy the corresponding file(s) into 
the local code directory (which needs to be specified at the genmake 
step by genmake2 -mods=../code, or whatever I call my directory) and 
make the changes there. In this case I need to restart the build 
process (make CLEAN && make makefile) to regenerate the makefile with 
the correct locations of the sources. An example for this is in 
verification/exp4/ where you find a copy of obcs_calc.F (normally in 
pkg/obcs), with some specific open boundary boudary conditions for 
u,v,t,s hard-wired into the code).
Advantage: if my changes break anything, only my local experiment is 
broken.
Disadvantage: my changes are invisible to CVS, so that it can happen 
that when I update my global code (cvs update), changes (possibly 
improvements) in the original file (obcs_calc.F in the example) are not 
merged into the local files. [This actually happenend to exp4: now it 
is possible to read the boundary conditions that are hard-wired in 
exp4/code/obcs_calc.F from a file that you can specify at run-time, 
actually make this local copy superfluous (in principle).]

If I want to make changes that should affect all of my possible 
experiments, I make them in the original code directly, but then you 
have to keep track of these change via CVS (cvs diff). Candidates are 
debugging information, extra output or changing something more 
fundamental.

General (also "private") CPP-flags should go into CPP_OPTIONS.h, which 
is included into basically all source files. Again, the default is in 
model/inc/CPP_OPTIONS.h, but here you really should make a local copy 
and put it in your code directory. Each of the packages in pkg have 
their own CPP-flag files, usually called ${pkg-name}_OPTIONS.h, that's 
where packages specific flags should go (make also a local copy of 
those).

Martin

On Jun 2, 2005, at 4:10 PM, Ed Hill wrote:

> Hi Rene,
>
> Welcome to the MITgcm-support list!  I've subscribed your email address
> and included your message below.
>
> In regards to the build system, we have successfully setup cross-
> compilation.  In fact, I think it was a Linux-on-Itanium system acting
> as the head-node and cross-compiler for a NEC SX-6.  And you should 
> only
> have to create one custom options file (or "optfile") in order to
> specify the set of compilers and other options that you want.
>
> We currently have three example optfiles for SX-6 machines and they are
> located in:
>
>   MITgcm/tools/build_options/SUPER-UX_SX-6_*
>
> so please take a look at them and then copy one and make modifications
> to it to suit your particular machine, your libraries, etc.  Some of 
> the
> other optfiles also provide examples on how to incorporate netCDF (you
> just need to include the headers and libs).
>
> If you encounter problems and want help then please copy and paste them
> into an email to this list (along with the commands you used to create
> them!) and we'll try to help you figure it out.
>
> good luck!
> Ed
>
> ps - The build process is documented at:
>
>   http://mitgcm.org/pelican/online_documents/node137.html
>
>
> =====  original email  =====
>
> Date: Thu, 02 Jun 2005 13:13:35 +0200
> From: Rene Redler <redler at ccrl-nece.de>
> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
> To: MITgcm-support at mitgcm.org
> Subject: MITgcm beginner's questions
>
> hi,
>
>     I have downloaded your latest available version from the CVS
> server yesterday. Based on the documentation I was able to practically
> examine the first steps to get a make file plus dependencies on
> my Linux PC. This would work fine if my Linux PC were the target
> platform on which I ran the executable. Instead I'd like to
> create a binary for a NEC SX6 using the SX cross compiler and
> relevant libraries (e.g. NetCDF) on my Linux PC.
>
> I guess I have to manually edit some file(s) to teach your building
> process the correct settings. For doing this I need to avoid
> the generation and execution of small binaries used for testing
> some local settings.
>
> I am more than willing to read the manual. Any hint to where related
> info is located is welcome.
>
> Furthermore I'd like to add some lines of code (included with CPP keys)
> to the original sources. What's the best practice to do this,
> is it ok to edit the sources in MITgcm/model/src, or is it better
> to to do this in some experiment specific dir, like
> MITgcm/verification/... - and where to put those private CPP keys.
>
> Thanks for nay brief hint.
>
> Rene
>
> _______________________________________________________________