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

[Teodoro Laino]

Daniel,

just an additional reply, cause I understand the frustration you expressed
in your message above.

We have the user-pages (wiki) here on the google forum. Axel started 
them 2 years ago..
and it's time to refresh them..
So...
Why don't you create a new one on COLVAR and specify there what you wrote
in your message ?
I'm sure that future users will be extremely glad..
and you will give part of your time to the CP2K project.

Cheers
Teo

Daniel_M wrote:
> Yes, that was also my first guess: the program computes the plane
> employing the periodic image of some atom when this atom goes out of
> the cell. Yesterday I launched the same calculation defining the plane
> with three atoms more centered in the cell and nothing weird is
> happening. I am very sorry because I should have done this before
> posting my problem here.
>
> On the other hand, I think that it would be a good idea to introduce
> some note about this in the input manual, just a line saying "please
> keep in mind that the CV's are computed in such a way that ...(etc
> etc)...". Maybe for the developers this is a such an obvious question
> that doesn't need to be commented, but I think that this is the kind
> of comment that beginner users like me (not just beginner with cp2k,
> but beginner with periodical systems too) would find very useful. I
> say this because, even when I knew that my atoms were very close to
> the cell borders, I thought "ok, but maybe the CV's are computed in
> such a way that it doesn't matter if an atom goes out of the cell, in
> order to avoid abrut changes in the CV's". Now I realize that
> accounting for this effects would require a lot of hard work in the
> development and we need to be more realistic about the things that we
> expect from the code.
>
> Thank you very much for your time!!
>
> Cheers
> Daniel
>
> On Apr 3, 12:40 am, Laino Teodoro <teodor... at gmail.com> wrote:
>   
>> Dear Daniel,
>>
>> First my apologies cause you will never see me running an input file
>> like that. It takes too much time compared to my free time.
>>
>> What I can say is that, the COLVAR you mentioned is bug-free. Several
>> other tests (I did right now) assessed its reliability.
>>
>> Nonetheless, just inspecting at the geometry of your system I *think*
>> it's quite obvious the source of your problem.
>> Could you please load the trajectory file you generated with VMD,
>> setting up the cell and wrapping all the atoms
>> inside the cell for all the snapshots?
>> (the TRAJECTORY file in CP2K never wraps atoms inside the cell).
>>
>> Once you have done that.. I'm sure it will be obvious to you why the
>> distance changes sign "without obvious reasons".
>>
>> Hint: the atoms defining your plane are close to the border of the cell.
>>
>> Teo
>>
>> On 2 Apr 2009, at 12:32, Daniel_M wrote:
>>
>>
>>
>>     
>>> Well, I am completely sure that the index of the atoms are fine, so I
>>> have uploaded a input file called "proof.inp". Maybe it will not run
>>> very fast, but from all the tests that I have done, this is the one in
>>> wich the problem is showed more quickly. In the file 'colvar.txt' one
>>> can see this after some steps:
>>>       
>>>          0.0     -4.24017     -1.93942     -4.24017     -1.93942
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          0.2     -4.23735     -1.93803     -4.23735     -1.93803
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          0.4     -4.23490     -1.93660     -4.23490     -1.93660
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          0.6     -4.23280     -1.93516     -4.23280     -1.93516
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          0.8     -4.23101     -1.93372     -4.23101     -1.93372
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          1.0     -4.22959     -1.93225     -4.22959     -1.93225
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          1.2     -4.22858      1.85731     -4.22858      1.85731
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>          1.4     -4.22796      1.85447     -4.22796      1.85447
>>> 0.00000      0.00000      0.00000      0.00000      0.00000
>>> 0.00000
>>>       
>>> So here is the "jump" in the second colvar, the distance point plane.
>>> In my other tests, one can see more "jumps" like this, but these jumps
>>> appear after much more steps that in this case. I have been looking
>>> carefully to be completely sure that this is not a problem with the
>>> index of the atoms or something like that, so I will be very thankful
>>> if you can tell me something about this.
>>>       
>>> Thanks again,
>>> Daniel
>>>       
>>> On Apr 1, 9:15 pm, Laino Teodoro <teodor... at gmail.com> wrote:
>>>       
>>>> 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.
>>>>>>>               
> >
>