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

[Teodoro Laino]

Thanks,
I will look into this and will be back to you ASAP.
cheers,
Teo

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.
>>>>>           
> >
>