Re: Colvars and COM restraints for protein+membrane; plus a minor bug

From: Jérôme Hénin (jhenin_at_ifr88.cnrs-mrs.fr)
Date: Thu Sep 23 2010 - 14:37:52 CDT

Hi Marc!

On 23 September 2010 16:24, Marc Baaden <baaden_at_smplinux.de> wrote:

>
> Hi,
>
> Following some exchange with a colleague using geometrical plane and
> cylinder
> restraints in Charmm to keep membrane and protein from drifting too much, I
> am trying to implement something similar within NAMD.

Just in case: did you try the NAMD option zeroMomentum? It could be enough
to prevent drift, although maybe not to a sufficient precision that nothing
would happen over long times.

> Some discussion on
> the mailing list suggested that the colvars module could be used for
> this. Unfortunately I couldn't find any specific example, and so I'd
> like to cross-check whether I went for the right implementation, and
> also post my implementation if anybody wants to use it.
>
> [...]
>
> The purpose of the "memb_plane" restraint is to keep the membrane
> centered at -30 on the z-axis. The purpose of the "prot_cyl" restraint
> is to keep the protein around (0,0) on the xy axis. Is this the way to
> do it?
>

Yes, this looks right.

I also noticed a bug in the definition of the atom groups. I have a
> multimeric protein, with each chain called "PEPA", "PEPB",.. ; I want
> all Calpha atoms of all chains, and don't want to use the "psfSegID"
> specification. But if I don't include it, NAMD complains and doesn't
> start. On the other hand, the atom numbers seem to be properly taken
> into account (eg also those not in segID PEPA are counted). THis seems
> to be a but to me.
>
> It's also a bit unfortunate that one cannot use several segment
> identifiers as in all Calphas of PEPA, PEPB, etc.
>

Does that still happen using the newly released 2.7b4? I fixed some problems
there, but if I have created new ones, I should fix them asap.

> I also wonder whether it would make a difference to include all lipid
> (respective protein) atoms in the atom groups (this is how it was setup
> in Charmm), or only the P and Calpha atoms as done here.

That could be a serious performance hit, so the P atoms sound like a better
solution to me.

> In particular,
> does the forceConstant have to be scaled according to the number of
> particles (I don't think so)?

You are right, the force constant should not be scaled. If the number of
atoms involved doubles, the force on each atom will be halved, but the
overall physical impact of the restraint will be unchanged.

> Also, it seems that using too large an
> atom group might hurt performance. Any experience/numbers available?
>

Nothing directly comparable: the effect it a combination of increased
communications (which may or may not be limiting) and increased load on the
master node (which may or may not be totally offset by dynamic load
balancing), so the impact depends on the size of the system, the number of
nodes, network topology, latency and bandwidth... essentially on everything.
So the only way to be sure is to run benchmarks under real-world conditions.
I can tell you that much: I have had cases where too many atoms in colvars
killed throughput.

Please let me know if the bugs persist in 2.7b4.

Best,
Jerome

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:54:32 CST