From: Giacomo Fiorin (giacomo.fiorin_at_gmail.com)
Date: Mon Nov 24 2014 - 16:53:25 CST
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