One task within a peano4.api.taskgraph.Graph. More...

Data Structures
class	DataAccess
	How a task's action sets actually access a submodel it declares via use_cell()/use_face()/use_vertex() - i.e. More...

class	GridEntity
	Which kind of mesh entity a Task works on. More...

Public Member Functions
	__init__ (self, str name, "Task.GridEntity" entity, Optional[str] task_has_to_repeat=None, Optional[bool] may_spawn_background_tasks=None, Optional[Iterable[str]] tags=None)

	add_dependency (self, "Task" task)

	use_cell (self, "peano4.api.datamodel.DoF" submodel, "Task.DataAccess" qualifier)
	Declare that this task's action sets access a cell submodel (e.g.

	use_face (self, "peano4.api.datamodel.DoF" submodel, "Task.DataAccess" qualifier)
	Declare that this task's action sets access a face submodel, and how.

	use_vertex (self, "peano4.api.datamodel.DoF" submodel, "Task.DataAccess" qualifier)
	Declare that this task's action sets access a vertex submodel, and how.

	add_action_set (self, "peano4.api.solversteps.ActionSet" action_set)
	A task can hold an arbitrary number of Peano 4 action sets.

Data Fields
	name

	entity

	has_to_repeat

	may_spawn_background_tasks

Detailed Description

One task within a peano4.api.taskgraph.Graph.

Every task works on exactly one kind of mesh entity - a vertex, a face or a cell - which has to be specified through entity when the task is constructed. GLOBAL tasks are the exception: they do not work on any mesh entity (peano4.api.taskgraph.Task.Task.GridEntity).

Task dependencies

Every task also holds dependencies, i.e. other Task instances that have to be completed before this task can run. This sequence is empty by default; use add_dependency() to add further tasks to it.

Task action sets

Every task furthermore holds an arbitrary number of Peano 4 action sets (peano4.api.solversteps.ActionSet), i.e. the actual grid-sweep logic the task realises once it is compiled into an Observer. This sequence is empty by default; use add_action_set() to add further action sets to it. Their order matters - see peano4.api.solversteps.Step.add_action_set().

Task data usage

A task's action sets are handed mesh data (fineGridCell..., fineGridFace..., fineGridVertices...) as arguments once they are compiled into an Observer - but only for the vertex/face/cell submodels the surrounding peano4.api.solversteps.Step was told about via its own use_cell()/ use_face()/use_vertex(). An action set cannot make that declaration itself (several tasks, and hence several Steps, can share the same action set), so every task has to declare which submodels it needs through use_cell()/use_face()/use_vertex() below. The task graph compiler then forwards these declarations to the Step(s) it compiles this task into.

Task repetitions

Finally, a task can be marked as repeating via task_has_to_repeat. By default (None), a task runs once. Passing a non-None string works if and only if it is a valid boolean C++ expression. Peano will evaluate it on the global runner after the task has finished and then decide if to rerun this step. An all time classic is the following expression

not peano4::grid::isGridStationary( peano4::parallel::SpacetreeSet::getInstance().getGridStatistics() )

which means this task will repeat until the mesh becomes stationary.

Background tasks

Some task graph compilers can run parts of a task in the background, i.e. as tasks that outlive the mesh traversal event which spawns them (peano4.api.taskgraph.compiler.CellTaskProducerConsumer.translate_with_sequential(), peano4.api.taskgraph.compiler.CellTaskProducerConsumer.translate_with_fusion()). Such compilers check whether this is safe, and leave the task as it is if they cannot be sure. The flag may_spawn_background_tasks steers this behaviour:

None (default): The compilers decide whether running the task in the background is safe.
True: You know that running the task in the background is fine. The compilers skip their checks.
False: The task must never run in the background, e.g. as it reduces data in unprepareTraversal() such as a global CFL condition. The compilers leave the task as it is without any further check or warning.

Task tags

Every task carries a set of tags, i.e. of plain strings. A task can carry arbitrarily many tags at the same time. The task graph compilers ignore them. Tags allow the code which creates a task graph to tell other code what a task does, without that code having to know how the graph is built. Tags are global: Add a tag via task.tags.add(tag) and find all tasks with a tag via peano4.api.taskgraph.Graph.find_tasks(). ExaHyPE's numerical schemes, for example, tag all tasks which produce a new solution with exahype2.api.Solver.Solver.SolutionUpdateTaskTag, such that others can add postprocessing steps after them (Manipulate an existing solver's steps (e.g. inserting additional sweeps)). Use names with a prefix, e.g. the name of the defining class, so tags of different parties cannot clash by accident.

Task processing

The tasks will later on be taken by the graph compiler which maps them onto a sequence of peano4.api.solversteps.Step instances. How many of these logical steps (grid traversals) are required depends on the structure of the task graph but also the type of compiler chosen. Contraray, each action set that is added to a task will remain to be a real peano4.api.solversteps.ActionSet, and subsequently be translated into exactly one peano4.api.output.ActionSet, i.e. one pair of header and implementation file called MyFancyObserverOfAGridTraversal2ThisActionSet.

Things to read to get the full picture:

peano4.api.taskgraph This is the overall description of the task graph API and should be the starting point for understanding how to use it. It notably describes some design decisions re dependencies, grid entities and action sets.
Action sets and events
peano4.api.taskgraph

Definition at line 8 of file Task.py.

Constructor & Destructor Documentation

◆ init()

peano4.api.taskgraph.Task.Task.__init__	(		self,
		str	name,
		"Task.GridEntity"	entity,
		Optional[str]	task_has_to_repeat = `None`,
		Optional[bool]	may_spawn_background_tasks = `None`,
		Optional[Iterable[str]]	tags = `None`
	)

Definition at line 203 of file Task.py.

Member Function Documentation

◆ add_action_set()

peano4.api.taskgraph.Task.Task.add_action_set	(		self,
		"peano4.api.solversteps.ActionSet"	action_set
	)

A task can hold an arbitrary number of Peano 4 action sets.

Eventually the overarching task graph will be mapped onto a sequence of steps (observers) and those steps then grab those action sets from the tasks and execute them.

It is important to note that the action set passed in can define actions for multiple grid entities, while the task is specified over a particular mesh entity. This seems to be contradiction but is actually explained in peano4.api.taskgraph.

Definition at line 271 of file Task.py.

References peano4.api.solversteps.Step.Step.action_sets.

◆ add_dependency()

peano4.api.taskgraph.Task.Task.add_dependency	(		self,
		"Task"	task
	)

Definition at line 228 of file Task.py.

References exaparty.api.particle.AlgorithmStep.AlgorithmStep.dependencies.

◆ use_cell()

peano4.api.taskgraph.Task.Task.use_cell	(		self,
		"peano4.api.datamodel.DoF"	submodel,
		"Task.DataAccess"	qualifier
	)

Declare that this task's action sets access a cell submodel (e.g.

a peano4.api.datamodel.Patch registered via peano_project.datamodel.add_cell()), and how -

See also: Task.DataAccess for what qualifier to pass. Forwarded to the peano4.api.solversteps.Step this task is compiled into, i.e. to its own use_cell(), so the generated Observer passes fineGridCell<name> into every touch-cell/create-cell/... operation.

Definition at line 231 of file Task.py.

References peano4.api.datamodel.Model.Model.cell_data, peano4.api.solversteps.Step.Step.cell_data, tarch.plotter.api.input.PatchFileParser.UnknownAttributes.cell_data, peano4.api.solversteps.Step.Step.cell_data_access, and peano4.api.taskgraph.Task.Task.entity.

◆ use_face()

peano4.api.taskgraph.Task.Task.use_face	(		self,
		"peano4.api.datamodel.DoF"	submodel,
		"Task.DataAccess"	qualifier
	)

Declare that this task's action sets access a face submodel, and how.

See also: use_cell() for the general mechanism and Task.DataAccess for what qualifier to pass.

Definition at line 247 of file Task.py.

References peano4.api.taskgraph.Task.Task.entity, peano4.api.datamodel.Model.Model.face_data, peano4.api.solversteps.Step.Step.face_data, and peano4.api.solversteps.Step.Step.face_data_access.

◆ use_vertex()

peano4.api.taskgraph.Task.Task.use_vertex	(		self,
		"peano4.api.datamodel.DoF"	submodel,
		"Task.DataAccess"	qualifier
	)

Declare that this task's action sets access a vertex submodel, and how.

See also: use_cell() for the general mechanism and Task.DataAccess for what qualifier to pass.

Definition at line 259 of file Task.py.

References peano4.api.taskgraph.Task.Task.entity, peano4.api.datamodel.Model.Model.vertex_data, peano4.api.solversteps.Step.Step.vertex_data, and peano4.api.solversteps.Step.Step.vertex_data_access.

Field Documentation

◆ entity

peano4.api.taskgraph.Task.Task.entity

Definition at line 213 of file Task.py.

Referenced by peano4.api.taskgraph.Task.Task.use_cell(), peano4.api.taskgraph.Task.Task.use_face(), and peano4.api.taskgraph.Task.Task.use_vertex().

◆ has_to_repeat

peano4.api.taskgraph.Task.Task.has_to_repeat

Definition at line 222 of file Task.py.

◆ may_spawn_background_tasks

peano4.api.taskgraph.Task.Task.may_spawn_background_tasks

Definition at line 223 of file Task.py.

◆ name

peano4.api.taskgraph.Task.Task.name

Definition at line 211 of file Task.py.

Referenced by solvers.aderdg.kernels.Gemms.Gemms.__repr__(), test_derive_load_store_compute_flag._FakeSubmodel.__repr__(), test_propagate_use_statements._FakeSubmodel.__repr__(), exaparty.api.particle.ExplicitEulerFixedSearchRadius.ExplicitEulerFixedSearchRadius.__setup_algorithm_steps(), exaparty.api.particle.AlgorithmStep.AlgorithmStep.__str__(), exahype2.api.Solver.Solver.Plotter._add_time_interval_bookkeeping_to_solver(), exaparty.api.particle.LeapfrogFixedSearchRadius.LeapfrogFixedSearchRadius._setup_algorithm_steps_dict(), exagrype.api.CCZ4Solver.CCZ4Solver._tasks_of_this_solver(), peano4.api.datamodel.DoF.DoF.additional_load_and_store_arguments_for_other_dof(), exaparty.api.particle.ExplicitEulerDynamicSearchRadius.ExplicitEulerDynamicSearchRadius.algorithm_steps(), exaparty.api.particle.tests.DastgenTestDummyParticle.DastgenTestDummyParticle.algorithm_steps(), exahype2.api.Solver.Solver.Plotter.create_finish_call(), exahype2.api.Solver.Solver.Plotter.create_is_active_predicate(), peano4.api.solversteps.UserActionSet.UserActionSet.get_action_set_name(), peano4.api.taskgraph.compiler.fuse-steps-illustrations._IllustrationActionSet.get_action_set_name(), test_fuse_steps._FakeActionSet.get_action_set_name(), peano4.api.datamodel.DoF.DoF.get_full_qualified_type(), peano4.api.datamodel.DoF.DoF.get_logical_type_name(), peano4.api.solversteps.Step.Step.get_observer_class_name(), dastgen2.attributes.Enumeration.Enumeration.get_to_string(), and exaparty.api.particle.Particle.Particle.readme_descriptor().

The documentation for this class was generated from the following file:

src/peano4/api/taskgraph/Task.py

Data Structures

Public Member Functions

Data Fields