I’m running a nested West Antarctic domain (not containing the pole!) that uses ERA5 to force the glm at n320 and then nests 12 > 4 > 1 km LAMs inside that (essentially the same setup that Andrew is using to run over the South Orkney islands in this ticket).
The glm and first forecast of the 12 km nest run fine, but I get failures on the second forecast:
UM_READDUMP Dump does not match STASH list: Wrong processing code.
and also a fail in the createbc step of the 3 km nest, which I presume is related to the former.
I’m not sure why the stash for the dump processing would be any different to Andrew’s suite (which runs) as I have made minimal changes (I’ve changed the charging code, shifted the domain, pointed it to different start files and added a few ancils + stash to the conf file but that’s pretty much it).
Can you advise? Thanks.
Ella
EDIT: have narrowed it down to the TOT PRECIP AFTER TSTEP stash, which has the incorrect processing code. pe_output says:
UM_READDUMP : Dump field 3375 does not match STASH processing code for section 0 item 348
[0] Expected processing code 128
[0] Found processing code -32768
Is this because I’ve got stash packing switched off? I can’t see a way to change the processing code. I can ignore the variable for now, but it would be good to get it working if poss, so I don’t have to manually sum solid+liquid precip in post.
EDIT 2: ignoring doesn’t work, because it just throws up a similar error with another variable. Must be something more fundamental than a issue with that particular variable.
Hi Grenville, It’s u-cu484. The committed version should crash, I’m using my working copy to debug which stash are causing the problems. Removing all the stash requests gets it to run so I think it’s a few stash outputs that are causing the error.
Cheers
Ella
Thanks Grenville. I was still getting errors about other variables after I ignored 00384 but I narrowed it down to being (I think) one of the fluxes in section 3 before my suite window crashed - is puma down? E
Sorry to drag you back in @grenville , but the plot thickens…
I’ve taken all the STASH out and sequentially added them back in (painstakingly), and it seems that I’m getting errors when any outputs related to the large-scale cloud scheme are used.
So far the following have all been causing crashes:
TOTAL PRECIPITATION RATE 05216
LARGE SCALE SNOWFALL RATE 04204
LARGE SCALE RAINFALL RATE 04203
TOTAL COLUMN QCF RHO GRID 30405
TOTAL COLUMN QCL RHO GRID 30406
TOTAL COLUMN Q (WATER VAPOUR PATH) 30461
The specific error is
Error from routine: EXPPXI
[0] ? Error message: Invalid item number 0
Immediately before this in the pe outfile it has this message:
LOOKUP TABLE
[0] 216000 64-bit words long
[0] WARNING: User defined field found - STASH code : 0
[0] Setting internal model number to atmosphere.
[0] WARNING: User defined field found - STASH code : 0
[0] Setting internal model number to atmosphere.
[0] READFLDS: reading 3375 fields with all-to-all algorithm
[0] readflds[0] : reading fields 1 to 211 on this PE.
which sounds like the UM is potentially mis-reading these stash entries?
Have you got any ideas where this is coming from? I can’t see anything untoward in e.g. app/um/rose-app.conf
Classically, the one thing I want to focus on for this simulation is the impact of cloud composition on precipitation events, so these are quite crucial diagnostics!
The tidystashtransform macro changes the names of namelist entries to something the model doesn’t like, which causes it to complain. I had to re-add all the outputs in manually in the GUI and NOT run the macro (meaning my namelist entries are called something like streq(1), streq(2) etc.
Yeah it’s weird! I’ve never had that problem before with the macro, but Paul says he’s seen it before too. I think he’s planning to pass it on to someone at the Met Office. E
