Nesting Suite

Configuration Information

Rose Job
rosie copy u-aa753
Release Type
Technical - The model is confirmed to run at NCI for any ACCESS user, but results have not been checked for validity
Test Status
Email if experiencing technical difficulties running the suite.


Describe the configuration, who created it and who would find it useful

The Nesting Suite enables one-way nesting from within a UM experiment, creating a series of nested limited area domains that pass boundary conditions from lower resolution to higher resolution.

Users of the suite can specify their own nesting domains, and can seed the run from either a global model run or from existing output files. The suite is designed as a generic framework, so specific science settings are up to the user and can for example be imported from a GA job.

Originally developed by Stu Webster at the Met Office, ported to NCI by Scott Wales. This is the development suite and will change as new features are added, for a full list of changes see the changelog or roses-u trac ticket 52. The suite is automatically tested at NCI whenever a change is made - see Test Status above for the latest result.

More information:

Run Instructions

Describe how to run the model at NCI

The nesting suite requires metadata to be created for each nested region before it can be configured. To specify the maximum number of nests to use:

cd bin
  • REGIONS is the number of nested groups being run from the driving model
  • RESOLUTIONS is the number of nests within each region
  • CONFIGS allows simultaneous science settions, processor decomposition or timestepping to be run for the same domain for comparison purposes.

For information on how to set up the domains see the Nesting Suite presentation from the ACCESS workshop: NestingSuite.pptx

In rose edit go to jinja2:suite.rc- > General Run Options and set SITE to NCI to use Raijin's PBS configuration.

The model can be configured to run from either a global model or from archived output files. Running from a global model is recommended at NCI, to configure this go to jinja2:suite.rc -> Driving Model Setup and select RUN_MODE = Re-run from analyses on disk. Set dm_ic_file to the initial conditions being used. Also in jinja2:suite.rc -> Cycling Options set INITIAL_CYCLE_POINT and FINAL_CYCLE_POINT to the same date as the input file, failing to do this will cause errors in the lateral boundary condition generation.

The suite uses its own date handling, so both CYCLE_POINT values should be the same. To specify the run length go to jinja2:suite.rc -> Nested Region I Setup and set rgI_runlen. If multiple regions are in use the global model will run for the maximum run length of all regions.

The configuration settings used for testing can be found in the file opt/rose-suite-nci-test.conf.


Model versions and resolutions

Describe the component model versions used and their configurations


UM 10.3 with user-selectable science configuration. Users can specify the configuration for each nest with jinja2:suite.rc -> Nested Region I -> Resolution J -> Config K setup: rgI_rsJ_mK_config, which has options including ga6, ukv and singv. These act as overrides, and are combined with the settings in the um Rose App.

Sea Ice
Land Surface

Jules 10.3, see Atmosphere for how to specify the configuration


Input Data

Where are the input files used by the model, and are they accessible to all ACCESS users?

  • Global model ancillaries are from TIDS
  • Limited area ancillaries are generated using CAP

For testing purposes the model runs from an initial conditions file in TIDS, however users of the suite need to replace this with their own initial conditions in production runs with the correct start date and resolution.

Output Data

Where does the model put its output, and how much does it generate?

Model output is placed in /short/$PROJECT/$USER/cylc-run/$RUNID:

  • Ancillary files for each domain are in share/data/ancils
  • Forecast output and boundary conditions for each domain are under share/cycle/$TIMESTAMP

Instructions for Testing

How should this model be modified for testing? Tests should require minimal resources but still show the model's full behaviour - e.g. how do you reduce the run length to 2 cycles

A trivial test of a 50x50 grid inside a N216 global model can be run with

rose suite-run -O nci-test


How does the model perform on the NCI systems? Units should be modified as appropriate, e.g. per model hour for NWP runs

Performance of the model will vary depending on the selected domains and their resolutions, and should be tested when developing a new configuration

How to Cite

How should users of the configuration cite this work?

Last modified 4 years ago Last modified on May 6, 2016 11:26:14 AM