Running a UM job - NCAS Computational Modelling Services

Report
NCAS
Unified Model Introduction
Part 1b: Running the UM
University of Reading, 3-5 December 2014
Contents
• The UM User Interface (UMUI)
• Running a UM job
• UM output
2
UM User Interface
• The UMUI is a graphical window-based interface to the UM.
• It is available via the PUMA service, which provides:
– All the latest UMUI changes
– Centralised access to local files (hand-edits etc)
– A common job database for all academic and MONSooN users
• The UMUI allows users to select the code version, scientific
configuration and run-time options.
• The UMUI then creates the scripts which control the UM run.
– Further changes to these scripts can be made via hand-edits.
• It also assigns values to namelists that are read in by the UM at
runtime.
3
Creating a UM job
• Choose a UM job from UKMO, NCAS or a colleague that is close to
what you wish to run.
– Either copy the job into your own job if they are in the same
local database,
– or upload (import) a basis file (the full description of a UM job which
has come from another UMUI database) into your own job.
• NCAS standard jobs should be available under the umui owner.
• Basis files can be downloaded (exported) from the UMUI and
emailed.
– Note that additional UMUI files (hand-edits, STASHmasters etc) and
data files may also need to be copied to the target system.
4
UMUI vocabulary
Experiments: e.g. xxab
• A grouping of UM jobs
• Identified by a description in the UMUI
• Only your experiments are displayed by the UMUI, unless otherwise
requested
• Experiments can be created, copied and deleted
Jobs: e.g. xxabc
• Up to 26 jobs can be grouped in an experiment
• Jobs can be created, copied and deleted
• 2 jobs can be differenced (if using the same UM version)
Within a job:
Navigation window > input windows
(Note that these can very between UM versions.)
5
6
How UM jobs are defined
UM jobs are defined by:
• A UM version (e.g. vn8.2)
• Specific UMUI settings (and hand-edits which alter these)
• A particular horizontal and vertical resolution
• A list of changes to the main code base, in the form of FCM
branches.
• A defined set of input files: start files, ancillary files and lateral
boundary conditions.
Modelling systems such as HadGEM3 or UKV span different UM
versions and have specific “standard jobs” as they develop over time.
7
• The UM User Interface (UMUI)
• Running a UM job
• UM output
8
Submitting a job
The UM uses namelists for setting parameters at runtime; these are
set in the UMUI.
PUMA
HPC (MONSooN/Archer)
UMUI
process
scripts
namelists
code
submit
UM run
What do you need to know about the system where the UM is
installed?
• directory structure and disk space setup
• job submission mechanism and queue structures
• input files available e.g. start files, ancillary files
9
Stage 1: Compilation
The compilation is handled by the Flexible Configuration Management
(FCM) system which:
•
•
•
•
manages code components;
creates Makefiles for compilation and loading;
compiles and links the code according to options selected;
creates an executable.
UMUI settings:
Compilation and Run Options -> Compile and run options for
Atmosphere and Reconfiguration
–
–
–
–
“Compile Model executable”
“Run the model”
“Directory for the Model executable” : Usually $DATAW/bin
“Filename for the Model executable” : Often $RUNID.exe
10
Stage 2: Reconfiguration
The reconfiguration is a stand-alone program which modifies UM
atmosphere start files (and ocean files for UM 6.6.3 and earlier).
• Compiled with FCM
• Runs as a parallel application
• Produces a new start file
UMUI settings:
Compilation and Run Options -> Compile and run options for
Atmosphere and Reconfiguration
–
–
–
–
“Compile Reconfiguration executable”
“Run the reconfiguration”
“Directory for the Reconfiguration executable” : Usually $DATAW/bin
“Filename for the Reconfiguration executable” : Often qxreconf
11
Stage 3: Running
UMUI settings:
Input/Output Control and Resources -> Start Date and Run Length
Options
– “Specify the date and time of the start dumps”
– “Target run length”
For a given run length, the number of processors and length of time to
request depend on the queue structure of the machine and the
performance of the job.
12
Stage 3: Running
User Information and Submit Method -> Job submission method
– “Define submission method”
• ‘qsub’ for PBS Pro : Cray XC30 (Archer)
• Loadleveler : IBMs (MONSooN)
• Linux ‘at’ : Local PCs and workstation
– “Number of processes for ATMOS East-West”
– “Number of processes for ATMOS North-South”
User Information and Submit Method -> Job submission method ->
Qsub
– “Job time limit”
13
• The UM User Interface (UMUI)
• Running a UM job
• UM output
14
STASH
Spatial and Temporal Averaging and Storage Handling
1) Select diagnostic from Load New Diagnostic section
2) Time profile
when diagnostic will be output
(start and end time and frequency)
whether time processing required
(accumulation, mean, time series)
3) Domain profile
vertical
(specify which levels)
horizontal
(limited area, meaning [zonal, vertical,
meridional, horizontal], weighting)
4) Usage profile
select output unit for the diagnostic
15
16
STASH in the UMUI
• The UMUI windows for STASH are different from model windows.
• Diagnostics -> load new diagnostics -> (double click on the section)
• Available diagnostics are organised in sections. Some diagnostics
have HELP information, a lot don’t!
• Just because a diagnostic is available doesn’t mean it
works!
17
Package switched off
Package switched on
Verify diagnostics (Ctrl+V)
18
STASHmaster file
Contains information on all the atmosphere diagnostics available
H1| SUBMODEL_NUMBER=1
H2| SUBMODEL_NAME=ATMOS
H3| UM_VERSION=8.4
#
#|Model |Sectn | Item |Name
|
#|Space |Point | Time | Grid |LevelT|LevelF|LevelL|PseudT|PseudF|PseudL|LevCom|
#| Option Codes
| Version Mask
| Halo |
#|DataT |DumpP | PC1 PC2 PC3 PC4 PC5 PC6 PC7 PC8 PC9 PCA |
#|Rotate| PPF | USER | LBVC | BLEV | TLEV |RBLEVV| CFLL | CFFF |
#
#===============================================================================
#
1|
1 |
0 |
2 |U COMPNT OF WIND AFTER TIMESTEP
|
2|
2 |
0 |
1 |
18 |
1 |
1 |
2 |
0 |
0 |
0 |
0 |
3| 000000000000010000000000000000 | 00000000000000000001 |
1 |
4|
1 |
2 | -3
-3
-3
-3 -12
20 -99 -99 -99 -99 |
5|
0 |
56 |
0 |
65 |
0 |
0 |
0 |
0 |
5 |
#
On puma: /home/umui/umui/umui2.0/<vnX.Y>/variables/STASH_master_A
19
Adding new diagnostics
Users can add new diagnostics
• Advice via the CMS website (STASH user guide)
• Users must provide a STASHmaster file to the UMUI:
Atmosphere -> STASH -> User-STASHmaster files.
Users can copy the diagnostics settings from one UM job to another
using:
copy_stash
• This script takes as input two UM basis files.
• The two jobs must be at the same UM version.
20
UM output listing
Text output from the UM is written to a .leave file:
• e.g. xagmc000.xagmc.o98342.t14136.leave
• Stored in: $HOME/output
Output listing options controlled by UMUI
Input/Output Control and Resources -> Output Choices
The output listing can be quite large and confusing.
Check output listing for
• Timings reported at the end of the listing file
• Key words like ERROR, ABORT, "file not found"
Check presence of key files such as:
• executable after compilation
• start file after reconfiguration
• output files after model run
21

similar documents