Peano

Searching...

No Matches

Tree walker to realise particle-particle interactions with particles held by different adjacent cells or on different mesh levels. More...

Inheritance diagram for peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles:

[legend]

Collaboration diagram for peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles:

[legend]

Public Member Functions
	__init__ (self, particle_set, particle_particle_interaction_kernel, touch_vertex_first_time_compute_particle_update_kernel=None, touch_vertex_last_time_compute_particle_update_kernel=None, prepare_traversal_kernel="", unprepare_traversal_kernel="", additional_includes="", active_particle_set=None)
	Initialise object.

	get_body_of_operation (self, operation_name)
	Return actual C++ code snippets to be inserted into C++ code.

	get_body_of_getGridControlEvents (self)

	get_body_of_prepareTraversal (self)

	get_body_of_unprepareTraversal (self)

	get_action_set_name (self)
	Return unique action set name.

	user_should_modify_template (self)
	Is the user allowed to modify the output.

	get_includes (self)
	Return include statements that you need.

	get_attributes (self)
	Return attributes as copied and pasted into the generated class.

	get_constructor_body (self)
	Define a tailored constructor body.

Public Member Functions inherited from peano4.solversteps.ActionSet.ActionSet
	get_static_initialisations (self, full_qualified_classname)

	get_destructor_body (self)

Data Fields
	d

Data Fields inherited from peano4.solversteps.ActionSet.ActionSet
	descend_invocation_order

	parallel

Protected Attributes
	_particle_set

Static Private Attributes
	__Template_TouchVertexFirstTime

	__Template_TouchVertexLastTime

	__Template_TouchCellFirstTime

	__Template_TouchCellLastTime

	__Template_EndTraversal

Additional Inherited Members
Static Public Attributes inherited from peano4.solversteps.ActionSet.ActionSet
str	OPERATION_BEGIN_TRAVERSAL = "beginTraversal"

str	OPERATION_END_TRAVERSAL = "endTraversal"

str	OPERATION_CREATE_PERSISTENT_VERTEX = "createPersistentVertex"

str	OPERATION_DESTROY_PERSISTENT_VERTEX = "destroyPersistentVertex"

str	OPERATION_CREATE_HANGING_VERTEX = "createHangingVertex"

str	OPERATION_DESTROY_HANGING_VERTEX = "destroyHangingVertex"

str	OPERATION_CREATE_PERSISTENT_FACE = "createPersistentFace"

str	OPERATION_DESTROY_PERSISTENT_FACE = "destroyPersistentFace"

str	OPERATION_CREATE_HANGING_FACE = "createHangingFace"

str	OPERATION_DESTROY_HANGING_FACE = "destroyHangingFace"

str	OPERATION_CREATE_CELL = "createCell"

str	OPERATION_DESTROY_CELL = "destroyCell"

str	OPERATION_TOUCH_VERTEX_FIRST_TIME = "touchVertexFirstTime"

str	OPERATION_TOUCH_VERTEX_LAST_TIME = "touchVertexLastTime"

str	OPERATION_TOUCH_FACE_FIRST_TIME = "touchFaceFirstTime"

str	OPERATION_TOUCH_FACE_LAST_TIME = "touchFaceLastTime"

str	OPERATION_TOUCH_CELL_FIRST_TIME = "touchCellFirstTime"

str	OPERATION_TOUCH_CELL_LAST_TIME = "touchCellLastTime"

Detailed Description

Tree walker to realise particle-particle interactions with particles held by different adjacent cells or on different mesh levels.

This code snippet creates a tree walker, i.e. an action set that runs through the underlying spacetree top down and builds up the active set and the local set. These sets can then be used to trigger mesh events. It works if and only if you use continuous storage per vertex as introduced with the memory pools.

Within touchCellFirstTime(), the routine exposes the following data besides the generic information of any action set:

marker The CellMarker is avaialable to a compute kernel and allows you to query spatial information. This one is actually one of the generic objects which every action set has available, but we highlight that it is there, as the discussion on uniqueness for particle-particle interactions explicitly refers to the marker.
activeParticles The list of active particles is a list of pointers. It follows the generic definition of active sets.
localParticles This is a list of local particles, i.e. particles which are tied to the cell's adjacent vertices. While they reside on the cell's level, we have no guarantee that they reside within the current cell. They might also be contained within its halo of marker.h()/2.

The additional field _activeParticles is an alias for activeParticles.

The code is slightly more sophisticated compared than its cousin, the UpdateParticle_MultiLevelInteraction_Sets, as it exposes more information:

numberOfActiveParticlesPerVertex This alias for _numberOfActiveParticlesPerVertex is a sequence of integers which tells you how many particles within activeParticles are added by one particular vertex.
numberOfCoalescedLocalParticlesPerVertex is a sequence of integers which tells you how many particles within localParticles are added by each adjacent vertex.

Both pieces of information are important if you work with memory pools as discussed below.

Different particles species

Both active and local set are of the same type if you stick to the default value of None for active_particle_set. But you can also let particles of different type interact by selecting a local particle set that is different to the active one. Users can inject code to modify the local set per cell and hence to alter particle states.

Realisation and data consistency

This tree walker realises the two sets via two lists: Per cell, we append the local set to the active set and memorise on a stack how many of these particles have been added. When we backtrace, i.e. ascend within the tree again, this memorised size is used to remove the last n elements from the active set.

So the active set grows while we descend in the tree, and it is truncated when we ascend again.

This is a very efficient implementation yet fails if particles move up and down within the tree while we walk. It should work perfectly fine if particles do not move. If particles move up and down, the present algorithms might have redundant pointers within the active set. It is therefore absolutely key that this action set is not used in combination with any other action set which lifts data, as a lift destroys contributions made by coarser mesh cells. If particles drop, we also cannot use this action set, as, again, it might corrupt the active sets constructed by coarser meshes. The issue with the lifts notably becomes apparent once you take into account that lifts trigger a scatter on gathered vertices. That is, we descend within the tree and build up our continuous index spaces. Then, later, we decide that we lift one particle. This lift means that particles associated with a coarser vertex are scattered. However, our active set assumes that we had a valid, continous memory for them. So all of our active sets are now invalid. Sieves in contrast work, as long as their action set is used before the current one. They merely add data to the active set that's constructed next.

No lifts.
No drops.
Sieves are fine as long as they happen before touchVertexFirstTime() of this action set.
Lifts into a global sieve list are fine, as long as they happen in touchVertexLastTime() called after this action set.

In the case of a dynamic setup, i.e. in combinatino with the action set UpdateParticleGridAssociation, you might be better of with using the set-based implementation of the particle-particle interaction.

Further plug-in points

Besides the cell kernel which is there to realise particle-to-particle interactions, we also have a vertex kernel which we call whenever a vertex is loaded for the first time. That is, you can assume that the vertex kernel has been launched for all \( 2^d \) vertices of a cell before its cell kernel is triggered. The vertex kernel is also passed on the active set (from the coarser level). Its local set is all the particles whose centre lies within the square/cube around the vertex with mesh size h. So this area goes h/2 along each each coordinate axis into the neighbouring cells.

Flattening of particle arrays

The routine not only keeps track of how many particles we add per iteration. It also keeps track of the number of particles per vertex that have been added. If you know that you work with a memory pool, i.e. a consecutive storage of particles, you can use this additional meta information within your kernel invocations to work with loops over consecutive arrays (AoS) rather than sole link lists. You can exploit that you know something about individual chunks indexed by the pointers.

To exploit this additional information, you cannot use localParticles anymore, i.e. you have to use localParticles. This means, you might have to check if a particle is contained within a cell manually. Once you rewrite your kernels that way, you can exploit the integers _numberOfActiveParticlesPerVertex and numberOfCoalescedLocalParticlesPerVertex:

Assume you enter a cell and you get the localParticles list hosting 19 pointers. Further to that, you receive the array numberOfLocalParticlesPerVertex with four integer entries. You know that the first five entries point to one continuous chunk of particles in memory, the next seven do so as well, and so forth. This holds if and only if you work with a memory pool which maintains vertex-local or globally continuous particles.

I do recommend to call toolbox::particles::ensureThatParticleListsEncodeContinuousMemoryChunks() for your data to ensure that the memory layout above is preserved. Simply add the calls

::toolbox::particles::ensureThatParticleListsEncodeContinuousMemoryChunks(
  activeParticles,
  _numberOfActiveParticlesPerVertex
);
::toolbox::particles::ensureThatParticleListsEncodeContinuousMemoryChunks(
  localParticles,
  numberOfLocalParticlesPerVertex
);

to your cell-wise compute kernel. Furthermore, you might want to check if all vertices are properly gathered:

::toolbox::particles::ensureAllParticleListsAreGatheredOrEmpty(
  fineGridVerticesMyParticleSetName
);

The actual compute kernels then typically look similar to the following code snippet:

typename std::list<T*>::const_iterator localParticlesIterator  = localParticles.begin();
 
for (auto localParticlesChunkSize: numberOfLocalParticlesPerVertex) {
  T*  localParticlesChunk = *localParticlesIterator;
  std::advance( localParticlesIterator, localParticlesChunkSize );
 
  for (int localParticleNumberInThisChunk=0; localParticleNumberInThisChunk<localParticlesChunkSize; localParticleNumberInThisChunk++) {
    if (
      marker.isContained( localParticlesChunk[localParticleNumberInThisChunk].getX() )
      and
      // ensure that particle is not updated twice
    ) {
      [...]
    }
  }
}

Iterating over the active set follows the same pattern. Most codes will have to couple local and active sets and hence use a kernel structure similar to

typename std::list< typename ParticleContainer::value_type >::const_iterator localParticlesIterator  = localParticles.begin();
 
for (auto localParticlesChunkSize: numberOfLocalParticlesPerVertex) {
  typename ParticleContainer::value_type  localParticlesChunk = *localParticlesIterator;
  std::advance( localParticlesIterator, localParticlesChunkSize );
 
  typename std::list< typename ParticleContainer::value_type >::const_iterator activeParticlesIterator = activeParticles.begin();
  for (auto activeParticlesChunkSize: numberOfActiveParticlesPerVertex) {
    typename ParticleContainer::value_type  activeParticlesChunk = *activeParticlesIterator;
    std::advance( activeParticlesIterator, activeParticlesChunkSize );
 
    computeInnerLoop(
        marker,
        localParticlesChunk,
        localParticlesChunkSize,
        activeParticlesChunk,
        activeParticlesChunkSize
    );
  }
}

This inner loop is where the magic happens, i.e. where we can exploit the fact that localParticlesChunk and activeParticlesChunk both point to coninuous memory regions. This means that computeInnerLoop is structurally simple:

void computeHydroForceInnerLoop(
    const peano4::datamanagement::CellMarker&  marker,
    Particle*                                  particlesAssociatedWithLocalVertex, // das ist falsch
    int                                        numberOfLocalParticles,
    Particle*                                  activeParticles,
    int                                        numberOfActiveParticles
) {
  for (int activeParticleNumberInThisChunk=0; activeParticleNumberInThisChunk<numberOfActiveParticles; activeParticleNumberInThisChunk++) {
    for (int localParticleNumberInThisChunk=0; localParticleNumberInThisChunk<numberOfLocalParticles; localParticleNumberInThisChunk++) {
      // read from activeParticles[activeParticleNumberInThisChunk]
      // write to particlesAssociatedWithLocalVertex[localParticleNumberInThisChunk]
    }
  }
}

Dynamic adaptive mesh refinement

In the second sweep of any adaptive mesh refinement, we might drop particles and hence destroy our nicely arranged memory layout. Once particles move up and down the mesh hierarchy, the entries in _numberOfActiveParticlesPerVertex are all invalid. In such a case, we have to switch off any coalesced memory access.

The generic mesh traversal description provides further context and details. The important detail here is: As soon as we might suspect that the memory layout is corrupted, we have to assume that our pointers are all ov the place and do not point to continuous data anymore. Even worse, we know that previously built-up active sets might be invalid. We have built them up top-down, but when we drop data out of the active set, they change on-the-fly.

Optimising coalesced compute kernels

Compute kernels can be optimised quite aggressively, but fiddling out how they can be optimised is tedious. I recommend to use MAQAO and Intel's compiler optimisation feedback. The page Particle memory pools holds additional information. It is also worth studying Swift's performance optimisation remarks with respect to vecorisation as well as Swift's discussion of swift_particle_lifecycle Particle Lifecycle "vectorised kernels".

You cannot collapse the two for loops. That would lead to a scattered iteration space in memory and hence make any vectorisation impossible.
The active loop has to be the inner one. I do not understand why, but Intel's icpx refuses to vectorise if the local loop is the inner one.
The compiler has to be able to inline. According to https://clang.llvm.org/docs/AttributeReference.html#always-inline-force-inline this is something one should be able to control via the annotation
```
    [[clang::always_inline]]
```
but this led to multiple compiler crashes (again with Intel). To some degree this makes sense: The function has to be in the header! I played around with ipo, but that did not resolve the fundamental issues.
You might have to recursively study all inlined methods and make the stuff they use inline as well.
Typically, you have to embed the inner-most loop into a statement alike
if (

marker.isContained(particlesAssociatedWithLocalVertex[localParticleNumberInThisChunk].getX())

and

not particlesAssociatedWithLocalVertex[localParticleNumberInThisChunk].getCellHasUpdatedParticle()

) {

// read from activeParticles[activeParticleNumberInThisChunk]

// write to particlesAssociatedWithLocalVertex[localParticleNumberInThisChunk]

}

The generic Peano optimisation page provides some useful hints how to guide these optimisation through the compiler. It also makes sense to study swift2::kernels::computeHydroForce() which was one of the first routines that we optimised along these ideas.

Definition at line 12 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

Constructor & Destructor Documentation

◆ init()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__init__	(	self,
		particle_set,
		particle_particle_interaction_kernel,
		touch_vertex_first_time_compute_particle_update_kernel = None,
		touch_vertex_last_time_compute_particle_update_kernel = None,
		prepare_traversal_kernel = "",
		unprepare_traversal_kernel = "",
		additional_includes = "",
		active_particle_set = None )

Initialise object.

Arguments

particle_set: ParticleSet

particle_particle_interaction_kernel: String holding C++ code

active_particle_set: ParticleSet or None You can compare different particles species with this argument. It allows you to make the active particles stem from another species than the local ones that you actually update. Pick None if both sets are of the same type.

touch_vertex_first_time_compute_particle_update_kernel: String or None Can be empty, but if you wanna move particles, then a minimal example string passed equals

for (auto* localParticle: localParticles ) {

localParticle->setMoveState( globaldata::Particle::MoveState::NotMovedYet ); }

i.e. you will have a variable localParticle available in this kernel and it is a pointer.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Reimplemented in swift2.api.actionsets.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.

Definition at line 316 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

References peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__init__().

Referenced by peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__init__().

Here is the call graph for this function:

Here is the caller graph for this function:

Member Function Documentation

◆ get_action_set_name()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_action_set_name ( self )

Return unique action set name.

Returns a description (word) for the mapping which is also used as class name for the generated type. As a consequence, the result should be one word (if possible) and uppercase. Also, every subclass should overwrite this routine.

The generator will take the result and construct eventually classes similar to MyStep2Dummy.h and MyStep2Dummy.cpp or similar for the example below, where we return Dummy.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Reimplemented in swift2.api.actionsets.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.

Definition at line 511 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_attributes()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_attributes ( self )

Return attributes as copied and pasted into the generated class.

Please note that action sets are not persistent, i.e. there is one object creation per grid sweep per tree.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Reimplemented in swift2.api.actionsets.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.

Definition at line 535 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_body_of_getGridControlEvents()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_body_of_getGridControlEvents ( self )

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 502 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_body_of_operation()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_body_of_operation	(		self,
			operation_name )

Return actual C++ code snippets to be inserted into C++ code.

See class' string constants starting with OPERATION_ for possible values of operation_name.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Reimplemented in swift2.api.actionsets.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.

Definition at line 486 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_body_of_prepareTraversal()

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 505 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_body_of_unprepareTraversal()

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 508 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_constructor_body()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_constructor_body ( self )

Define a tailored constructor body.

By default, the constructor of an action set is empty. If you you assign attributes to your action set, you however might want to initialise them here. We do not support initialisation lists, to all has to be done via setters unless you create attributes on the heap.

The constructor's signature will look similar to

   EnumerateAndInitSolution2petsc_actionsets_InitVertexDoFs0(int treeNumber);

where the treeNumber is -1 if this is the global instance of the action set owned by a rank, or a number greater or equal 0 if this action set is a clone of the glocal action set that's used by one tree traversal.

See also: get_attributes() to add attributes to your action set

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 546 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ get_includes()

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_includes ( self )

Return include statements that you need.

All of these includes will eventually end up in the header of the generated C++ code.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 517 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ user_should_modify_template()

Is the user allowed to modify the output.

Return whether you expect the user to modify the generated code. If this is the case, then the API places the generated output in the directory actions. Otherwise, it goes into the observer directory and will be overwritten in each and every Python run.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 514 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

Field Documentation

◆ __Template_EndTraversal

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__Template_EndTraversal

staticprivate

Initial value:

=  jinja2.Template(
        
    )

Definition at line 480 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ __Template_TouchCellFirstTime

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__Template_TouchCellFirstTime

staticprivate

Initial value:

=  jinja2.Template(
        
    )

Definition at line 405 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

Referenced by exahype2.tracer.InsertParticlesFromFile.InsertParticlesFromFile.get_body_of_operation(), peano4.toolbox.particles.InsertParticlesAlongCartesianLayoutIntoUnrefinedCells.InsertParticlesAlongCartesianLayoutIntoUnrefinedCells.get_body_of_operation(), peano4.toolbox.particles.InsertParticlesByCoordinates.InsertParticlesByCoordinates.get_body_of_operation(), peano4.toolbox.particles.InsertRandomParticlesIntoUnrefinedCells.InsertRandomParticlesIntoUnrefinedCells.get_body_of_operation(), peano4.toolbox.particles.ParticleTreeAnalysis.ParticleTreeAnalysis.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists.UpdateParticle_MultiLevelInteraction_StackOfLists.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_SingleLevelInteraction.UpdateParticle_SingleLevelInteraction.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_SingleLevelInteraction_ContiguousParticles.UpdateParticle_SingleLevelInteraction_ContiguousParticles.get_body_of_operation(), swift2.actionsets.DynamicMeshRefinementAnalysis.DynamicMeshRefinementAnalysis.get_body_of_operation(), and solvers.api.actionsets.PlotVertexDataInPeanoBlockFormat.PlotVertexDataInPeanoBlockFormat.get_body_of_operation().

◆ __Template_TouchCellLastTime

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__Template_TouchCellLastTime

staticprivate

Initial value:

=  jinja2.Template(
        
    )

Definition at line 454 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

Referenced by exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.get_body_of_operation(), exahype2.tracer.DumpTracerIntoDatabase.DumpTracerIntoDatabase.get_body_of_operation(), peano4.toolbox.particles.ParticleAMR.ParticleAMR.get_body_of_operation(), peano4.toolbox.particles.ParticleTreeAnalysis.ParticleTreeAnalysis.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists.UpdateParticle_MultiLevelInteraction_StackOfLists.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_body_of_operation(), swift2.actionsets.DynamicMeshRefinementAnalysis.DynamicMeshRefinementAnalysis.get_body_of_operation(), and swift2.actionsets.UpdateParticleMarker.UpdateParticleMarker.get_body_of_operation().

◆ __Template_TouchVertexFirstTime

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__Template_TouchVertexFirstTime

staticprivate

Initial value:

=  jinja2.Template(
        
    )

Definition at line 383 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ __Template_TouchVertexLastTime

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.__Template_TouchVertexLastTime

staticprivate

Initial value:

=  jinja2.Template(
        
    )

Definition at line 394 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ _particle_set

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles._particle_set

protected

Definition at line 360 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

◆ d

peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.d

Definition at line 361 of file UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py.

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

python/peano4/toolbox/particles/UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.py

Public Member Functions

Data Fields

Protected Attributes

Static Private Attributes

Additional Inherited Members

Detailed Description

Different particles species

Realisation and data consistency

Further plug-in points

Flattening of particle arrays

Dynamic adaptive mesh refinement

Optimising coalesced compute kernels

Constructor & Destructor Documentation

◆ __init__()

Arguments

Member Function Documentation

◆ get_action_set_name()

◆ get_attributes()

◆ get_body_of_getGridControlEvents()

◆ get_body_of_operation()

◆ get_body_of_prepareTraversal()

◆ get_body_of_unprepareTraversal()

◆ get_constructor_body()

◆ get_includes()

◆ user_should_modify_template()

Field Documentation

◆ __Template_EndTraversal

◆ __Template_TouchCellFirstTime

◆ __Template_TouchCellLastTime

◆ __Template_TouchVertexFirstTime

◆ __Template_TouchVertexLastTime

◆ _particle_set

◆ d

◆ init()