Annoucing hoomd-rs!

[joaander]

A team in the Glotzer Lab are developing a new simulation tool, hoomd-rs. We
have a working prototype and plan to make it available open source when it is ready
for production use.

hoomd-rs is a collection of Rust crates that implement particle simulations
and related methods. It performs Monte Carlo simulations of hard shapes and
interacting particles (both isotropic and anisotropic) as well as molecular
dynamics simulations with a variety of particle interaction. hoomd-rs
provides public APIs for vector math, geometric primitives, spatial data
structures, energy calculations, and all other components of the simulation
that users can employ in their own analysis and simulation methods. You can use
hoomd-rs to create real-time interactive visualizations of simulations,
execute long-running simulations in batch mode on high performance computing
resources, and analyze the results of those simulations.

hoomd-rs is the spiritual successor to the Python package HOOMD-blue.
While the two share many common features, hoomd-rs provides many
capabilities that HOOMD-blue cannot, such as:

• Custom per-particle attributes.
• Custom particle interactions that can depend on custom per-particle attributes.
• Custom vector representations, including curved spaces.
• Custom MC trial moves and acceptance criteria.
• Custom simulation box geometries (including non-periodic simulation boxes).
• Custom visual representations of simulation elements.
• Build command line applications on all the platforms that Rust supports.
• Run real-time interactive simulations for Linux, Mac, the web, and Windows natively.

hoomd-rs makes it straightforward to customize everything about the
simulation while maintaining a high level of performance. Through the use of
generics, Rust will inline your custom code inside the innermost simulation
loops and compile it to machine code. In contrast, HOOMD-blue offers limited
opportunities for user customization with Python scripts that are interpreted
at runtime.

We plan to implement thread based parallelism in hoomd-rs, but not domain
decomposition or GPU acceleration. hoomd-rs should be an effective replacement
for most HOOMD-blue simulations on the CPU. HOOMD-blue will remain the best
choice for massive simulations that require GPUs, and I will continue to maintain it
for the foreseeable future.

[mikemhenry]

Awesome! Very exciting!

[tommy-waltmann]

Wow! That's super cool to hear, the glotzerlab is really going all in on rust tools. I immediately curious about a few things:

1. Does that mean most active HOOMD-blue will stop?

2. Was the main motivator for this transition the potential for more speed or more customization?

3. What kind of speedups have you seen in your prototypes on parallel CPU simulations compared to HOOMD-blue on a single CPU node?

[joaander]

1. I will continue to maintain HOOMD-blue for the foreseeable future.
2. Both, but customization is more important. Users that customize HOOMD-blue with Python are frustrated at the limited customization options, the slow performance of their Python code, and the complexity of dealing with the timing of custom actions and the memory layout of the zero-copy arrays. hoomd-rs allows users to customize much more of the simulation, those customizations are compiled to machine code, and they are simpler to write. For example, a custom pair potential can be as simple as:

   let cutoff_pair = CutoffPair {
       r_cut: 3.0,
       evaluator: Isotropic(|r| 1.0 / (r.powi(12))),
   };

3. The hoomd-rs prototype is not yet at a stage where it is possible to meaningfully compare full simulation performance. I plan to provide some performance comparisons when they are available.

[MartinGirard]

I like the potential customization without extensive c++ coding. Is there any plan to eventually interface this with GPU code (is it possible in Rust)?

[joaander]

There are several efforts to make GPU kernels possible in Rust. I haven't looked into them because I have no plans to provide GPU support in hoomd-rs. To even include that in the design goals would severely limit the amount of customization that I want to offer. One of the major problems that limits customization in HOOMD-blue is that so many of the operations (force computation, integration, neighborlist updates, even internal structures within the particle data, etc...) can only be run on the whole system at once because they are performed in a GPU kernel. Many data structures and results are therefore only kept in sync with the simulation state at the level of a whole timestep. As a consequence, it is very challenging to write a custom routine in HOOMD-blue that needs information computed by other classes updated at a predictable sub-timetstep granularity, even for CPU code. In hoomd-rs, internal data structure are kept in sync always. Add one new particle to the state and it will immediately show up in the next neighbor search.

For another example: GPUs work best with structures of arrays, which is why you can't easily add new custom particle properties in HOOMD-blue -- you would need to add a new array to ParticleData and updated dozens of other files that reference it (the communicator, sorter, etc...) and duplicate PotentialPair to pass the new parameter to your potential. hoomd-rs uses an array of structures and lets you define the structure. That makes it zero effort to add new particle properties and have your potentials depend on them, but it will not use the GPU memory efficiently. MD performance on GPUS is limited entirely by memory bandwidth, so using a structure of arrays on the GPU will certainly kill the performance to the point where the CPU is faster.

Current GPUs are extremely expensive and the vast majority of users really don't get a cost benefit out of using them. In most of the benchmarks I see for production research, only a few achieve cost-neutral performance on the GPU. The very few that actually have a benefit on the GPU show a small benefit. Therefore, the vast majority if users would be better served by a thread parallelism code that will run quite fast on the current 128-core HPC rigs which are MUCH more available than GPU resources.

In any case, compute resources are cheap compared to human resources. Many users I work with spend far more time attempting to write their model (weeks/months) in HOOMD-blue than it takes to actually run it. Even a modest increase in computational cost is worth it if that same researcher could have their custom model working in a matter of hours.

That being said, I understand that there will be some cases where HOOMD-blue running on GPUs is still by far the best solution for a particular problem. I will continue to maintain HOOMD-blue to make these projects possible. I've gotten a lot of complaints over the years for all the breaking changes I made to HOOMD-blue -- I would have thought that researchers would be happy at the news that such breaking changes will now occur must less often.