Number of fields exceeds reserved headers and nudging?

[MYoshioka]

Monsoon3 #vn13.9 #Nudging

Hi,

I’m getting this error with my suite u-du347.

? Error from routine: STWORK
? Error message: STWORK: Number of fields exceeds reserved headers for unit 20

I see some of the tickets asking about this but I’m not sure if it’s the same problem.

This suite is descended from the UKESM standard job u-dr799. The direct copy of this, u-du141, completed running for 3 months fine. In u-du216 I converted it from historic to 2015- simulation and it also ran without a problem. In u-du347, I’m trying to implement nudging.

pe_out tells me that unit 20 is pp130, which I use for pm output (UPM) for monthly means. reserved_header was originally set to 60,000. I increased it little by little and now it’s 600,000 (10x bigger) and it’s till failing.

I think I set it 400,000 in the previous run, and the run failed in day 20, now it fails in day 29. To complete a cycle of 3 months, maybe I should set it to 2,000,000 ? Or should I set a cycle to be 1 months and reserved_header something like 1M? The suite currently includes lots of stash requests that I don’t need (but they do not include what I need yet), so I may be able to reduce the number of them.

But is it OK? I feel it strange. I turned on nudging, changed calendar to Gregorian, and added a few stash requests required for nudging but using a different usage (UPUKCA). For UPM, I think I added only 3 diagnostics: section 39 items 3, 8, 13.

So I feel that the problem may be something else. I changed reinit_step from 30 days to 1 real month for example, and any of these might be causing a problem?

Oh, this can provide a hint. Output size has been hugely increased and it appears to me to suggest that something might have gone wrong.

-rw-r–r–. 1 masaru.yoshioka.ext asci 5036756992 Nov 11 12:26 du216a.pm2015mar
-rw-r–r–. 1 masaru.yoshioka.ext asci 124390473728 Nov 13 16:29 du347a.pm2015jan

Below is an output from my vn13.7 suite for comparison. It is nudged with all necessary diagnostics requested and without all unnecessary ones. It is a pp file so the size of a field file would be twice as big.

-rw-r–r-- 1 myoshioka gws_asci 1396073008 May 26 11:23 dq162a.py20161201.pp

Have you seen something like this? Can you suggest anything I can try?

I said the other day that I was having a problem in committing suites but it was turned out to be a suite specific problem, and committing works fine with other suites. So all suites mentioned here are committed, if you need to check them.

Thanks.
Masaru

[mdalvi]

Hi Masaru,

In the TMONMN profile you have changed only the processing (averaging) period to Real months, but output frequency ‘unt3’ is still Days (effectively: daily output)

These changes need to be made for all TMONMNXX as well as T30day/ T90day profiles for consistency.

Note also that currently with Gregorian calendar the UM only does the monthly meaning correctly when run in 1-month segments i.e. EXPT_RESUB=P1M (This should be fixed in vn14.0).

Alternatively, u-ds836 is a copy of u-dr799 with Nudging included, and has been tested so you could start from this.

Mohit

[MYoshioka]

Thank you Mohit.

I fixed that part but the result doesn’t seem to change. I also set this;

rose-suite.conf:12:EXPT_RESUB=‘P1M’

I’m getting exactly the same error as before. So there must be something else that is causing this problem.

Thank you for suggesting the suite where nudging has been implemented. But I’ll stick with this one a little bit to learn what exactly I need to do.

I committed the suite again.

Masaru