Submitting updates for inclusion in GEOS-Chem

From Geos-chem
Revision as of 16:36, 13 July 2020 by Lizzie Lundgren (Talk | contribs)

Jump to: navigation, search


The GEOS-Chem Steering Committee (GCSC) encourages updates to the GEOS-Chem model. Updates to the GEOS-Chem model benefit both the developer and the entire GEOS-Chem community. The developer benefits through coauthorship and citations. Priority development needs are identified at GEOS-Chem users' meetings with updates between meetings based on GCSC input through working groups.

When should you submit updates to the GEOS-Chem code? Bug fixes should be submitted as soon as possible and be given high priority. Code related to model developments should be submitted when it is mature (i.e. a paper has been submitted). Your working group chair can offer guidance on the timing of submitting code to the GCST.

The practical aspects of submitting updates to the GEOS-Chem Support Team are outlined below.


  1. Contact your Working Group leaders to request that your changes be included in the standard code.
  2. Create or log into your GitHub account.

  3. Fork the GEOS-Chem repositories. Navigate to each appropriate GEOS-Chem repository on GitHub and click Fork in the top-right corner of the page.

  4. Clone your forks of the GEOS-Chem repositories to your system:
  5. Add your modifications into a new branch off of the master branch.

  6. Test your update thoroughly and make sure that it works.
  7. Review the code update checklist and data checklist below.

  8. Create a pull request in GitHub (recommended) or a Git patch file.
  9. The GEOS-Chem Support Team will add your changes to the standard code.

Checklist for code update submissions

  1. Use F90 free format whenever possible
  2. Include thorough comments throughout code updates
  3. Remove extraneous code updates (e.g. testing options, other science)
  4. Include full citations at the top of relevant source code modules
  5. Complete GCHP updates required with GEOS-Chem Classic updates

Checklist for data submissions

  1. Choose a final file naming convention for all data files that are to be submitted.
    • Requesting files to be renamed after the benchmark process has begun can cause confusion and prevent reproducibility.

  2. Make sure netCDF data files are COARDS-compliant
  3. Concatenate individual netCDF files together so as to reduce tne number of files that need to be opened.
    • e.g. If the data is a multi-year archive of monthly-mean data, create one file per year containing all data variables. Each data variable would have 12 timestamps, one for each month.
    • Reducing the number of files that have to be opened results in more efficient GEOS-Chem simulations.

  4. Make sure files have been chunked and deflated.
    • Deflation level 1 is usually sufficient for most files.
    • e.g. ./ 1

  5. Follow these additional steps to ensure data can also be read by GCHP:
    • All variables should be of type float (aka REAL*4) or double (aka REAL*8). The MAPL library used by GCHP cannot read integer data from netCDF files.
    • Use a recent reference date, if possible, for the time:units attribute. MAPL may have issues interpreting reference times such as 1750 which is prior to the Julian-to-Gregorian calendar switch.
    • Make sure the time units attribute is of format "x since YYYY-MM-DD HH:ss:MM" where x is a time unit such as hours or days, and YYYY, MM, DD, HH, ss, and MM are reference year, month, day, hour, second, and minute.
    • The first time value in each file should be 0, corresponding with the reference time.

  6. Include updated HEMCO Configuration file (if the data will be read via HEMCO).
  7. Include README file detailing data source, contents, etc.

  8. Include script(s) used to process original data

  9. Include a summary or description of the expected results (e.g. emission totals for each species)

Further reading