Difference between revisions of "Compiling GCHP"
|Line 35:||Line 35:|
These will execute <tt>./build.sh clean</tt> and <tt>./build.sh build</tt>. All build information is sent to both the terminal window and to a log file called <tt>compile.log</tt>. Git information for both source code repositories at compile time are recorded in a separate file called <tt>lastbuild</tt> for future reference. Upon successful compilation, the following empty files are created in your GCHP source code directories:
Revision as of 21:23, 1 March 2019
- Hardware and Software Requirements
- Downloading Source Code
- Obtaining a Run Directory
- Setting Up the GCHP Environment
- Basic Example Run
- Configuring a Run
- Output Data
- Developing GCHP
- Run Configuration Files
This section provides instructions on how to clean and compile GCHP. There are several options for cleaning and compiling which allow clean and compilation of subsets of modules, thereby minimizing recompilation to only modules you have modified.
You are ready to compile GCHP after you have obtained the GCHP source code, set up your run directory, and set your environment. First time compilation can take a while (30 minutes or more) because it requires building large modules, including ESMF, MAPL, FV3 dycore advection, and GEOS-Chem. MAPL, which is short for Modeling, Analysis and Prediction Layer, is built on ESMF, aka the Earth System Modeling Framework. Both systems are highly flexible but highly complex, with significant compilation times. Fortunately, MAPL and ESMF do not need to be recompiled unless parts of their code have been modified which is usually not necessary. Subsequent compile times will therefore be significantly shorter, on the same order of magnitude as compiling GEOS-Chem Classic.
If you run into problems compiling GCHP and cannot figure out why, please create an issue on the GCHP issue tracker located at https://github.com/geoschem/gchp/issues.
Run Directory Makefile
The GCHP run directory Makefile contains several options for cleaning and compiling source code, as well as utility options you might find useful. Options are printed out by typing the following at the command line:
We encourage you to do this and browse the options available. Several options are particularly useful for cleaning up files in your run directory and displaying the status of your source code.
To compile GCHP from scratch, navigate to your run directory and check that your gchp.env symbolic link is pointing to the environment file you wish to use. Next, type the following within the run directory:
make clean make build
These commands will execute ./build.sh clean and ./build.sh build. All build information is sent to both the terminal window and to a log file called compile.log. Git information for both source code repositories at compile time are recorded in a separate file called lastbuild for future reference. Upon successful compilation, the following empty files are created in your GCHP source code directories:
These files indicate successful compilation per module and their presence prompts the GCHP source code Makefile to skip compiling each component during future builds unless you explicitly clean the source code. If you are ever uncertain on whether your ESMF, MAPL, and FV3 dycore were previously build, check if these files exist.
For subsequent GCHP compilations you have several options. You can see all options by typing the following at the prompt from within your run directory:
This will display all make options to your screen. For compilation the make targets you are interested in are clean, clean_mapl, clean_gc, build, build_mapl, and build_gc. Here is a brief summary of these options.
Clean/compile ALL source code, including ESMF, MAPL, and FV3:
make clean make build
Clean/compile all source code except ESMF:
make clean_mapl make build_mapl
Clean/compile all source code except ESMF, MAPL, and FV3:
make clean_gc make build_gc
Same as above but compile GEOS-Chem with debug flags turned on (note that this will slow down the model)
A typical workflow would look like you getting a run directory, compiling from scratch (make clean; make compile), editing GEOS-Chem code in GeosCore, and then recompiling without cleaning (make build_gc). Since this workflow is the most common the default make target, meaning the target used when none is specified, is set to build_gc. Therefore to rebuild GEOS-Chem after changing GEOS-Chem files or any high-level files in the GCHP directory you can simply type this:
Note that if you change your underlying libraries set in your environment you MUST do a full source code clean before rebuilding. Otherwise you will likely encounter a segmentation fault when running the model. For this reason it is recommended that you create a new run directory for each new environment you want to run in, e.g. if you want to test with both Intel and GNU fortran compilers.
Also note that these build targets were added in GCHP version 12.2.0. If you are using an earlier version type make help to view your make options.
If GCHP compiled without issues, you should see:
################################### ### GCHP compiled successfully! ### ###################################
Compiling GCHP produces a GCHP executable called geos that is stored in the bin/ subdirectory of your GEOS-Chem source code directory. Compiling within the run directory makes a copy of the executable locally for use within your run directory.
Compiler output, including warnings and error messages, will be stored in a log file called compile.log. If you inspect your log file or watch the compile output real-time, you will notice that there are many warnings and error messages. Many of these errors are due to leftover components in MAPL which are no longer used but which still try to compile. As long as the compilation continues, these errors can almost always be ignored and they will have no effect on the operation of GCHP.
Beware that MAPL will continue to compile even if a compile error occurs. This is because MAPL compilation involves compiling a series of components, many of them dependent on components that came before, and compilation rules are relaxed to allow minor problems. One component may fail compilation but the compilation will not crash until the built file is needed later on in the build sequence. It is therefore necessary to search your log file for errors high above the final error in the event of compile failure. The log file will be long so this should be done by keyword search. Here are strategies that typically hone in immediately on the original MAPL error:
- Search for string "making install". This will take you through the compilation starts of all major components within MAPL. If there was a compile problem in any of the components you will see messages about it directly above the start of compilation of the next component. In other words, look at the code above all results of your keyword search.
- Search for string "error". Ignore results where error is in a filename or in a source code string that triggered a warning.
Another thing to be wary about is if you edit a file in MAPL and your last build was a successful, your new build may appear successful when there was an actual problem. This would be the case because of the relaxed build rules and the fact that the previous build produced a binary. While an initial build after cleaning would end up with a dependency error later in the build process that would halt production of a final GCHP executable, a rebuild without cleaning would not. An indication that you have this sort of problem would if you reran the model after recompiling with your MAPL update but your update does not appear to have executed.
Here are some tips for troubleshooting this sort of problem.
- Check your compilation log file for errors using the guidelines presented above.
- Check the source code directory to see the file times. If the binary for the file you updated is older than the other binaries then it encountered a compile error in your update.
- When editing MAPL it is usually a good idea to add in one or more print statements on what you are doing so you can verify in your run log that it executed.
Advanced Compilation Topics
The Makefile in the run directory invokes a bash shell script called build.sh that includes changing into the source code directory and invoking source code Makefiles. At its core, building GCHP simply requires the inclusion of additional target HPC=yes if cleaning and hpc if compiling when invoking make in the GEOS-Chem repository. Cleaning GCHP also requires changing into the GCHP directory explicitly to clean ESMF, MAPL, and FV3 dycore.
If you are interested in seeing the core make commands used for all options provided in the run directory Makefile, see the commands defined in build.sh. You can then trace the build sequence by looking at the Makefiles in the GEOS-Chem and GCHP repositories. Note that calling make always invokes the Makefile in the directory you are in and changing into the GEOS-Chem and GCHP source code directories occurs within build.sh. Also note that the GRID=4x5 argument has no effect on the resolution at which the model runs since GCHP functions on the cubed-sphere grid. However, passing GRID is required so that components of GEOS-Chem Classic are functional.
If you are interested in the build sequence for MAPL, look at the various *.mk files ESMA_base.mk, ESMA_arch.mk, and GMAO_base.mk in GCHP/Shared/Config as well as GNUMakefile within GCHP/Shared and all its subdirectories. Also see GIGC.mk in the highest level of the GCHP repository for the include dependencies between GCHP modules.
Currently GCHP does not compile with cmake but work is in progress to make this possible in the future.