As far as this error message is concerned, the nudging code checks on the 1st timestep whether this field is active in STASH, and requesting with TALLTS ensures that.
I cannot say at this stage why requesting with TMONMN does not work n this case and worked earlier, unless there has been a change in the way ‘sampling’ is specified (should be something like ‘sample-every-timestep-and-average-over-one-month’).
Also check in pe_output or job.err if there are any warnings from PRELIM about this diagnostic.
No changes to those samplings! I had turned off one of the output streams and then turned it back on again (and recommitted) but cannot get it back working. There is nothing in the PRELIM saying that the STASH is denied etc. is it reliant on any other diags?
No it is not dependent on any other diagnostic or setting. If the output stream has been turned Off previously maybe STASH still thinks it is not needed and hence deactivates all diagnostics to that pp stream.
If the 30-451 diagnostic is not needed in the output you can change the request to use TALLTS and UPUKCA.
Sorry that was not clear from me, I meant one of the output streams for this diagnostics (i.e. the UP4 one). I’ll try changing to UPUKCA as I do not need to copies of it.
I was reading the documentation on nudged UKESM1-AMIP and noticed the recommendation to stop using TMONMN and to use TDMPMN and UPMEAN output? Is this needed? I inherited this job from a previous project and it uses TMONMN still.
The Nudged UKESM1-AMIP documentation is for UKESM1.0 (11.x) where climate meaning for Gregorian calendar was not working properly. Most of the issues have been fixed for UKESM1.1 (vn13.x) which is most probably the suite you have inherited.
As long as the ‘branches/dev/mohitdalvi/vn12.0_gregorian_fixes’ branch from u-dk793 has not been removed then the meaning should work fine. This gathers the relevant fixes as they were being applied to the UM, up to vn13.x.
That sounds like either a corrupted file/ disk issues , or a corrupted diagnostic.
Have you been able to run a copy of the predecessor suite without any changes? This is useful especially if there are STASH/ output stream changes proposed.
Also, could you let me know the suite and location of the runs (ARCHER/ Monsoon, user-id), so I can try to take a look ?
Yeah I have been able to run it for a month but this is the first time I have tried to run longer! The job id is u-dq440 and I am running on Archer2 (should be in my work folder /work/n02/n02/s2261584)
I have checked both the job and the branch and did not make any changes to 52-228. The last cycle (20010101T0000Z) failed on the pptransfer with the error [ERROR] Archive directory /work/n02/n02/s2261584/cylc-run/u-dq440/share/cycle/20010101T0000Z/u-dq440/20010101T0000Z doesn’t exist. This is strange as this is three months of the cycle (I was getting this previously when I had it set to 1M so increased the cycling frequency). Could this be what is causing the error in the diagnositc?
Sorry I am very confused I haven’t run into any errors like this before!
As you can see the path in the error message seems to be constructed incorrectly: u-dq440/share/cycle/20010101T0000Z/u-dq440/20010101T0000Z
Also, Gregorian calendar runs can only use 1-month segments as STASH cannot support climate meaning for longer periods (yet - likely to be fixed at vn14.0).
So, it is worth re-setting RESUB to 1M and trying to address this error first. If you are re-running the suite make sure to empty share/data/History_Data/ to avoid conflict with earlier files.
You can ignore the Archive directory error in pptransfer for the 20010101T0000Z cycle. This is because it’s the first cycle and there is no data that is finished with ready to be archived. Please just set the pptransfer task to succeeded.
The /work/n02/n02/s2261584/cylc-run/u-dq440/share/cycle/20010101T0000Z/u-dq440/20010101T0000Z directory naming is fine. This is just a result of how the postproc app is set up to archive to the $ROSE_DATAC directory. This is fixed at a later postproc release but doesn’t impact the running of the suite.
Thank you both. I think previously I was getting this to work and the only thing I am slightly confused as to why I have changed is in the app/housekeeping/rose-app.conf file I added the line “prune{share/cycle}=-P3M” following the advice given in this ticket: Switch off ARCHER2 automatical archiving - #2 by RosalynHatcher
All the prune{share/cycle}=-P3M does is delete the staged archive data directory from the /work/n02/n02/s2261584/cylc-run/u-dq440/share/cycle directory once it has been successfully transferred to JASMIN.
Ok great thank you. It has now run a full year successfully! I can’t see any data in the /work/n02/n02/s2261584/archive/u-dq440 file at all however (it is all on Jasmin). Without the restart file here I’m not sure how the job will keep running? Does the prune also delete this data?