Opened 6 years ago

Closed 6 years ago

#1203 closed help (fixed)

Ozone and methane budgets

Reported by: s1251469 Owned by: luke
Component: UM Model Keywords: ukca,ozone budget
Cc: Platform: ARCHER
UM Version: 7.3



I would like to calculate the ozone and methane budgets and lifetimes from standard run (xfvfd). My job is xjhxd.

I have output the Ox prod, Ox loss, deposition and air mass diagnostics from section 34 UKCA section. Could you tell me what units these reactions and other diagnostics are in? And where I can look up units myself (if possible)?

I have a problem that the output is not correct for the diagnostic which is partly why I don't know the units.
e.g. The O3 dry deposition (34321) in it's output is..
long_name = "Flux through O(1D)S + H2O Rxn"
name = "temp"
units = "degC

Firstly, is this expected? Secondly, do you have any scripts that I can run on pp or a netcdf file to correct to useful names?

Finally, to work out the methane lifetime I need the methane concentration. I can't find this in section 34. I can see mean methane from stochem in section 0. Not sure if this is applicable. Can you tell me where to find it?

Many thanks,

Change History (30)

comment:1 Changed 6 years ago by s1251469

actually it's the methane mixing ratio I want, not concentration.

Last edited 6 years ago by s1251469 (previous) (diff)

comment:2 Changed 6 years ago by luke

Dear Declan,

I would recommend completing Tutorial 9 of the UKCA Tutorials ( as this covers the diagnostics package in depth.

Most diagnostics are in moles/gridcell/s.

The issue with the naming is a mismatch between the STASHmaster_A file read by Xconv and the user-defined one used in your job. To get Xconv to see the correct names please use the PRESM_A file used in one of your /home/n02/n02/s1251469/umui_runs/xjhxd-* directories. You should copy this somewhere else (as these directories can be deleted). You will need to open it in a text editor and then paste in the header and footer from another user-STASHmaster file, e.g.


#|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 |


1|   -1 |   -1 |   -1 |END OF FILE MARK                    |
2|    0 |    0 |    0 |    0 |    0 |    0 |    0 |    0 |    0 |    0 |    0 |
3| 000000000000000000000000000000 | 00000000000000000000 |    0 |
4|    0 |    0 | -99  -99  -99  -99  -30  -99  -99  -99  -99  -99 |
5|    0 |    0 |    0 |    0 |    0 |    0 |    0 |    0 |    0 |

and remove the line at the top giving the number of records. Now load Xconv and click 'Setup' and 'Select STASH master files' to load it in. You might also want to look around the 'Setup Xconv Defaults' options - I like using both long and short names, for example.

Essentially the names in Xconv are not important, what is important is the names in the UM, from your user STASHmaster files.

The STOCHEM methane is something different. The UKCA methane mixing ratio is fixed to be a constant field in this version of UKCA (TropIsop). As such, it cannot be selected in the UMUI STASH panel. This job is using the ~ukca/hand_edits/VN7.3/r1.0/CheM_trgas_presentday_full.ed hand-edit, which sets


This means that the CH4 concetration (mass-mixing ratio) is set from the UMUI panel

 -> Model Selection
   -> Atmosphere
     -> Scientific Parameters and Sections
       -> Spec of trace gases
         -> Gen 2-stream LW rad absorption by CH4 (Methane)

If this logical were set to .FALSE. the value used is set in UKCA_MAIN

        fch4 = 1.76e-6

(this value is in volume-mixing ratio here). You may also find the air mass diagnostic useful, either tropospheric (34361) or whole-atmosphere (34363).


Last edited 6 years ago by luke (previous) (diff)

comment:3 Changed 6 years ago by luke

  • Owner changed from um_support to luke
  • Status changed from new to accepted

comment:4 Changed 6 years ago by s1251469

hello luke,

thanks for the info. I am making some progress on the budgets but I might have to come back to you on it.

As for the xconv names. I have got the long_names read in correctly using the method you described but the var ID in the netcdf output seems to still be set to the incorrect names. Is there some way I can get xconv to set these differently other than manually typing them in every time I archive a new run? Where is it reading them from?

As an aside, is there some where I can learn about the UM versions? What version is the standard tropisop using? HadAm??

and also is there any description of hybrid_ht levels? I don't really understand what they are, I would like to be able to plot vertical profiles on height or pressure levels.

many thanks,

comment:5 Changed 6 years ago by luke

Hi Declan,

The short_name is fixed by the PPFC (pp field code) in the user STASHmaster file, and this can be changed in xconv/convsh by clicking the 'Names' tab on the top-right. However, while these may be a bit strange (e.g. 'field545' etc) they should all be unique and so are still usable.

If you would rather work with proper names then I can suggest downloading and installing something like Iris ( - a python library developed by the Met Office for reading in their data. You can write what is know as a 'call-back' to assign the correct names. Another option could be cf-python ( which is also designed to work with pp files. If you prefer IDL then the Met Office IDL library is available (under license) from . They all perform similar functions, so it is really a matter of personal choice. Xconv is great for a first-look at data, but is quite basic in many respects. You would need to convert data to pp from the native fields-file format, using ff2pp first.

The UKCA release jobs at vn7.3 are based around HadGEM3-A r2.0. An example of work using a similar mode to the release job is which describes the implimentation of a different photolysis scheme than the one used in the release job, but the rest is the same.

Please see the following page for a mathematical description of the hybrid-height vertical coordinate: (you will need to scroll through to about a third of the way down). This coordinate is the same as the absolute height above a certain amount (for the L60 model, I think that this this is 18km (level 30)), and below that the height is actually the height above the orography (i.e. the 20m level is 20m about the sea, or 20m above a mountain etc). Generally speaking, plotting the 'surface' (20m) level is fine, and similarly for vertical profiles you can, for a first look, plot the Hybrid Ht.

You may prefer to interpolate the fields to pressure levels. To do this, you need the 'PRESSURE AT THETA LEVELS AFTER TS' diagnostic (STASH code 0,408). It is relatively straight-forward to then interpolate using log(p). This will create a field with lots of missing data lower down due to the orography.

I hope this helps.


comment:6 Changed 6 years ago by s1251469

That's all good. I've made some progress with the budgets. I'm quite sure I have the correct units now. I just have a few questions:

1) How is the tropopause defined in UKCA? I was initially trying to use the definition used in Stevenson 2006 of <150ppb(O3) but I realise now that the reaction fluxes probably have a tropopheric mask already applied to them.

2) What reactions are included in the minor loss reactions diagnostic (34312)?

3) Stevenson 2006 refers to ozone loss through reactions with alkenes and NOx. I can see a diagnostic for alkenes but not NOx. Is it not considered important?

My P,L,D,STE,burden,lifetime values in Tg or Tg yr-1 using all the diagnostics in UKCA are 5500,4300,1200,-20 (actually model STE is 360), 340, 23days

My values only using diagnostics mentioned in stevenson 2006 are 3800,4100,1100,1500,340,23days

The values for this are ok I think. But the STE (L+D-P) just doesn't seem right. I would appreciate any thoughts on what terms should be included in the budget.

comment:7 Changed 6 years ago by luke

Hi Declan,

Before you continue I would advise you to read-through the UKCA diagnostics tutorial at as this will explain how to add new diagnostics and look through the relevant routines.

  1. The tropopause for the diagnostics is defined as a merging of 2.0PVU and 380K surfaces, and is done in ukca_tropopause.F90. This routine also contains comments that may be useful for you.
  1. The fields that are in the diagnostics are defined in asad_flux_dat.F90. If you scroll down to the definition of 34312 this will give all the reactions.
  1. If you would like to see the output for any reactions not specified, please add them.

The Ox budget provided is on originally defined by Paul Young, and considers production and loss of Ox, not just O3. Any diagnostics provided are ones that UKCA developers have found useful in the past and that we think may be useful for new users, but you are encouraged to add your own diagnostics and not feel hampered by the ones provided.

I would advise you to make your own budget that you are happy with, and also to turn-off the masking of the reaction fluxes. This would mean that you can then use your own ozonopause definition.


comment:8 Changed 6 years ago by s1251469

Hello Luke,

Firstly, apologies for making you repeat yourself regarding the tutorial. I didn't ignore the first suggestion but I hadn't got round to it. I have now completed the tutorial. It has been very helpful.

I am sticking with the budget diagnostics already there but rest assured that I feel comfortable with the idea of adding new diagnostics if I need them.

I am happy with all my budget calculations now. thankyou for your help.

At the suggestion of federico and alex, I would like to switch on the interactive dry deposition. I have done this with the switch. I have also changed from the 2D stashmaster file to the 3d.

However, I am getting output which appear to be correct for the bottom layer but zeros in all layers above. Is there something else I need to do to get this to work?

You can see my output on archer /work/um/xjhxd/archive/

Also, since switching to the 3d stashmaster file I seem not to be able to output OH and HO2 mixing ratios. Why is that?

comment:9 Changed 6 years ago by luke

Looking in your xjhxd job, the monthly-mean stream (UPMEAN) still has these diagnostics output on DIAG, so you will only get 2D fields from this. The diagnostics package should be able to pick-out a 3D field and then output this properly.

Did you take the Wesely scheme branch from Federico? If not you may need to merge in that code, as the vn7.3 release job needs these routines updating. I needed make-up a special job for him because of this. This also could be causing problems.

Can I check if you have merged-in Federico's code (or at least the code I provided to Federico) prior to running your job? If so, I'll take a copy and have a look. If not, can you merge it in and try again. This also counts similarly for the OH/HO2 issue.


comment:10 Changed 6 years ago by s1251469

Hello Luke,

Following your suggestion, I have tried to merge with federico's. However, it is difficult because he has not used fcm commit on his job since copying the standard release so the files that would be merged are only ukca_light ones that I have changed. I have tried just copying over his asad_chem_flux_diags.F90 file but the run fails before it produces output. It does compile though.

I don't think either of us fully understand when fcm commit should be used. Fed feels his code is not ready to be set his code in stone yet so should he avoid using fcm commit?

This allows me to ask. Can one use fcm commit to save different versions and then select them in umui or can you only use the most recent fcm commit version? eg. I was wondering if I should commit a control copy then a copy with a new scheme and switch between the versions. At the moment I am just saving files that I make code changes in and then swapping them in and out of a working copy.

So I guess the main question is, do you have a version that I can merge with to get this interactive deposition working? should the only change need to be in asad_chem_flux_diags.F90?

apologies for the complication.

comment:11 Changed 6 years ago by s1251469

I should perhaps add that I feel ready to settle on a version. I have learnt to calculate and plot several diagnostics of interest. This may be relevant since I can try and implement this interactive scheme in my current configuration but maybe it would be easiest to do it once I have picked my control version.

You had mentioned that it might be best for me to use vn8.4. Is this nearly ready? Presumably it would solve the above problem?

Speaking to Alex Archibald, he has offered me a troposphere only version at vn7.3 that includes a O3+NO2 tag for lightning which would be very useful. I could use that or re-implement it in a later such as vn8.4.

I also wish to incorporate turn on certain cloud ice diagnostics which requires some kind of change to my current configuration.

Firstly, can you offer any advice on this? Secondly, if you think it is wasting my time to implement the interactive scheme in my current version then don't worry about it I can try and find out what model to use first.

many thanks,

comment:12 Changed 6 years ago by luke

Hi Declan,

Please see ticket 1017 for details of the branch and job:

I think that running with Alex's vn7.3 tagged NOx branch may be the best idea in the short term - this model has been well used and we are happy with the results. You may need to take the Wesely scheme changes from the branch mentioned in ticket 1017 if you wanted to include that as well - the code would be the same. While we are progressing with vn8.4 it isn't quite ready yet.

With regards to fcm commit - this can and should be done as frequently as possible. It doesn't matter if the code works or not, but it is a handy method of keeping track of changes. If you don't commit it can easily lead to problems and you can't backtrack.


comment:13 Changed 6 years ago by s1251469

Hi Luke,

My wesely code seems to be working but tempermental. I can get 3d O3 dry dep array with non-zero values above the surface. I initially did this with daily means without a problem. I want to output monthly means though.

If I output daily mean ozone in one stream and monthly mean (3rd timestep only) in another I can get the right kind of output. However, running with the same diagnostic seems to cause errors when I run for a year…(NB/ this is actually for another diagnostic but I seem to remember getting it for dry dep)

ERROR detected in routine STWORK: stop model

: No. of output fields (= 4097 ) exceeds no. of reserved PP headers for unit 60
STASH : Error processing diagnostic section 34 , item 321 , code 4


UM ERROR (Model aborting) :
Routine generating error: UKCA_MAIN1
Error code: 34
Error message:

It seems to me that I am not correctly using the diagnostics but the code is good. Can you offer any education on this matter?

Kind regards,

comment:14 Changed 6 years ago by s1251469

Just to correct myself.

34321 is O3 dry dep so the above error is what happens if I have a TMONMN in stream pb and a TDAYM in stream pa.

comment:15 Changed 6 years ago by luke

Hi Declan,

This isn't actually to do with the diagnostic itself, more to do with the fact that you are outputting too many things to the UPB stream within its re-initialisation period.

Please see the solution to Task 3.1 from the UKCA tutorials, which gives the fix for this.


comment:16 Changed 6 years ago by s1251469

Thankyou Luke,

Are expected that that would fix the confused wesely output? I made a change but it's still only outputting surface. That's without including the additional TDAYM O3 dep output though.

Are you suggesting to keep the TDAYM output and just correct the pb field as in task 3?

I am confused as to why I would need to output the diagnostic twice to get a monthly mean.


comment:17 Changed 6 years ago by luke

Hi Declan,

I'm not sure what you mean by "confused Wesely output".

You state above that you can get non-zero values above the surface layer, so this should be OK to send to a TMONMN (sampled on the 3rd timestep with an off-set of 2 - i.e. UKCA timesteps) assuming that you change the periodic initialisation of your output stream correctly, or send to a different stream.

You need to make sure that your STASHmaster file is set-up for the 3D theta grid - see Tutorial 9:


comment:18 Changed 6 years ago by s1251469

Hi Luke,

Confused wesely output =
1) When I output with TMONMN (on 3rd timestep, offset 2) I only get the bottom layer.
2) following a suggestion of federico, when I output TDMPMUKCA (but mean over 3 dumps) I get all layers.

This has obviously solved my problem. I will use TDMPMUKCA. Do you see any problem with that?

I have no idea why TMONMN won't work. It works for all the other budget reaction fluxes.

Many thanks,

comment:19 Changed 6 years ago by luke

Hi Declan,

Can you give me the jobid of this job?


comment:20 Changed 6 years ago by s1251469

The job is xjhxf

pb is my main output stream

time domains used:
TMONMN_L is a copy of TMONMN but with UKCA timespteps (used for reaction fluxes)
TDPMONM is a copy of TDPMUKCA but averaging over 3 dump periods (used for O3/NOy dry dep)


comment:21 Changed 6 years ago by luke

Hi Declan,

I'm guessing it's 34321 that you are trying to output. You should make sure that you use DALLTH rather than DIAG to output it. You also shouldn't send things outputted over dump periods to any stream other than the UPMEAN stream (sending it to UPB may give you very strange numbers). As far as I can see your TMONMN_L is fine - the levels are determined by the domain profile, so try using DALLTH.


comment:22 Changed 6 years ago by s1251469

Hi luke,

Yep 34321.

I have been using DALLTH the whole time.

Federico also gave up using TMONMN which is why he's using the dump averages. He has done a test where he output a month of TDAYM and also using TDPMONM and the dump averaging gives the correct values.

I'm quite unsure what to do. This is wasting a lot of my time when it's not of any great concern to me what the deposition is. I have two options at the moment as I see it:
1) use TDPMONM with the interactive scheme
2) use TMONMN with the interactive scheme turned off

Which would you suggest?


comment:23 Changed 6 years ago by luke

Hi Declan,

I would suggest sending everything to UPMEAN if you can, and having a TDMNUKCA profile which is a copy of TDMPMN but samples as UKCA timesteps. I usually only send stuff to another stream if I have to, or if I need daily/hourly output etc.

I'll try running your job and seeing if I can replicate the problem.


comment:24 Changed 6 years ago by s1251469

Oh ok. I wasnt aware that was best practice.

I have a stupid question then. Where is the UPMEAN output? In the directory above archive? Is it called …da…?


comment:25 Changed 6 years ago by luke

UPMEAN send things to climate-meaning, so you will have .pm (monthly), .ps (seasonal), .py (annual), and .px (decadal) files existing in your archive folder (if you are archiving). This is controlled under the 'post-processing, dumping, and meaning' panel. This is where most UKCA diagnostics in the base job you took were being sent.

As I said, UPMEAN should only be used with a variation of TDMPMN - and TDMPMN should not be used with another stream.

See UKCA Tutorial 3:


comment:26 Changed 6 years ago by s1251469

Thanks. I will adjust things to work in that way then.

Is it ok to delete the diagnostics that were already in the UPMEAN stream from the standard release job? I was a little nervous about just getting rid as I wasn't sure if they were used for anything.

I don't really want to archive more than is necessary.


comment:27 Changed 6 years ago by luke

Hi Declan,

If you like, you can remove all the fields in STASH and the model will still run - it will be a bit of a waste though… (but a handy check that everything works!).

I would advise keeping the standard output in, as this is useful for comparing things. While at the moment you are only interested in one or two things, you never know what you might wish you had included later on! Unless space is a really big issue, I wouldn't remove too much.

You can convert the 64-bit fieldsfiles that come out of the UM to 32-bit pp format using the ff2pp command. I have written a script which can do this and be submitted to the serial queue. See /work/n02/n02/luke/src/makepp .


comment:28 Changed 6 years ago by luke

Hi Declan,

Please see my job xjmkf. As far as I can see, this is outputting 34321 to the UPB stream using TMONMN_L and DALLTH, and has values which are not just in the lowest model level. Please look at my output in /work/n02/n02/luke/um/xjmkf/archive to see if this is as you would expect/want.

The easiest way to check differences in STASH is to open the main STASH window and go to Diagnostics → Output table to file in each job, and then use xxdiff to view the differences.

If you are happy that this issue is resolved, please let me know so I can close this ticket - you can then open a new ticket for any new issues. I am currently still looking into the N96L63 tagged NOx job, but this is rather complicated and I will contact you about that separately.


comment:29 Changed 6 years ago by s1251469

Yep. Your output looks good. Thankyou for your help.

I am switching to using UPMEAN as you suggested and I have 3D dry dep working with TDPMUKCA. I just need to get through a run to check my yearly values.

This issue is resolved. As is the hector one you shut. Thankyou.

I am happy with the release job now and I can do all my testing satisfactorily as long as I get a good value for deposition. Then hopefully it won't be too hard to switch it to something else. Most of my work is just in ukca_light.

As I said before, it would be nice to use Alex tagged Lightning Ox but if you have another N96 job on ARCHER that you think it would be easier to go with then I am open to that.


comment:30 Changed 6 years ago by luke

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.