[CP2K:1940] Re: Negative values of distance point plane
Laino Teodoro
teodor... at gmail.com
Wed Apr 1 19:15:26 UTC 2009
Every COLVAR is extensively debugged.
Of course there could always be a bug hidden somewhere.
I would suggest you to be fully sure that the index of the atoms you
are using for defining
point-plane are really the ones that you after visualize in the
trajectory.
In case you really think that there is a bug, please post here an
input file, which runs
fast (few minutes) and that shows the problem. I will be more than
glad to look into this
problem (if there is a problem).
Cheers
Teo
On 1 Apr 2009, at 20:38, Daniel_M wrote:
>
> Yes, of course there is sign, but what I am saying is that when
> looking at the trajectory, the atom is always at the same side of the
> plane. That is why I said that there were no apparent reasons for the
> changes of sign.
>
> Regards
> Daniel
>
>
> On Apr 1, 7:18 pm, Teodoro Laino <teodor... at gmail.com> wrote:
>> Dear Daniel,
>>
>> the colvar distance_point_plane has indeed a sign (which is of course
>> arbitrary but the convention
>> is kept identical through all the runs).
>>
>> It's like the X-axis when the plane is represented by the Y-Z
>> plane. In
>> this case you have negative values
>> as well as positive ones (depending whether you are on the right
>> or on
>> the left of the plane).
>> The FES is then reconstructed appropriately (keeping into account
>> that
>> there is a sign).
>>
>> Cheers
>> Teo
>>
>> Daniel_M wrote:
>>> Hello all,
>>
>>> I am doing a metadynamics run with two CV's, the first one is a
>>> distance difference, and the second one is a distance form one
>>> atom to
>>> the plane defined by another three atoms (distance_point_plane), and
>>> in the restart file I get this:
>>
>>> &SPAWNED_HILLS_POS
>>> -4.2713988616046992E+00 1.7692731063313687E+00
>>> -4.2415320702304804E+00 1.6823099667946908E+00
>>> -4.1197722933904597E+00 1.6400825985199678E+00
>>> -4.0211331086844284E+00 -1.7636635945478967E+00
>>> -4.0887529234851119E+00 -1.8119253111270353E+00
>>> -4.3118373674780779E+00 -1.8777540223261953E+00
>>> -4.5038606867087800E+00 -1.9127672598968923E+00
>>> -4.5467464488708362E+00 -1.8940504927990562E+00
>>> -4.4478669666377524E+00 -1.8071942971411046E+00
>>> -4.2782329931276726E+00 -1.6799394839899713E+00
>>> -4.0599453872710356E+00 -1.5353354404292809E+00
>>> -3.7256739864976223E+00 -1.4408969228377622E+00
>>> -3.2889301466304106E+00 1.5168333233130824E+00
>>> -3.3312107263224515E+00 1.6300531470526305E+00
>>> -3.9632834279171361E+00 1.8350661975684184E+00
>>> -4.7936175752581018E+00 2.0804316415464172E+00
>>> -5.3922491308119431E+00 2.2976355912785600E+00
>>> -5.6080480550074885E+00 2.4572528448822148E+00
>>> -5.4284540537686894E+00 2.5602508049566670E+00
>>> -4.9798068411401930E+00 2.6085576679914477E+00
>>> -4.3567044485888404E+00 2.5994868107989220E+00
>>> -3.7234913325899757E+00 -2.3902310570173584E+00
>>> -3.3239883518412294E+00 2.5195888354088920E+00
>>> &END SPAWNED_HILLS_POS
>>
>>> As you can see, in the second column the distance_point_plane takes
>>> positives and negatives values with no apparent reason (and I have
>>> checked the trajectory and the system behaviour is correct), so I
>>> suposse that "internally" cp2k is treating these values as positive
>>> values, but I don't know if this may be indicative of some more
>>> important bug. And, in any case, I think that this will lead to
>>> serious problems when reconstructing the FES if somebody tries to do
>>> that without taking a look at the restart file previously.
>>
>>> Regards,
>>
>>> Daniel
>>
>>> ** I have been looking at the previous discussions and haven't found
>>> anything about this. My apologies if this has been already
>>> discussed.
> >
More information about the CP2K-user
mailing list