Dynamic bonding

[joaander]

Original report by stephen thomas (Bitbucket: amburan, GitHub: amburan).

---

I am interested in dynamically bonding random particles to its neighbors at a prescribed frequency. I tried doing this using callbacks in HOOMD. Using frued for finding neighbors greatly improved performance. After doing some profiling, it was found that avoiding the snapshot creation can further improve the performance of the bonding routine. I am thinking about adding this code as a plugin or as a component in HOOMD. As of now, I am assuming that the cut off radius of the neighbour list will be larger than the distance for finding bonding candidates. I would be interested to know if there exist another feature that I can borrow ideas from or reuse code? Greatly appreciate advice on how to go about doing this.

Thanks, Stephen.

[joaander]

Original comment by stephen thomas (Bitbucket: amburan, GitHub: amburan).

---

After a quick search in the code, it feels like the I should be using some function in BondedGroupData to modify the bond group data and that I should inherit from an "Updater" or an "Analyzer" to do the same.

[joaander]

You should write an Updater to make changes to the bonds. Updaters change system properties, Analyzers only look at the current system properties and output results based on that.

Changes to BondedGroupData should be minimal, there should be enough API calls in that class already for you to use to implement your method. If not, we can have a discussion about what additional API is needed.

HOOMD's nlist API is flexible. Look at md/pair.py update_rcut methods and see how users of a neighbor list subscribe to a callback to provide what r_cut values you need. At the python script level, the user supplies the nlist to the pair/updater/whatever. So you can choose to use the same nlist as the pair potentials, or an independent nlist with a different r_cut if needed (i.e. the bond change r_cut is much larger than the pair force r_cut - and/or it operates on a slower period).

[joaander]

Original comment by stephen thomas (Bitbucket: amburan, GitHub: amburan).

---

I get the following linker error if I include std::shared_ptr in the C++ class constructor

#!c++
DyBondUpdater::DyBondUpdater(std::shared_ptr<SystemDefinition> sysdef, std::shared_ptr<NeighborList> nlist)
        : Updater(sysdef), m_nlist(nlist)

#!bash

ImportError while importing test module '/home/sthomas/projects/hoomd-blue_s/dybond_plugin/dybond_plugin/test-py/test_example.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
dybond_plugin/test-py/test_example.py:7: in <module>
    import hoomd.dybond_plugin;
../build/hoomd/dybond_plugin/__init__.py:10: in <module>
    from hoomd.dybond_plugin import update
../build/hoomd/dybond_plugin/update.py:9: in <module>
    from hoomd.dybond_plugin import _dybond_plugin
E   ImportError: /home/sthomas/projects/hoomd-blue_s/build/hoomd/dybond_plugin/_dybond_plugin.so: undefined symbol: _ZTI12NeighborList

But, if I change the FindHoomd.cmake line

#!bash

set(HOOMD_LIBRARIES ${HOOMD_LIB} ${HOOMD_COMMON_LIBS})

to

#!bash

set(HOOMD_LIBRARIES ${HOOMD_LIB} ${HOOMD_MD_LIB} ${HOOMD_COMMON_LIBS})

I am able to run without errors.

Is this the right way to do it?

[joaander]

Yes. If your C++ library depends on symbols in the MD component, you do need to link directly to the MD shared library.

[joaander]

Original comment by stephen thomas (Bitbucket: amburan, GitHub: amburan).

---

Thanks! This works fine when we build as an external component since the path to the MD shared library is specified in the FindHoomd.cmake file. But when I compile the plugin as a built in component in HOOMD using the symbolic link strategy and run, I get the linking error:

Traceback (most recent call last):
  File "../dybond_plugin/dybond_plugin/test-py/test_example.py", line 7, in <module>
    import hoomd.dybond_plugin;
  File "/home/sthomas/projects/hoomd-blue_s/build/hoomd/dybond_plugin/__init__.py", line 10, in <module>
    from hoomd.dybond_plugin import update
  File "/home/sthomas/projects/hoomd-blue_s/build/hoomd/dybond_plugin/update.py", line 10, in <module>
    from hoomd.dybond_plugin import _dybond_plugin
ImportError: /home/sthomas/projects/hoomd-blue_s/build/hoomd/dybond_plugin/_dybond_plugin.so: undefined symbol: _ZTI12NeighborList

Can you advice me on building it as a built in component?

[joaander]

See for example, the CMakeLists.txt file in the DEM component.

target_link_libraries(_dem _hoomd _md ${HOOMD_COMMON_LIBS})

You don't need to link to a discovered MD library, but the specific _md target that has already been built.

[joaander]

Original comment by Michael Howard (Bitbucket: mphoward, GitHub: mphoward).

---

In our CMake script we use:

#!cmake
if(NOT DEFINED HOOMD_MD_LIB)
set(HOOMD_MD_LIB _md)
endif(NOT DEFINED HOOMD_MD_LIB)

# link the library to its dependencies
target_link_libraries(_${COMPONENT_NAME} ${HOOMD_LIBRARIES} ${HOOMD_MD_LIB})

to support both internal and external builds. If I remember right, we also had some trouble with the rpath on the libraries, so we also explicitly import the _hoomd and _md libraries into our python wrappers:

#!python
import hoomd
from hoomd import _hoomd
from hoomd.md import _md

[joaander]

All user questions resolved.

[joaander]

Original comment by Carl Goodrich (Bitbucket: carlpgoodrich, GitHub: cpgoodri).

---

Hi Stephen, I am trying to do something very similar (i.e. dynamically adding and removing bonds when particles are very near each other). Were you able to get this working? If so, is it either publicly available or would you mind describing your solution?

I am fairly new to HOOMD, and so I really appreciate any help you could give me. Thanks! Carl

[joaander]

Original comment by Eric Jankowski (Bitbucket: erjank, GitHub: erjank).

---

Stephen did get this working, but we're waiting on some questions about contracting being resolved before we can make the repository public again. Hopefully you'll only need to wait a week or two. Our paper describing the work is available here: https://www.worldscientific.com/doi/abs/10.1142/S0219633618400059?src=recsys

[joaander]

Original comment by Carl Goodrich (Bitbucket: carlpgoodrich, GitHub: cpgoodri).

---

Hi Eric,

Thanks for your quick response! Quick question: is there a way to sign up to get automatically notified when it is made public?

Thanks again, Carl

[joaander]

Original comment by Eric Jankowski (Bitbucket: erjank, GitHub: erjank).

---

I don't think there's an easy way to get automatically notified. Stephen or I will probably remember to nudge you if it's not a long time from now.

[joaander]

Original comment by Carl Goodrich (Bitbucket: carlpgoodrich, GitHub: cpgoodri).

---

Awesome, thanks!

[joaander]

Original comment by stephen thomas (Bitbucket: amburan, GitHub: amburan).

---

Hi Carl,

The code is finally public. I took longer than anticipated, but here is the url if you still need it: https://bitbucket.org/cmelab/hoomd_blue/src/dynamic_bonding/ Feel free to ask me if you have questions.

Best Regards, Stephen.

[joaander]

Original comment by Carl Goodrich (Bitbucket: carlpgoodrich, GitHub: cpgoodri).

---

Hi Stephen,

Thanks for the heads up!! I worked out a workaround for what I was doing, but it was only a temporary solution... I'll definitely take a look at this.

Thanks again, Carl