[CP2K:1971] Re: Negative values of distance point plane
Teodoro Laino
teodor... at gmail.com
Tue Apr 7 12:43:39 UTC 2009
Dear Daniel,
I seriously doubt that the situation is really like you say.
COLVARS are used not only in metadyn but also as constraints/restraints.
They have been extensively tested in many cases..
Anyway, if you will be able to provide an example running very fast (< 1
minute), possibly using classical MD,
then you can come back and we can discuss again the problem.
Keep in mind that the amount of time we can dedicate in helping you is
very limited and if you want help
from people you need first to help people (that's a kind of general rule
in forums!), working a bit on isolating
and reproducing in a clever way what you think is a bug.
Till then, input files running at 400 Ryd cutoff, 15-20 Angstrom cells
and QZV8P basis sets are very
probably ignored (since you don't need to waste 15 minutes to compute
energy and forces to show a
possible bug which is located in a part of the code that does not
depend on the way you compute forces!!)
Just as a remark the commit "Bug fixed for LANGEVIN on COLVARS" was
related only to lagevin
applied on COLVARs (a very special version of metadynamics, which does
not influence anyway the
value of the COLVARs).
Regards,
Teo
Daniel_M wrote:
> 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.
>>>>>>>>>
> >
>
More information about the CP2K-user
mailing list