Issues with Assigning Different Bonds

[Jasper Marcum]

Hi all,

I am having an issue in a project I am working on where the parameters for one type of bond don't seem to affect the outcome, so I wrote a simpler simulation that contains 5 different isolated pairs of particles, with 3 different types of parameters for harmonic bonds. The first and the third pair have bond type 'AA', the second pair has bond type 'BB', and the fourth and fifth pairs have bond type 'CC'.

The pairs with bond types 'AA' and 'BB' move in the expected manner, but the pairs with bond types 'CC', don't move at all. I have confirmed this by animating the trajectories of the particles and by checking that `harmonic.forces` returns all zeros for the last four particles. This is all consistent with some parameters not affecting my main project.

I have attached a short script that shows how I am implementing this. Can anybody explain why the last two pairs of particles are not behaving as if there is a bond between them? Am I incorrectly specifying or assigning the bond types? 

I see that in this example, the list for bond types has a length of 1, and there is only one type that applies to every particle. How does this change when you want to specify multiple types of bonds and place them between specific pairs of particles?

Thank you for reading,

Jasper 

[Joshua Anderson]

Jasper,

The `types` arrays - both particle types and bond types - are not N-length arrays. They are N_types length arrays. 

To fix the behavior you are seeing, set:

```

snap.particles.types = ['A', 'B', 'C']

snap.bonds.types = ['AA', 'BB', 'CC']

```

In this way, a bond with typeid 0 is of type 'AA', a bond with typeid 1 is of type 'BB', and a bond with type 2 is of type 'CC'. More generally a bond with typeid `t` is of type: `bonds.types[t]`. Looking at your typeids, you are assigning `typeid` correctly from 0 to N_types.

The reason for the behavior you are getting is that the first 'CC' bond type has id 3, of which there are none in the system. The bond you intended to be 'CC' is actually the second 'AA' type which is inaccessible because HOOMD will always find the first matching string when mapping names to ids.

I will make modifications to both GSD and HOOMD to detect duplicate type name strings and report an error. Feel free to make a pull request extending that how to guide to make it more useful.

------

Joshua A. Anderson, Ph.D.

Research Area Specialist, Chemical Engineering, University of Michigan

--
You received this message because you are subscribed to the Google Groups "hoomd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/901d22ea-0f7f-4fb5-b295-8707bb791d52n%40googlegroups.com.
<bond_issues.py>

[Jasper Marcum]

Joshua,

Thank you so much for clearing this up.

Jasper