GEOS–Chem v9–02 Online User's Guide
Previous | Next | Printable View (no frames)
Appendix 8: Modifications to facilitate Grid-Independence in GEOS–Chem
GEOS–Chem will form the core of a fully-coupled system that will connect to the NASA GEOS–5/GCM. Before this can happen, the GEOS–Chem standard model must become compliant with the Earth System Model Framework (ESMF). This will allow us to take advantage of Message Passing Interface (MPI) parallelization via ESMF, which has been a long-term goal of the GEOS-Chem development community. MPI parallelization will facilitate GEOS–Chem simulations at extremely fine horizontal resolution, running on hundreds or thousands of CPUs.
To achieve this coupling between GEOS–Chem and the NASA GEOS–5 GCM, we have introduced the concept of grid-independence. We no longer shall assume a preset horizontal grid, but instead shall allow the GCM to dictate the size of the grid, and how many grid boxes will be processed by each CPU. This lets us to keep the all calls to ESMF library routines completely outside of GEOS–Chem.
We have made it a priority to implement necesary structural changes into GEOS–Chem without disrupting ongoing GEOS–Chem research projects. We have already removed several legacy code routines that prevented GEOS–Chem from connecting to the NASA GCM. We have added new source code instructions into many GEOS–Chem routines, set apart by C-preprocessor switches. Eventually, the new code will replace the old code, but during the transition phase we must keep both new and old code side-by-side.
We describe below the structural changes that we made to facilitate Grid-Independence in GEOS–Chem. Please also see our Grid-Independent GEOS–Chem wiki page for the latest information.
Our initial preparations involved replacing F77-style legacy code with modern F90 code:
A8.2 Construction of the Chemistry Component
We began by attempting to interface GEOS–Chem's chemistry solver, photolysis, and dry deposition routines into a "Chemistry Component" that could be plugged into the GEOS–5 GCM. An initial test (using the Beijing Climate Center's GCM as a proxy) revealed several bottlenecks that we had to rectify immediately:
We modified all functions in in grid_mod.F (as well as routine GET_LOCALTIME in time_mod.F) to accept longitude, latitude, and altitude indices as inputs. In other words, functions such as GET_XMID( I ) now look like GET_XMID( I, J, L ), etc.
We moved computation of the overhead ozone columns (and interpolation to TOMS/SBUV, where that data exists) outside of FAST–J. FAST–J now accepts this as an input argument.
We introduced netCDF I/O capability into GEOS–Chem and converted several ASCII data files to netCDF. We shall continue to migrate all of GEOS–Chem's data files to netCDF, but this will be a gradual transiton.
We created a new module to read and regrid Olson land map data from its native resolution. This module can be used with both the older (1992, 0.5° x 0.5°) and newer (2001, 0.25° x 0.25°) Olson map products. This removed legacy code that relied on ASCII data input.
We created a new module to read and regrid MODIS leaf-area-index data from its native resolution (either 0.5° x 0.5° or 0.25° x 0.25°). This removed legacy code that relied on ASCII data input.
We corrected all of these issues prior to the release of v9–01–03. Please see our GEOS–Chem v9–01–03 wiki page for more details about each of these improvements.
For better compatibility with the Earth System Model Framework—which controls the flow of data between components of the GEOS–5 GCM—we have added the following structural changes into the standard GEOS–Chem code:
We have introduced new derived type objects into GEOS–Chem. These objects will render referencing data arrays via USE statements obsolete.
We now pass an argument named am_I_Root from main.F to lower level subroutines. This will allow us to restrict printing to the root CPU when we connect GEOS–Chem to the GEOS–5 GCM.
We now determine available Fortran logical unit numbers while GEOS–Chem is running rather than using fixed, pre-defined values.
A8.3 Construction of the Emissions Component
Initally, we focused on delivering the GEOS–Chem "Chemistry Component" (chemistry, photolysis, dry deposition) to NASA/GSFC for inclusion into the GEOS–5 GCM. We achieved this in June 2011. With the help of our colleagues at GSFC, we are continuing to refine the performance of the GEOS-Chem within the GEOS–5 GCM.
We also are re-engineering GEOS–Chem's emissions routines into an "Emissions Component". We have the following goals in mind:
We wish to achieve a total separation between emissions routines and chemistry routines
We wish to implement "top-down" data flow (i.e. all data enters/leaves each subroutine via the argument list, contained in derived type objects)
We wish to segregate all file I/O operations from routines in which computations are performed. This will prevent bottlenecks to parallelization.
We wish to have a flexible data structure to which we can attach emissions data, scale factors, or geographical masks.
Christoph Keller (Harvard) is currently working on this task. He has created a new emissions data structure (a "linked list") that will form the backbone of the GEOS–Chem Emissions Component. The work is ongoing.