Hi, I wanted to introduce our Vulcan climate modeling group to this forum. We have been working with the FV3GFS component of the UFS for over a year in close collaboration with GFDL, and hope to be able to make some contributions upstream (e.g. the CCPP). These edits span several of the "core submodules" in the UFS. For example, we have added diagnostics to FV3, fixed bugs, and plugged-in prognostic machine learning paramaterizations to CCPP. We have developed this work in this repo: https://github.com/VulcanClimateModeling/fv3gfs-fortran, which loosely mimics the top-level structure of https://github.com/ufs-community/ufs-weather-model.
Some of our contributions are probably of interest to the broader community, but aspects of the UFS submodule hierarchy make it challenging to contribute upstream changes: many of the submodules don't have automated tests on github and some cannot be built/tested in isolation.
In particular, I could easily envision contributing to https://github.com/NCAR/ccpp-framework/. It has tests and clear build instructions. On the other hand, https://github.com/NCAR/ccpp-physics does not look like it can be built outside of the context of the UFS of the single column model. Therefore, testing any contribution to this repo would require forking/updating all the parent repos in sequence, before finally building triggering the cmake build from the root of https://github.com/ufs-community/ufs-weather-model. To avoid this laborious process we have turned all submodules into subtrees in our fork, and built a small test suite that checks for bit-for-bit regression of reduced resolution simulations.
How does the core development team approach testing/integration across the sub-module hierarchy? Forgive me if this is already documented someplace.
Also, are there any plans to restructure these sub-modules into independently buildable/testable units. I think that could really accelerate external contributions.