Re: tilt colvar

From: JC Gumbart (gumbart_at_ks.uiuc.edu)
Date: Mon Nov 24 2014 - 17:57:44 CST

You’d think I’d remember, but wrapping has always been that annoying thing I ignore until it matters, and then promptly forget about. :)

Thanks guys!
JC

On Nov 24, 2014, at 5:53 PM, Giacomo Fiorin <giacomo.fiorin_at_gmail.com> wrote:

> Hi JC, if you remember, a few years back during development we had a different approach, whereby all atoms in one selection/group would be wrapped to the periodic image closest to the 1st atom. This approach didn't play well with large proteins that span more than half the box dimensions, a problem first noticed in a test run done by you.
>
> Following that error, we implemented and documented the current behavior: no wrapping, and PBCs applied only to the combinations of two positions that clearly represent the distance between two points in the unit cell.
>
> Giacomo
>
> On Mon, 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
>>
>>
>
>
>
>
>
> --
> Giacomo Fiorin
> Assistant Professor of Research
> Institute for Computational Molecular Science (ICMS)
> College of Science and Technology, Temple University
> 1925 North 12th Street (035-07), Room 704D
> Philadelphia, PA 19122-1801
> Phone: +1-215-204-4213
> https://icms.cst.temple.edu/members.html
> http://giacomofiorin.github.io/
>

This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:21:25 CST