clean up GPU code

Since this is going to be such a sweeping change, that it shouldn't be started so far into the development cycle for 0.8.0. Pushing back to 0.9.0

Shifting milestone targets around again. This one won't be as bad as originally thought. It should clean up the memory allocation code considerably.

r1359 implements a reworked force data structure following the newly created guidelines.

There is still much more to do.

r1362 fixes bugs created in r1359. HOOMD now runs without crashing.

Are the newly created guidelines documented somewhere?

Replying to phillicl:

Are the newly created guidelines documented somewhere?

Yep. You'll need to build the documentation from the latest svn release to get it, but it is under "GPU Implementation" in the developer design notes page.

Note that it is a work in progress and will be updated with more info as I implement each piece. The rest is in my head right now, but I don't want to put it on paper, so to speak, until I've tried it out and see that it will work the way my imagination says it will.

Currently these are the only two points in the updated docs and I haven't completed the reorganization of the code to match them completely yet. # More consistent use of prefixes on arguments. # make GPU data structures classes with device functions for accessing data elements and host functions for allocation and deallocation

The 2nd is the most important and biggest task. GPU data structure allocation, especially with the new multi-GPU stuff is just a big ugly mess right now and it is difficult to impossible to add new stuff (like the virial). Implementing these "lightweight" gpu_*_data_arrays and similar classes with their own internal memory management functions will go a long ways toward fixing that.

See the new gpu_force_data_arrays if you want an example. Though, an examples more relevant to your code will come when I redo the internal data structures of NVTUpdaterGPU.

r1442 completes the first 3 bullet points on all GPU force computes. The new file/function naming scheme and argument ordering are documented in the developer design notes.

Today, I only had time to rework the force computes. Tomorrow I'll get the other computes, updaters and data structures.

r1448 completes a couple of the tasks

• More consistent file and function names.
• More consistent argument orderings

The documentation is improved too, but I'm not calling that one complete yet.

The new file naming scheme is beautiful in its simplicity. Most all of the CUDA code is tied in very tightly with a C++ class. So we put the CUDA code that ClassName? class uses in ClassName?.cu and the definitions in ClassName?.cuh. This structure has the added benefit that it will naturally transition to moving all the CUDA code out of the cuda/ directory and in with the rest (to be considered separately in #170).