Single Particle

Adds a single particle to the library. This single particle is simply a tuple which holds access to multidimensional data of a trivial type for a single particle. This new class serves multiple purposes:

• It provides a convenient get/set infrastructure for individual particles within a list of particles
• It replaces the BufferParticle. The copy in this case should be more efficient than the byte-wise copy of the BufferParticle and also easier to maintain. This comes at the cost of potentially some extra memory usage because of the padding.
• Because the particles themselves are trivial, one can make a Kokkos::View of these particles. This is effectively then an implementation of Array-of-Structs.
• One should be able to easily use a Kokkos::View of particles with MPI because they are of trivial type by casting them to a char pointer.
• This will hopefully also solve some potentially non-portable code that was doing a bunch of casting in the BufferParticle implementation as found by @gchen

changed milestone to %FY18 Q3 Cabana Development

assigned to @uy7

@rfbird If you could check this one out as well that would be great. It puts us much more in line with how codes like LAMMPS handle their serialization.

How worried should we be about people abusing this deep copy thinking its a shallow (free) accessor?

It's obviously implied by the typing, so I'm not sure how much we can do, but thought it was worth checking

Seems pretty solid to me!

One final question though, why is "The copy in this case should be more efficient than the byte-wise copy of the BufferParticle"? Isn't it ~the same?

I think it is more efficient because we are doing this to copy a double

double x;
double y = x;

instead of something like this:

double x;
double y;
for ( int b = 0; b < 8; ++b )
    static_cast<char*>(&y)[b] = static_cast<char*>(&x)[b]

which is effectively what BufferParticle was doing. This was suggested by the LAMMPS team on the last call.

At a minimum the syntax is more clear an an individual particle seems like a useful construct.

Ok, great!

mentioned in merge request !18 (merged)

added 1 commit

• be53dfd4 - removing extra include

Compare with previous version

merged

mentioned in commit 402967db