Negative values of distance point plane

[Daniel_M]

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.