Gregorian Emissions

Hi,

I have created a new set of emissions, which are on a 360 day calendar and I would like to use them in a nudged run (365 day calendar). I have ensured that calendar flexible is set to 1 and so assumed this would allow them to run similar to the CMIP6 emissions, but I am getting the error: EM_GET_TIME_REC: File starts 1750 1 1 0 0 0 630000 0
???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!
? Error code: 241
? Error from routine: UKCA_NC_EMISS_MOD:GET_EMFILE_REC
? Error message: Invalid time record 2, End-of-file reached ?
? Error from processor: 0
? Error number: 77

I think this is one of my new files as they have the reference date of 1750, but they begin in 2000 (with the time offset of 90015 days to take us up to January 15th 2000, on a 360 day calendar). As this is running out of file, my guess is that the model is assuming a 365 day calendar, which takes us to June 1996 instead (I think this is how the maths works!). How can I make sure it reads the dates as I expect?

Also, I note in the documentation this text “As for UM ancillary files, when converting the calendar there is no scaling of the data performed to conserve total annual emissions: it is for the user to ensure that the file contains the total emissions they require. Such scaling would only be recommended for long-lived species for which accumulated emission (over years/decades) is more important than the emission rate itself (over seconds/days).” Can I confirm that this is suggesting that the long-lived species files are multiplied by a factor of 365/360?

Thanks,

Hannah

Hi Hannah,

Yes, for your 2nd question re scaling. That is how I have seen the calendar conversions done in the past.

For your actual error the cylc-run/suite-name/work/date-time/atmos_main/pe_output/ files should have more detail: possibly the filename, and the values the model is actually seeing.
For timeseries data I have in the past also updated the timestamps using cdo/nco to match the origin and stride for the Gregorian calendar. However, the ‘calendar_flexible=1’ is supposed to signal the model to ‘intelligently’ do the conversion. Hence it will be useful to see what the pe_output is showing.

Mohit

Hi Mohit,

Thank you! The output helped me realise that I was trying to run January 1st but my emissions were from the 15th.

Do you have an example of where the scaling has been done before? I’m guessing I need to do CH4, Me2CO, C2H6 and CO as these are my species where avg lifetime > 1 month, but want to check!

Thanks,

Hannah

Hi,

I cannot produce the whole script here, but the scaling was applied to each monthly mean value as:

ndays_in_month = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]

do i = 1, 12 ! months

value_monthly_out = value_monthly_in * ndays_in_month[i] / 30.0

end do

Re your files, for the CMIP6 emissions the 1850-2014 files were constructed by prepending 1850 as 1849 and 2014 as 2015 to allow for the interpolation between middle of first and last months.

Hi Mohit,

Just a quick question on this, I can see if this ticket here https://code.metoffice.gov.uk/trac/ancil/wiki/ukca/NetcdfEmissions, there is discussion of this month to month scaling ‘Timeseries plots: ​http://www-hc/~hadtq/emissions/cmip5-2000-v2. The strange month-to-month variation in these plots is because they were scaled by the length of Gregorian month when converting calendar to conserve the total emission in each month. This was an unfortunate choice and shouldn’t be repeated; in any case we have decided not to scale emissions of SLCF for calendar conversion in future.’

From what I have read, CMIP5 emissions were scaled by 365/360 but the CMIP6 emissions were not. Based on the comments on this ticket, I am wary of scaling month to month as suggested in the last reply. Is this the common practice?

I also can’t see on the roses tickets anyone who has switched to Gregorian calendar and changed emissions files (except SO2_natural and CH4_biomass). I have the calendar flexible in the ones I have made, I am just confused about this re-scaling as I cannot find it being done!

Thanks,

Hannah

Hi Hannah,

The excerpt above was from one of the CMIP5 emission processing scripts, so not sure what the ticket above is referring to.

Looking further at the CMIP6 emission processing code, it looks like here was no scaling applied to any species (except for CH4) when converting between calendars.

For further details on the processing you might have to ask one of the original developers of the ticket about the recommended method.

Mohit

Hi Mohit,

Thank you. I have used a copy of the CMIP6 processing code to create my emissions and can also see this code loop about the convert_to_calendar_360. My emissions all have the 360 day calendar and have calendar_flexible set to 1. CH4 has calendar_flexible set to 0 so I think this loop of code is being followed:

if convert_to_calendar_360:
# 2. Convert calendar (and scale to conserve total flux for CH4).
time_flexible = 1
for time in times:
calconv.convert_cube_calendar(time, calendar=“360_day”)
if “CH4” in species.upper():
days_per_year_365d = 365.0
days_per_year_360d = 360.0
time.data = time.data * days_per_year_365d / days_per_year_360d
time_flexible = 0

Based on this, I am assuming no additional post-processing scaling by me needs doing anymore? I may need to use these emissions also for a 360 day calendar one, but perhaps this code can be rerun and produce just gregorian emissions? I can see the revisions were made by harolddyson is this who you would suggest contacting?

Thanks,

Hannah

Hi Hannah,

From what I can follow on the CMIP6 documentation, the source data was on 365-day calendar, but the final emission files were created for 360-day calendar without any scaling, except in case of CH4 where the total was adjusted.

I mean’t the members who actually processed the data to create files CMIP6/ForcingData – ANCIL

Harold is one of the owners for the Ancil codebase, but might not have been involved in the ‘science’ decisions for the processing.

Mohit

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