swift2.api.actionsets.TaskGraphKernelWrappers Namespace Reference

Functions
	construct_touch_vertex_first_time_call (current_species_set, touch_vertex_first_time_kernel, use_multilevel_dependencies)
	Take the kernel to be used in touch first time and wrap into tasks.
	construct_touch_cell_first_time_call (current_species_set, touch_cell_first_time_kernel, use_multilevel_dependencies)
	Wrap cell kernel into task.
	construct_touch_vertex_last_time_call (current_species_set, touch_vertex_last_time_kernel, use_multilevel_dependencies, alter_particle_position_or_interaction_radius)
	Wrap vertex kernel into task.

Function Documentation

construct_touch_cell_first_time_call()

swift2.api.actionsets.TaskGraphKernelWrappers.construct_touch_cell_first_time_call	(		current_species_set,
			touch_cell_first_time_kernel,
			use_multilevel_dependencies )

Wrap cell kernel into task.

Consult the documentation of construct_touch_vertex_first_time_call() for a discussion of the task orders.

In principle, the handling cells is straightforward: We take the \( 2^d \) adjacent vertices and exatract their task numbers, and then we also add an additional task number for the parent cell if we have multi-level dependencies.

Capture rules of lambda

Please consult the documentation of construct_touch_vertex_first_time_call().

Definition at line 134 of file TaskGraphKernelWrappers.py.

References peano4.toolbox.api.EnumerateCellsAndVertices.construct_marker_name().

Here is the call graph for this function:

construct_touch_vertex_first_time_call()

swift2.api.actionsets.TaskGraphKernelWrappers.construct_touch_vertex_first_time_call	(		current_species_set,
			touch_vertex_first_time_kernel,
			use_multilevel_dependencies )

Take the kernel to be used in touch first time and wrap into tasks.

As we work with task dependencies, I decided to always spawn tasks, even if these degenerate to empty ones as no particles are associated to a vertex. Otherwise, it just became a nightmare. Notably note that the kernel is not empty in most cases, as it is enriched with Swift dependency tracking anyway.

Multiscale task order

In terms of multiscale dependencies, we impose the following order:

• touchVertexFirstTime(): Touch all associated particles for the first time. At this point, touchVertexFirstTime() on corresponding coarser levels has to be complete.
• touchCellFirstTime(): Handle all particles within the cell. At this point the corresponding first touch of every particle has to be finished.
• Recurse
• touchVertexLastTime(): At this point, touchVertexLastTime() on all finer levels has to be complete.

Realisation

• Get the task number to be used (corresponding to TouchVertexFirstTime).
• Allocate the set of in dependencies from coarser level if a multiscale algorithm is used.
• Issue task.
  

If we build up one task graph per algorithmic step, there's no particularly interesting details left: The underlying observer with its action sets will yield a touch first-vertex first-vertex first-cell-vertex last-vertex last sequence. The last "vertex last" event will be followed by a global waitForAllTasks() call, and therefore we are ready to for the subsequent mesh sweep. All the "vertex first" calls will use the same task number. The second "vertex first" task therefore will have an in-out dependency on this number.

If we roll around, i.e. build up a task graph over multiple mesh sweeps, no such strategy will work, as we have to insert a "vertex last"-"vertex first" dependency in-between any two sweeps. This fact is ignored here and left to the user. Indeed, consult MultisweepTaskGraph for details on how they handle these wrap-around dependencies.

Capture rules of lambda

The task bodies as injected by Swift work with the object's attributes and also with references. Both things are not really copied by a capture = clause: The references are copied, but still point to the same, temporary object. The accesses to object attributes are internally mapped onto this->attribute and hence the pointer this is copied, but not the attribute itself.

All of the rules are detailed in https://en.cppreference.com/w/cpp/language/lambda#Lambda_capture.

Therefore, we have to explicitly copy the task-relevant attributes, and we even use an explicit initialiser to do so.

Definition at line 8 of file TaskGraphKernelWrappers.py.

References peano4.toolbox.api.EnumerateCellsAndVertices.construct_marker_name().

Here is the call graph for this function:

construct_touch_vertex_last_time_call()

swift2.api.actionsets.TaskGraphKernelWrappers.construct_touch_vertex_last_time_call	(		current_species_set,
			touch_vertex_last_time_kernel,
			use_multilevel_dependencies,
			alter_particle_position_or_interaction_radius )

Wrap vertex kernel into task.

Consult the documentation of construct_touch_vertex_first_time_call() for a discussion of the task orders. Multiple things have to be taken into account here:

• We add dependencies to all \( 2^d \) adjacent cells. Their tasks have to be completed before we start our work. This is notably important if we are on the finest mesh level, i.e. the marker is not refined. But it never hurts to add these dependendices.
• We then add dependencies for finer levels (see discussion below).

Once these two types of dependencies are in, we can spawn the task.

The tricky part in this routine is the identification of fine grid dependencies. We don't have access to the fine grid data at this point anymore. So what we have to do instead is memorising the dependencies that will be established from fine to coarse on the finer level. We use

std::set<::swift2::TaskNumber> parentTasks = getVertexNumbersOfParentVertices(

to find out the tasks of the up to \( 2^d \) parent tasks. Those are not yet spawned, as their touchVertexLastTime() will come later when we ascend in the tree. Therefore, we memorise that we have to add these later as in-dependencies in the underlying action set's _pendingDependencies attribute.

Capture rules of lambda

Please consult the documentation of construct_touch_vertex_first_time_call().

Definition at line 232 of file TaskGraphKernelWrappers.py.

References peano4.toolbox.api.EnumerateCellsAndVertices.construct_marker_name().

Here is the call graph for this function: