Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#2787 closed help (fixed)

Start year issues

Reported by: ChrisWells Owned by: um_support
Component: UM Model Keywords:
Cc: Platform:
UM Version:



I've been trying to run a copy of the Historical UKESM suite (mine is u-bg346; copy of u-), but I can't get the emissions files to work.

I get the error:

???!!!???!!!???!!!???!!!???!!!       ERROR        ???!!!???!!!???!!!???!!!???!!!
?  Error code: 1983
?  Error from routine: GET_EMFILE_REC
?  Error message: Invalid time record 2, End-of-file reached ?
?  Error from processor: 574
?  Error number: 55

I've seen this before in #2679 - it's because at least one of my ancil files has the wrong time, and must be set with update_type = 1 (from here

Also the error code 1983 should be the timestep (i.e. month) of the file in question, and as I'm running at 2015, whereas it was at 1850 before, and (2015-1850)*12 = 1980 months, it must be a monthly file that's set at 1850 instead.

But I've been through ukca_em_files, and can't see a file which is causing the error. Is there a systematic way of seeing all the files taken in by this routine, so I can find the file(s) causing the error?


Change History (16)

comment:1 Changed 2 years ago by grenville


Your model stops when trying to run time step 1080 which is Model time: 2015-01-16 00:00:00.

Your emission files have unusual monthly mean timings, some fields are at midday on the 16, some at midnight on the 15th - the periodic files that you have not altered all use midnight on the 16th.

It feels a bit suspicious that your model fails on Jan 16 at 00:00:00 and there is no data at that time. I suggest correcting all the emission files to use 16th at 00.


comment:2 Changed 2 years ago by ChrisWells

Hi Grenville,

Thanks for the tip! I thought I'd changed the dates of the files to make them right, but now the model fails with the same error, code 2 this time, and I can't see why at all.

Do you know if I might have edited the emissions files wrong?

Many thanks,

comment:3 Changed 2 years ago by grenville

please switch print status to Extra diagnostic messages (search for PRINT_STATUS in the rose gui)
and set prnt_writers to All tasks write — resubmit


comment:4 Changed 2 years ago by ChrisWells

Hi Grenville,

I've done that, and ran the model - but I can't see any more useful info. I can't see timestep-resolution output in the .out files, or useful output in the .err ones. Do you know where this might be?


comment:5 Changed 2 years ago by ChrisWells

Hi Grenville,

I've noticed something odd with the times in the CMIP6 files, in /projects/ancils/cmip6/ancils/n96e/timeslice_1850/AerosolChemistryEmissions/v3/

If you dump the time data, it starts from 36015 which makes sense (days since 1750 are 360 *100, plus 15 to get to 15th Jan), but then there are differences.

Some have

time = 36015, 36044, 36075, 36105, 36135, 36165, 36195, 36225, 36255, 36285, …

and some have

time = 36015.5, 36044, 36075.5, 36105, 36135.5, 36165, 36195.5, 36225.5, …

Some are days from 1850 so are shifted, but still have odd features e.g.

time = 15.5, 44, 75.5, 105, 135.5, 165, 195.5, 225.5, 255, 285.5, 315, 345.5 ;

So it seems some are always integer days (midday on 16th), and some are 0.5-off sometimes (midnight on 16th). What is common to all of them is that the 2nd timestep is shifted back by 1 compared to what is expected.

It's the same with the 2014 timeslices and the 1850-2014 timeseries files.

So the reason my files are as they are originally is because I edited copies of the 1850-2014 timeseries files to make them.

It seems the model is ok with the .5-out days, but the 2nd timestep being early is common to all. The model failed with error code 2 (2nd timestep) when I edited the times to be strictly every 30 (i.e. overrode this early 2nd timestep, as well as the 0.5-out times), so it seems this is necessary?

So I'm a bit confused, but I'm probably back to my original error - what should I do from here?


comment:6 Changed 2 years ago by luke

Hi Chris,

The UKCA emissions (and indeed, any periodic or timeseries UM ancillary file) define monthly-means to be dated as the middle of the month. For a 30-day month this is therefore midnight on the 16th. For 31-day months this is 12noon on the 16th, for February this is midnight on the 15th (28-day month) or 12noon on the 15th (29-day month for leap-years).

The code should work perfectly well with either 360-day or Gregorian calendars used in the emissions, although there might be some slight differences in monthly totals coming about from the time interpolation. The End-of-file reached error usually means that you have a timeseries file that is dated to end prior to the current model date, i.e. there is no data available for the interpolation (which does not extrapolate, so will fail once it hits the final date in the file).

What is the current error? Also look in the job.out file (or the pe_output/fort6 files) as there may be an informative error message printed just prior to the error message.


comment:7 Changed 2 years ago by grenville


has update_type = 2

but only one time value

that looks incorrect.


comment:8 Changed 2 years ago by ChrisWells

Hi both,

Thanks for the tip Grenville - I've changed that but that file has worked before so it might still be expected to work. I'll see what happens though.

Thanks for the info Luke. So if I run now I get

?  Error from routine: GET_EMFILE_REC?  Error from routine: GET_EMFILE_REC
???!!!???!!!???!!!???!!!???!!!       ERROR        ???!!!???!!!???!!!???!!!???!!!

?  Error message: Invalid time record 2, End-of-file reached ?

All the processors give the same, i.e.

???!!!???!!!???!!!???!!!???!!!       ERROR        ???!!!???!!!???!!!???!!!???!!!
?  Error code: 2
?  Error from routine: GET_EMFILE_REC
?  Error message: Invalid time record 2, End-of-file reached ?
?  Error from processor: 4
?  Error number: 56

I changed u-bg346 to have the constant 30-day intervals, and ahve u-bg441 with my original files, but both now give me the above error.

Do you know what I should do?


comment:9 Changed 2 years ago by ChrisWells

just an update - running with update_type=0 on the dummy SO2 file doesn't fix the issue.


comment:10 Changed 2 years ago by grenville

ncdump -h /home/d00/chwel/emissions/cmip6/emissions/historical/control/2006-2015/

still say says update_type = 2

comment:11 Changed 2 years ago by luke

This is just a dummy file (hence the name) so doesn't need to be changed. You can just use one of the standard ones here, e.g.:


Here update_type = 0.

comment:12 Changed 2 years ago by grenville

Have you changed suites?

comment:13 Changed 2 years ago by ChrisWells

Hi sorry for the confusion Grenville, I made a file called /home/d00/chwel/emissions/cmip6/emissions/historical/control/2006-2015/ (note the which I ran in a copy of the suite, u-bg451, with the same error. This was to not mess up any suites which use the old file, incase that would impact them.

So I still have the issue.


comment:14 Changed 2 years ago by ChrisWells

Hi both,

I think I've fixed this. I'd not changed some files (e.g. VolcanoAod?, VolcanoSad?, NitrogenDeposition?); they were timeseries 1850-2014 and my model was failing at start of 2015. Changing them to continuous (2014) files seems to have fixed this.

I'll close this trac now.


comment:15 Changed 2 years ago by ChrisWells

  • Resolution set to fixed
  • Status changed from new to closed

comment:16 Changed 2 years ago by grenville


Glad you found the problem.


Note: See TracTickets for help on using tickets.