New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
ticket/1737/General – NEMO
wiki:ticket/1737/General

Version 5 (modified by frrh, 8 years ago) (diff)

--

Create GC3 package branch for coupling branches

Here we record work involved in the creation of a GC3 coupling code package branch to contain all relevant NEMO coupling branches.

17/05/2016

Starting from Marc Stringer's coupled set up where he has replaced the existing NEMO GO6 branches with the GO6 package branch: ​fcm:NEMO.xm/branches/UKMO/dev_r5518_GO6_package@6533

We are left with:

​fcm:NEMO.xm/branches/UKMO/dev_r5107_xios_initialize_toyoce@5580 ​fcm:NEMO.xm/branches/UKMO/dev_r5107_hadgem3_mct@6355 ​fcm:NEMO.xm/branches/UKMO/dev_r5107_hadgem3_cplseq@5646 ​fcm:NEMO.xm/branches/UKMO/dev_r5107_hadgem3_cplfld@5592

The notable thing about these is that they ALL originate from a pre 3.6 version of the trunk and therefore have been through at least one trunk upgrade rendering it extremely difficult for the non-expert (and indeed for many experts) to identify what the actual relevant changes are as they are hidden by swathes and swathes of trunk updates and svn keyword additions/removals. However, I recognise the names of these branches from NEMO3.4 and earlier and since I was probably responsible for much of the original development I would hope to stand a better chance than most in identifying what each of them does....

Taking these in turn:

We start by creating the initial package branch in which we intend to apply all these changes: ​​svn+ssh://forge.ipsl.jussieu.fr/ipsl/forge/projets/nemo/svn/branches/UKMO/dev_r5518_MO_couple_package

  • ​fcm:NEMO.xm/branches/UKMO/dev_r5107_xios_initialize_toyoce@5580 - The original change was a simple replacement of "oceanx" with "toyoce" on one line. Only AFTER this were the svn keyword removed It has been through 3 further updates which seem to be entire trunk merges or svn keyword removal. This branch could be rendered redundant if the UKMO were to change the name of the ocean model component from toyoce to oceanx, but that is embedded in existing UM control scripts etc and would require various other changes to accommodate it so we retain it for now, but intend to get rid of this once things are switched to using MOCI scripts instead of UM scripts.

Carry out direct changes.... not merges! ​​svn+ssh://forge.ipsl.jussieu.fr/ipsl/forge/projets/nemo/svn/branches/UKMO/dev_r5518_MO_couple_package@6543 refers

  • ​fcm:NEMO.xm/branches/UKMO/dev_r5107_hadgem3_mct@6355 - This was originally simply to introduce CPP controls for OASIS3-MCT and to correct bugs in the buffer sizing and grid definitions of cpl_oasis3.F90. This should really be unnecessary and controllable just by using the standard OASIS CPP keys since NEMO vn3.6 ONLY now deals with OASIS3-MCT! However this branch appears to have been hijacked for other things too including correcting and improving error abort conditions (e.g. getting rid of totally unhelpful STOP statements which have no associated error or other informational message.) This looks such a mess and there seem to be so many trunk and other upgrades making it difficult to see what's relevant that I think I should just make raw changes without attempting merges and if necessary we just employ key_oasis3. svn merge -r rev1:rev2 simply DOES NOT WORK anyway.

When trying to do custom merges of selected revisions. (We'd need to use all sorts of tricks like svn merge (branch) (trunk) (working copy) or specifying subdirectories to avoid svn merge incorrectly picking up irrelevant changes), we run into spurious and imaginary changes which are simply not there! This is thought to be caused by removal of files/sub-directories in the repository consequent to updating the original branch with a trunk merge.... another reason not to do that!

  • ​fcm:NEMO.xm/branches/UKMO/dev_r5107_hadgem3_cplseq@5646 - This is in essence about resequencing the events in the coupling cf. the NEMO base code. Simply merged in two parts all changes from 5479 to 5491 inclusive (i.e. prior to the trunk being merged into the branch) and 5572 to 5646 inclusive (all changes after the trunk merge). Bizarrely svn merge worked ok this time by doing svn merge branch@revision1 branch@revision2. There seem no rhyme or reason to when it works and when it fails or more worryingly when it does something completely erroneous.
  • ​fcm:NEMO.xm/branches/UKMO/dev_r5107_hadgem3_cplfld@5592 - This branch is garbage anyway and needs to be deleted because it contains a complete copy of the trunk within it! This really should have been addressed a long time ago.

OK well we've ground to a halt - we have a package branch which is OK in as much as it runs, but the results are altered. No doubt this is due to nasties occurring during trying to manually unpick all the trunk merges and svn property updates etc.

I think we're better off creating new versions of these branches relative to 3.6 anyway (somebody is going to have to, so it may as well be me!) and then merge these into a package branch.

Getting on with this we now have:

So we should now delete the rancid old versions of these based on r5107 at the first opportunity.

Created package branch: ​http://fcm3/projects/NEMO.xm/browser/branches/UKMO/dev_r5518_GC3_couple_pkg which is a much simpler operation now that we are working with clean branches from the appropriate trunk revision.

Testing this branch versus the original multi-branch configuration we have bit comparison.

So it seems safe to employ this.

We do, however need to keep this package branch under constant review in case of any changes to the component branches. We also must ensure that no development is done directly in the package branch. All developments must be done in separate component branches and merged into the package branch in order to allow them to have a chance of being included in the NEMO trunk code at a (not too distant) future date.

Udate July 2016:

Following discussion with Dan Copsey, Dave Storkey and Malcolm Roberts about NEMO branch management it was decided that the package branch instigated by this ticket will henceforth be the sole NEMO GC3 coupling-specific related branch and that any further changes may be applied directly to this branch rather than needing to maintain separate component branches.

Consequently we have deleted the original component branches (both the r5107 and r5518 versions) since GC3 is now officially configured to use the amalgamated package branch. (The old component branches will obviously still be accessible in svn, via specific revision number should the need arise, however there is no expectation of a need for this.)

So in summary, the package branch contains code to:

1) Change the name of the NEMO component as seen by OASIS to "toyoce" for historical consistency with Met Offic opractices and embedded suite control functionality. The intention is that this will ultimately revert to the NEMO base code name once MO suites and control systems have been adapted suitably. 2) Apply special treatment to incoming coupling surface velocity components to ensure correct and consistent values of components when rotating from geographic orientation to NEMO local orientation.

3) Re-sequence coupling operations in line with MO practice and use of CICE as the ice model of choice

4) Apply improved error handling, replacing use of uninformative STOP statements and similarly unhelpful shut down controls with meaningful messages and use of ctl_stop.

5) Cater for suppression of land points in coupled models by using the optional 4th argument in: CALL oasis_def_partition ( id_part, paral, nerror, jpiglo*jpjglo )