Discussion related to conflict resolution practices within the CCPP

[grantfirl]

• How should we best handle conflicts that arise? E.g. multiple versions of the same scheme, code divergence, scientific disagreements, standard name disputes

[mkavulich]

Notes from CCPP visioning workshop breakout session:

What works: Suites are a good way to indicate which schemes work well (or are designed to work) together.

Things that could be improved: Code needs to be published with specific caveats: what grid is used, what dycore is used, what vertical coordinates are used, and what acceptable deviations from these parameters might be. Schemes in submodules would help reduce the problem of different hosts wanting to update different schemes a different cadences. Submodules will also help isolate variables in the schemes, so you can be sure the only thing you’re changing is the particular scheme of interest. CCPP governance needs to do work to recognize when code is diverging at different institutions and bring things back together.

Unanswered questions: How can we capture results from other groups? If we list a limitation (this is only tested in this way) but another group discovers it works well (or doesn’t work well) in this other context, can we document that? People want to move to CCPP so that they can use the physics that other models use, but then when other models use different versions of their scheme that necessarily is a conflict; how can we encourage compromise/unification? Do we need a specific committee for standard names discussions, at the risk of continued meeting proliferation? Finally, the problem of scheme code divergence can be solved by unifying to CCPP, but in order to adopt CCPP in different hosts we need to converge the physics. Will submodules help this chicken-egg situation?