MOM6 code: where it lives and what's the best way to know what version I'm using

COSIMA
1

I’m quite puzzled with the way MOM6 is being developed. Seems like the code lives here: GitHub - mom-ocean/MOM6: Modular Ocean Model but also here: GitHub - NOAA-GFDL/MOM6: Modular Ocean Model

The latter is a fork of the former and it seems to be actively developed?

I’m also intrigued by the fact that MOM6 does not make tagged releases of the code (Tagged MOM6 releases · Discussion #1587 · mom-ocean/MOM6 · GitHub). This was always puzzling me as in order to reproduce results it seems that we need to keep track the specific hash commit from the NOAA-GFDL/MOM6 repo that we used to create a MOM6 executable, right?

2 Likes
2

Yes MOM6 is being developed as a federated system. @angus-g knows more, and if this is documented well somewhere, but basically all the nodes (forks) develop independently and run their own test suite. Periodically a node will make a PR to the MOM6 GitHub repository, and all the nodes will clone the PR and run their own test suites. When everyone agrees the PR is good it is merged, and all nodes pull the latest version to their forks.

Yes you will need a hash to identify the code you have used. This is arguably better than a tag, which can be changed to point to another hash. It doesn’t stop a fork from using tagging in their own fork.

3

As Marshall mentioned in the linked discussion, there’s a visual overview of the structure. I’m not sure if there’s an “official” overview document, however. It has always been the case that the dev/gfdl branch was for active development, and “stable” or verified changes were merged into main.

The issue of tagged versions has come up often, but MOM6 has a policy of not breaking (bitwise) reproducibility. In the ideal situation, the tests @Aidan alluded to cause no bitwise changes to answers, signalling the changes are compatible with all the test cases that all the member institutions care about. Otherwise, answer changes can be tracked down pretty easily, e.g. by bisection. If answer changes are detected, and they’re deemed to be correct, such as from fixing a bug, they can be retained.

It used to be the case that the previous result from an answer-changing commit could be obtained by setting a flag, e.g. USE_2018_ANSWERS or something to that effect. I think this is changing to essentially a date stamp: in theory you could reproduce your answers from a given date with a main checkout by simply setting this date stamp appropriately.

Also, a tag only captures the state of MOM6 itself, but doesn’t give you information about the rest of the environment (dependencies like FMS, compilers, libraries), so I think some kind of version-pin that encapsulates these is a bit more practically useful. When I compile MOM6 on Gadi, I generate a manifest.yaml which includes the git hashes of dependencies, module versions, compile flags/definitions, etc. This is probably a bit of a duplication of Spack’s wheelhouse though!

1 Like
4

Thanks for pointing out the visual overview @angus-g I hadn’t seen that before.

Apropos of that Marshall’s diagram suggested the existence of a dev/access branch for “ACCESS”. I appreciate being included, but it does suggest that perhaps this branch should be created and made the default for the COSIMA fork.

Or perhaps dev/COSIMA for the COSIMA fork and dev/access for ACCESS-NRI when we get into the business of MOM6 support? This could get complicated …

5

Yes, perhaps worth thinking/talking about soon whether there is a want/need for both a COSIMA and ACCESS fork, or whether they can be one and the same?

6

Definitely something that should be thought about and discussed.

I’m assuming COSIMA will want to develop on their own MOM6 fork in the COSIMA Github Organisation, as they have the freedom to change their dev branch as they see fit.

ACCESS-NRI will want to do gadi-based CI testing which will require a MOM6 fork in the ACCESS-NRI GitHub repository for security reasons. It is this sort of testing that is part of being a MOM6 node.

It may be that this would mean the COSIMA folks wouldn’t have to set up gadi-based CI testing, as there is definitely work involved in setting it all up and maintaining it.

If we’re running different forks I don’t think it makes sense to have identically named branches on the respective forks. They’re clearly going to be out of sync and that is probably desirable. If they’re named differently their purpose is obvious. Plus we could sync the COSIMA branch to the ACCESS-NRI fork and test it separately.

Would be interested in your thoughts @aekiss and @micael.

7

I’m assuming COSIMA will want to develop on their own MOM6 fork in the COSIMA Github Organisation, as they have the freedom to change their dev branch as they see fit.

No necessarily. I think it depends who will host the “official” MOM6 fork of the Australian community (see bellow) .

ACCESS-NRI will want to do gadi-based CI testing which will require a MOM6 fork in the ACCESS-NRI GitHub repository for security reasons. It is this sort of testing that is part of being a MOM6 node.

Is it decided that NRI will be MOM6 node? I’m asking because initially it was supposed to be COSIMA. Personally, I’ve have no opinion on this, but would be good to get this clarified.

It may be that this would mean the COSIMA folks wouldn’t have to set up gadi-based CI testing, as there is definitely work involved in setting it all up and maintaining it.

I would strongly be in favor of not duplicating the CI, but we need to see how this fit with the testing of ACCESS-OM3, as for sure we want to test changes to MOM6 as a component of the coupled model.

8

To expand a bit further. The branch names and the actual workflow for new developments will depend on where will we create the pull requests to mom-ocean/MOM6 from. I think that’s the key decision to be made here.

9

It’s a good point. No, I don’t suppose so. I was getting a bit too focussed on CI, and wondering if that was something the NRI could take care of, to relieve COSIMA of the burden of configuring and supporting it.

This is a really good point. The testing the NRI will want to do is broader than the remit of COSIMA alone, which is an argument for the NRI to do the CI testing.

Another good point. Reducing it to the actual technical detail is helpful to clarify what is being discussed.

COSIMA could make a PR to a fork of MOM6 in the ACCESS-NRI repository, and have the rests run there. Once passed another PR could be made to mom-ocean/MOM6 from the COSIMA fork.

Being a node involves running all the tests that you want to pass that matter to that node. Does the above workflow effectively mean that COSIMA becomes responsible for mediating changes that affect the coupled models? Maybe that is ok, and COSIMA folks would like some input into the way the coupled model uses the ocean.