GA4.0 testcases

The Met Office GA4.0 configuration is a standard release of the code. See Walters et al, The Met Office Unified Model Global Atmosphere 4.0 and JULES Global Land 4.0 configurations, Geosci. Model Dev. Discuss., 6, 2813-2881, 2013

The configuration here is based on the vn8.2 code with GA4.0 patches for both the UM and JULES.

The local branch includes several fixes needed to make the code work in our environment (mainly backported from later UM releases).

UMUI experiment uahg contains original Met Office basis files and local build and run jobs.

uahga and uahgc are from the original Met Office basis files, with climatological dust and interactive dust respectively. Met Office jobs were amcha and amchc, documented at (Met Office wiki login required).

  • uahgd is a local build job
  • uahge is a local run job (climatological dust) with resolution N96 L85. Note that this still uses the 360 day calendar of the Met Office job.

Ancillary and input files

The job uses ancillary files from raijin:~access/data/ancil/HG3A31/. The ancillary files and directories are set using environment variables rather than explicit paths. These environment variables are set in the files ancil_dirs and ancil_filenames from the directory ~access/AccessModelExperimentLibrary/GA4.0/ancil (set in the "in file related options" section of the UMUI)

The sample job uses an L85 initial condition created by Greg Roff from ERA data, ~access/AccessModelExperimentLibrary/GA4.0/data/emoses1982010100mlL85.


The job uses hand-edit files (on accesscollab) from the standard Met Office GA4.0 configuration.


Run environment

The example job is set to run with 64 cores where a one month run takes about 5000 s. The job time and memory limits are set appropriately for this. The job uses executables from ~access/AccessModelExperimentLibrary/GA4.0/bin and other scripts from $UMDIR/vn8.2/normal/runscripts.

Note that in this version of the UMUI is not completely adapted to the local environment. The job time is taken from the time limit for resubmission, whether or not resubmission is used.

The memory per core can only be set in the LoadLeveler section of the Submit Method panel, which is not normally selected. The example job sets the memory limit at 1 GB/core. This is sufficient on 32 cores or more but likely not on 16, so if you need to run on only 16 for some reason you'll have to reset this to 2GB/core.

The job should be runnable by anyone with no changes.

Last modified 4 years ago Last modified on Oct 10, 2014 2:26:43 PM

Attachments (1)

Download all attachments as: .zip