Negative values of distance point plane

[Daniel_M]

Hello Teo and everybody,

I will be very glad to refresh the user pages... but before that, I am
very afraid that my problems are not solved yet. I will tell you what
is happening now:

As I said in my previous message, I launched the calculation defining
the plane with three atoms very inside the cell (atoms 85, 87 and 92),
and everything seemed to be going well... until the step 433 in the
molecular dynamics, in which the same "jump" happened to the distance
atom-plane. Then I looked at the trajectory, drawing the cell
boundaries and wrapping the atoms, and none of these atoms was
crossing the boundaries!

And then, just to be sure, I looked at another calculations that I had
done with another CV  (the difference between two bond distances), and
I realized that in these calculations also were jumps in the CV
distance difference, but I didn't realize it before because the
trajectory seemed perfectly smooth. So I looked at the trajectory
again, drawing the cell boundaries and wrapping the atoms, and here
again, no one atom was crossing the boundaries! But the thing is that
I drew the periodic images of the atoms, and I found that the values
of the CV when the "jumps" happen match with the values of the CV if I
take the periodic image of one of the atoms for calculating that CV.
So, my system was beheaving *like* if some atom was crossing the cell
border, but actually no one atom is doing that! I also tried to center
the wrapping cell in the origin instead of in the unit cell, and even
so the system behaviour doesn't match with the CV values.

So finally I thought 'maybe my version of cp2k is a bit old and has
some bug that has already been fixed', and then I found that for my
version, the last CVS entry was in Feb 11, 2009, and I looked at the
changes in the sources since that date and found some changes at March
6 that said "Bug fixed for LANGEVIN on COLVARS". So, that bug that is
fixed in the new versions, may be the responsible of what is happening
to me???

Thank you very much for your help. Sorry about telling you all this,
but I think that may be useful for the rest of the people, just in
case somebody runs into the same problems.

Cheers,
Daniel





On Apr 3, 12:49 pm, Teodoro Laino <teodor... at gmail.com> wrote:
> 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.