From Geos-chem
Jump to: navigation, search

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

Versions and Validation


Help Resources and Quick Links

GCHP Core Development Team

Please contact the GEOS-Chem Support Team with GCHP questions and feedback.

Name Title Institution Email Focus
Lizzie Lundgren Scientific Programmer Harvard elundgren [at] seas [dot] harvard [dot] edu
  • Primary contact for GCHP support
  • GCHP development and validation
  • GCHP documentation
Sebastian Eastham Research Scientist MIT seastham [at] mit [dot] edu
  • GCHP WG Chair
  • GCHP development and validation
Randall Martin Professor Dalhousie randall.martin [at]
  • GCHP WG Chair
  • GCHP validation
Colin Lee Doctoral Student Dalhousie colin.lee [at]
  • GCHP diagnostic validation and development
Bob Yantosca Senior Software Engineer Harvard yantosca [at] seas [dot] harvard [dot] edu
  • GCHP development
Jiawei Zhuang Graduate Student Harvard jiaweizhuang [at] g [dot] harvard [dot] edu
  • GCHP development and validation
Mike Long Research Associate Harvard
(based in NC)
mlong [at] seas [dot] harvard [dot] edu
  • GCHP development and validation

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:

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)