Difference between revisions of "UKCA & UMUI Tutorial 3"
Line 40: | Line 40: | ||
[[Image:UMUI_DumpMean_Main.png|thumb|300px|right|Figure 2: The dumping and meaning main UMUI panel.]] |
[[Image:UMUI_DumpMean_Main.png|thumb|300px|right|Figure 2: The dumping and meaning main UMUI panel.]] |
||
[[Image:UMUI_DumpMean_NEXT.png|thumb|300px|right|Figure 2: The dumping and meaning follow-on UMUI panel.]] |
[[Image:UMUI_DumpMean_NEXT.png|thumb|300px|right|Figure 2: The dumping and meaning follow-on UMUI panel.]] |
||
+ | Climate meaning is controlled in the same panel where the restart dump frequency is set: ''Model Selection → Atmosphere → Control → Post processing, Dumping & Meaning''. The main panel is shown in Figure 2. In this example, as is standard for all climate jobs, restart dumps are created every 10 days, and this example as these dumps archived every 9 files, starting with the 9th file after the job is started, i.e. every 3 months (to save space you may choose to change this to 1 year or every 36 files). All other dumps are deleted after they are no longer needed. This means that if the model crashes and needs to be restarted, you will at most have lost 10 days of run. '''Note:''' while the model will bit compare on restarting from an old dump, this will not be the case if the dump frequency is changed. |
||
+ | |||
+ | This panel has selected ''regular frequency dumps with possible meaning sequence'' so '''climate meaning''' is possible. To do this, you must specify a date for the meaning sequence. '''Note:''' you should be careful about this choice of date, especially if you are changing the start-date of the run. It is advised that this meaning squence date is set to be on or before your start date. If it is not you will not generate some of the climate mean files. |
||
+ | |||
+ | The follow-on window from this panel (shown in Figure 3) gives more details about how climate meaning works. These files work on multiples of the dump period, so the first climate mean file created will be a multiple of 3 dump periods (i.e. 3x10 days, or 30 days. Since we are running a 360-day calendar, this is 1 model month) which is the '''pm''' monthly-mean file, which we considered when [[UKCA & UMUI Tutorial 2 | running existing UKCA Job]]. The second climate-mean file is a multiple of 3 of the monthly-mean files (i.e. 3x30 days, or 90 days, which is a season), the '''ps''' seasonal-mean file (the meaning date is important here to get the correct 3 months for each season). The third climate-mean file is a multiple of 4 of the seasonal-mean files (i.e. 3x90 days, or 360 days, a year), the '''pa''' annual-mean file. The final file created is a multiple of 10 of the annual-mean files - a decadal-mean '''px''' file. |
||
+ | |||
+ | The fields outputted to each of these pm, ps, pa, or px file is the same, and in the same order. All that is different is the meaning done to each field. '''Note:''' if you change the dump frequency you will change the frequency of creation of these climate-mean files. In this instance you would need to change the multiple for the first file to get a monthly-mean file correctly. |
Revision as of 14:03, 11 June 2013
What is STASH?
STASH is the Unified Model's storage handling and diagnostic system. It is designed to cope with the many different configurations that the UM can be used in, but still provide output in a consistent and standard way.
Prognostic and Diagnostic Fields
The UM considers variables (or fields) to be of two different types, prognostic or diagnostic. Prognostic fields are ones which the model must have values for, prior to each timestep, as the equations of motion the model solves require these fields (these are fields such as specific humidity or potential temperature) so they must exist in the model start dump. Diagnostic fields are all other fields that are derrived from prognostic ones, and as such the model does not need to have prior values for these. Ancillary files (such as emissions, SSTs etc) contain prognostic fields.
From a user's perspective, STASH is used to output fields during the run, and from this point of view it does not matter if these are prognostic or diagnostic fields. However, you will need to consider these differences when you add new chemical tracers.
STASH Sections and Items
Each field that is considered by STASH has a unique address which is given by a section and an item number. Prognostic fields are mostly held in section 0 (with the exception of tracers) and diagnostics are organised by areas of the code, e.g. short-wave radiation diagnostics are held in section 1, long-wave radiation diagnostics are held in section 2 etc. Some sections will always be on, and some sections will only be on if a certain process is selected, e.g. the interactive land-surface scheme. Each section can hold up to 512 items, where each item is a separate prognostic or diagnostic field, and can be either 2D or 3D.
Each field has its own entry in a STASHmaster file. There is a master list of fields which is held in the STASHmaster_A file, which is located at
/projects/um1/vn8.2/ctldata/STASHmaster/STASHmaster_A
on MONSooN, and at
/work/n02/n02/hum/vn8.2/ctldata/STASHmaster/STASHmaster_A
on HECToR. This is also a handy list of all the fields that can be outputted from the model, which is easier to search than by going through the UMUI panels.
Output Files
Before we cover outputting diagnostics from the UMUI STASH panel, we will first cover the different output fields files that are produced by the UM. Output from STASH is sent to different output streams, and there are two types of files used by these streams: standard PP files and climate mean files.
Standard PP files
In your UMUI job, go to Model Selection → Post Processing → Initialization and processing of mean and standard PP files. As well as choosing the packing profile (see the Help button for more information) this panel also describes how these different files are treated. As can be seen in Figure 1, there are 11 PP files defined, PP0 to PP10, which correspond to designators pa to pk (with units 60-69, and 151 - these unit numbers may be important in warning and error messages).
The table in this panel can be used to set various properties of these files, such as the time period the file covers, and whether or not the file is archived (i.e. either to the archive/ sub-directory or RDF facility on HECToR, or two the /nerc disk or MOOSE on MONSooN). Being able to change the time period is very useful - while for many simulations monthly mean files are preferred (see the discussion about climate meaning below), often you may wish to output higher frequency data, e.g. 6-hourly. These PP files are limited to a finite size and so outputting a month of 6-hourly data may cause the model to crash at run-time. The solution to this is to change how frequently the files are generated, e.g. you could output daily files instead of monthly ones.
Climate Mean files
Climate meaning is controlled in the same panel where the restart dump frequency is set: Model Selection → Atmosphere → Control → Post processing, Dumping & Meaning. The main panel is shown in Figure 2. In this example, as is standard for all climate jobs, restart dumps are created every 10 days, and this example as these dumps archived every 9 files, starting with the 9th file after the job is started, i.e. every 3 months (to save space you may choose to change this to 1 year or every 36 files). All other dumps are deleted after they are no longer needed. This means that if the model crashes and needs to be restarted, you will at most have lost 10 days of run. Note: while the model will bit compare on restarting from an old dump, this will not be the case if the dump frequency is changed.
This panel has selected regular frequency dumps with possible meaning sequence so climate meaning is possible. To do this, you must specify a date for the meaning sequence. Note: you should be careful about this choice of date, especially if you are changing the start-date of the run. It is advised that this meaning squence date is set to be on or before your start date. If it is not you will not generate some of the climate mean files.
The follow-on window from this panel (shown in Figure 3) gives more details about how climate meaning works. These files work on multiples of the dump period, so the first climate mean file created will be a multiple of 3 dump periods (i.e. 3x10 days, or 30 days. Since we are running a 360-day calendar, this is 1 model month) which is the pm monthly-mean file, which we considered when running existing UKCA Job. The second climate-mean file is a multiple of 3 of the monthly-mean files (i.e. 3x30 days, or 90 days, which is a season), the ps seasonal-mean file (the meaning date is important here to get the correct 3 months for each season). The third climate-mean file is a multiple of 4 of the seasonal-mean files (i.e. 3x90 days, or 360 days, a year), the pa annual-mean file. The final file created is a multiple of 10 of the annual-mean files - a decadal-mean px file.
The fields outputted to each of these pm, ps, pa, or px file is the same, and in the same order. All that is different is the meaning done to each field. Note: if you change the dump frequency you will change the frequency of creation of these climate-mean files. In this instance you would need to change the multiple for the first file to get a monthly-mean file correctly.