I've been talking (hopefully not erroneously) using phrases like "teed up in memory", and "tasks the scheduler is thinking about".

"pool" doesn't imply contiguous graph

If it's a typing/taxi/subprocess pool as opposed to a filing system (the rest of the graph) this works well - if it's a pool of water then it's not unreasonable to expect it to be a contiguous thing, and it's not: Extending that analogy leads to task puddles. For Pythony people this is probably not a problem, but I don't know if other languages use the word pool in the same way.

We've been using "spawn" and "remove" for these forever.

How about loaded/archived ? I think this hints at the relationship between the pool and the graph...

You get a 🐸 for mention spawning to a pool: Presumably 🐸 + 🔥 (flame wars) = 🦎 (salamander)

I'm not sure we actually need to expose the task pool and spawn terminologies to users.

I more or less agree on "spawn" - it's not too hard to avoid that, but we can't avoid calling the task pool something.

we only need to explain what n=0 means

Exactly, that's what I'm talking about! The term "n-window" doesn't really mean anything to the scheduler, it's a GUI thing. But nevertheless, the GUI n-window is centered on the scheduler task pool. So what do we call that?

"Active window" is problematic for the reasons above. I think "scheduler task pool" is fine (for the other reasons above) but I'm open to other ideas if you have any.

We have to call it something! We really need to clean up the documentation in this respect before doing the big 8.3.0 evangelising of the new intervention methods etc.

I'm not sure we actually need to expose the task pool and spawn terminologies to users.

I more or less agree on "spawn" - it's not too hard to avoid that, but we can't avoid calling the task pool something.

we only need to explain what n=0 means

Exactly, that's what I'm talking about! The term "n-window" doesn't really mean anything to the scheduler, it's a GUI thing. But nevertheless, the GUI n-window is centered on the scheduler task pool. So what do we call that? What exactly is the "pool" of tasks displayed by cylc dump or by the GUI when n=0?

"Active window" is problematic for the reasons above. I think "scheduler task pool" is fine (for the other reasons above) but I'm open to other ideas if you have any.

But we have to call it something! We really need to clean up the documentation in this respect before going all out on evangelizing 8.3.0 intervention methods etc.

For stalls, it's easy enough to say that Cylc could not proceed further through the graph (no need for pool terminology).

What I was getting at here is that stalls are caused by tasks that are retained in the the scheduler task pool, which is very much in the face of users as the basis of the n-window. And so failed tasks (e.g.) will always be visible regardless of the value of n, unlike others which recede into the past.

The difference in task matching is something that we plan to address in the near future.

Unfortunately, that ain't gonna be done in time for 8.3.0. I need to be doing migration seminars at NIWA (and possibly elsewhere) as soon as we release 8.3.0.

And anyway, even if we can make all commands task pool agnostic, that won't eliminate the central reason for the user-facing nature of the task pool: it is "all the tasks that the scheduler is currently actively managing", and it is the basis/center of the GUI n-window.

For stalls, it's easy enough to say that Cylc could not proceed further through the graph (no need for pool terminology).

What I was getting at here is that stalls are caused by tasks that are retained in the the scheduler task pool, which is very much in the face of users as the basis of the n-window. The fact that they are retained in task pool is what keeps them visible regardless of how far back in the graph they are.

The difference in task matching is something that we plan to address in the near future.

Unfortunately that ain't gonna be done in time for 8.3.0. I need to be doing migration seminars at NIWA (and possibly elsewhere) as soon as we release 8.3.0.

But in any case, even if we can make all commands entirely task pool agnostic, that won't eliminate the central reason for the user-facing nature of the task pool: it is the basis/center of the GUI n-window.

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool as:

• the pool of tasks currently under active management by the scheduler
• and the n=0 basis of the GUI n-window

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

Feel free to suggest other names for "task pool", but we have to call it something in order to describe what Cylc does (to users!).

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool as:

• the pool of tasks currently under active management by the scheduler (note "under active management" doesn't necessarily matter in itself to users, but it is the justification/explanation for the task content of n=0)
• and the n=0 basis of the GUI n-window

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

Feel free to suggest other names for "task pool", but we have to call it something in order to describe what Cylc does (to users!).

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool as:

• the pool of tasks currently under active management by the scheduler (note "under active management" doesn't necessarily matter in itself to users, but it is the justification/explanation for the task content of n=0)
• and the n=0 basis of the GUI n-window

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

Feel free to suggest other names for "task pool", but we have to call it something in order to describe what Cylc does (to users!). I'm doubtful there's anything better that we haven't thought of yet.

I'm not sure we actually need to expose the task pool and spawn terminologies to users.

I more or less agree on "spawn" - it's not too hard to avoid that, but we can't avoid calling the task pool something.

we only need to explain what n=0 means

Exactly, that's what I'm talking about! The term "n-window" doesn't really mean anything to the scheduler, it's a GUI thing. But nevertheless, the GUI n-window is centered on the scheduler task pool. So what do we call that? What exactly is the "pool" of tasks displayed by cylc dump or by the GUI when n=0? And how do we explain the task content of n=0?

"Active window" is problematic for the reasons above. I think "scheduler task pool" is fine (for the other reasons above) but I'm open to other ideas if you have any.

But we have to call it something! We really need to clean up the documentation in this respect before going all out on evangelizing 8.3.0 intervention methods etc.

For stalls, it's easy enough to say that Cylc could not proceed further through the graph (no need for pool terminology).

What I was getting at here is that stalls are caused by tasks that are retained in the the scheduler task pool, which is very much in the face of users as the basis of the n-window. The fact that they are retained in task pool is what keeps them visible regardless of how far back in the graph they are.

The difference in task matching is something that we plan to address in the near future.

Unfortunately that ain't gonna be done in time for 8.3.0. I need to be doing migration seminars at NIWA (and possibly elsewhere) as soon as we release 8.3.0. And we need to have the documentation sorted out accordingly by them.

But in any case, even if we can make all commands entirely task pool agnostic, that won't eliminate the central reason for the user-facing nature of the task pool: it is the basis/center of the GUI n-window.

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool as:

• the n=0 basis of the GUI n-window, which is:
• the pool of tasks currently under active management by the scheduler
  • (and explain what kind of tasks it comprises)
  • (note "under active management" doesn't necessarily matter in itself to users, but it is the justification/explanation for the task content of n=0)

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

Feel free to suggest other names for "task pool", but we have to call it something in order to describe what Cylc does (to users!). I'm doubtful there's anything better that we haven't thought of yet.

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool as:

• the n=0 basis of the GUI n-window, which is:

• the pool of tasks currently under active management by the scheduler

  • (and explain what kind of tasks it comprises)
  • (note "under active management" doesn't necessarily matter in itself to users, but it is the justification/explanation for the task content of n=0)

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

Feel free to suggest other names for "task pool", but we have to call it something in order to describe (to users) what Cylc does and what they see in the UIs. I'm doubtful there's anything better that we haven't thought of yet.

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool(*) as:

• the n=0 basis of the GUI n-window, which is:
• the pool of tasks currently under active management by the scheduler
  • (and explain what kind of tasks it comprises)
  • (note "under active management" doesn't necessarily matter in itself to users, but it is the justification/explanation for the task content of n=0)

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

(*) Feel free to suggest other names for "task pool", but we have to call it something in order to describe (to users) what Cylc does and what they see in the UIs. I'm doubtful there's anything better that we haven't thought of yet.

For stalls, it's easy enough to say that Cylc could not proceed further through the graph (no need for pool terminology).

What I was getting at here is that stalls are caused by tasks that are retained in the the scheduler task pool, which is very much in the face of users as the basis of the n-window. The fact that they are retained in task pool is what keeps them visible regardless of how far back in the graph they are.

The difference in task matching is something that we plan to address in the near future.

Unfortunately that ain't gonna be done in time for 8.3.0. I need to be doing migration seminars at NIWA (and possibly elsewhere) as soon as we release 8.3.0. And we need to have the documentation sorted out accordingly by then.

But in any case, even if we can make all commands entirely task pool agnostic, that won't eliminate the central reason for the user-facing nature of the task pool: it is the basis/center of the GUI n-window.

Final end-of-the day comment on this:

I'm not sure we actually need to expose the task pool and spawn terminologies to users... we only need to explain what n=0 means

oliver sanders are you suggesting we call the task pool "n=0" instead of "the task pool"? I'm not entirely averse to that, although it seems a little nonsensical when the GUI is not involved ("n edges out from what?"). But even that would just be a different name for the same concept, which is, like or not, "the pool/group/whatever of tasks that the scheduler is actively managing at this moment" - that is what I don't think we can realistically avoid referring to (by whatever name) in the docs, for the reasons above.

Final end-of-the day comment on this:

I'm not sure we actually need to expose the task pool and spawn terminologies to users... we only need to explain what n=0 means

oliver sanders are you suggesting we call the task pool "n=0" instead of "the task pool"? I'm not entirely averse to that, although it seems a little nonsensical when the GUI is not involved ("n edges out from what?"). But even that would just bd a different name for the same concept, which is, "the pool/group/whatever of tasks that the scheduler is actively managing at this moment" - that is what I don't think we can realistically avoid referring to (by whatever name) in the docs, for the reasons above.

Final end-of-the day comment on this:

I'm not sure we actually need to expose the task pool and spawn terminologies to users... we only need to explain what n=0 means

oliver sanders are you suggesting we call the task pool "n=0" instead of "the task pool"? I'm not entirely averse to that, although it seems a little nonsensical when the GUI is not involved ("n edges out from what?"). But even that would just bd a different name for the same concept - i.e., "the pool/group/whatever of tasks that the scheduler is actively managing at this moment"_ .

In reply to @revilo666:matrix.org

proposal - for 8.3.0 docs

Can we agree on this:

(A) We define the scheduler task pool(*) as:

• the n=0 basis of the GUI n-window, which is:
• the pool of tasks currently under active management by the scheduler
  • (and explain what kind of tasks it comprises)
  • (note "under active management" doesn't necessarily matter in itself to users, but it is the justification/explanation for the task content of n=0)

(B) We ditch the word "spawn":

• tasks enter the task pool (e.g. when their first prerequisite becomes satisfied)
• tasks exit or leave or are removed from the task pool when no longer needed

(*) Feel free to suggest other names for "task pool", but we have to call it something in order to describe (to users) what Cylc does and what they see in the UIs. I'm doubtful there's anything better that we haven't thought of yet.

Hey all, I want to get on with documentation tweaks for 8.3.0. I'll take the lack of response to this to mean no one had major objections or counterarguments. One adjustment though, on looking closer, "spawn" is the right user-facing term to describe how the flow advances when outputs are completed - see https://github.com/cylc/cylc-flow/pull/6067#discussion_r1580076467

As an aside, oliver sanders famously claims to dislike terminology debates (despite being the prime offender other than myself, - "it takes two to tango" as the saying goes!) but really it's unavoidable and fundamentally a good thing - how else can we settle on the best way to describe and explain these sometimes quite subtle concepts.