rethink ParticleData and relationships with WallData and BondData

It's that time again! Time to push back low-priority tickets to the next milestone.

Here is an idea: Create a new SystemDefinition class. This class will contain

• ParticleData
• ExecutionConfiguration
• WallData
• BondData
• AngleData
• DihedralData
• RigidData
• ...

One can already see that this is more scaleable than the current setup as it will trivially and simply allow for the addition of more data structures. (hmmm... maybe with a base class for all the *Data structures, we could have a string based request mechanism. That would allow for infinite expandability without polluting the C++ namespace with lots of get* methods and will require changing fewer files.... I'll think about it).

Another interesting side effect is that we could implement a generic ArrayData? that stores a float array, one element per particle. This class would come with aquireReadOnly, acquireReadWrite, release and all the needed GPU data management built in. It could be used for data structures that are only needed for specific force computes in a nice clean abstract way (i.e. charge for electrostatics or diameter for the upcoming shifted lj. + anything new anyone dreams up a requirement for). I'll have to think about this one too. This will create some complications with the particle sort, but those are not unsolvable.

ParticleData and the ExecutionConfiguration are considered fundamental in that they are initialized first and will always be present. Thus, they can be passed as shared pointers to any of the other *Data structures in SystemDefinition which is required behavior so that those classes can refer to particle tags and whatnot.

Heck, we could even move the profiler into the SystemDefinition?. That way, system wide profiling would be easy to turn on/off. Though we need to carefully consider if we want to remove the functionality to only profile certain computes.....

How to initialize this beast is a whole different question. The current ParticleDataInitialzier model has got to go. It would be pretty nasty to setup for SystemDefinition and not at all scaleable. I'll think about it some more. I think we need a push method, not a pull method for the initialization. I.e., the initializer pushes data into the SystemDefinition and returns a shared pointer to what it has created. This will make the intitializers more like functors and less like classes.

Bumping the priority up another notch. This needs to be the first thing done for 0.9.0 so everything else that follows is done in the new framework.

The more I think about this setup, the better I am liking it. We could even roll the ArrayData? idea into ParticleData? (named so since ArrayData? will store data per particle). It could be used for all the arrays as they are now! (position, velocity, acceleration, ...). This would be very nice from a code management/replication perspective: only one piece of code to handle the per-particle data management on the GPU. Less code and less complicated code will mean a smaller potential for bugs. We get the "partial aquire" for free, too! If some compute only needs the position, then it only aquires the position which means that only the position is copied device->host (for example) (the current ParticleData? would copy everything position, velocity, accel....). The other thing we get for free is free and painless extensions of data structures. Adding particle diameters will be trivial in this system.

The only drawback I can think of at the moment is that this will make for longer aquire calls. I.e. where we had

ParticleDataArrays pdata_arrays = m_pdata->aquire()

we will now have

float4 *pos = m_pdata->aquire<float4>("position");
float4 *vel = m_pdata->aquire<float4>("velocity");
float4 *accel = m_pdata->aquire<float4>("acceleration");

The syntax is preliminary of course, but you can see I'm already thinking about writing the ArrayData? class with templates for even more code re-use. I'm not sure exactly what form things will take yet, but I like how the idea is shaping up.

... oh well ... I guess I need to go back to working on 0.8.0 and finish that before I can start the fun rewriting of ParticleData?.