CI and RTS system

[bensonr]

Opening for a conversation begun in PR #42

[ofuhrer]

So we have a container build of fv3atm (NCEPlibs, ESMF, FMS, stochastic physics, fv3atm are all checked out and built in the container) that runs a simple c12 and c48 test case using fortran and OpenMPI. This would already go a long way as a first regression test and would ensure that a) the submitted PR compiles and b) the submitted PR gives a model that runs and c) the submitted PR does not change results (if that should be the case). It would be straightforward to integrated this into GitHub using Travis CI (which is free for open-source projects).

The main issue is that - to my understanding - the code in this repo cannot run standalone and needs to be integrated into a model. As observed several times before, one of the problems is also that we are not working on the same codebase as GFDL. Taking the master of GFDL_atmos_cubed_sphere and dropping it into that container generates a significant number of conflicts, both for the build as well as the FMS version and atmosphere.F90.

[thomas-robinson]

I think the first step is to resolve how to manage the differences between the gfdl and emc branches. Next we can identify a few configurations that we want to run CI and RTS on. Then we would be able to identify a platform to run the tests.

Dropping the master branch into a GFDL model doesn't work, however, the master branch merges into the dev/gfdl branch used by the GFDL models. I haven't worked with the EMC branch, so I'm not sure how easily the changes to master will merge in. My understanding is that the changes on master will be beneficial to both EMC and GFDL. I think (personal opinion) it's important to keep these two streams consistent with the master branch so that there isn't a split which leads to two different FV3s.

[lharris4]

Ultimately changes in atmos_cubed_sphere will need to be tested in a particular build of a model. The dycore needs different interfaces for different models, and is intended to be tailored for the needs of each model. I don't think we could specify a single codebase that will satisfy everyone.

…

On Mon, May 11, 2020 at 9:43 AM Tom Robinson ***@***.***> wrote: I think the first step is to resolve how to manage the differences between the gfdl and emc branches. Next we can identify a few configurations that we want to run CI and RTS on. Then we would be able to identify a platform to run the tests. Dropping the master branch into a GFDL model doesn't work, however, the master branch merges into the dev/gfdl branch used by the GFDL models. I haven't worked with the EMC branch, so I'm not sure how easily the changes to master will merge in. My understanding is that the changes on master will be beneficial to both EMC and GFDL. I think (personal opinion) it's important to keep these two streams consistent with the master branch so that there isn't a split which leads to two different FV3s. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVGNXO5R5BC737JKZFLRQ76IFANCNFSM4M4FJWLA> .

[ofuhrer]

@lharris4 , is there a very simple driver for atmos_cubed_sphere that allows to run the dynamical core for a doubly-periodic tile or an idealized cubed-sphere simulation? That would be a great starting point for regression tests of the dynamical core.

You are right that ultimately changes in atmos_cubed_sphere need to be tested in the context of a model. But in principle, the regression tests of that model should also be associated with the repo of that model (and not in the repo of just the dynamical core).

[bensonr]

With a functioning CI and RTS system based on idealized analytical solutions implemented by @laurenchilutti, I'm closing this issue.