|
|
| (44 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| The instructions on this page are a summary of the GEOS-5 tutorial Arlindo da Silva has been presenting. For the moment, we presume that the user has an account on '''sourcemotel''' and access to the NCCS machines (e.g., '''discover''').
| | These are checkout and build instructions for GEOS-5. We presume that the user has an account and appropriate permissions on '''cvsacl''' to check code out, and access to the NCCS machines (e.g., '''discover''') to build and run code. |
| | | # [[GEOS-5 Checkout and Build Instructions (Heracles)]] |
| == How to Check Out the Code ==
| | # [[GEOS-5 Checkout and Build Instructions (Ganymede)]] |
| === Find a place to store and build the code ===
| | # [[GEOS-5 Checkout and Build Instructions (Fortuna)]] |
| The GEOS-5 (AGCM) source code checks out at about 40 MB of space. Once compiled, the complete package is about 500 MB. Your home space on '''discover''' may not be sufficient for checking out and building the code. You should consider either requesting either a larger quota in your home space (call the tag x6-9120 and ask, telling them you are doing GEOS-5 development work) or building in your (larger) nobackup space. But consider, ''nobackup'' is not backed up. So be careful...
| | # [[GEOS-5 Checkout and Build Instructions (pre-Fortuna)]] |
| | |
| === Setup your environment to check out code ===
| |
| With the above step complete, let's get ourselves ready to check out the code. We'll be using the UNIX ''cvs'' command to check out the code. The basic syntax is:
| |
| | |
| % cvs -d $CVSROOT checkout -r TAGNAME MODULENAME
| |
| | |
| Here, $CVSROOT specifies the CVS repository we'll be getting the code from, MODULENAME is the particular module (set of code) we'll be checking out, and TAGNAME is a particular version of that module. Let's fill in the blanks:
| |
| | |
| % cvs -d :ext:c-sourcemotel.gsfc.nasa.gov:/cvsroot/esma co -r ams-GEOSdas-2_1_6-3 GEOSagcm
| |
| | |
| So our module is ''GEOSagcm'' and the tag is ''GEOSdas-2_1_6''. Note that I substituted the shortcut ''co'' for ''checkout'' in the above command.
| |
| | |
| The above command is generally valid. You ought to be able to execute it and checkout some code. If you don't have your ''ssh keys'' setup on '''sourcemotel''' then you should be prompted for your '''sourcemotel''' password. The assumption here is that your username on '''sourcemotel''' is the same as on the machine you are checking the code out on. If not, modify the command like this:
| |
| | |
| % cvs -d :ext:SOURCEMOTEL_USERNAME@c-sourcemotel.gsfc.nasa.gov:/cvsroot/esma co -r ams-GEOSdas-2_1_6-3 GEOSagcm
| |
| | |
| Here's a short cuts. So that you don't have to type in the ''-d :ext:c-sourcemotel.gsfc.nasa.gov:/cvsroot/esma'' business all the time, you can add the following lines to your, e.g., ''.cshrc'' file:
| |
| | |
| setenv CVSROOT ':ext:c-sourcemotel.gsfc.nasa.gov:/cvsroot/esma'
| |
| setenv CVS_RSH ssh
| |
| | |
| Modify as appropriate if you need to put your username in or if you use a different shell (i.e., put the analog of these lines into your .bashrc file or whatever).
| |
| | |
| If you set that up, you should be able now to type in:
| |
| | |
| % cvs co -r ams-GEOSdas-2_1_6-3 GEOSagcm
| |
| | |
| Enter your password when prompted and the code should check out.
| |
| | |
| If you want to avoid typing in your password all the time (recommended) you need to set up your ''ssh keys''. There are some good instructions on this [[here]]. Once you have created your keys on the local machine (i.e., '''discover''') you want to give '''sourcemotel''' the contents of the public key file (~/.ssh/id_dsa.pub). Log on to '''sourcemotel''' in your browser and click on the "My Page" tab and then on the "Account Maintenance" heading. Scroll down the page and you'll see a little block called "Shell Account Information." Inside that is a link to "Edit Keys." Click the link and then paste the contents of your id_dsa.pub file as a new line into the window. Click "Update" and you're good to go. It may take 10-15 minutes for '''sourcemotel''' to propagate the updated keys, so until that happens you may still have to type in your password.
| |
| | |
| === Setup your environment to build the code ===
| |
| Now you've checked out the code. Your should have a directory called GEOSagcm in front of you. You're almost ready to build the code at this point.
| |
| | |
| The first thing to do is to make sure you have a compiler and the necessary libraries available. I'll assume you're on '''discover'''. In this case, you want to load some ''modules''. Modules define versions of compilers and libraries (like MPI and math libraries) used by the compiler. When you load the modules, they set your environment up to find the relevant versions. Again, assuming your shell is '''csh''' or '''tcsh''' then add the following lines to your ''.cshrc'' file and re-source it:
| |
| source /usr/share/modules/init/csh
| |
| module purge
| |
| module load comp/intel-9.1.052
| |
| module load lib/mkl-9.1.023
| |
| module load mpi/impi-3.1.038
| |
| This is a set of modules that will work with the version of GEOS-5 we are trying to compile here. Other module definitions are possible (you could, for example, look at the module definitions in /home/dasilva/.cshrc).
| |
| | |
| The model also has dependencies on the so-called "Baselibs." These will generally be prepared in advance for you. You just need to tell your shell where to find them. On '''discover''', you can set your environment up to know where the Baselibs are by setting the environment variable BASEDIR as follows:
| |
| | |
| setenv BASEDIR /discover/nobackup/projects/gmao/share/dao_ops/Baselibs/v2.1.1-build3
| |
| | |
| In fact, it's a good idea to add this line to your .cshrc file too.
| |
| | |
| Now, with that set, navigate to the source directory:
| |
| | |
| % cd GEOSagcm/src
| |
| | |
| If this is your first trip into the src directory, do yourself a favor and get rid of the file ''Assert.pl'':
| |
| rm -f Assert.pl
| |
| Don't ask why; just do it.
| |
| | |
| At this point, you can build the issuing the following command:
| |
| | |
| % gmake install
| |
| | |
| If you do that, go away and take a coffee break. A long one. This may take an hour or more to build. There are a couple of ways to speed this process up. One way is to build the code without optimization:
| |
| | |
| % gmake install FOPT=-g
| |
| | |
| The code builds faster in this instance, but be warned that without optimization any generated code will run very slowly.
| |
| | |
| A better way is to do a parallel build. To do this, start an interactive queue (on '''discover'''):
| |
| | |
| % qsub -I -W group_list=g0604 -N g5Debug -l ncpus=8 -l walltime=12:00:00 -S /bin/tcsh -V -j eo
| |
| | |
| Note that the string following "group_list=" is your group-id code. It's the project that gets charged for the computer time you use. If you're not on "g0604" that's okay, the queue system will let you know and it won't start your job. To find out which group you belong to, issue the following command:
| |
| % getsponsor
| |
| and you'll get a table of sponsor codes available to you. Enter one of those codes as the group_list string and try again.
| |
| | |
| Wait, what have we done here? We've started an interactive queue (interactive in the sense that you have a command line) where we've now go 8 cpus allocated to us (and us alone!) for the next 12 hours. We can use all those 8 cpus to speed up our build as follows:
| |
| % gmake --jobs=8 pinstall
| |
| The syntax here is that "--jobs=" specifies the number of cpus to use (up to the 8 we've requested in our queue) and "pinstall" means to do a parallel install. Don't worry, the result should be the same as "gmake install" above but take a fraction of the time.
| |
| | |
| What if something goes wrong? Sometimes the build just doesn't go right. It's useful to save the output that scrolls by on the screen to a file so you can analyze it later. Modify any of the build examples above as follows to capture the text to a file called "make.log":
| |
| % gmake --jobs=8 pinstall |& tee make.log
| |
| and now you have a record of how the build progressed. When the build completes (successfully or otherwise) you can analyze the build results by issuing the following command:
| |
| % Config/gmh.pl -v make.log
| |
| and you'll be given a list of what compiled and didn't, which will hopefull allow you to go in and find any problems.
| |
| | |
| If all goes well, you should have a brand-new build of GEOS-5. Step back up out of the ''src'' directory you should see the following sub-directories:
| |
| Config
| |
| CVS
| |
| Linux
| |
| src
| |
| In the ''Linux'' directory you'll find:
| |
| bin
| |
| Config
| |
| doc
| |
| etc
| |
| include
| |
| lib
| |
| The executables are in the ''bin'' directory.
| |
| | |
| In this example, the directory ''GEOSagcm'' is the root directory everything ends up under. You can specify another location by setting the environment variable ESMADIR to some other location and installing again.
| |
| | |
| == How to Setup and Run and Experiment ==
| |
| Now that you've built the code, let's try to run it. In the exercise that follows, we will ''clone'' a previous experiment. This will give you the basic idea of how to set up an experiment that we can refine in later exercises.
| |
| | |
| In what follows I will assume we are working on the NCCS computer '''discover'''.
| |
| | |
| === Decide on Your Experiment ID and Setup the Associated Directories ===
| |
| The first thing we need to do is decide on an '''experiment ID'''; that is, the name of our experiment. I'll call my experiment '''dragnet''', but you can pick any name you like. Usually it's something to do with the experiment.
| |
| | |
| Next, we need to set up two directory structures. The first, the '''home directory''' will contain the scripts we use to run the experiment. We don't want to lose these, so we'll make the home directory for the experiment actually reside in our home directories on '''discover''', which is backed up and recoverable in case anything goes wrong. Since I potentially will run many GEOS-5 experiments before I retire, I'm accumulating these home directories in a sub-directory called ''geo5''. So, if you follow that, make the home directory:
| |
| | |
| % mkdir -p /home/colarco/geos5/dragnet
| |
| | |
| where you substitute your username for ''colarco''.
| |
| | |
| The second directory is the experiment directory, which is where the experiment is actually run from. This space is volatile, and the experiment can accumulate quite a bit of data as it runs, so we need a fairly large disk space to contain it. I put these things on my ''nobackup'' space on '''discover''', but note that ''nobackup'' means this is not backed up.
| |
| | |
| % mkdir /discover/nobackup/colarco/dragnet
| |
| | |
| There's nothing magical about these directory structures; you can use whatever you like. You'll just have to edit your scripts accordingly.
| |
| | |
| === Populate the Experiment Directory ===
| |
| At the beginning of the experiment, the experiment directory will contain a few things:
| |
| | |
| # The GEOSgcm.x executable (the model itself)
| |
| | |
| # Resource files
| |
| # Restarts
| |