Guidance for Managing CCPP Physics UFS Application Fork

As more institutions start to use CCPP, we propose to create a CCPP fork to be used by all UFS applications.

• This action is in alignment with CCPP code management guidance.
• Such a fork is also needed to support agile operational implementation of NCEP models and its maintenance in NCEP operation.
• It reduces the burden of CCPP code manager at DTC
• For the UFS Fork, the code manager will focus on UFS-related physics updates. It reduces the burden of UFS physics code manager.

The authoritative GitHub ccpp-physics repository is https://github.com/NCAR/ccpp-physics/. A Fork of this main repo will be created at https://github.com/ufs-community/ccpp-physics to serve the UFS modeling community. The following guidance shall be followed to manage this ccpp-physics Fork. The target date for creating this Fork is late August or early September 2022.

Roles and Responsibilities

NWS/NCEP/EMC and DTC will co-manage this Fork and contribute 1.0 FTE and 0.5 FTE to the effort, respectively.

Relationship between the Fork and UFS Applications

This Fork shall be used as the official physics code repository for all UFS applications, including MRW, SRW, S2S, Hurricane, air quality and other emerging UFS applications. All UFS applications will point to the ufs/dev branch, or a tag in the UFS Fork.

Conducting development

Developers in the UFS community should direct their PRs to the Fork when those are targeted for operational applications in the short term. In other cases, developers can choose to propose physics updates directly to the authoritative repo.

Collecting development efforts

A ufs/dev branch will be maintained in the Fork to receive PRs from developers. All physics Pull Requests (PRs) to ufs/dev shall undergo the existing ufs-weather-model RT and ORT tests. The purpose of ufs/dev is to collect development from developers for the purpose of testing. Developers and code managers from the community, including DTC, are allowed and encouraged to review the PRs. Subject-matter experts (point of contact) associated with each parameterization will be notified via the GitHub CODEOWNERS mechanism to provide reviews.

Transferring development to the authoritative repository

Code managers for the authoritative repository and the Fork should have a weekly standing meeting where they discuss upcoming PRs so that all are aware of changes coming, which will make merges easier. Code managers will update the dev/ufs branch of the Fork at least once a month. If significant changes are made to either the Fork or the authoritative repo, the code managers can decide to update dev/ufs more often. When a PR is accepted to the ufs/dev branch of the Fork, the Fork code managers will submit this PR to the authoritative repository main branch. Before this PRs is accepted in the main branch of the authoritative repository, it needs to pass RTs for all participating models (currently UFS WM and CCPP SCM). If RTs for participating models do not pass, developers submitting the PR are requested to engage in a timely manner to work with UFS Fork and the CCPP authoritative code managers to resolve any issues.
Permanent differences (deltas) between the authoritative repository and the Fork are highly discouraged and should be avoided as much as possible. If present, they need to be tracked, and are under responsibility of the Fork managers.

Other

All UFS applications shall still use the authoritative ccpp-framework repository (https://github.com/NCAR/ccpp-framework/). Authors of updates and new physics parameterizations committed to the Fork shall work with DTC CCPP team to either update existing documentation or provide new content to the CCPP Technical Documentation (https://ccpp-techdoc.readthedocs.io/) and Scientific Documentation (https://dtcenter.ucar.edu/GMTB/v6.0.0/sci_doc/). The rules described in the Guidelines for Institutional Forks should be followed. This document overrides the Guidelines shall conflicts arise.