search

mom-ocean / FMS

GFDL's Flexible Modeling System: This is a fork for use with the MOM5 model.
Other
2 stars 1 forks source link

Managing MOM5 FMS fork #3

Closed aidanheerdegen closed 3 years ago

aidanheerdegen commented 4 years ago

MOM5 now includes FMS directly using subtree from a branch on this repo (https://github.com/mom-ocean/FMS/tree/MOM5_ulm_update).

We now need to decide on a structure for this repository so everyone knows how it should be updated, and potentially stay in synch with the upstream FMS repository.

At some point FMS will diverge to such an extent that it would require substantial (too much) maintenance to MOM5 to just use the most recent version. It may have already reached that point as MOM5 is currently using a (modified) 2015 version.

A couple of options that came to mind:

  1. Keep master following the upstream repo and have a mom5 branch with the currently used version of the code. Make the mom5 branch the default for this repo.

  2. Make master the currently used branch in MOM5. Follow upstream in an upstream branch.

Both of these options would requiring force modifying the current master branch, which has a few of the updates @marshallward made to FMS on top of the a 2018 version of the code. I didn't want to do this without consulting first.

Any thoughts @marshallward @russfiedler @nichannah

aidanheerdegen commented 4 years ago

I took silence to mean ambivalence so I have chosen to do option 2.

I copied the previous master branch to oldmaster. This preserves the commits from PRs that we had done at that point, but is otherwise not useful to keep around.

I made a new branch upstream which is a clone of the current state of the GFDL FMS repo master branch.

I then force pushed master to be the same as MOM5_ulm_update, which is the current version of the shared subdirectory in MOM5.

To make changes to FMS in MOM5:

  1. branch from master, e.g. newfeature
  2. make changes and commit back to newfeature on this repo
  3. check out newfeature branch using subtree in a MOM5 branch 
    git subrepo clone -b newfeature git@github.com:mom-ocean/FMS.git src/shared
  4. push new feature branch to MOM5 and make PR
  5. test
  6. make a PR to master in this repo, when code is checked and ok'ed merge to master
  7. update to master in MOM5 PR branch 
    git subrepo clone -b master git@github.com:mom-ocean/FMS.git src/shared
  8. Merge MOM5 PR
marshallward commented 4 years ago

Sorry for the slow reply, I think option 2 is the better option, assuming upstream refers to GFDL's FMS.

We're rapidly approaching the point where the GFDL FMS is going to be unusable by MOM5, since high level functions like save_restart and restore_state are going away, replaced by much lower level IO operations. In the case of MOM6, these functions had to be entirely re-implemented in the MOM6 framework layer.

Unless someone wants to go through the exercise of re-implementing those functions, I think that any solution should assume that MOM5 will point to its own self-manged FMS repositories.

marshallward commented 4 years ago

BTW if you are going to be renaming these branches, you may want to consider the master->main transition which GitHub is moving towards:

https://github.com/github/renaming

MOM6 has recently renamed dev/master to main, and git is also planning to remove any special significance to the master label.

aidanheerdegen commented 4 years ago

Thanks for the heads up on the transition to main, did not know that. Is now already later this year?

Yes upstream is the GFDL master branch. Agreed that FMS is/has diverged so much that we cannot seamlessly update to using it in the foreseeable future.

However it is useful to have a branch we can check against, cherry-pick from, or branch from any commit that is newer than the current commit and still API compatible with MOM5.

It might be useful to establish what the most recent API compatible version is, and perhaps update to it?

We would also like incorporate all the parallel netCDF work @marshallward and @rxy900 did which is on a separate FMS branch I believe.

The oldmaster branch has 3 commits on top of the fork from FMS. Do they need to be included also?

https://github.com/mom-ocean/FMS/commits/oldmaster

marshallward commented 4 years ago

I agree, there are potential benefits to separating the management of MOM5's FMS, even if it doesn't converge with the GFDL release. The parallel netCDF work is a good example of that.

Currently nearly all of the GFDL FMS tags ought to be useable. I believe that all 2019.x tags respect the current API, and that 2020 tags from 2020.03 onward will also honor this API. (There were some issues with 2020.01 and 02, which is why MOM6 is still using 2019.01.03). There is a plan to eventually drop the old API, but it will not happen until at least 2021, and perhaps later.

There should still be plenty of time to consider another FMS sync, and perhaps even an opportunity to pick up an instance of the new API, so I agree this is a good idea.

As for the GitHub timetable, I am not sure where they are up to. MOM6 was a bit lucky because no one was using master, all of the hubs had their own dev/XXX branch, and dev/master was almost exclusively used for syncing across hubs.

aidanheerdegen commented 4 years ago

Can you identify a candidate branch/commit that should be the one we can use to test PIO with compression for ACCESS-OM2?

Is it just this one?

https://github.com/NOAA-GFDL/FMS/tree/with-parallel-netcdf

Should it be rebased on to one of those later commits you mention above?

Are there any other commits we need to add on top?

marshallward commented 4 years ago

That one is probably as good a place to start as any, after testing it.

Merging on top of that one may be difficult, it's hard for me to say, but anything newer will start to contain the new API.