Re: tilt colvar

From: JC Gumbart (gumbart_at_ks.uiuc.edu)
Date: Tue Dec 02 2014 - 18:30:22 CST

Doh - of course that makes sense. NAMD can’t unwrap it - just keep it from wrapping again.

Thanks,
JC

On Dec 2, 2014, at 4:35 PM, Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:

> If you restart from coordinates where the protein is not split, and turn wrapping off, then it should stay in one piece.
>
> J
>
> On 2 December 2014 at 19:56, JC Gumbart <gumbart_at_ks.uiuc.edu> wrote:
> Apparently turning off wrapping doesn’t work as expected either (see attached picture). The protein still splits across the boundary. I’ll admit that how the PBCs are interpreted in NAMD is still a bit of a mystery to me.
>
> So then is the only solution to restrain its COM in the center of the box?
>
> Thanks!
> JC
>
> <nowrap.png>
>
>
>
> On Nov 24, 2014, at 4:09 PM, Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:
>
>> Good to know the new VMD interface was useful to solve this.
>>
>> If the coordinates used internally in the simulation have your protein split, there is no way the colvars will make sense of them. Either of the options you mention should work fine. My personal taste goes towards disabling wrapAll and enabling zeroMomentum.
>>
>> Best,
>> Jerome
>>
>>
>> On 24 November 2014 at 21:42, JC Gumbart <gumbart_at_ks.uiuc.edu> wrote:
>> Thanks - I was meaning to look into this option. I figured it out. It’s the wrapping, or lack there of. When the protein is split across the boundary, I get the value from the simulation. When I use PBC tools to join the fragment, it gives the value I expect. I really didn’t expect this behavior at all.
>>
>> Is the solution to turn off wrapAll? Restrain the protein to the box center?
>>
>> Thanks,
>> JC
>>
>>
>> On Nov 24, 2014, at 9:46 AM, Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:
>>
>>> Hi JC,
>>>
>>> I'm still not sure what's happening in your case. Another way to investigate, if you use the development version of VMD, is to compute the colvar on-the-fly in there. E.g. you can load your trajectory and issue these commands:
>>> cv molid top
>>> cv configfile myconfig.in # wherein you could define both the tilt and orientation
>>>
>>> then:
>>> cv frame <n>
>>> cv update
>>> cv printframe # will print values of all currently defined colvars
>>>
>>> That way you can inspect your trajectory interactively. You can also move the helix manually and calculate the new colvar value, to check that it matches your intuition.
>>>
>>> I hope that helps.
>>> Jerome
>>>
>>> PS: command "cv" might actually be "colvars" depending on exactly which development version you have.
>>>
>>> On 22 November 2014 at 15:10, JC Gumbart <gumbart_at_ks.uiuc.edu> wrote:
>>> Here’s the entire file. In TMorientrev.ref, the helix is aligned with the z-axis.
>>>
>>>
>>> Colvarstrajfrequency 20
>>> ##Colvarsrestartfrequency 100
>>>
>>> colvar {
>>> name position
>>>
>>> width 0.5
>>>
>>> distanceZ {
>>> forceNoPBC yes
>>> main {
>>> atomnumbers { 7 9 24 25 26 28 43 44 45 47 62 63 64 66 81 82 83 85 100 101 102 104 119 120 121 123 138 139 140 141 145 147 }
>>> }
>>> ref {
>>> atomnumbers { 168 220 272 324 376 428 480 532 584 636 688 740 792 844 896 948 1000 1052 1104 1156 1208 1260 1312 1364 1416 1468 1520 1572
>>> 1624 1676 1728 1780 1832 1884 1936 1988 2040 2092 2144 2196 2248 2300 2352 2404 2456 2508 2560 2612 2664 2716 2768 2820 2872 2924 2976 3028 3080
>>> 3132 3184 3236 3288 3340 3392 3444 3496 3548 3600 3652 3704 3756 3808 3860 3912 3964 4016 4068 4120 4172 4224 4276 4328 4380 4432 4484 4536 4588
>>> 4640 4692 4744 4796 4848 4900 4952 5004 5056 5108 5160 5212 5264 5316 5368 5420 5472 5524 5576 }
>>> }
>>> }
>>> }
>>>
>>> colvar {
>>> name tilt
>>>
>>> width 0.05
>>>
>>> tilt {
>>> atoms {
>>> atomnumbers { 7 9 24 25 26 28 43 44 45 47 62 63 64 66 81 82 83 85 100 101 102 104 119 120 121 123 138 139 140 141 145 147 }
>>> }
>>> refPositionsFile {
>>> input/TMorientrev.ref
>>> }
>>> refPositionsCol { O }
>>> }
>>> }
>>>
>>> # P atoms
>>> colvar {
>>> name Pin
>>>
>>> width 1.0
>>>
>>> lowerboundary -5.0
>>> upperboundary 5.0
>>>
>>> lowerwallconstant 50.0
>>> upperwallconstant 50.0
>>>
>>> distanceZ {
>>> main {
>>> atomnumbers { 168 220 272 324 376 428 480 532 584 636 688 740 792 844 896 948 1000 1052 1104 1156 1208 1260 1312 1364 1416 1468 1520 1572
>>> 1624 1676 1728 1780 1832 1884 1936 1988 2040 2092 2144 2196 2248 2300 2352 2404 2456 2508 2560 2612 2664 2716 2768 2820 2872 2924 2976 3028 3080
>>> 3132 3184 3236 3288 3340 3392 3444 3496 3548 3600 3652 3704 3756 3808 3860 3912 3964 4016 4068 4120 4172 4224 4276 4328 4380 4432 4484 4536 4588
>>> 4640 4692 4744 4796 4848 4900 4952 5004 5056 5108 5160 5212 5264 5316 5368 5420 5472 5524 5576 }
>>> }
>>> ref {
>>> dummyatom ( 0.0, 0.0, 0.0 )
>>> }
>>> }
>>> }
>>>
>>> harmonic {
>>> name tiltpos
>>> colvars tilt position
>>> centers 0.0 0.0
>>> forceConstant 1.0
>>> }
>>>
>>>
>>>
>>>
>>> On Nov 22, 2014, at 7:00 AM, Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:
>>>
>>> > Hi JC,
>>> >
>>> > Can you post the config for your tilt colvar?
>>> >
>>> > Jerome
>>> >
>>> > On 22 November 2014 at 01:12, JC Gumbart <gumbart_at_ks.uiuc.edu> wrote:
>>> >
>>> >> I tried your idea of replacing tilt with orientation. For an example
>>> >> frame, I get for the quaternion (0.31, 0.37, 0.59, -0.64). I then loaded
>>> >> this frame along with my reference frame, translated both so that they were
>>> >> centered on the origin, and then, using quaternion2rmatrix.tcl, applied a
>>> >> rotation. It went from something like this
>>> >>
>>> >> | /
>>> >> | /
>>> >> | /
>>> >> | /
>>> >>
>>> >> to this
>>> >>
>>> >> |
>>> >> |
>>> >> |
>>> >> | ———— (a bit misleading, it’s not perfectly aligned with any axis, but is
>>> >> certainly more planar)
>>> >>
>>> >> Clearly it doesn’t agree with the expected rotation. Comparing the
>>> >> matrices
>>> >>
>>> >> q2r
>>> >> -0.52 0.83 -0.11
>>> >> 0.04 -0.10 -0.98
>>> >> -0.84 -0.53 0.02
>>> >>
>>> >> and measure fit from VMD gives
>>> >> -0.35 -0.85 -0.39
>>> >> 0.81 -0.48 0.33
>>> >> -0.47 -0.20 0.86
>>> >>
>>> >> Shouldn’t these give the same values? What’s going on here?
>>> >>
>>> >> Thanks,
>>> >> JC
>>> >>
>>> >> On Nov 21, 2014, at 12:35 PM, Giacomo Fiorin <giacomo.fiorin_at_gmail.com>
>>> >> wrote:
>>> >>
>>> >> Hi JC, one issue could be that the helix changes structure internally, and
>>> >> the rigid-body assumption breaks down, but perhaps you checked already for
>>> >> that.
>>> >>
>>> >> Another possibility is that the axis is not what it's supposed to be, i.e
>>>
>>>
>>
>>
>
>

This archive was generated by hypermail 2.1.6 : Wed Dec 31 2014 - 23:23:05 CST