Keep completed tasks in the active window ? (GUI)

Cylc Cylc Support
1

Hi everyone,

For debugging, I’d like to keep completed tasks visible in the GUI after they slide out of the ‘active window’. Is it in any way possible?
I understand that it would be unpractical in a production setting, but I’m developping a workflow and just learning, so that would be very helpful.

Thanks!

2

Hi Elliot!

You can change the “N window” in the gui: In the workflow window go to the Burger bar and look for “set graph window extent” - this brings up a dialog allowing you to see more of the non active graph - N-edges from active tasks.

image
image1039×823 100 KB

You may also find cylc graph useful to produce static visualizations of the workflow. Personally I like the -c (highlight cycles) option.

1 Like
3

Note, be careful not to set this number too high it can put a lot of load on the scheduler.

We plan to provide easier access to historical task information in future releases.

2 Likes
4

Thank you very much @wxtim , that worked !

That’s good to hear @oliver.sanders. I’ll look out for future releases. :smile:

5

Hi there Devs,

Very nice work on Cylc and thanks for the hints described above. I wanted to ask a follow up on this–is it possible to set a default value for graph window extent, say in global.cylc, flow.cylc, or a jupyter config file? I wasn’t able to find any information about that in the docs, but apologies if it is already described somewhere. I find myself changing this first thing every time I open the GUI, and I don’t see a way to set this in the TUI–though I have noticed that the TUI will use the GUI value.

Thanks!

6

Thanks @deitrr !

No, we haven’t exposed that (changing the n-window extent) except in the GUI. Although it is actually a pretty trivial thing to do, so we might be able to up the priority.

I’ve posted an issue on the repository: Set n-window extent: default and current value (non-GUI) · Issue #6377 · cylc/cylc-flow · GitHub

Currently the content of the active window is computed and maintained in the scheduler, which is why changing it in the GUI affects what you see in TUI as well (as you’ve observed).

The default is low (n=1) because a high value would be bad for very large workflows. Computing the window is quite expensive, and graph layout (for the GUI graph view) is prohibitively expensive, for very large graphs.

7

Awesome, thanks @hilary.j.oliver !

Good to know about the performance, I will be sure to watch out for that. Our current use cases don’t generally have very large graphs, it is just nice to see a few more steps away from the current active tasks.