 |
Peano
|
|
Peano
|
Holds a sequence of Task instances. More...
Public Member Functions | |
| __init__ (self) | |
| add_task (self, Task task) | |
| List[Task] | find_tasks (self, *tags) |
| Return all tasks of this graph which carry at least one of the tags, in the order in which they have been added to the graph. | |
| insert_after (self, Union[Task, List[Task]] anchors, Task task) | |
| Insert a task directly after one or several anchors. | |
| List[Task] | ordered_tasks (self) |
| Linearise this graph's tasks into the order peano4.api.taskgraph.compiler.Sequential.translate() compiles them into: a straightforward recursive traversal of the dependency DAG (visit a task's dependencies before the task itself), which - since every dependency is visited before whatever depends on it - yields a valid topological order. | |
| log_as_text (self, str title="Task graph") | |
| Textual counterpart to visualise(): logs a plain-text rendering of this task graph through peano4.api.Logger(), for LoggerVerbosity.TEXT runs, where a matplotlib window is neither wanted nor - in a batch/ non-interactive run - even possible. | |
| visualise (self, str title="Task graph") | |
| Render this task graph with matplotlib as a UML state diagram: one rounded-rectangle state per task, a solid transition arrow from every dependency to the task that depends on it. | |
Data Fields | |
| tasks | |
Static Protected Member Functions | |
| bool | _depends_on (Task task, Task other) |
| True if task depends on other, directly or indirectly. | |
| peano4.api.taskgraph.Graph.Graph.__init__ | ( | self | ) |
Definition at line 16 of file Graph.py.
References peano4.api.taskgraph.Graph.Graph.tasks.
| peano4.api.taskgraph.Graph.Graph.add_task | ( | self, | |
| Task | task | ||
| ) |
Definition at line 19 of file Graph.py.
References peano4.api.taskgraph.Graph.Graph.tasks.
| List[Task] peano4.api.taskgraph.Graph.Graph.find_tasks | ( | self, | |
| * | tags | ||
| ) |
Return all tasks of this graph which carry at least one of the tags, in the order in which they have been added to the graph.
A task which carries several of the tags is returned only once.
| tags | str One or several tags, i.e. strings which the tasks hold in their set tags (peano4.api.taskgraph.Task.Task). |
Definition at line 22 of file Graph.py.
References peano4.api.taskgraph.Graph.Graph.tasks.
Insert a task directly after one or several anchors.
The routine adds task to the graph and makes it depend on all anchors. All tasks which have depended on any of the anchors so far depend on task instead. Consequently, task runs after the anchors but before anything that used to follow them.
Use this routine to add a step to a task graph which someone else has built, e.g. to postprocess the outcome of a task. task should not depend on any other task yet, unless these dependencies run before the anchors anyway.
Pass several anchors if several tasks produce one outcome together. The optimistic Finite Volumes, for example, write the new solution either in one task or in another, depending on the cell. A single task inserted after both runs once per cell, after whichever of the two has updated this cell. The anchors must not depend on each other, neither directly nor indirectly, as the redirection would create a cycle otherwise.
| anchors | peano4.api.taskgraph.Task or List[peano4.api.taskgraph.Task] One task or a list of tasks of this graph. |
| task | peano4.api.taskgraph.Task The new task. It must not be part of the graph yet. |
| peano4.api.taskgraph.Graph.Graph.log_as_text | ( | self, | |
| str | title = "Task graph" |
||
| ) |
Textual counterpart to visualise(): logs a plain-text rendering of this task graph through peano4.api.Logger(), for LoggerVerbosity.TEXT runs, where a matplotlib window is neither wanted nor - in a batch/ non-interactive run - even possible.
Renders the same information visualise() draws as a UML state diagram - every task's grid entity, its dependencies, its action sets (as "do / <name>" lines), the cell/face/vertex submodels it declares via use_cell()/use_face()/use_vertex() (each annotated with its Task.DataAccess qualifier) and whether it repeats - as one block of text per task, ordered root to sink by dependency depth exactly like visualise() lays its layers out top to bottom.
Definition at line 144 of file Graph.py.
References peano4.api.taskgraph.Graph.Graph.tasks.
| List[Task] peano4.api.taskgraph.Graph.Graph.ordered_tasks | ( | self | ) |
Linearise this graph's tasks into the order peano4.api.taskgraph.compiler.Sequential.translate() compiles them into: a straightforward recursive traversal of the dependency DAG (visit a task's dependencies before the task itself), which - since every dependency is visited before whatever depends on it - yields a valid topological order.
This is the single source of truth for "the task after this one" that both translate() and peano4.api.taskgraph.compiler.PropagateUseStatements.propagate_use_statements() rely on; they must agree on the same order, since the latter's whole job is to reason about which task's Observer immediately follows which other one's once compiled.
Repeated calls recompute the order from scratch (cheap - task graphs here are small) rather than caching it, so adding further tasks/dependencies after an earlier call is always reflected.
Definition at line 108 of file Graph.py.
References peano4.api.taskgraph.Graph.Graph.tasks.
| peano4.api.taskgraph.Graph.Graph.visualise | ( | self, | |
| str | title = "Task graph" |
||
| ) |
Render this task graph with matplotlib as a UML state diagram: one rounded-rectangle state per task, a solid transition arrow from every dependency to the task that depends on it.
Tasks are laid out top to bottom by dependency depth (a task without dependencies sits at the top; everything that - directly or transitively - depends on it sits below it), so following the transitions always moves downwards, exactly like reading a state diagram's flow of control. The tasks of one layer sit side by side: every task sits straight below its leftmost dependency and is moved to the right only where it would otherwise overlap another task.
A filled black circle - the UML initial pseudostate - transitions into every task that has no dependencies; every task nothing else depends on transitions into a bullseye - the UML final pseudostate. A task with has_to_repeat set (i.e. not None) is additionally drawn with a small self-transition loop right of its state, the standard UML notation for "this state can re-trigger itself", labelled with the task's has_to_repeat string itself.
Every action set attached to a task (
Every state also carries a small coloured badge in its top-left corner indicating which kind of grid entity (vertex/face/cell/ global) the task works on; a legend below the title spells out what each colour means, restricted to the entity kinds actually used in this particular graph.
Opens a blocking matplotlib window; close it to continue.
Definition at line 205 of file Graph.py.
References peano4.api.taskgraph.Graph.Graph.tasks.
| peano4.api.taskgraph.Graph.Graph.tasks |
Definition at line 70 of file Graph.py.
Referenced by peano4.api.taskgraph.Graph.Graph.__init__(), peano4.api.taskgraph.Graph.Graph.add_task(), peano4.api.taskgraph.Graph.Graph.find_tasks(), peano4.api.taskgraph.Graph.Graph.log_as_text(), peano4.api.taskgraph.Graph.Graph.ordered_tasks(), and peano4.api.taskgraph.Graph.Graph.visualise().
1.9.8