hey there,
i’m porting a job to cylc 8 and am getting this at cylc val time…
> cylc val .
WARNING - Cannot have more than 1 repetition for zero-duration
recurrence 19500101T0000Z.
Valid for cylc-8.1.4
19500101T0000Z is the 1st cycle point btw
it doesn’t stop the workflow but would be good to know what this means!
thanks for any tips
jonny
Recurrence expressions are what determine the cycling characteristics of each graph string in your workflow: Glossary — Cylc 8.2.0 documentation
In some of the recurrence formats you need to specify a cycle interval. For “run once” graph strings (R1 =...) it can be a zero interval (e.g. P0Y for zero years) to avoid confusing readers with a finite interval that is not meaningful for run-once. But for a cycling graph (e.g. R = ... or R3 = ...) a zero-interval will generate a warning.
R1 = "a => b" # OK
R1//P0Y = "a => b" # OK but pointless (in this case)
R3//P0Y = "a => b" # WARNING: can't repeat 3 times at the same cycle point!
ok thanks for that hilary! there are a few R1 = ... statements in the flow-processed.cylc` file (see below).
so i guess i need to combined these R1 = ... statements together?
thanks
[[graph]]
R1 = """
fcm_make_pp => fcm_make2_pp => POSTPROC_GROUP
fcm_make_ocean => fcm_make2_ocean => recon
fcm_make_um => recon
fcm_make_drivers => fcm_make2_drivers => coupled
install_ancil => recon
recon => coupled
"""
R1 = """
coupled[-P1Y] => coupled => POSTPROC_GROUP:succeed-all => housekeeping
postproc_atmos[-P1Y] => postproc_atmos
postproc_cice[-P1Y] => postproc_cice
postproc_nemo[-P1Y] => postproc_nemo
"""
[[graph]]
R1 = """
init_cfc_age_dump => coupled
"""
No, those R1’s look fine. You don’t have to combine them. There must be other parts of your graph that specify multiple repetitions with a zero interval?? (e.g. R//P0Y)
Although on closer look, there’s no point in having intercycle dependence (coupled[-P1Y] => coupled) in an R1 graph at the initial cycle point.
Here’s an example that causes your warning:
[scheduling]
initial cycle point = now
[[graph]]
R//P0Y = "foo => bar"
[runtime]
[[foo, bar]]
On validation:
$ cylc validate .
WARNING - Cannot have more than 1 repetition for zero-duration recurrence R//P0Y.
Note it prints the problem recurrence (R//P0Y).
The following example, i.e. an explicit date-time (or ^ - initial cycle point) with no R1, generates exactly your warning:
[scheduling]
initial cycle point = 1950
[[graph]]
^ = "foo => bar"
[runtime]
[[foo, bar]]
… and it fails validation as well, with
WorkflowConfigError: Cannot process recurrence 19500101T0000Z (initial cycle point=19500101T0000Z)
None of those are generating the warning. As Hilary has said, it would have to be something like R/1950/P0Y where the R/ means repeat indefinitely but the /P0Y means the interval is zero so there can be only 1 occurrence.
However I cannot reproduce your exact message with a workflow that passes validation, as 1950 by itself is not a valid recurrence, so I am curious as to how you achieved that
thanks @hilary.j.oliver @MetRonnie,
is there a way to strip out the graph = ... code on its own so i can try and debug this further. This is a pretty complex workflow for me and there are quite a new ‘include’ files in the flow.cylc which makes it a bit gnarly to debug.
thanks,
jonny
Is validation passing despite the warning, or is it failing with a fatal error?
If it is passing, you can use cylc config to view any part of the parsed configuration, including the graph. E.g. for a small example workflow:
$ cylc config -i '[scheduling]graph' demo/
R1 = build-model => model<m>
P1 = """
data => model<m>
model<m>[-P1] => model<m>
model<m>:file1 => post1<m>
model<m>:file2 => post2<m>
"""
If validation fails, the configuration is broken and can’t be parsed. In that case you can still use cylc view -j to view the Jinja2-processed configuration (before Cylc tries to parse it). Hopefully that will give a clean view of the graph. Otherwise you’ll have to resort to commenting bits of the graph out until you find the broken part.
the former 
…
> cylc val .
WARNING - Cannot have more than 1 repetition for zero-duration recurrence 19500101T0000Z.
Valid for cylc-8.1.4
the cylc config tip is great, don’t think i’ve used that before!
> cylc config -i '[scheduling]graph' .
WARNING: using wildcard entry for 'u-cy574' in /home/williamsjh/.cylc/projects
2023-07-28T03:58:41Z WARNING - Cannot have more than 1 repetition for zero-duration recurrence 19500101T0000Z.
R1 = """
fcm_make_pp => fcm_make2_pp => POSTPROC_GROUP
fcm_make_ocean => fcm_make2_ocean => recon
fcm_make_um => recon
fcm_make_drivers => fcm_make2_drivers => coupled
install_ancil => recon
recon => coupled
coupled[-P1Y] => coupled => POSTPROC_GROUP:succeed-all => housekeeping
postproc_atmos[-P1Y] => postproc_atmos
postproc_cice[-P1Y] => postproc_cice
postproc_nemo[-P1Y] => postproc_nemo
init_cfc_age_dump => coupled
"""
P1Y!^ = """
coupled[-P1Y] => coupled => POSTPROC_GROUP:succeed-all => py_for_afterburner => housekeeping
postproc_atmos[-P1Y] => postproc_atmos
postproc_cice[-P1Y] => postproc_cice
postproc_nemo[-P1Y] => postproc_nemo
"""
P1Y = """
postproc_nemo_grid[-P1Y] => postproc_nemo_grid
postproc_nemo_diaptr[-P1Y] => postproc_nemo_diaptr
postproc_nemo_ptrc[-P1Y] => postproc_nemo_ptrc
postproc_nemo_ptrd[-P1Y] => postproc_nemo_ptrd
"""
that’s the problem one.
Is that the exact form of the recurrence in the original Cylc 7 suite.rc? (In Cylc 7, it would be a sub-heading under [dependencies]…)
That looks reasonable (1 year cycle excluding the initial cycle point) … but I need to remind myself of how recurrence exclusions work…
ah cool, thanks, can confirm that is definitely the problem after commenting out that bit of the graph.
Is that the exact form of the recurrence in the original Cylc 7
suite.rc? (In Cylc 7, it would be a sub-heading under[dependencies]…)
yes it’s exactly as used in an equivalent `cylc’ 7 suite/workflow and was a change implemented by me (with help!).
That looks reasonable (1 year cycle excluding the initial cycle point) … but I need to remind myself of how recurrence exclusions work…
sounds good, it’s not stopping anything working but would be good to fix at some point. i have seen it in other workflows too which haven’t been edited by me so it’s not isolated.
cheers,
jonny
Interestingly,
^) not the main recurrence P1Y. (Exclusions can be full recurrences too - you might want to exclude one series of datetimes from another).Here’s an example that writes the same thing in 3 different ways:
[scheduler]
cycle point format = %Y
[scheduling]
initial cycle point = 3000
[[graph]]
P1Y ! ^ = "foo[-P1Y] => foo" # point exclusion - OK, with warning
P1Y ! R1/^/P0Y = "bar[-P1Y] => bar" # R1 recurrence exclusion - OK
R/^+P1Y/P1Y = "baz[-P1Y] => baz" # offset initial point - OK
[runtime]
[[foo, bar, baz]]
(And note, P1Y = <graph> is short for R/^/P1Y = <graph>)
Validation warns about the first one, but cylc graph shows they all do the same thing, which is start P1Y after the initial cycle point:
So I think the warning here is a bug that we need to look into. Thanks for the bug report!
Thanks for the bug report!
no worries, let me know if i can help at all.
cheers,
Track the bug fix here: Bad recurrence exclusion warning · Issue #5659 · cylc/cylc-flow · GitHub
@jonnyhtw - for the moment, an offset initial point, rather than an exclusion, is fine your use case (see my example above for task baz).
