How to build the OpenGGCM development version
Because it is an development version and not a release (and no mechanism to create a release exists yet), you have to use SVN, but you probably have been doing that already anyway.
I'm assuming you want to work with the "head" version, that is the latest official development version.
- Figure out where you want to put it on you computer. A good place might be ~/GGCM/head.
By the way, if you didn't know, the ~ indicates your home directory. It works in your shell -- try it: cd ~/bin will change into /home/kai/bin for me, but may change into /home/space/vapirev/bin for you.
- Make sure you have an account on artemis, which is where the SVN tree lives. You want to be able to log into artemis without having to enter your password, unless you enjoy entering your password hundreds of times in the future. (Because I assume you will be an active developer / tester). If you don't know how to make it happen, ask someone for help, in exchange for writing it up on this wiki afterwards.
- Check it out
mkdir ~/GGCM cd ~/GGCM svn co svn+ssh://artemis.sr.unh.edu/raid/svn/ggcm_legacy/branches/OpenGGCM_HEAD head
- Let autotools generate needed files. This step is only required for the development (SVN) version, not for a release.
You have to do it the first time you check it out, and you may have to do if something fundamental changes in the build system. So if you get weird messages about configure, automake, autoconf or whatever, try to repeat the following step:
cd ~/GGCM/head ./autogen.sh
Build the tools
This step should only be required once, after you checked out your new version. Should the tools change, however, you will have to do it again.
cd ~/GGCM/head/util ./configure --prefix=$HOME make make install
This will build and install the tools into the bin subdirectory of the prefix you selected, so into ~/bin if you stick with $HOME (The ~ trick does not work in the above situation, you have to use $HOME or spell it out.
The choice where to install it is yours, but it needs to be in your path.
You can test it: Just enter the fppn command:
kai@h101:~> fppn usage: fppn [-q] [-c] [-v1] [-v2] [-v3] [-v4] [-longout] [-fold] file
You should get the usage line back, not a "command not found" error.
Running OpenGGCM has not changed. Find your runme file and edit the second line to reflect the version of OpenGGCM you want to use, that is 'head':
kai@h101:~/GGCM/runmes/kkg0009> head -4 runme #!/bin/csh setenv OPENGGCMDIR /home/kai/GGCM/head $OPENGGCMDIR/bin/script.runme `pwd` `basename $0` 0; exit #....... template
Then, run it:
Changes to runme
For the most part, you should be able to use your old runme files. However, there are some potential issues:
Most of the old targets, while they currently still exist, probably won't work anymore, or at least not support the new features (modules in C, F90)
The three TARGETs which should work are: zaphod-myri, zaphod-eth, local.
- The first two can be run on your local machine. They will then generate necessary files, tar everything up and move
things over to zaphod, where the executable gets built and submitted. If your username on zaphod is different from the local machine, you will have to use TUSER to set the remote name.
- The TARGET local is useful for building and debugging on the same machine. It will, by default, only build the executable, but not try to run / submit it.
TARGETSUBMIT can be used to specify how to submit the job. Probably the most useful value other than the default that TARGET will set for you is nosubmit, which does the obvious thing.
TARGETHOST specifies, as before, the remote host that will run OpenGGCM. A useful value is localhost to replace the default, which will prevent the scp/ssh part of moving things over to the target machine.
If run locally, the executable, input files etc will all be in the subdir target in the runme directory. If the TARGETHOST is not localhost, this directory will be tar'ed up and moved into a subdirectory of the user's home, named the same as the run's name. (That location may change in the future.)
The SATOUT variable is now used to switch on / off the satellite-out feature.
run-template/test001 in your OpenGGCM distribution contains (if it is up-to-date) a sample runme file that can be used to get OpenGGCM to build and run and as a starting point for your own cases / extensions.
From the README:
This directory contains a template for a simple run. To run this example: - Create a directory somewhere (probably not within this OpenGGCM source). The name of the directory will be used as the name of the run. - Copy runme and swdata from this directory into your directory. - Edit runme for your system. You may have to edit the top to point OPENGGCMDIR to the toplevel idir of the OpenGGCM package that you want to use. - You may have to edit the TARGET, unless you have an account on zaphod. "local" is a good choice if you are on the system that will run OpenGGCM, but you will have to submit it yourself. You may also have to adjust MPIF77_FLAGS (and possibly MPIF77, which defaults to "mpif77"). - You may have to adjust LOCALF77 to point to a working F77 compiler on your system.
Take a look at the FAQ at OpenGGCM v4.