From: Giacomo Fiorin (giacomo.fiorin_at_gmail.com)
Date: Sat Oct 10 2009 - 01:21:25 CDT
Hi, indeed it's fairly easy with the collective variables module. You
can define a "distance" colvar, where "group1" are the atoms of
interest, and "group2" can be another group of atoms, or a dummy atom
(keyword: dummyAtom) centered on the point of interest.
The restraint can be applied in two ways: either by defining an
upperWall to the colvar that can kicks in after a certain distance
(including 0), or applying an harmonic bias centered in 0. The
distance from the point of interest will be forced back to lower
values, restraining the center of mass of the protein near there.
ICMS - Institute for Computational Molecular Science
1900 N 12 th Street, Philadelphia, PA 19122
work phone: (+1)-215-204-4216
On Fri, Oct 9, 2009 at 8:43 PM, Joshua Adelman <jadelman_at_berkeley.edu> wrote:
> Hi Bin,
> This is pretty trivial to code up using the GlobalMasters routines (at least
> in v2.6). You'll have to write your own GlobalMaster code and recompile
> namd, but otherwise it's simple. Take a look at the GlobalMasterMisc.C and
> .h files in the src/ directory. This code will only run on the head node,
> but in my experience, unless you are doing something really complicated, you
> won't see any slowdown.
> If you want to see example code, let me know.
> Also, I haven't used the collective variable features in NAMD 2.7, but
> doesn't the "distance" collective variable basically allow you to do this?
> Another alternative is to try PLUMED (which I have not):
> On Oct 9, 2009, at 8:19 PM, BIN ZHANG wrote:
>> Hi, All:
>> Browsing through the mailing list, I saw quite a few people interested in
>> restraining the center of mass (COM) of a group of atoms during their
>> simulation. However, to my understanding, NAMD does not have an elegant way
>> to do this (correct?). Though tclforces script could do the job, it would be
>> a pain while the number of atoms is big.
>> So my question is why does NAMD not offering this ability? It cannot be a
>> coding issue. Actually, I think it's rather trivial to implement this, given
>> that it already has SMD implemented. It should be basically the same as SMD,
>> except here we have zero velocity, and also the moving direction is updated
>> on the fly as r - r0.
>> Am I missing something here? Is NAMD 2.7b1 already able to do this? If
>> not, I would like to try to do it myself.
>> Thanks for any comments.
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:53:21 CST