- Hardware and Software Requirements
- Downloading Source Code and Data Directories
- Obtaining a Run Directory
- Setting Up the GCHP Environment
- Running GCHP: Basics
- Running GCHP: Configuration
- Output Data
- Developing GCHP
- Run Configuration Files
First time compilation can take 30 minutes or more because it requires building large modules from scratch, including ESMF, MAPL, FV3 dycore advection, and GEOS-Chem. ESMF (Earth System Modeling Framework) provides core infrastructure to GCHP while MAPL (Modeling, Analysis and Prediction Layer) serves as a layer between GEOS-Chem and ESMF. Both ESMF and MAPL have significant compilation times but generally 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 if you skip recompiling them, on the same order of magnitude as compiling GEOS-Chem Classic. Even if you do need to recompile them, you can greatly speed up recompilation by not cleaning first.
This page provides instructions on how to clean and compile GCHP. There are several options for cleaning and compiling which allow selectively cleaning and compiling modules within GCHP, thereby minimizing recompilation time. This is a very big time-saver so please pay attention to the information presented on this page. You can also always see all build options from the command line, along with tips on which option is most appropriate for your use case, by typing make or make help within your run directory.
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.
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:
It is important that you do this and browse the options available. Knowing which build options to use based on what you changed in the model or your libraries is important for saving yourself time. In addition, several make options extend beyond cleaning and compiling, such as cleaning up files in your run directory and displaying the status of your source code. If you have already created a run directory, try typing make help on the command line from within the run directory and scan through the output. Do this often until you feel confident in your recall of the make options available.
To compile GCHP from scratch, including ESMF, MAPL, FV3 advection, and GEOS-Chem core files, navigate to your run directory. Then type the followng:
make clean_all make build_all
When you first download source code the directories will already be clean, so doing make clean_all technically is not necessary. However, it is recommended to be in the habit of including clean for fresh builds. It will also be necessary if you change compiler or other libraries and want to rebuild GCHP source code.
All build information is sent to both the terminal window and to a log file called compile.log. Git information for source code at compile time are recorded in a separate file called lastbuild for future reference, similar to GEOS-Chem Classic.
Upon successful compilation, the following empty files are created in your GCHP source code directories:
These files indicate successful compilation per module. If you are ever uncertain on whether your ESMF, MAPL, and FV3 dycore were previously built, check if these files exist.
For subsequent GCHP compilations you have several options. You can remind yourself of all options by typing make or make help at the command prompt. Here is a brief summary of the primary build options. Please note that none of these commands clean the source code prior to compiling, meaning none of the previously generated binaries are deleted. This makes recompile time much faster since only the Fortran files that changed are recompiled and and have new binaries created.
make build_all # Compile all source code (slow) make build_mapl # Compile MAPL, FV3, and GEOS-Chem/GCHP core files (skips ESMF) make build_core # Compile GEOS-Chem/GCHP core files only (fast)
You can also do any of the above with GEOS-Chem debug flags turned on. Note that this will come with a performance penalty during your runs so you should only do this for debugging. The make command to do this are the same as above but with '_debug' appended to the target. For example:
A sample workflow for GEOS-Chem development that makes use of several build options would be:
- Create a run directory and set environment
- make clean_all; make build_all (compile from scratch)
- Verify a successful short run (detailed in next chapter)
- Edit .F or .F90 file in GEOS-Chem GeosCore
- make build_core (recompile without cleaning, and skip ESMF, MAPL, and FV3)
- Edit high-level GCHP .F90 file in the GCHP run directory, e.g. gigc_chunk_mod.F90
- make build_core (recompile without cleaning, and skip ESMF, MAPL, and FV3)
- Edit a high-level GCHP header file, e.g. Includes_Before_Run.H
- make clean_core; make build_core (clean and recompile GEOS-Chem/GCHP core files; cleaning is required so that the Fortran file that includes the header file is recompiled even though it did not change)
- Edit a MAPL file such as GCHP/Shared/MAPL_Base/MAPL_ExtDataGridCompMod.F90
- make build_mapl (recompile MAPL without cleaning)
- Recompile with debug flags off (make build_core) for longer runs after debugging
If you find yourself editing files in the GCHP/Shared, GCHP/Registry, or FVdycoreCubed_GridComp folders then you will need to recompile with option make build_mapl. Editing these files is advanced. If you are attempting to fix a MAPL error that appears during run-time you may be headed in the wrong direction since most MAPL errors are caused by bad configuration in the run directory. If you are unsure of what you are doing please create a GitHub GCHP issue and we will respond. Even if your question is not a true issue, having it on the GitHub issue tracker allows sharing the question and answer with the wider GCHP community, something we strongly encourage.
If a GCHP executable exists in the GEOS-Chem bin/ folder to be copied to your run directory, then you should see the following message at the end of compilation:
################################### ### GCHP compiled successfully! ### ###################################
If you did a clean compile of your code and you see this message then you know that GCHP compiled without error. 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.
If you are recompiling MAPL and see the "GCHP compiled successfully!" message then your compilation may not actually have been successful. This is because failure during compilation of different MAPL sub-components does not trigger the entire build to fail. It will continue and the old binary files for whatever component failed will be used instead. Only if you cleaned first and those files were deleted and needed later in the build would the end result be a build failure.
The general rule-of-thumb is if you clean and then compile, or if you rebuild using make build_core, then you can trust the "GCHP compiled successfully!" message. However, if you recompile using make build_mapl without cleaning first, then you will need to dig a little deeper to ensure a successful rebuild. The best way to do this is to do keyword search for "making install" in compile.log and scan the few lines directly above all instances of it. If there was a problem with MAPL compilation you will spot it immediately in one of these areas, and that is where you should look for clues on how to fix it.
If you plan on developing within MAPL please make sure you fully understand this approach to debugging since it will save you a lot of time and frustration. Repeat: if you are developing MAPL and recompiling be aware you need to check your compile.log for keyword "making install" to ensure success.
Why is this necessary? Again, it is because MAPL will continue to compile even if a compile error occurs. 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.
While this has already been stated, we will state it again since it is so useful. Here are strategies that typically hone in immediately on the original MAPL error:
- Search for string "making install", and look at the lines immediately above all results of your keyword search.
- A second and more tedious option is to search for string "error". Ignore results where error is in a filename or in a source code string that triggered a warning.
- If in doubt, 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.
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.
If you are interested in the build sequence and settings for MAPL, look at *.mk files in GCHP/Shared/Config, particularly ESMA_base.mk, ESMA_arch.mk, and GMAO_base.mk, 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.