Bug? Weird behaviour for FIXED_ATOMS in GEO_OPT (recent CP2K versions)

[Dr_Nick]

Hi Marcella,

thanks for your quick reply! I just checked and this solves the problem for 
recent 2.3 and 2.4 versions.

Best regards,
Raphael

On Wednesday, October 24, 2012 11:22:55 AM UTC+2, marci wrote:
>
> Dear Raphael
>
> You should be  able to recover the right behavior changing the BFGS 
> section as follows
>
>     &BFGS
>       USE_MODEL_HESSIAN FALSE
>       USE_RAT_FUN_OPT TRUE
>       TRUST_RADIUS 0.1
>       @if ${HESSIAN} == 1
>         RESTART_HESSIAN
>         RESTART_FILE_NAME ${PROJECT}-BFGS.Hessian
>       @endif
>     &END
>
> This restores the old defaults. 
> I hope the problem will be fixed soon.
>
> kind regards
> marcella
>
> On Tuesday, October 23, 2012 11:25:24 PM UTC+2, Dr_Nick wrote:
>>
>> Hi all,
>>
>> I am running a GEO_OPT with constraints. My file (attached) contains the 
>> following section:
>>
>>   &CONSTRAINT
>>     &FIXED_ATOMS
>>      COMPONENTS_TO_FIX XYZ
>>      LIST 1 2 11..14 35..38
>>     &END FIXED_ATOMS
>>   &END CONSTRAINT
>>
>> I recall that this worked with CP2K 2.2 and 2.3 version: i.e. the xyz 
>> coordinates of the fixed atoms do not move during optimization. 
>>
>> However with 2.4 (today's 12467) I noticed some very strange things:
>> - the 1st geometry (i=1) in the -pos-1.xyz file does NOT correspond to 
>> the starting structure. All positions are slightly off. This is also true 
>> when no constraints are applied and / or when I use other input files! 
>> - Fixed atoms move slightly.
>> - In one of my systems, some of the fixed atoms move slightly, while 
>> other fixed atoms experience large and totally "senseless" deplacements 
>> which causes the geometry optimization to fail.
>>
>> N.B.
>> - the constraints section is correctly read in because no force is 
>> displayed for the fixed atoms.
>> - the starting structure is reasonable because it was preoptimized before 
>> with another software.
>>
>> I ran the same input on different machines (Magny Cours and Xeon) to 
>> check for parallelization / optimization / compiler / version issues.
>> 2.4 branch 12467, 12431
>> 2.3 branch 12343, 12275, 12230, 12229
>> AMD: gcc 4.6.3 / 4.6.2 / 4.7.0 + openmpi 1.6.1 + openblas 0.1.1 / 0.2.3 + 
>> fftw 3.3
>> INTEL: intel 12.1.2 + openmpi 1.6.1 + MKL + intel FFTW / -O2 and -O3 
>> optimization
>> These versions have been compiled either by me or the admins of our 
>> cluster. I guess they know what they are doing.
>>
>> Here are my findings:
>>
>> - running on 1 CPU (cp2k.sopt) or using only 1 MPI process (cp2k.popt), 
>> everything is OK (*all versions*)
>> - running on more than 1 CPU everything is OK for <= 2.3 12230. All 
>> higher revisions are affected.
>> - OpenMPI has probably no influence because with the same version 
>> (1.6.1), old CP2K revisions are ok, new revisions are not. This would 
>> require more testing but where can I download old 2.3 revisions? The svn 
>> always gives you the most recent version.
>> - O2 / O3 optimization tested in the case of the intel compiler: no 
>> difference.
>>
>> So in my understanding, all versions >= 2.3 12230 are affected, when 
>> running on more than 1 CPU.
>>
>> Could you please have a look into this issue or try to reproduce? My 
>> input files are attached.
>>
>> Best regards and thanks for your help,
>> Raphael
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20121024/6aca9a2c/attachment.htm>