Dynamic Bonds

[astatt]

Implement dynamic bonds based on a distance criterion between two groups (which may either have no overlap or may be 100% identical).

The basic idea is to split this into roughly 3 steps:

1. Find all possible bonds by using a neighbor list. This list should not contain duplicates. We should use a separate neighbor list for the plugin because otherwise there might be funny unwanted interactions if particle interactions or neighbor list parameters change elsewhere in the code. We also might be able to make this very efficient because we are only interested in the intersection of the two groups, so we do only need the tree and not a verlet list and all the other overhead associated with a full neighbor list. T
2. Select bonds from all possible bonds based on some criterion (only N bonds per particle, only M bonds per step, ... ) Here we also need to keep track of all existing bonds in the system so that we can compare against it, should be done in a way which is transferable between CPU/CPU, so no vectors/maps.
3. Form the bonds by using m_bond_data->addBondedGroup, update the exclusions for the neighbor list handling the particle interactions. Right now, there is no easy way to add or remove bonds to the BondedGroupData , except for adding them on the CPU with m_bond_data->addBondedGroup. Therefore, we'll first try step 1 and 2 on the GPU and see how the performance is. A bond reservoir will cause issues when used with MPI. One potential useful extension would be to write a function which can add multiple bonded groups at once to avoid paying overhead multiple times.

While groups are very flexible, in MPI we will have to make sure that the buffer layer is large enough to be able to communicate all potential bond partners between ranks ( using particle types would be easier for this).

It might be interesting to keep track of the distance between possible bonding pairs as well to be able to have selection criteria based on this as well, e.g. closer bonds are formed first.

[astatt]

Commit dcb4b32534 has a first working draft of the bonding algorithm, both CPU and GPU. It's compiled against hoomd v2.9.2 and uses the hoomd/extern/neighbor for the tree neighbor list. It is passing the unit tests, e.g. no duplicate bonds are formed, and not too many.

To store a list of all possible bonds I used an array of Scalar3 (tag_1,tag_2,r_sq). This seems to result in fairly slow sorting/selecting with thrust::remove_if for removing "zero/empty" entries, thrust::sort and then thrust::unique to remove duplicates. This has to happen for every step this updater is called, so optimizing this seems worth it. A possible solution could be to remove the distance r_sq information and then use a paring function to map the two unsigned int tags to one new unsigned int and then do the sorting/selecting based on that one new int?

The second spot where the code is slow is for adding the bonds, as this happens on the CPU right now. How important that is strongly depends on how many bonds are actually formed.

[mphoward]

Is this something that's still of interest to you, or should we close?

[astatt]

Still working on/with it. We can leave it for after migrating to v3, or I can try to do a mad dash to finish it before.

[mphoward]

No rush, if you are still working on it, we will keep this open and keep the target as v1.1 (i.e., after the v3 migration). I was just looking to cleanup stale issues!

[mphoward]

Is this something you are still interested in or want? Feel free to close if not.

[astatt]

Yes - our group is still working on ideas related to bond formation of various kinds, but we have been slow. Eventually I will pick this back up and either test extensively and port to azplugins-v1 or rework this entirely... So if you don't mind having this orphan around for a bit longer, I appreciate it.

[mphoward]

That’s fine! I would advise you try merging up and making the minimum changes to get your branch to compile when we release v1, or this will get harder to do in future.