pretty much all my workflows (presumably same as most weather and climate users) have cycle points of the form…
for climate workflows, the cycle points almost always fall at midnight on the 1st of the month, i.e.
just wondering how possible it would be to make
cylc interpret truncated datetimes? so for example…
199901 <---> 19990101T0000Z
1999 <---> 19990101T0000Z
cycle points almost always fall at midnight on the 1st of the month
If it’s almost you might find it tricky. If it’s actually always you can set
flow.cylc[scheduler]cycle point format. I think that in your case
CCYYMM will achieve what you want.
If you can’t use this, can you give me more context about where you’d want to use the truncated format?
Is there a specific case where using a truncated datetime is not working for you? In general, Cylc does indeed support truncated datetimes.
Jonny’s referring to reduced precision datetimes (i.e. truncated from the right) rather than what Cylc refers to as truncated datetimes (i.e. truncated from the left).
[scheduler]cycling point format is the way to go for this case.
Ok yes, we should be clear about the terminology. But regardless, Cylc interprets
20000101T0000Z in most circumstances without having to set the cycle point format. Setting the cycle point format has the additional effect of printing all cycle points in that format and means you cannot use precision greater than the smallest unit in the format
thanks a lot for all the information @MetRonnie & @oliver.sanders!
the application that i’d be interested in setting up and/or finding out more about is using the command line
cylc tools. i probably should’ve said that in my original post! e.g. at the moment i use commands like this a lot (already using the assumed
runN shorthand before the
cylc log u-cy821//19780101T0000Z/fcm_make_lfric
and it would be handy to be able to type…
cylc log u-cy821//197809/fcm_make_lfric
… for example.
i think i probably don’t want to start messing around with the format of the dates in the workflows themselves since my work is so highly collaborative and i don’t want to make unilateral decisions for other users.
basically i was wondering if there is a way of making the
cylc command line arguments assume that something happens at
01T000Z or even
0101T0000Z unless told otherwise!
hope that makes sense!
That’s not possible. However, you can use bash auto completion: https://cylc.github.io/cylc-doc/8.2.1/html/reference/changes.html#bash-completion
cylc log (aka
cylc cat-log) is a special case - the cycle point in the ID you type has to match the job log file path (but as Dave mentioned, it can be autocompleted).
But commands like
cylc trigger etc. accept partially specified cycles e.g.
cylc hold u-cy821//1978-09/fcm_make_lfric
(note you have to use the dash between the year and month)
oh cool, didn’t know this!
it’s not working for me out of the box for some reason though
i’ll look into it, thanks @dpmatthews
good to know! playing around with this, i’ve found that this works (as you mentioned)…
cylc tr u-cy821/runN//1978-09/install_ainitial
and this one too…
cylc tr u-cy821/runN//19780901/install_ainitial
but this one doesn’t…
cylc tr u-cy821/runN//197809/install_ainitial
why does my first example above need a dash between
working now! thanks to @hilary.j.oliver!
for future ref…
cylc get-resources cylc-completion.bash <path-to-copy-file>
then put this in your
.bashrc or equivalent…
if [[ $- =~ i && -f /path/to/cylc-completion.bash ]]; then
I think it’s because that’s interpreted as the year 197809 rather than September 1978
ah ok, makes sense, even if that is something of a sci-fi date!