I have just done a 1-year AMIP test run of ACCESS-ESM1.5 using payu ( GitHub - coecms/access-esm-amip) and appreciated the clear instructions including the ‘Excessive Output Warning’. Years ago I used to be able to select the output using the UMUI but what is the best way to do it now? Editing the STASHC? Or does anyone else running ESM1.5 AMIP already have a set-up for a smaller set of output that they are able to share?
Thanks, Rachel
1 Like
Hi Rachel,
I’ve attached a STASHC file that @ariaan has put together which I’ve been using for my AMIP runs. The file gets rid of the daily and sub daily output and some of the monthly fields as well, reducing the amount of output each year from 157G to ~14G. Hive won’t let me upload a txt file so I’ve had to paste the text into a pdf.
STASHC_APmod2.pdf (32.1 KB)
Cheers,
Spencer
I have added .txt as a valid upload format. Thanks for the heads-up for that as an issue. If you, or anyone else, has a similar problem uploading a file please feel free to get in touch.
1 Like
Thanks for changing that @Aidan!
I’ve just attached the txt file here
STASHC_APmod2.txt (20.3 KB)
@spencerwong - Thanks for the help. It may take me a while to test this but hopefully it will also be useful for others doing AMIP ACCESS_ESM1.5 runs. Perhaps worth an update to the standard payu case to use the smaller output STASHC?
If you want to do that it is best to start an issue in the repo and then make a pull request that fixes it.
I just realised that I really should have included a list of the variables that it saves! I’ve just included a list of the names from the output here.
monthly_vars.txt (7.2 KB)
It’s tricky to update the STASH file for the standard payu case. For the moment, it has been designed to reproduce the case used for CMIP submissions exactly, as far as I know. That would mean keeping the STASH file as required by CMIP.
So I guess the question is how to best handle configurations with different levels of output so that people can find and identify them easily.
As long as it is well documented then it should be possible to keep configuration tweaks in separate branches.
If the main use case of this model is not CMIP6 style output, then the CMIP configuration could be in a branch. I’m in favour of this, as we know the model outputs a huge amount of data no-one ever uses, and causes issues down the track with data storage and not knowing what to retain and what to discard, so everything is kept by default.
1 Like
@spencerwong , @clairecarouge , @Aidan - thanks for all your contributions. Spencer - it was a good idea to post the list of variables, as your list didn’t include the carbon variables that I needed so your stashc doesn’t suit my needs. Instead I’ve taken the stashc from the 4xco2 run. It produces output that is intermediate in size between the amip case and Spencer’s example. While it may be what we used for CMIP6, it also has output that wouldn’t be of general interest - the pgh files are timeseries of CO2 output at CO2 monitoring sites, leftover from when we were doing more CO2 transport focussed work. Perhaps this is worth a discussion in the ESM working group sometime - whether we want a ‘library’ of STASHC files for a range of output applications and/or some documentation around how to change the output. Is using the UMUI still the easiest way to do this?
Given how much trouble people seem to have with them, that sounds like a really good idea.
I’m not sure about that. @holger would know, but not sure if he is about right now.
Hi
Sorry for answering so late. I don’t find the STASHC all that confusing, you have to mostly look at the STREQ lines. I think I have created a document on how to read it a while ago. I’ll have a look.
1 Like
Any luck finding that @holger?
I did remember writing about how to read the STASHC but couldn’t find it.
I’ve now looked again, and I found what I wrote in an email that I sent, so no wonders I didn’t find it in any of the documents I wrote on my disk.
Here’s the gist of it:
The configuration on which fields to output is controlled by the STASHC file in the control directory. It’s a convoluted process, and it’s almost impossible not to mess this up if you’re not exactly sure what you’re doing.
The file begins with a namelist called STASHNUM which gives the number of entries for the requests, as well as the number of domain, time, and use profiles further down the list:
&STASHNUM NUM_REQ= 234, NUM_DOM=37, NUM_TIM=20, NUM_USE=12 /
Let’s go through this, for an example. “Fraction of Sea Ice after Timestep” (Timestep referring to a specific point in the calculation) has the stash code: Model 1, Section 0, Item 31. (You can look this up in the file ~access/umdir/vn7.3/cntldata/STASHmaster/STASHmaster_A )
In the STASHC file, we see this namelist entry:
&STREQ IMOD= 1, ISEC=0, ITEM=31, IDOM=1, ITIM=3, IUSE=2 /
This says that we have a Stash Request for model 1, Section 0, Item 31, with Domain Profile 1, Time Profile 3, and Use profile 2.
The numbers mean the profile in the order in the same file. Below the Stash Requests, there are the TIME domain namelists, and since we have Time Profile 3, we need to look at the 3rd entry:
&TIME NAME="TDMPMN", ITYP=3
INTV=1,UNT1="DU",IOFF=0,ISAM=1,UNT2="T ",
IOPT=1,
ISTR=1,IEND=-1,IFRE=1,UNT3="DU",
/
This gives us a human-readable name (which is good), and then a list of parameters that I don’t know from memory. But the name is TDMPMN , where the T stands for time profile, and DMPMN probably means ‘Dump Mean’, i.e. a mean over the dump period (which I think is a month).
After the time profiles we get the entries for the domain profiles, and we need the first one:
&DOMAIN NAME="DIAG", IOPL=5
PLT=0,
IOPA=1,
IMSK=1, IMN=0, IWT=0,
TS="N",TSNUM=0,
/
This describes which levels to output, whether theta or rho levels, etc.
In this case, it’s a surface field, and DIAG is just that.
For other fields, you might see names like DALLTH (all theta levels) or DSOIL (soil levels).
Finally, we get to the Use Profiles, i.e. what to do with these fields. Usually it’s which files to output them to.
&USE NAME="Upamonth", LOCN=3
IUNT=60,
/
It goes into the PA file, which is meant for monthly outputs.
As far as I know, the NAME attributes of the profiles have zero impact on the model, and are just there so that we can read them easier.
If you do need to make changes, be careful. I would advise against changing the individual profiles, and only edit the STREQ entries. If you add or remove entries, make sure that at the beginning of the file in the STASHNUM section, you update the correct total number of entries.
1 Like