With the deprecation of max active cycle points the runahead limit now controls, as I see it, two separate scheduling factors:
Future runahead: how far ahead of clock time will the suite activate cycle points?
Past runahead: how far ahead of the lagging active cycle point will the suite activate cycle points?
You could actually make a case that cylc needs 4 variables to control these factors, to permit control both in terms of cycle points and in terms of time. But certainly I’m having a hard time figuring out how to get my suite to behave with only a single variable. The specific symptoms are that my (cylc7-compatible) suite specifies runahead limit = PT12H which applies to the forecast case. but if I am running the suite retrospectively, that runahead limit overrides the max active cycle points (which in cylc8 I can no longer specify separately) and the suite activates every cycle point up to the final cycle point. The scheduler then bogs down because of hundreds of active cycle points.
How far ahead of clock time will the suite activate cycle points?
Infinitely far.
The cycle point is a label: Unless you have clock triggers the workflow does not interact with the real world clock. Climate modelling wouldn’t work otherwise.
How far ahead of the lagging active cycle point will the suite activate cycle points?
The docs say:
The base point of the runahead calculation is the lowest-valued point with active or incomplete tasks present.
The specific symptoms are
I’m not quite sure I understand your case. It is possible that you’ve found some bug in compatibility mode, so lets investigate.
As far as I can see runahead limit = PT12H should only cause every cycle point to spawn to final cycle point if that point is < PT12H away. Can you boil your workflow down to a toy example along the lines of:
#suite.rc
[scheduling]
initial cycle point = ???
final cycle point = ???
# max active cycle points = ??? # n.b you can only have this...
runahead limit = PT12H # .. or this, not both
[[dependencies]]
[[[<recurrence>]]]
graph = foo # is there any inter-cycle dependency?
Both of these configured how far ahead of the oldest active cycle the workflow could run, the runahead limit in date-time syntax (e.g. the workflow may run 12 hours ahead), the max active cycle points in integer syntax (e.g. the workflow may run 12 cycles ahead).
Note max active cycle points was a poor choice of name as it didn’t actually control the number of cycle points which were permitted to be active, but the number of cycle points after the oldest.
At Cylc 8 runahead limit = P4 is exactly the same as max active cycle points = 5 at Cylc 7.
which in cylc8 I can no longer specify separately
You could not use these two configurations in combination in Cylc 7 either, you would get this error:
ERROR: use 'runahead limit' OR 'max active cycle points', not both
Since these two configurations are both configuring the same thing in different ways (and are mutually exclusive) we combined them.
To toggle behaviour for cases like this, use a Jinja2 variable:
{% if retrospect %}
runahead limit = P4 # i.e. max active cycle points = 5
{% else %}
runahead limit = PT5D
{% endif %}
the suite activates every cycle point up to the final cycle point
This definitely sounds wrong. We recently fixed an issue which could potentially cause this sort of problem. The fix is in Cylc 8.2.2.
If Cylc is still running more cycles than your expecting (with version 8.2.2), could you post a snippet of your flow.cylc file and we’ll investigate it.
