Details of Managing SVN repositories for ACCESS

Source Data Management for NWP the top page for NWP Source Code and Input Data Management

ACCESS SVN Repository Management

This page describes the issues and practices of managing the repositories for OPS+ODB, VAR, UM, SURF, NWP and the cylc scheduler/ROSE repository

Run scripts and utilities will be held under the NWP repository


  1. Met Office release patches for new versions
  2. Apply patch to existing repository, updating svn:trunk/src
  3. Apply local modifications for use on our machines

svn cp trunk/src branches/dev/vnxxx/local_changes/src

  1. users apply further developments

svn cp branches/dev/vnxxx/local_changes/src branches/dev/user/vnxxx/src

  1. Merge these branches back to branches/dev/vnxxx/local_changes/src as needed

(May also accept updates from branches/dev/vnxxx/local_changes/src to user's branch during this process)

  1. Tag repositories. To access these versions

svn cp tags/aps2_vnxxx_nnn
All repositories should have this tag


  • The trunk contains a history of Met Office patches
  • The version that developers branch off is


  • NMOC will use the tagged versions
  • Run scripts will be under

svn:nwp/branches/dev/aps2/scripts/${model} where ${model} is g, r, tc, srep, um, ...

  • Various utilities will be under

svn:nwp/branches/dev/aps2/utils/${util}''[[BR]] where ${util} is mars, verify, um2grb, umdump, odb, .....

  • To use a utility, use: module load
  • To use a library:

check out source code and then
make install to put them under ~access/apps

  • Various other scripts (such as thiose under ${CAWCR_SHARE}/scripts will be under


  • Tables of various utilities (um2grb??) will be under

svn:nwp/branches/dev/aps2/data''[[BR]] Should this be ..../tables?


  • Locations of executables and scripts are defined in the suite's environment file envfile
  • Run scripts: ${NWP_SHARE}/APS2/scripts/${model}
  • Executables: ${NWP_SHARE}/APS2/bin/${model} along with a README file
  • Building executables: OPS, VAR & SURF:

svn co branches/dev/vnxxx/local_changes/src
Run script: build_ops / build_var / build_surf
copy build / bin to ${NWP_SHARE}/APS2/bin/ops (or var , surf )

  • Building executables: UM

UMUI jobs umefa copy bin directory to ${NWP_SHARE}/APS2/bin/um

  • Suite Components on ngamai :

${NWP_SHARE} = ~access/nwpdir/share
OPS : ${NWP_SHARE}/APS2/OPS/components/Ops_OperComps_gl/v3 for OPS30
VAR : ${NWP_SHARE}/APS2/VAR/components/Var_OperComps_gl/v1
UM : ${NWP_SHARE}/APS2/um/components/N512/v1

  • Suite Components on raijin :

OPS / VAR / SURF : configured with rose
UM : ${NWP_SHARE}/APS2/um/components/N512/v1

  • Suite Control Data:
    • OPS / VAR (as from Met Office)
      • ${NWP_SHARE}/APS2/OPS/control
        • Elements, Scatwind_coeffs, Satwind_namelists,Sonde_coeffs, StationLists
      • ${NWP_SHARE}/APS2/Data
        • GroundGPS_biases, RTTOV7_coeffs, SatRad_biases, SatRad_coeffs, GPSRO_coeffs
      • ${NWP_SHARE}/APS2/Other
        • Covariance files
    • UM
      • ${UMDIR}/vn8.2/ctldata


QUESTION: How should external packages for OPS and VAR be handled

  • Under svn, which is updated for each release. This would be referenced from the build OR
  • Kept under ~/access/opdir and vardir and used in the build. This is what we do now

[PJS - My preference would be the first option. More in keeping with ISS software storage]

QUESTION: Should ODB be in its own repository or part of OPS?

  • Will have some post processing routines that will need to access ODB libraries
    • i.e. OPS is not the only software that will use the ODB
  • Otherwise whatever is easiest

QUESTION: What do we do about ${CAWCR_SHARE}/bin?

Last modified 5 years ago Last modified on Oct 20, 2016 2:16:48 PM