Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#1416 closed help (answered)

problem with duplicated variables in dumps from UKCA run

Reported by: s1251469 Owned by: luke
Component: UM Model Keywords: ukca
Cc: Platform: ARCHER
UM Version: 8.4



I am running UKCA vn8.4 and outputting tropospheric Ox budget diagnostics.

I have run 2 jobs which are almost identical (xkleg and xkria). The latter of these has started outputting the chemistry fluxes twice in the dump: once, on the UKCA timestep, and once on the model timestep. This causes problems in the climate meaning files as it seems to then put both in the same variable i.e. the number of vertical levels doubles with the lower set being the correct UKCA timestep fluxes and the upper set being the incorrect model timestep fluxes.

The start dumps are different but neither start dump has duplicated OX budget diagnostics. My branch is the same in both runs. The only branch that I see could have changed is the ncas branch but looking at the log it has not been edited since july 2013. both of my runs have been made in the last couple of months. The STASH diagnostics for the OX budget are the same with the same domains.

In xkria I turned on coupling of chemistry to the radiation scheme but I have also done a run (xkrix) without coupling and the same problem arose. I have altered which climate means are archived in xkrix - I don't see why this should matter.

Output from the jobs are at /home/n02/n02/s1251469/rdf/

Perhaps someone could explain to me how the dump output is determined?

many thanks,

Change History (11)

comment:1 Changed 6 years ago by luke

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

Hi Declan,

I don't have permission to see your


directory. Could you change the permissions so that I can see the output?


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

comment:2 Changed 6 years ago by s1251469


comment:3 Changed 6 years ago by s1251469

both of those jobs are before the bugfix by the way. xkrix is my job without the bug. The problem persists with that despite a different startdump and turning off reconfiguration as you said.

I have pointed to these two jobs because they are least different and have no code changes from me.

comment:4 Changed 6 years ago by s1251469

I have done a three month run and allowed all climate means to be archived.

Unsurprisingly though this did not solve the problem

comment:5 Changed 6 years ago by luke

Hi Declan,

I think the problem here is caused by a hand-edit which is used to turn on diagnostics for the UKCA evaluation suite. I'm sorry for the confusion caused by this.

This hand-edit can be found here:


If you look at this, you can see that these diagnostics are already on. By requesting them again you will have two copies of each diagnostics in the output files.

Fieldsfiles/pp-files store data in 2D slices - not as a 3D field. The 3D nature of the field is determined by Xconv when it reads through the 2D slice's header information a works out that the STASH code is the same but the level is different. In this case, the hybrid_ht field goes from 20m to 85km twice.

It does cause confusion though. The solution here is to either turn off the hand-edit (I would make sure all diagnostics you have not manually added are also included in the STASH panel in this case) or remove the duplicated items from the STASH panel.

If you go to


you can see output from my base job to check what STASH items have been included.

Can you give one of these a go and then give it a try?

Also, you should cease using any jobs that do not make use of the polar-row bugfix ASAP.


comment:6 Changed 6 years ago by s1251469

Hi Luke,

I turned off the hand edit and that worked.


comment:7 Changed 6 years ago by s1251469

Hey Luke,

Two further diagnostic problems…

1) I'm not sure if the NO2 mmr (34153) diagnostic is working quite right. I have created diagnostics to output tropospheric NO and NO2 following the tropO3 diagnostic. The tropNO (34355) matches the NO whole atmosphere diagnostic (34002) but with the troposphere clearly removed. However, my tropNO2 (34356) doesnt match the 34153 diagnostic. The tropNO2 follows more what I would expect by having a surface peak over china, however, I'm not too experienced with what the field should look like. Could you take a look at my output to make sure there isn't a problem with the NO2 mmr?

My job is xkriw
A days instantaneous hourly output is at /home/n02/n02/s1251469/work/xkriw/xkriwa.pc19991201
The NO2 field is for some reason called BrO. That'll make sense if you look in the umui STASH. This maybe suggests there is a problem with the STASHmaster file?
This run is with the handedit discussed above turned off but my output for /home/n02/n02/s1251469/work/xkrix/archive/xkrixa.ps2000djf looks like its giving a similar NO2 field and is still being called BrO in the output.

2) I have tried to output some extra lightning diagnostics (34387-34390) copying the approach for outputting the CG and IC flashes etc. This kind of worked in that something is output, however, the monthly means end up underestimated because it gives zero whenever there isnt lightning. For instance I have tried to output the height of the 440hPa level. My hourly fields show this to be ~6km where there is lightning but zero elsewhere. Obviously this is not the case. Clearly by copying the approach of the lightning diagnostics I have accidentally done this.

I wonder if you could look to see if there's any simple modification to set this straight. I feel the key will be the switches in asad_chem_flux_diags but I dont fully understand them. The important code is my PUMA directory, vn8.4_lightningHiRes, in ukca_light_ctl, asad_flux_dat and asad_chem_flux_diags. If you do a search for "dlf" you'll see all the modified code.

If there is no simple solution then dont worry, I'll try and work it out.

Kind regards,

comment:8 Changed 6 years ago by luke

Hi Declan,

The naming in Xconv is due to the default STASHmaster file you are loading. You can change this by going to

Setup -> Select STASH master files

You can check the NO2 by unlumping the rest of the NOy species from the advected NOy species 34098. I couldn't quite understand from your pp-files what was which. Can you output 34153 and 34356 to a separate monthly pp stream?

I would suggest you test your lightning diagnostics by passing in a constant field of a number (e.g. 3, 4, 5 etc). This should then check that you have the plumbing in place for your diagnostics.

Also - I should add that with the Christmas break rapidly approaching, and the UKCA course the 1st week back in January, I don't know how quickly I will be able to reply over the next few weeks.


comment:9 Changed 6 years ago by luke

Also - the umlumping should be done after converting the NOy species to VMR. NOy is converted as if it is NO2.

comment:10 Changed 6 years ago by s1251469

Thanks Luke,

I understand you're busy. I have followed your advice and managed to form a more specific question which might be quick for you to answer. I understand if you don't manage to respond.

Looking at the monthly mean NO2 which I have output, I think it's fine. I now think the problem is my tropospheric NO2 diagnostic, unsurprisingly.

I have output the lumped N diagnostic on the same time frequency as the tropospheric NO2 and NO2 mmr. In turns out that my tropospheric NO2 is actually tropospheric lumped N. I don't understand why this would be the case.

To produce the tropospheric NO and tropospheric NO2 diagnostics I made the following three steps. The tropospheric NO came out correct. Do you know why it would not work with NO2?

1) Introduced the following code in asad_flux_dat below the whole atmosphere ozone tendency diagnostic.

! NO in the troposphere

asad_flux_defn('OUT',34355,'X',.TRUE.,0,1, &
(/'NO ',' '/), &
(/' ',' ',' ',' '/)), &

! NO2 in the troposphere

asad_flux_defn('OUT',34356,'X',.TRUE.,0,1, &
(/'NO2 ',' '/), &
(/' ',' ',' ',' '/)), &

2) Included the new stash stuff

1| 1 | 34 | 355 |TROPOSPHERIC NO |
2| 0 | 0 | 1 | 1 | 2 | 10 | 11 | 0 | 0 | 0 | 0 |
3| 000000000000000000000000000000 | 00000000000000000001 | 3 |
4| 1 | 0 | -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 |
5| 0 | 1891 | 0 | 65 | 0 | 0 | 0 | 0 | 0 |
1| 1 | 34 | 356 |TROPOSPHERIC NO2 |
2| 0 | 0 | 1 | 1 | 2 | 10 | 11 | 0 | 0 | 0 | 0 |
3| 000000000000000000000000000000 | 00000000000000000001 | 3 |
4| 1 | 0 | -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 |
5| 0 | 1891 | 0 | 65 | 0 | 0 | 0 | 0 | 0 |

3) Initialised them and added them to the output.

comment:11 Changed 6 years ago by annette

  • Resolution set to answered
  • Status changed from accepted to closed

Ticked closed due to inactivity.


Last edited 6 years ago by annette (previous) (diff)
Note: See TracTickets for help on using tickets.