Opened 4 months ago

Closed 7 weeks ago

#2150 closed help (answered)

timestamp of .pa and monthly .pd files

Reported by: eelrm Owned by: um_support
Priority: normal Component: UKCA
Keywords: timestamp, STASH Cc: gmann
Platform: ARCHER UM Version: 8.4



I have found that although I simulate volcanic eruptions on July 1st, the output suggests they occur on 30th June.

I've conducted an ensemble of simulations (UKCA vn8.4 atmosphere-only, timeslice) of different sized volcanic eruptions where the eruption is specified to occur on 1st July - day 181 (30 day months).

Much of the output is set to go to monthly .pd files and when I look at the output anomaly, it is the June mean .pd file in which the volcanic perturbation is first seen. When traced back to the daily .pa files, the volcanic signal is first seen in the June 30th .pa file.

However, the 1st July dump file appears to have the same data for both volcanically perturbed and base-run simulations, indicating that the eruption, does indeed occur July 1st.

I have been informed that there could be an issue with the time-stamp being incorrect for the daily .pa files. Is the .pa file for June 30th in fact for July 1st? As we see the anomaly in the June monthly .pd file, are these monthly means also out of sync by a day?

Is there a way to fix this?

Thank you,

Best wishes,


Change History (4)

comment:1 Changed 4 months ago by luke

Hi Lauren,

Sorry for the delay in replying.

Can you check the date associated with the fields in the file, and not the filename? I suspect that this probably has something to do with time conventions, i.e. which day does midnight fall-in? Is it the start of one day or the end of the previous day?

The UM convention is for the midnight to be dated at the start of the next day, but it will be stored in a daily re-initialised file where the name of the file dates it for the previous day. This is for instantaneous fields.

However, when doing things like daily means, I believe that a similar convention applies, in that midnight is dated as the following day, but may be contained for meaning in the previous values, e.g. an emission that starts at midnight will have a small contribution turn up in the daily (and monthly, and seasonally, and annual, and decadal) means for the previous period.

Would you be able to check when exactly your emission is due to occur? Could this be the issue?


comment:2 Changed 3 months ago by eelrm

Hi Luke,

Thanks for your reply. Our emission is indeed from midnight so that looks like the issue.

The bounds on the date for the files run from midnight to midnight - does this mean that midnight could be included in the meaning for both days?



comment:3 Changed 3 months ago by luke

Hi Lauren,

Sorry for my delay in replying.

I don't believe so, as this would lead to double-counting. I think it is probably

midnight < t <= midnight

for averaging.

Try emitting from the first timestep after midnight (00:20 for N96L85) and seeing if this solves your issue.


comment:4 Changed 7 weeks ago by grenville

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

Closed for lack of activity

Note: See TracTickets for help on using tickets.