Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: update.

Some of the subdirectories in the ACME E3SM code contain code that was brought in from another repository.

There are two ways to bring in code from one git repo to another: subtree and submodule.   ACME uses both and our procedures are described in Sharing External Code using Git Subtree and Sharing External Code using Git Submodules.    Any source brought in as an external must be independently buildable and testable in that external.

Subtrees

...

Terms

  • external any subdirectory in E3SM whose entire content is from another repository
  • upstream master  the repository everyone is sending their changes to.  Only one so that everyone pulling from the same source is working with all the same changes.   The source of an external.

Methods for including externals

  • submodule  a link that points to another git repository.  See Sharing External Code using Git Submodules .
  • recursive submodule:   a submodule that is inside another submodule.  
  • subtree a set of files and commits from another git repo, brought in to your repo so that it looks like original content.  See Sharing External Code using Git Subtree
  • monorepo the entire repo is added once (usally with subtree) and developed within E3SM.  Might maintain a separate build/test system.
  • buildtime  the repo is checked out to the $CIME_OUTPUT_ROOT/$CASE/bld when compiling a case for the first time.  Code does not exist in E3SM repo.

Rules for adding externals

  1. Group leads must approve adding a new external.  The group needing the external can decide on the method of inclusion.  A POC for the upstream master must be identified and the IG group leads notified.
  2. The upstream master for the external must be build-able and testable on its own.
  3. For submodules, the linked repo must be readable by all E3SM developers.  If the upstream master can not be made readable, a fork must be maintained in E3SM-Project github and E3SM then links to that fork.

Development in externals

In general, there are several ways to develop with external code

  • strict 1-way:  all development is merged to the upstream master first and flows down to E3SM.  No exceptions.
  • mostly 1-way:  prefer strict 1-way but some exceptions can be made for emergency fixes
  • 2-way:  developers can make changes in E3SM or the upstream master.  POC keeps them in sync.

More specific instructions for externals are below.

Table of Externals currently in ACME

NameSubdirectory in ACMEexternal methodupstream masterdevelopment methodPOCNotes
CIMEcimesubtreehttps://github.com/
ACME-Climate
ESMCI/cime

5cc4a90bd04d9273abb00f71762ebba63f2c3531

acme_merge2_2 (cime2.0.14)ACME/

2-way


MCTcime/externals/MCTsubtreehttps://github.com/MCSclimate/MCT

bfbe1c0a7f43d743c549679a5ad9d4ade1f700fe

MCT_2.9.0

ACME/

mostly 1-way

usually brought in with CIME
PIOcime/externals/
PIO
pio*subtreehttps://github.com/NCAR/ParallelIO

67c69713ee282f1b1c2eb7facdc3572a53490ad0

pio1_9_22ACME/cime/externals/CMake

mostly 1-way

usually brought in with CIME
SCORPIO

externals/scorpio

externals/scorpio_classic

submodulehttps://github.com/E3SM-Project/scorpiostrict 1-wayJayesh KrishnaE3SM uses this and ignores cime/externals/pio
Kokkosexternals/kokkossubmodulegit@github.com:E3SM-Project/kokkos.git branch e3sm/kokkosstrict 1-wayJames Foucar
MPAS-Source

components/mpas-source

submodule

https://github.com/MPAS-Dev/MPAS-Model

strict 1-wayMPAS-Ocean, Seaice and land ice all use code from here.
RRTMGPcomponents/cam/src/physics/rrtmgp/externalsubmodulegit@github.com:RobertPincus/rte-rrtmgp.git branch developstrict 1-wayBen Hillman
COSP2components/cam/src/physics/cosp2/externalsubmodule

git@github.com:CFMIP/COSPv2.0.git branch CESM

-Development/CMake_Fortran_utils

c2572f19d671c35a4cca26911a55ef78b3ba2829

CMake_Fortran_utils_150308

ACME/cime/externals/genf90

_v2.1.4

strict 1-way

MPP

components/clm/src/external_models/mpp

submodulehttps://github.com/MPP-LSM/MPP branch alm/developstrict 1-wayGautam Bisht
FATES

components/clm/src/external_models/fates

submodule

https://github.com/NGEET/fates

strict 1-way
SBETrcomponents/clm/src/external_models/sbetrsubmodulegit@github.com:BeTR-biogeochemistry-modeling/sbetr.gitstrict 1-wayGautam Bisht
CVMixcomponents/mpas-source/src/core_ocean/cvmixrescursive submodulehttps://github.com/CVMix/CVMix-srcstrict 1-wayJon Wolfeused to be not in-source and fetched at build time.
ocean BGCcomponents/mpas-source/src/core_ocean/BGCrecursive submodulehttps://github.com/E3SM-Project/Ocean-BGCstrict 1-wayJon Wolfeused to be not in-source and fetched at build time.


 Externals planned for E3SM

...

NameSubdirectory in ACMEexternal methodupstream masterdevelopment methodPOCNotes
CICE column physicsTBDTBD?

?

?


GCAMTBDsubmodule?https://github.com/
PARALLELIO
JGCRI/
genf90

491d28dda46fb5dae93bcd50f9b6511e24a46465

(no tag)

 

 


Specific external development instructions

CIME:

Code location:  E3SM/cime

Any code development in E3SM/cime/config/acme can be committed directly to E3SM through the normal PR process.

Code development in other parts of CIME should be committed first with a PR in https://github.com/ESMCI/cime.  It will be then brought to E3SM by a subtree merge as in Maintaining the CIME subtree in ACME.

Report issues about the Case Control System, driver or coupler directly to  https://github.com/ESMCI/cime.   config file issues can be reported to E3SM gitub.