GEOS-Chem HP
Contents
About High Performance GEOS-Chem
GEOS-Chem with the high performance option (GCHP) is the next generation of GEOS-Chem. It uses a distributed memory capability designed to enable efficient scaling across many cores, and thus enable finer resolution simulations. GCHP also has the advantage of using a "cubed-sphere" geometry that enables more accurate transport and eliminates the polar singularity inherent to lat-lon grids. Despite these advances, you can still run the model on a single machine at coarse resolution if you choose to do so.
If you are working on a project using GCHP, please add your name and project description to the project table on the GEOS-Chem High Performance Working Group wiki page (see link below). If you would like to stay informed of GCHP developments, please join the GEOS-Chem High Performance Working Group mailing list. We also encourage you to join our GCHP Slack workspace.
GCHP Wiki Guide
Getting Started with GCHP
- Hardware and Software Requirements
- Getting Started with GCHP
- Tutorial Slide Presentations
Versions and Validation
Community
Help Resources and Quick Links
- Frequently Asked Questions
- Verifying a Successful Run
- Open-source tool for regridding between cubed-sphere and lat-lon created by Sebastian Eastham
- Previous GCHP issues now resolved in v11-02
- Known GCHP issues not yet resolved in v11-02
GCHP Core Development Team
Please contact the GEOS-Chem Support Team with GCHP questions and feedback.
| Name | Title | Institution | Focus | |
|---|---|---|---|---|
| Lizzie Lundgren | Scientific Programmer | Harvard | elundgren [at] seas [dot] harvard [dot] edu |
|
| Sebastian Eastham | Research Scientist | MIT | seastham [at] mit [dot] edu |
|
| Randall Martin | Professor | Dalhousie | randall.martin [at] dal.ca |
|
| Colin Lee | Doctoral Student | Dalhousie | colin.lee [at] dal.ca |
|
| Bob Yantosca | Senior Software Engineer | Harvard | yantosca [at] seas [dot] harvard [dot] edu |
|
| Jiawei Zhuang | Graduate Student | Harvard | jiaweizhuang [at] g [dot] harvard [dot] edu |
|
| Mike Long | Research Associate | Harvard (based in NC) |
mlong [at] seas [dot] harvard [dot] edu |
|
Cubed-sphere Grid Geometry
While regular, lat-lon grids are typically designated as ΔLat ⨉ ΔLon (e.g. 4⨉5), cubed-sphere grids are designated by the side-length of the cube, specified as CX (e.g. C24 or C180). The simple rule of thumb for determining the roughly equivalent lat/lon for a given cubed-sphere resolution is to divide the side length by 90. Using this rule you can quickly match C24 with 4x5, C90 with 1 degree, C360 with quarter degree, and so on.
Interactive Cubed-sphere Grid Illustrations
Jiawei Zhuang created the following interactive illustrations demonstrating key features of the GCHP cubed-sphere geometry:
- Step-by-step illustration on how to create a cubed-sphere grid
- Comparison of different cubed-sphere map projections
- Creating a "stretched" cubed sphere
- This is a way of getting fine resolution in a selected region of the world (e.g. akin to GEOS-Chem "Classic" nested-grid simulations)
Parallelizing over the Cube-sphere Grid
A cubed-sphere grid allows for natural parallelization. At a minimum, six cores are required such that one core is assigned to each face. At least one unique core therefore handles all processes on that face, with communication between the cores only occurring during transport processes. While any number of cores is valid as long as it is a multiple of six, you will typically start to see negative effects if a core is handling less than around one hundred grid cells due to excessive communication. In our standard default six core c24 configuration, each core handles one face with 576 cells (24x24) and communicates with four other cores.
--Lizzie Lundgren (talk) 16:22, 7 March 2018 (UTC)
