Relative Inter Cycle Dependencies

[oliver-sanders]

Note: Please update this example when addressing this issue.

With integer cycling the last cycle can be referenced by -P1, the second last with -P2 and so on. With date-time cycling we lose this functionality.

There are three ways we might want to write inter-cycle triggers with datetime cycling:

ISO8601 Duration

As we presently do though I'd suggest that this covers a small set of use cases:

    [T00]
        graph = foo[-P1D] => bar

Relative Cycle

As we presently do with integer cycling:

    [T00]
        graph = foo[-P1] => bar

Relative Cycle On Current Recurrence

Refer to the previous cycle on the current recurrence. Possible syntax:

    [T12]
        graph = foo
    [T00]
        graph = foo[-R1] => bar  # bar depends on foo from the previous T00
                                 # cycle.

Conclusions

Doing so would enable graph sections to be written independently of the recurrence with which they are implemented:

• This would help users to write more portable suites.
• This may also be of assistance to #1829.

Note that there is a runtime component to this as tasks will need to determine the cycle point at which their previous occurrence occurred ...

[oliver-sanders]

Another request for this today, see also https://github.com/cylc/cylc/wiki/Possible-Cylc-Futures#graphs

[matthewrmshin]

Ditto for runtime environment. A task may need to know:

• What cycle is my predecessor in?
• What cycle is my successor in?
• How long is the current cycle?
  • A cycle can be regarded as a duration of time starting from the current cycle point, and ending moment before the next cycle point.
  • In a climate suite, we may need to ask what is the final day of the current cycle?

[oliver-sanders]

(note the ability to specify "this task at it's last occurrence on any recurrence" would finally do away with the need for sequential tasks)

[dwsutherland]

Reposting form Element:

We have a[^] => b for relying on ICP tasks.. Perhaps we could also have [<] (and maybe [>]) to depend on the the previous (or next) instance of a task, e.g:

    [[graph]]
        T01, T03, T07 =  a[<] => a

This means we can deprecate [scheduling][special tasks]sequential, but can also be used with other than self:

    [[graph]]
        T01, T03, T07 =  a
        T02, T05, T11 = a[<] => b

Not sure if we'd want to take this any further though, i.e. [<2] (2 occurrences ago)

[Dooruk]

I see it is a long withstanding issue but just wanted to say this would be something quite useful for our Cylc dependent workflow as well!

[MetRonnie]

From #6739

Another possibility could be to plug in the existing next()/previous() functionality which can currently only be used in the initial cycle point setting. E.g.

[scheduling]
  [[graph]]
    # 1st of the month:
    01T00 = extract
    # Every day:
    P1D = extract[previous(01T00)] => process