Generating Monthly Averaged Diurnal Cycles

Unified Model
1

We’re running version 12 of the UM, in a nesting suite configuration, and want to reduce the volume of data we are outputting from the model - so I’ve a couple of questions about the model output:

  1. We are currently running 6-hour CRUN intervals - I assume accumulated variables (for daily averages, etc) will be carried across in the stash’s created for initialising these?

  2. Is it possible to generate monthly averaged diurnal cycles directly within the UM while it is running, rather than generating these afterwards from the model output?

2

Hi Doug

I’m not sure what you mean in (1). Very probably for (2) - have a look in/home/grenville/roses/u-cm829 the TMONNM[00-21] profiles are what you need (I think)

Grenville

3

hi Grenville,

Q1 is probably irrelevant (I’m just not quite clear how the restart process works for each cycle).

Your answer to Q2 is exactly what I was looking for. But it has now reminded me that real months are not a fixed length, and we are planning to run for 10 years, so we could end up with a rather large mismatch between these periods and the actual months. Can we reset the time period at the start of each year?

4

Doug

data that’s needed for meaning over longer times than the cycle time is held in the dump, it gives the expected results.
You’re running for 10 Gregorian years?

Grenville

5

Grenville,

Great - thanks for clarifying the situation with sample periods and dumps.

We are intending to run for 10 Gregorian years - using ERA5 data to drive the simulation, so I believe we will need to stick to real dates.

6

Actually - I think this has already been covered - as my suite (u-cr573) has a ‘Real Month’ option for diagnostic output times. I’ll try this, and see if it gives the desired output.

7

It turns out that the ‘Real Month’ output schedule option only works for climate simulations (with ‘lclimrealyr’ set to True). I’ve not managed to get this option to work for my LAM simulation - switching it on leads to a new error from ADD_ROUTINE_TO_DATE routine, which can be solved by setting ‘model_basis_time’ in ‘Run Control and Time Settings’, but this leads to a new error in the 2nd CRUN, where the ‘model_basis_time’ and ‘fixhd validity time’ now mismatch (with the recommended solution being to unset ‘model_basis_time’ again).

Rather than try to get two disparate time control systems to communicate properly, I will abandon trying to get ‘Real Month’ timings to work for now.

8

Hi Doug

Sorry that didn’t work, thanks for letting us know

Grenville