 |
Peano
|
|
Peano
|
Particle tracing over the Finite Volumes solver. More...
Public Member Functions | |
| __init__ (self, particle_set, solver, project_on_tracer_properties_kernel, projection_kernel_arguments="""marker,{{PATCH_SIZE}},{{NUMBER_OF_UNKNOWNS}}+{{NUMBER_OF_AUXILIARY_VARIABLES}},fineGridCell{{SOLVER_NAME}}Q.value,*p""") | |
| Set up the tracing. | |
| 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. | |
 Public Member Functions inherited from peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets | |
| 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_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 | |
| tracerDict | |
| Data Fields inherited from peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets | |
| d | |
| Data Fields inherited from peano4.solversteps.ActionSet.ActionSet | |
| descend_invocation_order | |
| parallel | |
Particle tracing over the Finite Volumes solver.
The action set works for cell-centered Finite Differences, too.
We only update cells which are marked with getHasUpdated(). For enclave solvers, we assume that this flag is only set after a cell has updated. Further to that, we also trace in the grid initialisation. If we did not trace there, the first dump prior to the first time step always would yield garbage. It would not even help to add tracing to the plot, as the tracing typically is cell-based, whereas most plotters plug into touchVertexFirstTime(), i.e. they still would dump the particle data prior to the actual tracing.
The class supports different ways how the data is projected onto tracer attributes (both which data entries and how they are interpolated), as well as various time integratiors. The only important detail here is that the integration happens patch-wisely, i.e. you cannot access any neighbouring patches or intermediate data from the time stepping calculations.
Definition at line 10 of file FiniteVolumesTracing.py.
| exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.__init__ | ( | self, | |
| particle_set, | |||
| solver, | |||
| project_on_tracer_properties_kernel, | |||
| projection_kernel_arguments = """marker,{{PATCH_SIZE}},{{NUMBER_OF_UNKNOWNS}}+{{NUMBER_OF_AUXILIARY_VARIABLES}},fineGridCell{{SOLVER_NAME}}Q.value,*p""" ) |
Set up the tracing.
Setting up the tracing first and foremost means that we have to couple the tracer particle set with the solver, and then we have to specify which projection kernels and which time integrator we want to use. Basically, we have to provide the C++ kernels which shall be used to move the tracer and to write new data into the tracer.
For the time stepping, Peano's particle toolbox provides some default integrators. If you use stationary tracers, toolbox::particles::StaticPosition (handed in as string) or None do the job. See comment below.
For the projection of solution data onto the tracer, the file exahype2/fv/Tracer.h provides a few pre-manufactured routines. Again, the projection kernel here requires a plain function call, and you have to ensure that this function call matches the data you actually wanna dump.
particle_set: ParticleSet
time_stepping_kernel: String Function call which does projection onto the particles and the actual position update. Hand in "toolbox::particles::StaticPosition" or None if you don't want the particles' to move.
project_on_tracer_properties_kernel: String Name of the routine that projects the Finite Volumes representation onto the tracers' properties. Hand in None if you don't want any field properties to be projected on the tracer. This makes sense if the velocity/trajectory of a tracer already encodes all information. Some popular arguments for this routine are enlisted above.
Reimplemented from peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.
Definition at line 38 of file FiniteVolumesTracing.py.
| exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.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.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.
Definition at line 149 of file FiniteVolumesTracing.py.
| exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.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.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.
Definition at line 172 of file FiniteVolumesTracing.py.
References exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.get_attributes().
Referenced by exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.get_attributes().
| exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.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.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.
Definition at line 155 of file FiniteVolumesTracing.py.
References exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.get_includes(), exahype2.tracer.DiscontinuousGalerkinTracing.DiscontinuousGalerkinTracing.tracerDict, and exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.tracerDict.
Referenced by exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.get_includes().
| exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.user_should_modify_template | ( | self | ) |
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.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.
Definition at line 152 of file FiniteVolumesTracing.py.
| exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.tracerDict |
Definition at line 90 of file FiniteVolumesTracing.py.
Referenced by exahype2.tracer.FiniteVolumesTracing.FiniteVolumesTracing.get_includes().
1.10.0