Ancillary time mean lookup items 1-12 are not compliant with UMDP F03

Unified Model
1

Dear CMS,

atmos_main in my UM vn13.5 suite u-dj442 failed for this error;

? Error code: 100
? Error from routine: REPLANCA
? Error message: Ancillary time mean lookup items 1-12 are not compliant with UMDP F03. Field no: 1
? Error from processor: 47
? Error number: 27

According to Ancillaries files for nudging the UKESM1-AMIP suite this happens due to a disk space shortage? But what disk is it in case of Monsoon2? Or is there a different cause for this?

Masaru

2

Hi Masaru,

Your error is not due to a disk space shortage. In the earlier issue referred, the message about Ancil headers was the last ‘Warning’ before the actual FLUSH_BUFFER error (which was due to disk space).

The failure in this case is due to the above warning now upgraded to an ‘Error’.

The root cause is some ancillaries not being fully compatible with the Gregorian calendar, leading to slight deviation in the time interpolation (using middle of month vs 16th of the month). Due to this being perceived to have an acceptable impact, there is an ‘‘override logical’’ available to use until all ancillaries are corrected.
l_enforce_f03_compliance=.FALSE., will revert this back to a Warning.

See #6438 (Fix in replanca for Gregorian calendar) – Unified Model (metoffice.gov.uk)

3

Hi Mohit,

Thanks. That is very helpful.

According to the job.err that you mentioned, it looks like qrclim.ozone that caused this problem. It is linked to
/projects/ancils/cmip6/ancils/n96e/timeseries_1850-2014/OzoneConc/v1/mmro3_monthly_CMIP6_1849-2015_N96_edited-ancil_2anc
, which uses 360-day calendar indeed.

As I said I copied a vn12.0 suite and upgraded it. The original suite (u-cy847) does use the same file but it should have been running OK probably due to its version. It does not seem to have l_enforce_f03_compliance.

So I could set l_enforce_f03_compliance=.FALSE. but there should be a better solution, right? I checked how it is done in my nudged suite (u-dg965) but it doesn’t seem to use any ozone ancillary…? I’m a bit confused here. I couldn’t figure out why it was possible. Any idea?

Alternatively there should be ozone ancillary files with 365-day calendar, aren’t there? I found
/projects/um1/ancil/atmos/n96e/ozone/sparc/1994-2005/vx/qrclim.ozone_L85_O85
where vx=v3 or v6. Do you think using one of these files is a good idea?
These appear to be zonal mean data so it must be somehow treated. Maybe setting zon_av_ozone = .true. ?

Masaru

4

Hi Masaru,

The ozone ancillary is required only for GAx suites which does not have interactive ozone, and not for UKESM configurations which has full chemistry running.

The fully compliant 365-day file should be available in the GC5 dataset: /projects/um1/ancil/atmos/GC5/n96e/ozone/sparc/1994-2005/v1/qrclim.ozone_L85_O85 but this is Y2000 mean cyclic and also zonal mean.

5

Hi Mohit,

That’s great. But it looks like I have to ask how I can use that data.

The model creates a symbolic link
/home/d03/myosh/cylc-run/u-dj442/share/data/etc/ancil/qrclim.ozone
pointing to the data above.

Where and what should I change to make the model create a symbolic link pointing to the data you suggested?

Sorry, this should be quite an elementary question.
Masaru

6

Hi Masaru,

There should be an ‘install_ancil’ app in the suite with a rose-app.conf which specifies the linking.
The original source file for ozone might be given as an environment variable like $ANCIL_OZONE_DIR/$UM_OZONE_ANCIL, (set from a central *ancil_versions’’ file) . This will have to be replaced via an absolute path to the new ozone ancillary.

7

HI Mohit,

like this? I thought maybe there was a more proper way to do, but if it’s good it’s good.
source=/projects/um1/ancil/atmos/GC5/n96e/ozone/sparc/1994-2005/v1/qrclim.ozone_L85_O85

But atmos_main seems to fail when I set zon_av_ozone=.true. for some reason. job.err shows this;

[0] ? Error code: 5
[0] ? Error from routine: READFLDS_CORE
[0] ? Error message: Readflds Address error for field 9277:
[0] ? Calculated (address)/(field_length): (1320114)/(104)
[0] ? Maximum D1 address: 1320073

It’s been running for a while now with it set false. Is it OK?

Masaru

8

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