Re-evaluate the --initial/final/start/stop-cycle-point options for restarts

[MetRonnie]

The ignore value for the cycle point cli options (--icp=ignore, --startcp=ignore etc) for cylc play are potentially confusing, and the behaviour is a little inconsistent.

Final cycle point

When the scheduler shuts down, the final cycle point is saved to the database (edit: only if the CLI opt --fcp was used to set it, not if it was only specified in flow.cylc). On restart, this DB value is loaded.

--fcp=ignore causes Cylc to ignore the value stored in the DB, and instead use the value in flow.cylc[scheduling]final cycle point. The two might be different:

• If the cli option --fcp=<point> was used in a previous run to override flow.cylc (then the cli-supplied value would have be saved in the DB).

Issues

• If the workflow has reached the final cycle point in a previous run, it has basically packed up and gone home, so --fcp won't do anything. Possibly this just needs to be documented clearer. (Doc PR: Add docs for cycle point options in restart cylc-doc#362)

These apply to all 4 types of cycle point:

• The name ignore is potentially misleading, as one might get the idea it will basically set the final cycle point to None. Maybe --*-cycle-point=reload/refresh/reset is clearer? However, the cycle point is reloaded from flow.cylc[scheduling] anyway if not previously set in the cli*. (Resolved in Change 'ignore' to 'reload' for cycle point cli opts #4313)

Initial cycle point

Initial cycle point is handled in much the same way as final cycle point. However, this time there is a second way the value stored in the DB might be different from flow.cylc[scheduling]:

• If flow.cylc[scheduling]initial cycle point = now or next() or previous(), in which case the timepoint is evaluated at the time of first start and stored in the DB

Issues

• In a restart, you can't change the initial cycle point using the cli opt. Any value for --icp=<point> apart from ignore will raise an error. However, you could in fact change the initial cycle point in flow.cylc[scheduling]. So why not using the cli opt? (Resolved: --icp option not valid for restart since Change 'ignore' to 'reload' for cycle point cli opts #4313)

Start cycle point

Similar to above, but there is no way of specifying the start cycle point in flow.cylc.

Issues

• It looks like --startcp=ignore doesn't actually do anything? The start point for a restart is whatever the last incomplete cycle point at shutdown was. (Resolved: --startcp=ignore/reload not valid since Change 'ignore' to 'reload' for cycle point cli opts #4313)

Stop cycle point

Issues

• --stopcp=ignore is inconsistent with the others. While it ignores the stop cycle point in the database, it doesn't use [scheduling]stop after cycle point, it instead uses the final cycle point (from the database if set there, otherwise flow.cylc). I think it should be changed to use [scheduling]stop after cycle point if set, otherwise the final cycle point. (Make --stopcp=reload use [scheduling]stop after cycle point instead of the final cycle point #4543)

---

*Apart from stopcp which is only reloaded from flow.cylc if not stored in the DB (which is the case if it was not set, or it was set but was reached)

[MetRonnie]

In a restart, you can't change the initial cycle point using the cli opt. Any value for --icp=<point> apart from ignore will raise an error. However, you could in fact change the initial cycle point in flow.cylc[scheduling]. So why not using the cli opt?

Coming back to this, I'm pretty sure --icp=ignore doesn't do anything and will raise a point parsing error

[MetRonnie]

The 2 questions that I think we should come to a decision on for 8.0rc1:

In a restart, you can't change the initial cycle point using the cli opt. Any value for --icp=<point> apart from ignore will raise an error. However, you could in fact change the initial cycle point in flow.cylc[scheduling]. So why not using the cli opt?

--stopcp=ignore is inconsistent with the others. While it ignores the stop cycle point in the database, it doesn't use [scheduling]stop after cycle point, it instead uses the final cycle point (from the database if set there, otherwise flow.cylc). I think it should be changed to use [scheduling]stop after cycle point if set, otherwise the final cycle point.

[hjoliver]

I'm struggling to remember exactly why we have these as CLI options. Even setting the ICP on the command line, as opposed to changing it in the config file, is a pretty minor convenience with a significant downside: the installed config file doesn't reflect what actually got run. Maybe the need for it is less now that we have proper workflow installation built in??

[oliver-sanders]

I think this is low priority and can be bumped to 8.x?

[MetRonnie]

Proposal (need to decide whether to implement this for 8.0rc1):

• Change --stopcp=reload option to use [scheduling]stop after cycle point (falling back to the final cycle point) instead of just using the final cycle point outright (this current behaviour makes even less sense now that ignore has been changed to reload)

---

As for the initial cycle point bit, I have checked, and in #4313 I made the --icp option entirely illegal for restarts. I think this is enough to tick off that part of the issue?

[MetRonnie]

All points addressed now