chains tethered to rigid bodies

[Nathan Horst]

Hello all,

I am trying to initialize a system that has non-rigid chains tethered to rigid bodies.

In HOOMD 1.3.3 initializing such a system was trivial using an xml file, but due to the new way of treating rigid bodies with a central particle, I have found this initialization to be more challenging. As i understand it, the particles in the rigid body that are used to tether the chains must be created from the central particle, so until they are created i cannot have bonds connected to those particles defined in the initial file.

Currently, I find myself doing the following:

creating an empty snapshot

Initializing the rigid body centers from a matrix of central particle positions.

Building the rigid bodies based on a matrix of particle positions in the body.

creating non-rigid particles in the snapshot and assigning types/positions/mass/etc.

grabbing the correct indexes between non-rigid particles and creating bonds between them

grabbing the correct indexes between non-rigid and rigid particles and creating bonds

As the system grows, this method seems to require a bunch of indexing and looping to simply initialize the system. Is there some easier way, akin to initializing with an xml file that supports the new rigid body implementation, or must I assign the bonds, etc. manually via a snapshot? Even if I am initializing from a GSD file instead of XML, I still will have the problem that until the rigid bodies are created, there will be no indexes to define the bonds that tether the chains to the outside of the rigid body, correct?

Thanks,

Nathan Horst 

 

 

 

 

 

[Michael Howard]

I don't think you have much choice to do what you have described above. The question is whether you are doing this initialization step in some external script that dumps an input file, or if you are doing it inside hoomd. The documentation (http://hoomd-blue.readthedocs.io/en/stable/module-md-constrain.html#hoomd.md.constrain.rigid) is less than transparent on this point, but does warn:

Automatic creation of constituent particles can change particle tags. If bonds have been defined between particles in the initial configuration, or bonds connect to constituent particles, rigid bodies should be created manually.

So, this would say to me that you should be able to create the initial configuration externally, if this is what you want to do, and then read it in. Then, don't call rigid.create_bodies() in your hoomd script. As to how you actually write the particles manually:

When you create the constituent particles manually, the central particle of a rigid body must have a lower tag than all of its constituent particles. Constituent particles follow in monotically increasing tag order, corresponding to the order they were defined in the argument to set_param(). The order of central and contiguous particles need not to be contiguous.

Maybe Jens can comment more on this though.

Regards... Mike 

[Joshua Anderson]

You can still create the constituent particles manually as you did in hoomd v1.x and use them to create bonds with other particles - whether you use XML or GSD. The main difference in v2.0 is that the position, orientation, velocity, etc.. of those particles is ignored - they are only placeholders. The relative body positions and orientations set in the script will take effect when the run starts.

The create_bodies method is only intended as a convenience so that you do not have to go through the manual constituent particle assignment step in your scripts. You can still do so, and need to do so when you want to assign bonds to constituent particles.

Note the following rule (in the documentation) that you must follow when assigning constituent particles to a body's central particle:

"""When you create the constituent particles manually, the central particle of a rigid body must have a lower tag than all of its constituent particles. Constituent particles follow in monotonically increasing tag order, corresponding to the order they were defined in the argument to set_param(). The order of central and contiguous particles need not to be contiguous."""

In short, the only thing you need to change from a v1.x workflow for input files is to add the body's central particle before its constituents and assign an appropriate position and orientation. If you want to completely replace a 1.0 workflow where the positions of the constituents determine the orientation of the body, then you will need to develop a script that interprets the orientation and center of mass of the body and automatically creates an appropriate central particle (and readjusts bond targets to match the new tag ordering). A general purpose script that performs these actions may be of interest to the hoomd user community.

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan
http://www-personal.umich.edu/~joaander/

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to hoomd...@googlegroups.com.
Visit this group at https://groups.google.com/group/hoomd-users.
For more options, visit https://groups.google.com/d/optout.

[Joshua Anderson]

Slight correction. When manual constituent particle creation, you still need to call create_bodies, just call create_bodies(False) to tell it that you want it to use existing constituent particles.

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan
http://www-personal.umich.edu/~joaander/

[Nathan Horst]

Thanks to both of you for the input, this is certainly a much easier way for me to initialize my system.

I do have one further question about integrating rigid and non-rigid particles in the same system. Rigid bodies now require the moment of inertia to be defined for the central particle, but does integrating with an anisotropic integrator also require that we define moments of inertia for non-rigid particles? I know that the default values of particle moments and diameters used to be 0.0, which meant point particles. However, test simulations using the anisotropic integrator give me the following error unless i specify a moment of inertia for all non-rigid particles. 

*Warning*: Integrator #7: Anisotropic integration requested, but no rotational degrees of freedom found for its group

Furthermore, if I impose moments and diameters of 0.0 onto this system, the above error remains, but if i change them to 'fake' non-zero values, i get the following error.

*Warning*: compute.thermo: given a group with 0 degrees of freedom.

            overriding ndof=1 to avoid divide by 0 errors

This suggests to me that the anisotropic integrator is trying to act on the non-rigid particles, even though I am telling it explicitly to act on the centers.

I have included a slightly modified runfile from an example in an issue previously brought up by Michael Goytia, where I have added a non-rigid particle and a bond that tethers it to a rigid body. Is there something I am doing wrong in the script?

Nathan

To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.

[Joshua Anderson]

This is something that is missing from the documentation. I will try and clear it up with a tutorial.

One of the main advantages to the new integrators in hoomd 2.0 is that you no longer need separate integrators for rigid bodies and non-rigid particles. You should use just one integrator that applies to both the rigid centers and the non-rigid particles (use group.union to create such a group). Inside the integrator, it uses the moment of inertia to determine if a particle has orientation degrees of freedom (body or extended particle) or not (point particle). It then applies the correct equation of motion to each particle. If you assign a moment of inertia to your point particles, you turn them into spheres that have rotational degrees of freedom - which will be a problem for NVT integrators if there are no torques applied to your spheres (the NVT integrator will try and equilibrate the rotational momentum of those spheres). You should keep your non-rigid lj-interacting particles as point particles with 0 moment of inertia. Only particles that get torques (rigid centers, DEM particles, gay-berne ellipsoids, etc...) should have non-zero moment of inertia.

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan
http://www-personal.umich.edu/~joaander/

To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users+unsubscribe@googlegroups.com.

[Nathan Horst]

Thanks, my system seems to be working as expected now.

However, a colleague of mine has been trying to make a similar system work, and I have not been able to figure out what is going wrong for him. I have attached a script in which he initializes a rigid particle, but the particle flies through the box even when it is the only thing there as you can see in the attached movie. Does anyone know why this is happening??

Thanks,

Nathan

[Joshua Anderson]

It is hard to guess, but one possible culprit is that you are using the nvt integrator with 0 initial velocity. That is always a recipe for problems. I would suggest the langevin integrator for testing. Alternately, the nvt integrator would be more well behaved for a system of particles given an initial velocity - it really is not designed to work with just a single particle.

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan
http://www-personal.umich.edu/~joaander/

To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users+unsubscribe@googlegroups.com.