runahead limit vs max active cycle points

[oliver-sanders]

Out of a recent discussion over the Cylc suite configuration. The Cylc documentation refers to runahead limit as being deprecated though we have not formally deprecated the configuration in the schema.

On second thoughts runahead limit actually makes a lot more sense in many cases.

1. max active cycle points is really an implementation detail of the current task pool (which might not make so much sense in Cylc9) whereas runahead limit refers more explicitly to the data workflow itself rather than the Cylc implementation.
2. There is also the problem of modularity, when switching parts of a workflow on and off it would require introspection to work out how many cycles we should expect within a certain time period as required to set max active cycle points, whereas the runahead limit is not effected in this way.

[scheduling]
    runahead limit = P5D

[[dependencies]]
    [[[T00, T12]]]  # base workflow
{% if FOO %}
    [[[T06, T09, T18, T21]]]
{% endif %}
{% if BAR %}
    [[[T03, T09, T15, T21]]]
{% endif %}

[hjoliver]

OK, I'm happy to keep them both.

I'm pretty sure we had actually intended to deprecate runahead limit as documented. Way back then (if I recall correctly) runahead limit had to be specified in seconds regardless of the cycle interval, which was particularly stupid for (e.g.) climate suites. But post-ISO8601 that's not an issue.

I'm not entirely convinced by your points 1. and 2. The need for this kind of limit (max active OR runahead limit) is sort of an artefact of the task pool in that we have to prevent succeeded tasks from piling up without limit in between the fastest and slowest tasks. But if we still want or need that sort of limit at Cylc 9 we can still just collate and count the unique cycle points of current "active" tasks. Point 2. sort of make sense if you have a multi-cycle suite without clock triggers in every cycle, I suppose, but again maybe we don't need this kind of limit at all once the task pool is gone.
(However, that doesn't change the fact that we can keep both limit types for now).

[oliver-sanders]

OK, in which case this is a documentation issue, transferring to cylc-doc.