[CP2K:1940] Re: Negative values of distance point plane

[Laino Teodoro]

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.
> >