Opened 5 weeks ago

Last modified 2 weeks ago

#2933 new help

Postproc time mismatch

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

Description

Hello,

I've had some difficulty postprocessing UM output. My suite u-bi879 is set up to automatically post process output on ARCHER.

The log file:
/home/n02/n02/lre/cylc-run/u-bi879/log/job/20080201T0000Z/postproc/03/job.err

indicates a mismatch between the expected and provided time formats. It looks like the postproc script (main_pp.py) is trying to postprocess some daily data but is using a monthly mean file:

[WARN] Iris Module is not available
[ERROR] Validity time mismatch in file /work/n02/n02/lre/cylc-run/u-bi879/share/data/History_Data/bi879a.pm2008feb to be archived

—> Expected [2008, 2, 1, 0, 20, 0] and got [2008, 3, 1]

[FAIL] Command Terminated

Any insights into what might have caused the time mismatch would be great.

Thanks,

Leighton.

Change History (21)

comment:1 Changed 5 weeks ago by grenville

Hi Leighton

You are using post-proc2.3, which is untested (by us). I see what's happening but do not know why; I'll need to consult with the authors of the code - that may take some time.

Can you revert to post-proc 2.2 and use the UM internal climate meaning?

Grenville

comment:2 Changed 5 weeks ago by grenville

Hi Leightonj
correction - post-proc 2.3 is fine - leave that as is, revert to UM climate meaning?

grenville

comment:3 Changed 5 weeks ago by grenville

Arrrgh - pl don't do anything yet - still trying things out

Grenville

comment:4 Changed 4 weeks ago by grenville

Hi Leighton

I suggest that you do revert to traditional climate meaning until we have fully tested the new version. It doesn't seem to be playing nicely with archiving.

Grenville

comment:5 Changed 4 weeks ago by Leighton_Regayre

Hi Grenville,

Thanks for taking the time to explore this problem and for the advice. This suite is a copy of the UKESM1-A so was originally set up with CMIP6 diagnostics. Can you give me any advice on which time profiles are causing the meaning problem so I can remove them? I'm not sure what "traditional climate meaning" implies.

I'm planning to use a copy of this suite as the base model for a large perturbed parameter ensemble (PPE), for which postprocessing will be really useful.

Thanks,

Leighton.

comment:6 Changed 4 weeks ago by grenville

Hi Leighton

The model can be configured to create climate means (typically, monthly, seasonal, annual, decadal) through internal functions to deal with maintaining partial sums over restarts etc - that is the traditional way; later suites do away with this, instead creating climate means in a post-processing step (this is the bit which is still unfamiliar to us.)

Do you need climate means at all - the model is configured to create monthly means directly from STASH?

Grenville

comment:7 Changed 4 weeks ago by Leighton_Regayre

Hi Grenville,

The daily and monthly means created in the traditional manner will be fine for our purposes.

My motivation for wanting to use the post-proccessing app is to automatically transfer the large amount of data created on /work over to /nerc and/or JASMIN. Is that possible without using the climate meaning aspects fo the post-processing app? Do I simply turn OFF the "create_*_mean" switches in the "File transformation" panel of the post-processing app?

Thanks,

Leighton.

comment:8 Changed 4 weeks ago by grenville

Leighton

Yes - in postproc→ atmosphere→file transformation, set create_means to false

Grenville

comment:9 Changed 4 weeks ago by Leighton_Regayre

Hi Grenville,

Perfect! I'll do that and see how it goes.

Thanks again,

Leighton.

comment:10 Changed 4 weeks ago by Leighton_Regayre

Hi Grenville,

I'm afraid the suite still fails in the post-processing step with the same "time mismatch" error, despite having create_means set to FALSE as recommended.

Is there an alternative to post-proc 2.3 that will move .pp files from /work to /nerc?

Thanks,

Leighton.

comment:11 Changed 4 weeks ago by grenville

Leighton

I have it on good authority (at the MO) that your suite runs correctly in its original configuration but with create_monthly_mean set to false. It may be that you have some files hanging about from a previous run? I am testing now with the original conifg.

Grenville

comment:12 Changed 4 weeks ago by Leighton_Regayre

Hi Grenville,

You could be right about redundant files hanging around and causing problems. I didn't clear the /work directory before rerunning the suite. I'm happy to do that now and retry my suite if that will save you time testing the original configuration.

Thanks,

Leighton.

comment:13 Changed 4 weeks ago by grenville

Please do - I need the experience with the new climate meaning, so will continue anyway.

comment:14 Changed 4 weeks ago by Leighton_Regayre

Hi Grenville,

I removed all related data from /work and /nerc folders related to this suite. The job still fails with the same "time mismatch" error, despite having create_means set to FALSE.

Before the error is a warning about an Iris Module not being available. Could this be related? There are no clues as to which Iris module is missing.

Thanks,

Leighton.

comment:15 Changed 4 weeks ago by grenville

Hi Leighton

snap - sorry this is frustrating progress; we are working on it with the MO.

Grenville

comment:16 Changed 3 weeks ago by grenville

Leighton

Odd one this - we were being misled by conflicting issues.
With climate meaning switched off in the post-proc app, you need to avoid having a pm stream, so change the filename_base for pp130 to something other than "….pm%C" (and not a stream already taken.)

I set this as '$DATAM/${RUNID}a.pw%C', and the validation error was fixed.

With climate meaning switched on, it's perfectly OK to have a pm stream (indeed necessary the way it's configured.)

We successfully ran your suite with climate meaning on (with create_monthly_mean = false (your original suite had this set to true, but monthly means come directly from the model)) with the pm monthly mean stream as set.

You can see output from my job on ARCHER at /home/n02/n02/grenvill/cylc-run/u-bi879, where I have used the pw stream for monthly means.

Grenville

comment:17 Changed 3 weeks ago by grenville

PS
You probably should avoid a ps stream too - s may be interpreted as a seasonal file with a particular header expected.

comment:18 Changed 2 weeks ago by Leighton_Regayre

Hi Grenville,

Thanks for making sense of this problem. It sounds like the climate meaning is very sensitive.

Could you clarify a few things for me please?
Are you saying that the climate meaning is calculating its own monthly, seasonal, annual and decadal means (depending on which switches I select)? Therefore, if I use "pm" for the "meanbase_stream" value it will cause conflict with the ".pm" output stream used for other diagnostics calculated by the model?

Are you suggesting I change the value of "meanbase_stream"?

My main purpose in using the postproc app is to automatically move existing output files from /work to /nerc. I wasn't planning to make additional files. Am I misusing the postproc app? Is there a simpler way to achieve an automated file transfer?

Thanks again,

Leighton.

comment:19 Changed 2 weeks ago by grenville

Leighton

Your model is configured to create monthly means directly from STASH. With appropriate switches set, the postproc app will create seasonal, yearly.. means; it will use monthly means in the pm stream to do that. The problem arises when climate meaning is switched off and an output stream is named with a pm prefix - that confuses the file conversion (to pp) in postproc. If you are happy with monthly means, change the filename_base to pw (say) - meanbase_stream is unused in this case. If you want seasonal, yearly means… leave all as it - just make sure you are not requesting monthly means in postproc climate meaning.

Grenville

comment:20 Changed 2 weeks ago by Leighton_Regayre

Hi Grenville,

I'm still not sure if I need to use postproc for this purpose. It sounds like new mean files will be created by the postproc app if I set the meanbase_stream to say pw, whereas I'd really just like to automate the move of existing daily and monthly mean files.

Is there a simple way to do that?

Thanks,

Leighton

comment:21 Changed 2 weeks ago by grenville

Hi Leighton

See comment 17 - no need to change meanbase_stream. Change filename_base for pp130

Grenville

Note: See TracTickets for help on using tickets.