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

**URL:** <https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523>\
**Category:** Unified Model\
**Tags:** Monsoon2\
**Created:** [18 September 2024 15:02 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523 "2024-09-18T15:02:19Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![MYoshioka](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@MYoshioka](https://cms-helpdesk.ncas.ac.uk/u/MYoshioka)\
**Post date:** [18 September 2024 15:02 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/1 "2024-09-18T15:02:19Z")

</div>

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](https://cms-helpdesk.ncas.ac.uk/t/ancillaries-files-for-nudging-the-ukesm1-amip-suite/937) 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

---

<div class="post-metadata">

**Author:** ![mdalvi](https://avatars.discourse-cdn.com/v4/letter/m/ad7895/32.png) [@mdalvi](https://cms-helpdesk.ncas.ac.uk/u/mdalvi)\
**Post date:** [19 September 2024 11:03 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/2 "2024-09-19T11:03:59Z")

</div>

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)](https://code.metoffice.gov.uk/trac/um/ticket/6438#comment:22)

---

<div class="post-metadata">

**Author:** ![MYoshioka](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@MYoshioka](https://cms-helpdesk.ncas.ac.uk/u/MYoshioka)\
**Post date:** [19 September 2024 16:07 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/3 "2024-09-19T16:07:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mdalvi](https://avatars.discourse-cdn.com/v4/letter/m/ad7895/32.png) [@mdalvi](https://cms-helpdesk.ncas.ac.uk/u/mdalvi)\
**Post date:** [19 September 2024 16:22 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/4 "2024-09-19T16:22:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MYoshioka](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@MYoshioka](https://cms-helpdesk.ncas.ac.uk/u/MYoshioka)\
**Post date:** [20 September 2024 11:55 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/5 "2024-09-20T11:55:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mdalvi](https://avatars.discourse-cdn.com/v4/letter/m/ad7895/32.png) [@mdalvi](https://cms-helpdesk.ncas.ac.uk/u/mdalvi)\
**Post date:** [20 September 2024 12:12 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/6 "2024-09-20T12:12:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MYoshioka](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@MYoshioka](https://cms-helpdesk.ncas.ac.uk/u/MYoshioka)\
**Post date:** [20 September 2024 15:25 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/7 "2024-09-20T15:25:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://europe1.discourse-cdn.com/flex013/uploads/cms_support/original/1X/1fd2411499ffcbc299fe756cd5cdf26e44956558.png) [@system](https://cms-helpdesk.ncas.ac.uk/u/system)\
**Post date:** [20 October 2024 15:25 UTC](https://cms-helpdesk.ncas.ac.uk/t/ancillary-time-mean-lookup-items-1-12-are-not-compliant-with-umdp-f03/1523/8 "2024-10-20T15:25:41Z")

</div>

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