Negative values of distance point plane

[Daniel_M]

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.