added family grouping plus family and cycle collapsing #1810
Conversation
|
Still to do (in order of priority).
|
|
Im struggling with grouping by families due to the fact that they can be nested ... The contextCollapsing and Expanding nodes is easier as the .dot file just needs the node/s added/removed .... and the edge (relationship between the node and other nodes) defined... This means I dont have to directly deal with a hierarchy (nested structure) as things are just being added/removed. For grouping the syntax is a little different, using subgraphs ... For grouping by cycle point there are no nested cycle points (doesnt make sense) so its just a case of making subgraph for each cycle. The subgraphs do need to account for the fact that the nodes may have been expanded or collapsed but that can be managed by calculating what nodes need to be included from the The problemThe problem is with nested grouping which is relevant for
The way this is represented in the .dot code is by having subgraphs within subgraphs...
The above is an simple example of some graphviz code for a simple nested family situation. Below is an example for a more complicated one... The subgraphs can be I have thought about giving each node a ranking in terms of how 'deep' it is in the hierarchy then ranking from most deep to least deep then looping through ... but this wont work because (as in the example above) you would miss out a lot of the graph |
|
I think this is a problem that warrants recursion as it's tricky to unroll as an iterative loop. Here's an idea of what that could look like (Python syntax):
from random import random
TASKS = {
'foo': {
'name': 'foo',
'parent': 'FOO',
},
'FOO': {
'name': 'FOO',
'parent': 'root'
},
'bar': {
'name': 'bar',
'parent': 'BAR1',
},
'baz': {
'name': 'baz',
'parent': 'BAR2',
},
'BAR1': {
'name': 'BAR1',
'parent': 'BAR',
},
'BAR2': {
'name': 'BAR2',
'parent': 'BAR',
},
'root': {
'name': 'root',
'parent': None,
},
}
TREE = {
'root': {
'FOO': None,
'BAR': {
'BAR1': None,
'BAR2': None,
},
},
}
def add_subgraph(dotcode, pointer, graph_sections):
for key, value in pointer.items():
dotcode.append(
f'subgraph cluster_{str(random())[2:]} {{'
f'\nlabel = "{key}"'
)
if value:
add_subgraph(dotcode, value, graph_sections)
if key in graph_sections:
dotcode.extend(graph_sections[key])
dotcode.append('}')
return dotcode
def get_dotcode(tasks):
graph_sections = {}
for task in tasks.values():
parent = task['parent']
if not parent:
continue
section = graph_sections.setdefault(parent, [])
section.append(f'{task["name"]} [title="{task["name"]}"]')
dotcode = ['digraph {']
add_subgraph(dotcode, TREE['root'], graph_sections)
return dotcode
for item in get_dotcode(TASKS):
print(item)digraph {
subgraph cluster_23300787190407446 {
label = "FOO"
foo [title="foo"]
}
subgraph cluster_5025488657295563 {
label = "BAR"
subgraph cluster_2135762450670372 {
label = "BAR1"
bar [title="bar"]
}
subgraph cluster_4413670667138756 {
label = "BAR2"
baz [title="baz"]
}
BAR1 [title="BAR1"]
BAR2 [title="BAR2"]
}I haven't taken cycles into account in this solution, you'll need to add a This solution will also add entries for families which have no tasks, so, you'll need some fancy logic for removing empty families, and any families that contain only empty families. |
markgrahamdawson
force-pushed
the
family-subgraphs
branch
from
21472f9 to
e45ccec
Compare
markgrahamdawson
force-pushed
the
family-subgraphs
branch
from
f1540f6 to
676466f
Compare
|
@wxtim This is normally as a result of an uncaught error which will be visible in the console |
| // If yes - we want to include in the grouping | ||
| this.groupFamily.includes(child.node.name) && | ||
| // But if its collapsed then we dont want to group it | ||
| // We dont put boxes around collapsed nodes - design choice |
There was a problem hiding this comment.
I'd question that design choice, but I'm guessing that it's been thrashed out?
I think that collapsed nodes should retain the box to indicated that it's not just a single task. Moreover, that the state icons are coloured task-state icons not job icons.
| .find('.graph:first .edges:first') | ||
| .children() | ||
| .should('have.length', 10) | ||
| .should('be.visible') |
There was a problem hiding this comment.
Consider checking that you have the failed task icon in here?
| .should('be.visible') | |
| .should('be.visible') | |
| .get('.failed') |
|
I've left a workflow running all day in the background with this display on and haven't noted any indication of slowdown. |
| allParentLookUp () { | ||
| const lookup = {} | ||
| for (const namespace of this.namespaces) { | ||
| const array = [] | ||
| let parent = namespace.node.firstParent | ||
| while (parent) { | ||
| const childTokens = this.workflows[0].tokens.clone({ cycle: `$namespace|${parent.name}` }) | ||
| const childNode = this.cylcTree.$index[childTokens.id] | ||
| array.push(childNode.name) | ||
| parent = childNode.node.firstParent | ||
| } | ||
| lookup[namespace.name] = array | ||
| } | ||
| return lookup | ||
| }, |
There was a problem hiding this comment.
I tried jamming a console.log statement in here and found that this function gets called every time the graph updates. I.E, we're recomputing the lookup even when the namespaces aren't changing.
The cause of this appears to be erroneous namespace deltas, nothing to do with this PR, see cylc/cylc-flow#6689.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Hopefully fixed with |
I have unfortunately found an similar issue with cycles Collapsed families and grouped by cycle Collapsed families and grouped by cycle... and then collapse by a cycle
however two collapsed cycles do have edges between each other
|
There was a problem hiding this comment.
I have created a short-lived feature branch for this and changed the base. I am happy for the PR to be merged into this branch and will open some follow-up PRs to address some technical debt.
We may also hold off merging the feature branch into master until cylc/cylc-flow#6689 is addressed.
oliver-sanders
merged commit 2d48deb
into
cylc:graph-group-collapse
Partly addresses issue #1130
The grouping of nodes by cycle point is completed in this pr #1763
----Notes on work----
Some ideas for a unified approach to grouping/collapsing cycles/families. I'm suggesting unifying the handling of cycles and families (note, cycles represent the "root" family so they are essentially the same thing).
Grouping/Ungrouping - Drawing dashed boxes around a cycle/family.
Collapsing/Expanding - Reducing a family down to a single node.
Limitations of the Cylc 7 approach:
Note, for simplicity, this approach groups/collapses all instances of selected families rather than managing this at a per-cycle level. I think this is probably more aligned with expectations, but does represent a minor limitation, e.g. there's no ability to collapse all but one cycle. The ability to expand/collapse specific cycle instances would be a reasonable enhancement.
Design Sketch
Had a quick discussion on this (more to come):
Check List
CONTRIBUTING.mdand added my name as a Code Contributor.setup.cfg(andconda-environment.ymlif present).CHANGES.mdentry included if this is a change that can affect users?.?.xbranch.