Hoomd v3 Support - Githubissues

ur-whitelab / hoomd-tf

A plugin that allows the use of Tensorflow in Hoomd-Blue for GPU-accelerated ML+MD

https://hoomd-tf.readthedocs.io

MIT License

30 stars 8 forks source link

Hoomd v3 Support #240

Open whitead opened 3 years ago

whitead commented 3 years ago

Hoomd is changing how plugins work. Need to migrate

hgandhi2411 commented 3 years ago

HOOMD v3 is still under development. So far, changes in v3 that directly affect HTF are:

context.initialize replaced with new context API. See this tutorial.
CMake >= 3.9
Changes in how plugins work (specifically, changes in CmakeLists.txt)
Building from source requires a C++14 compatible compiler, so our docs should state this
HOOMD writes minimal output to stdout/stderr by default. For user-defined output, see their logging tutorial.
HOOMD box equality checking returns NotImplemented for non-hoomd.Box objects, check how this affects our implementation.

RainierBarrett commented 3 years ago

HOOMD v3 is introducing custom actions in python (see here). I'm wondering if this would be an easier approach to updating to HOOMD v3 compatibility?

Josh Anderson mentioned he'd be happy to talk about what we would need from our end to update HOOMD-TF to HOOMD v3 compatibility. For instance, he mentioned that it's already possible to grab the HOOMD particle positions without having to do custom C++ stuff to get at the GPU memory addresses. They don't have a similar feature for neighbor lists yet, but he says we just need to ask for that. Does this sound like a good route for us? What would stand in the way of going this route? One thing that jumps out at me is we would want to do some benchmarking to check for latency differences. Thoughts?

whitead commented 3 years ago

Still thinking about it. See discussion here from a few months ago when we discussed how this would look.

whitead commented 3 years ago

@RainierBarrett I'm worried that accessing particle positions will not be the GPU memory, but CPU right? That probably won't work well access on GPU for tensorflow. But I agree we should probably make some serious benchmarks and use them to inform decisions like this.

joaander commented 2 years ago

One of our goals with the API is to provide low overhead pathways for pure Python user scripts and plugins.

gpu_local_snapshot provides access to the local particle data on the GPU using the cuda_array_interface
'gpu_local_force_arrays` does the same for forces.
md.force.Custom provides a path for Python classes to compute forces.
'update.CustomUpdaer` (similarly CustomWriter and CustomTuner provide a path for Python classes to be called during the run loop.

@b-butler can provide additional technical details if needed.

joaander commented 2 years ago

https://github.com/glotzerlab/hoomd-blue/pull/1211 adds an API to query the floating point precision of the build.