DISPATCH
trace_particles_mod Module Reference

Trace particle module. Two classes of trace particles will be supported (this is not yet fully implemented): More...

Data Types

type  trace_particles_t
 

Variables

type(random_trandom
 

Detailed Description

Trace particle module. Two classes of trace particles will be supported (this is not yet fully implemented):

1) The bulk of the particles are used to accurate trace the motion of mass, with a fair number of particles per cell, constantly renormalized to accurately represent the mass in the patch.

2) A small fraction of trace particles, intended for graphics, are flagged with a bit that results in a higher cadence of saving to disk, with particles moving only a few cells between snapshots.

Disk files should be organized with one file per snapshot for the bulk particles, while the graphics particles should be accessible in one file per rank, since it needs to be written too frequently for collective MPI calls. When reading and plotting, one can open these rank files, and make a selection, based on for example their first location. Subsequently, as particles transition to other ranks, this has to be handled by the reader.

One example: For superonic turbulence, one may choose to save only two snapshots per dynamic time L/M, while that would correspond to at least N/2 cell transitions. Hence, the number of particles needs to be of order N smaller in the graphics files, if disks files should have about the same size. In principle, only positions and particle IDs need to be save in the bulk snapshots, which means of order 16 bytes per particle, and one can then allow a few particles per cell, w/o a major increase in data volume.

Conversely, one can allow of order N times fewer particles in the graphics files, or about one particle per 1000 cells, or one particle per radius 10. One could choose to make the graphics particles have a constant fraction of the mass, especially if one ensures that their paths accurately reflect the the path of the mass. For such a small fraction it does not make sense to even consider mass conservation, and one should instead extra precision in their motion.

The particle ID and a few flags may be encoded in a 64 bit integer, with the upper 4 bits reserved for flags, being masked out when considering IDs.

In the case of the bulk particles, we are interested in two partially conflicting requirements: 1) they should be renomalized frequently, to keep the weight of each particle from becoming too extreme (small or large) compared with the amount of mass in the cell (or in the patch). 2) particle heritage should be accessible, so one can identify exactly where a particle comes from. This could be achieved by reserving the lowermost No bits for their "original" ID.