Opened 9 years ago

Closed 8 years ago

#889 closed help (fixed)

Reducing model output

Reported by: SimonDriscoll Owned by: annette
Component: UM Model Keywords: stash
Cc: Platform:
UM Version: 6.6.3



in order to conserve space I wanted to reduce model output to only the diagnostics I wished or may needed to analyse. I was advised that to do this I should change things in:

Atmosphere—>STASH—>STASH. Specification of Diagnostic requirements

and then once I'm in there I choose the Incl option from Y to N if I don't want it to be outputted.

And the same for Ocean, i.e.:

Ocean—>STASH—>STASH. Specification of Diagnostic requirements

The 'incl' option seems possible to be referring to actually 'using' rather than outputting some schemes/data, but I tried this anyway.

In my job xhlaf with which I tried this I get complaints and it doesn't run (HECToR's not available currently so I can't detail the specific complaint) - xhlaf is a copy of a job that has run perfectly fine without these changes to the STASH.

Could you tell me the correct way to reduce model output?

Many thanks,


Change History (8)

comment:1 Changed 9 years ago by ros

Hi Simon,

Yes, turning off some of the diagnostics that you don't want will reduce model output. However you do have to be careful which diagnostics you turn off as some are essential (e.g. for coupling). In your job xhlaf you have unfortunately turned off a lot of the coupling fields so the job is now falling over unable to do the coupling. The one it's currently complaining about is DustDDL1d1 in the atmosphere (3,441 Dust Dry dep flux from lev 1 Div 1). You need to make sure that all the diagnostics in Package B are enabled.


comment:2 Changed 9 years ago by SimonDriscoll

Hi Ros,

aha. Ok.

I turned on all of the diagnostics in package B (and have just re-checked), compilation and reconfiguration give no errors but the NRUN collapses with the complaint:


UM ERROR (Model aborting) :
Routine generating error: INITIAL
Error code: 208
Error message:

INIT_A2O: Coupling field not enabled - dmsflx, ocn


I'm guessing 'ocn' means ocean and I'll check through for 'dmsflux'. Are there any other packages I should have on?



comment:3 Changed 9 years ago by annette

Hi Simon,

I see you got the job xhalf running. I just wanted to point out though that the error message above suggests Ocean STASH item 208 is the problem. The coupling fields are in Package A for the Ocean.

Best wishes,

comment:4 Changed 9 years ago by SimonDriscoll

Hi Annette,

thanks for this.

In my wisdom, accidental luck, or anywhere in between the two I seem to have turned that STASH off without knowing "INITIAL Error code: 208" referred to a stash diagnostic. :)

I remember wondering something about the diagnostics with only a + next to them. These, namely 207 and 208, are the only two turned on in the ocean now.

Just to check, do you mean that for an identical simulation compared to a normal run I need all the package A diagnostics on, or is it fine to not have the package A coupling fields in the ocean? (I'm not sure if all were previously on in e.g. xhlae or just a few… I guess all though from what I can tell about coupling fields)

I'm a little uncertain about just where the boundary of having the same run but simply reducing the model output is (which is what I was originally told turning off stash diagnostics would do) and actually changing the results of the run I'm outputting are. Which is, without saying, disconcerting.



comment:5 Changed 9 years ago by annette

Hi Simon,

I am not really familiar with the HadGEM2 model so I can't say what fields are essential for the run. I am only going on the information provided from the error messages you gave. I would say though that leaving on any fields in the "Coupling fields" packages is a good strategy. The Package Switches panel in STASH in the UMUI gives information about each of the packages so you should be able to decide whether you need them or not. I guess the ones marked HG2 you definitely want.

Apart from this, STASH should not change the results of the run, but of course we can't say this for definite for all configurations. If you are concerned you may want to do some investigation of this on your own, by comparing your reduced STASH run to a run with the original STASH.


comment:6 Changed 8 years ago by SimonDriscoll

Hi Annette,

many thanks.

"but of course we can't say this for definite for all configurations."


"If you are concerned you may want to do some investigation of this on your own, by comparing your reduced STASH run to a run with the original STASH."

The only thing that comes to mind is how much of my run do I have to compare to be sure that in all the fields I will investigate in my future analysis over the months to come (including fields I may not think of looking into now), after using a month or so of modelling time too, I will have runs are so indifferent to the former to be non-negligible in my results and conclusions of my analysis… (and also if it's possible someone can do this through turning on and off other bits of STASH, how generally robust are some aspects of some results).

I'm not sure I have the answers.

Thanks for your help.

Warm regards,


comment:7 Changed 8 years ago by annette

  • Owner changed from um_support to annette
  • Status changed from new to assigned

Hi Simon,

From your earlier comments, you were concerned that switching off certain portions of STASH would change the results of the run - which I take to mean the model state or prognostic variables. You can test this by comparing dumps from the original run and run with modified STASH. As I said you shouldn't see a difference. It depends how important this is to you how much effort and resources you put into this testing. Your supervisor or colleagues should be able to help with this.

As to the robustness of the model in general, you need to think about what you might potentially change in subsequent experiments and what parts of the model or diagnostics are important to you.

Best wishes,

comment:8 Changed 8 years ago by annette

  • Keywords stash added
  • Resolution set to fixed
  • Status changed from assigned to closed

Hi Simon,

I'm closing this ticket as the original query has been resolved.


Note: See TracTickets for help on using tickets.