Glm recon failing looking for dust clay soil fraction

Unified Model
,
1

Hi CMS,

I’ve started another run using suite u-dc576, which is a copy of u-cy223 (I’ve got ten of these suite running perfectly at the moment). It’ failing in the recon, looking for STASH 418 (soil dust clay fraction).

???
???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!
? Error code: 30
? Error from routine: RCF_RESET_DATA_SOURCE
? Error message: Section 0 Item 418 : Required field is not in input dump!
? Error from processor: 0

The only thing about this suite that is different to u-cy223 is the dates (2020).

It’s pretty confusing because the task does produce as astart file and the field is in it (albeit all zeroes). So it’s not that the field isn’t in the input dump, it’s more that it’s not got any values.

I figured that I might be using cycle dates after the end of the global ancil file, but it’s a climatology so it shouldn’t be causing a time-related issue.

Can you help?

Cheers,
Ella

2

Update: I also tried adding these stash in under glm_um>recon>configure ancils and: 1) referring to the um ancil directory on archer, 2) setting to zero. I figured there must be a reference to stash 418 in the optional config for ga7 but I can’t see it (seems like the only references are in the confusingly named opt/rose-app-nosoildust.conf

I also tried running with GA6.1 in case that eliminates the need for the soil dust ancil.

Turning on extra diags doesn’t really help either. Any thoughts? I’m really stuck here.

Ella

3

Ella,
Is it the case that u-dc576 is identical to u-da701 apart from dates (if not u-da701, which successfully running suite is it identical to?)

Grenville

4

Hi Grenville,

Yep, all the suites starting u-da, plus u-dc576, are copies of u-cy223 and so should be identical aside from dates.

(Btw I got past the soil dust clay error by adding it in under the glm recon panel, but I’m now getting the same error relating to stash 221, snow soot content.)

5

Update: I tested running the suite as-is and changing the dates to 2000, and it runs with no problem. So it’s definitely something about the year being 2020.

Any insight would be much appreciated with this as I also need to run years 2021, 2022 and 2023, which I assume will have the same problem…

6

This is bizarre - looking

1 Like
7

Did you manage to find any reasons for this, Grenville?

8

We’re still looking - this is undesirable behaviour!! It appears that there is some logic in the masses of nesting suite jinja that users aren’t aware of or it’s a bug.

9

okay, that sounds like a deeper issue than I had anticipated! Thanks for digging into this for me…

10

fyi, I also tried a month in 2022 and got the same error using this same suite.

11

Hi Ella,

There is a bit of logic in the job script which sets the nodust optional configuration based on the date:

cylc__job__inst__env_script() {
# ENV-SCRIPT:
eval $(rose task-env)
DUST_OPT=
EC_OPT=
DATE=$(rose date -c -f %Y%m%d%H%M)
  if [[ $DATE -lt 201107201200 ]]; then
    DUST_OPT=nodust
  fi
}

This is pulled in from the file suite-runtime/dm.rc in the suite.

The logic seems to be that there is no dust in UM start dumps before this date (I found a reference to this in the suite repo: https://code.metoffice.gov.uk/trac/roses-u/changeset/7458)

However looks like you are starting from an ERA file anyway, so that logic isn’t relevant.

Hopefully that explains what is going on with the different behaviour based on the start dates.

Annette

12

Thanks Annette. So I can just change that date?

Edit for anyone also having this problem: I did just change the date (to 01/01/24) and it runs fine.

1 Like
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.