For example, suppose the application requires a unique id, energy, momentum and density to be stored on a set of of particles. Then the following code could be used
DMSwarmInitializeFieldRegister(dm)
DMSwarmRegisterPetscDatatypeField(dm,"uid",1,PETSC_LONG);
DMSwarmRegisterPetscDatatypeField(dm,"energy",1,PETSC_REAL);
DMSwarmRegisterPetscDatatypeField(dm,"momentum",3,PETSC_REAL);
DMSwarmRegisterPetscDatatypeField(dm,"density",1,PETSC_FLOAT);
DMSwarmFinalizeFieldRegister(dm)
The fields represented by DMSwarm are dynamic and can be re-sized at any time. The only restriction imposed by DMSwarm is that all fields contain the same number of points.
To support particle methods, "migration" techniques are provided. These methods migrate data between MPI-ranks.
DMSwarm supports the methods DMCreateGlobalVector() and DMCreateLocalVector(). As a DMSwarm may internally define and store values of different data types, before calling DMCreateGlobalVector() or DMCreateLocalVector(), the user must inform DMSwarm which fields should be used to define a Vec object via DMSwarmVectorDefineField() The specified field can can changed be changed at any time - thereby permitting vectors compatable with different fields to be created.
A dual representation of fields in the DMSwarm and a Vec object is permitted via DMSwarmCreateGlobalVectorFromField() Here the data defining the field in the DMSwarm is shared with a Vec. This is inherently unsafe if you alter the size of the field at any time between calls to DMSwarmCreateGlobalVectorFromField() and DMSwarmDestroyGlobalVectorFromField(). If the local size of the DMSwarm does not match the local size of the global vector when DMSwarmDestroyGlobalVectorFromField() is called, an error is thrown.
Additional high-level support is provided for Particle-In-Cell methods. Please refer to the man page for DMSwarmSetType().