Bespoke UM stashpacks via the GUI

Hi all.

I am busy generating my own set of stashpacks for a range of ACCESS-rAM3 experiments I am setting up. I have created the necessary .configuration files which work well. I am wanting to refine the GUI so that I can select the relevant packs per experiment (for my own sanity and future proofing). Is it possible to:
a) Change the text on the GUI to my own descriptions of each of my own packs?
b) Set the GUI to point to a .conf file that is not named to the default “stashpackX”?
c) Add more than 7 stashpacks into my options list.
If so, where would I change this? (Sorry if this is obvious but couldn’t find where to do this on the documentation)

Thanks in advance!!

Hi @Michael_Barnes,

You can theoretically create new stash pack numbers and put them into the User-Interface. You can also change modify the descriptions in the user interface. It would require modifying the rose/cylc meta (for the User Interface) and the underlying calls.

If you want to go down that path I can help you but it would be more “bespoke” type help.

But to be honest, a much more straightforward way to go would be to soft-link to different versions of stashpack6.

The actual stashpack6 used would be kept in the experiment output directory so you would have a record.

We could also script which stashpack6 is linked for what level of the nest (but again this is off-script work).

I think it would be more in-line with the expected use.

Maybe let’s chat.

@Michael_Barnes please note that supporting infrastructure changes to help scientists keep track of multiple different STASHpacks is not in the current workplan. This may affect our ability to provide support. If there is anyone in the community who would like to help @Michael_Barnes with the necessary changes please feel free to post here.

Thanks @cbengel, all understood. Thanks for your responses. All understood. I will kept using the one default customisable stash pack and just keep track it via the output.

Thanks @Michael_Barnes for being so understanding. Your suggestion is genuinely a cool idea. If you are interested I suggest floating it amongst 21CW to garner more support and have a coordinated request put through. That way we can balance what you want against other existing requests. Sorry we have so much to do.

No of course. I really did not expect you to do this!!! Really was just asking the community whether this is possible (as a new access user). But will continue as planned and suggested!! Thanks for taking the time to respond @cbengel!

The problem with anything related to rose/cylc in the RNS is that it is very sophisticated but unwieldy to learn quickly. It is too much to explain in a post and requires support in my opinion (and experience). I know you weren’t asking for that type of support but it is what would be needed.

If this is something that may be useful, we can help. I’m assuming my experience with the AM3 stash is transferable, and @Paul.Gregory can probably run the rAM3 suite with his eyes closed.
Let’s chat to see what we can do!

Hi Michael.

I have never edited the file meta/rose-meta.conf which contains all the logic required to add/delete fields from the rose edit GUI.

However, I have added logic to add extra STASH to an older rAM3 flagship suite.

If you look at the Flagship suite here: https://code.metoffice.gov.uk/trac/roses-u/browser/d/q/1/2/6/trunk/rose-suite.conf

You’ll see an extra entry in the rose-suite.conf here:

USE_NCI_CLOUD_STASH=false

This is a switch which allows the user to add extra STASH fields related to clouds (which I built to support @qinggangg’s research).

If you set that to ‘true’, a macro in suite-macros.rc (https://code.metoffice.gov.uk/trac/roses-u/browser/d/q/1/2/6/trunk/suite-macros.rc) will do the following:

116  {# Turn on stashpack. Do this before picking up science config so that GA science configs
117	       do not try to use reflectivities diagnostics (because they comment out these diags . #}
118	    {%- for n in range(1,NSTASH+1) -%}         
119	      {%- if mod["stashpack"][n-1] -%}
120	        {% do opts.append("stashpack"+n|string) %}
121	      {%- endif -%}
122	    {%- endfor -%}
123	    {# Add extra STASH for NCI cloud diagnostics #}
124	    {%- if USE_NCI_CLOUD_STASH -%}
125	       {% do opts.append("nci-clouds") %}
126	    {%- endif -%}

This will add the flag nci-clouds to the options argument when rose executes the UM forecast task. The rose convention is that any ‘option’ name corresponds to the file name filter of an app/opt file. In this case, it is an extra STASH pack located in app/um/opt/rose-app-nci-clouds.conf to the UM run.

The extra STASH is here : https://code.metoffice.gov.uk/trac/roses-u/browser/d/q/1/2/6/trunk/app/um/opt/rose-app-nci-clouds.conf

From the rose manual : Rose Environment Variables — Rose Documentation 2.7.0 documentation

Each KEY in this space delimited list switches on an optional configuration in an application. The (KEY) syntax can be used to denote an optional configuration that can be missing. The configurations are applied in first-to-last order.

i.e. everything in ROSE_APP_OPT_CONF_KEYS is a /app/um/opts/rose-app-OPTIONNAME.conf file.

So when I executed the cylc task to launch the UM forecast, the values of ROSE_APP_OPT_CONF_KEYS were:

ROSE_APP_OPT_CONF_KEYS="ns rcf_orog stashpack1 stashpack6 nci-clouds GAL9 fixed 3D_ancils lbc custom"

So that’s the framework to add bespoke STASH without editing the GUI.

  1. Add an entry <OPTION_NAME> to your rose-suite.conf file to provide a switch.
  2. Add an entry to your suite-macros.rc file (ideally in the same section which loads STASH packs) to add <OPTION_NAME> to your suite macro which controls runtime options.
  3. Create extra STASH contents in your app/um/opt/rose-app-<OPTION_NAME>.conf file

I would be interested in such a thing too - I’m just usnig stashpack6 at the moment for my own stash outputs, but would be amazing to have a few others so I could turn on an off different outputs more easily (eg. different stash for different domains).

Thanks @sonyafiddes . I will raise this at ACCESS-NRI (and discuss how to fit it in amongst other work). :smiley: