search

cylc / cylc-flow

Cylc: a workflow engine for cycling systems.
https://cylc.github.io
GNU General Public License v3.0
329 stars 93 forks source link

Set n-window extent: default and current value (non-GUI) #6377

Open hjoliver opened 6 days ago

hjoliver commented 6 days ago

We're getting quite a few requests for this, and it would be easy to do (and of course, we do plan to do it ... this probably features in an existing issue somewhere, but I failed to find it).

Currently the default is fixed (n=1) and users can only change it via the GUI.

Users need to be able to:

The appropriate (or at least the maximum appropriate) n-window extent is kinda workflow-dependent, and possibly user-dependent (e.g. for users who typically only run small workflows), so I think it would make sense to set the default n-window extent via both a global and workflow config item.

oliver-sanders commented 1 day ago

The n-window extent is intended to be a client (GUI, Tui) property, it was never intended to be a scheduler property, so configuring it there doesn't really make sense. The n-window generation code needs to be moved out of cylc-flow into cylc-uiserver (higher priority), but we haven't found the time to do this yet. With current memory management issues at the UIS allowing higher values to be configured by default is a bit of an issue.

ColemanTom commented 1 day ago

I don't know that you need to be able to change the displayed n-window from CLI, but, it would be useful to be able to do various non-UI commands, that rely on the n-window being set, without having to do things via the UI. I think cylc show for example relies on the UI n-window. So, being able to do cylc show --n-window=3 ... as an example I think would make sense.

hjoliver commented 1 day ago

The n-window generation code https://github.com/cylc/cylc-uiserver/issues/464 (higher priority), but we haven't found the time to do this yet.

Yes but I'm concerned that we're unlikely to get this done any time soon. It is quite a big change, and there are reasons why the datastore ended up in the scheduler in the first place (as a rather long term interim measure!). Plus, as you note, we need to put effort into UIS efficiency before attempting that.

hjoliver commented 23 hours ago

Trying to think of some way forward that would work now and in the future.

It's quite important to have a workflow-specific default n-window extent. Some users run small and large workflows. For large workflows it is bad to have a large default N, but for small ones it is annoying to have a small default that you just change up immediately every time. Even saving workflow-specific N value changes in the client is not ideal, because it's more of a workflow thing than a client thing (is this workflow sufficiently big that we should have a very small window by default, or not?).

Having default n-window extent as a workflow config item doesn't necessarily imply configuring the scheduler. It could be treated as workflow metadata that determines the initial window extent in the scheduler (now) or in the UIS (future).