#2685 closed help (answered)

Missing UM mean (*.pm*) output

Reported by: cbellisario Owned by: um_support
Component: UM Model Keywords: UPMEAN output
Cc: Platform: NEXCS
UM Version: 11.0


Dear NCAS team,

I am trying to run the model for a whole year and print monthly mean output of several variables.
I have added the corresponding STASH with 'tim_name' = 'TDMPMN' and 'use_name' = 'UPMEAN'.
However, in the folder cylc-run/suite_number/share/data/History_data, there is no trace of the associated file in 'suite_number'a.pm'date'.
I suppose that there might be a conflict somewhere but I cannot figure out where.
The suite number is 'u-bd453', running on NEXCS.

Thank you in advance,

Best regards,


Change History (6)

comment:1 Changed 20 months ago by willie

Hi Christphe,

The STASH table needs to be re-indexed, so run stashindices.TidyStashTransform.

Also the UPMEAN profile is set to "dump store" - I think this should be set to "be written to an FF output stream". You'll need to supply an output stream (to be set up in Model Output Streams).


comment:2 Changed 19 months ago by cbellisario

Dear Willie,

Thank you for you answer, I managed to access the *.pm* files in the associated folder.

However, it leads to an observation that may have to introduce a new ticket, I am not sure.

To summarize, I have been implementing the model in several parts (UM, SOCRATES and JULES).
One of those required to introduce a new stashmaster, properly created to keep in memory an output of SOCRATES during the various timesteps (downwelling longwave flux over bands).
It works correctly as I have checked several times.

However, I intend to estimate the impact of my changes in comparison to the classic run.
To do so, I 'canceled' my changes (with several IF conditions) and I saw that the results between the basic run and the modified run where still different.
Thinking of maybe I wrote something wrong in the code, I verified all the modifications.
But because I could not find out what was wrong, I then tried something: running the model with the source code being the same as the basic run.

So we have:
Suite u-bb397: basic run with source code:

  • GA7.1_UM11.0_AMIP/Branch_Seq00_Base/vn11.0_Branch_base/
  • GA7.1_UM11.0_AMIP/Branch_Seq00_Base/vn5.1_Branch_base/
  • GA7.1_UM11.0_AMIP/um11.0_JM_tile_emis_update/

Suite u-bb586: modified run with source code:

  • GA7.1_UM11.0_AMIP/Branch_Seq00_Base/vn11.0_Branch_base/
  • GA7.1_UM11.0_AMIP/Branch_Seq00_Base/vn5.1_Branch_base/
  • GA7.1_UM11.0_AMIP/um11.0_JM_tile_emis_update/

instead of the modified sources

  • GA7.1_UM11.0_AMIP/Branch_Seq02_JULES_mod/vn11.0_Seq02_JULES_mod/
  • GA7.1_UM11.0_AMIP/Branch_Seq02_JULES_mod/vn5.1_Seq02_JULES_mod/
  • GA7.1_UM11.0_AMIP/Branch_Seq02_JULES_mod/um11.0_Seq02_JULES_mod/

In the results (tested mainly on the surface temperature), I obtain also huge differences. Therefore, I came to the conclusion that the stashmaster modifications lead to differences in my climatic outputs.

I currently have no idea about how to check this and I would value if you could help me on this (should I create a new ticket?)

With best regards


comment:3 Changed 19 months ago by grenville


I'm not sure we can help with this - have you added new entries to the STASHMaster or changed existing entries. Have you touched the entry for surface temperature?


comment:4 Changed 19 months ago by cbellisario

Dear Grenville,

Indeed, I made several changes related to the STASHMaster to solve the initial problem.
To be short, I had to add the downwelling longwave flux on bands (from SOCRATES) to the STASHMaster in order the variable to be remembered between the timesteps.
So, from the existing STASHMaster, I added a new entry. Here are the changes performed:

  • In rosie go, I changed the um/meta from um-atmos/vn11.0 to um-atmos/vn11.0_HEAD, which is a working copy of the um/meta where I can perform the changes.

Then, the changes introduced are located in
Then the files where changes are required:

  • I added in the first file the section:

2| 2 | 0 | 2 | 1 | 5 | -1 | -1 | 2 | 1 | 2 | 0 |
3| 000000000000000000020000000000 | 00000000000000000001 | 3 |
4| 1 | 2 | -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 |
5| 0 | 1582 | 0 | 129 | 0 | 0 | 0 | 9999 | 0 |


Which is a copy/paste of the corresponding SURFACE DOWNWARD LW RADIATION
2| 2 | 0 | 2 | 1 | 5 | -1 | -1 | 0 | 0 | 0 | 0 |
3| 000000000000000000020000000000 | 00000000000000000001 | 3 |
4| 1 | 2 | -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 |
5| 0 | 1581 | 0 | 129 | 0 | 0 | 0 | 9999 | 0 |

That is used to save the integrated surface downward lw radiation. I did change some of the dimension to take into account the bands. I associated the number 512 in section 0 as a free slot.

  • Then, in the second file, I added the description:

help=Gridbox mean spectral downward longwave radiation at the surface.

Again, based on what is already existing for the integrated surface downward longwave radiation.

The next changes I have performed are located in the code to extract the value in a specific variable:

  • Definition of the pointer in src/control/top_level/atm_fields_real_mod.F90

REAL, POINTER :: lw_down_band(:,:,:) ! Spectrally resolved surface

! downward LW at radiation timestep

  • Definition of the pointer indice in src/control/top_level/atm_d1_indices_mod.F90

INTEGER :: jlw_down_band ! Surface downward LW at radiation timestep on

! each band

  • The value of the pointer indice is initialised in src/control/top_level/set_atm_pointers.F90

jlw_down_band = si(512,Sect_No,im_index) ! Surface down LW on band

  • The values are filled in src/control/top_level/set_atm_fields.F90

lw_down_band(tdims%i_start:tdims%i_end,tdims%j_start:tdims%j_end,1:9) &

⇒ d1(jlw_down_band:jlw_down_band + &

field_length(theta_points,no_halo,1)*9 -1)

After transmitting the values down to JULES where LW and LW_band are used, I did checked that on each points I had LW(i,j) = sum( LW_band(i,j,:) ) so that the integrated downwelling longwave radiation is consistent with the sum over the bands of the band resolved downwelling longwave radiation, and it is.

So I am wondering if there is a missing step, or something I did wrong that could have messed up with other stash parts?
I did said that the surface temperature was modified, but as a symptom. I have no idea and no way to know if it is directly that variable that is modified in a bad way at some point.

Thank you for your help, I do not know where to look for.

Best regards,


comment:5 Changed 18 months ago by cbellisario

Dear Grenville,

I might have a partial answer to my issue described in the previous messages.

When I rewrote STASHmaster_A and STASHmaster-meta.conf, I based the lines on the already existing SURFACE DOWNWARD LW RADIATION as said previously.
I did changed bits to match what I was looking for.

I also implemented the PP Field Code code number (from 1581 to 1582) as written in the document "Unified Model Documentation Paper C04 - Storage Handling and Diagnostic System (STASH)".

However, this code was already used in STASTHmaster_A, even twice:
For 1| 1 | 6 | 217 |GWD Froude number
For 1| 1 | 0 | 239 |TOA - SURF UPWARD LW RADIATION W/M2|

I did changed that number to 1584, which is not used elsewhere in STASHmaster_A.
I also changed the reference in STASHmaster-meta.conf:

And I was glad to see that the differences disappeared.

I assume that the index numbers where in conflict with that used the same PPFC. However, I still do not understand how STASHmaster-meta.conf works since the code between () does not specify the the section number for example. I could not find anything related in the documentation.

Hoping that will help people facing the same trouble.

Best regards,


comment:6 Changed 17 months ago by grenville

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


We'll close ticket now


Note: See TracTickets for help on using tickets.