Dipole correction & number of cores - bug ?

[Matt W]

Hi,

I can't reproduce your results - your test case runs fine for me on 1, 2 or 
4 cores. I guess you may have a bad version of ifort? Did you run the 
regtests to see if your build seemed correct?

Matt

On Thursday, August 24, 2017 at 5:42:31 PM UTC+1, ashish dabral wrote:
>
> Dear all,
>
> I have been facing some strange issues with CP2K version 4.1 and I'm 
> looking forward having your advice. 
>
> I would like to apply the self-consistent dipole correction for a slab 
> calculation and I noticed an inconsistent behavior of cp2k with respect to 
> the number of cores used:
>
> Whenever I'm running a simple exercise of a water molecule in a box (see 
> the attached test.inp file) using 1 core, the dipole correction is working 
> smoothly and I'm reaching convergence without any issue. On the other hand 
> if I'm using more than 1 core, cp2k returns the following error message: 
> " Dipole correction needs more vacuum space above the surface ".
>
> I hence hacked a bit the code to understand what I did wrong and printed 
> some information from the surface_dipole.F routine.
>
> I monitored the "height_min" and  "rhoav_min" internal variables that are 
> used to detect the position of the vacuum section in the supercell. 
> If I'm correct, line 183 of the routine is basically checking whether the 
> average of the electronic density (rhoav_min - if I got it well) is low 
> enough (IF (rhoav_min >= 1.E-5_dp) -> stop) to provide the index of the 
> numerical grid that corresponds to vacuum.
>
> The strange thing is that whenever I'm using 1 core, cp2k detects a 
> rhoav_min value of 2.776668424252914E-007 within the first scf cycle and 
> goes on without any issue until convergence. 
> On the other hand, while whenever I'm using 2 and 4 cores, it returns a 
> value of :2.327421985372404E-004 and 6.156728744828596E-005, respectively. 
> In both cases, this is larger than the threshold used to detect the vacuum 
> part at line 183 (IF (rhoav_min >= 1.E-5_dp)) - I attached the log files 
> for your inconvenience. 
> I was naively expecting that rhoav_min should be the same, independently 
> of the number of the grid used but obviously either there is an issue with 
> the averaged value or the system is probing another point of the grid. 
> Unless if I'm mistaken, it looks to me that there is an issue with the 
> collection by mpi of the grid values or something like that but 
> unfortunately, I could not trace further the issue. 
>
> I'm hence wondering if someone else has met the issue and if so, I'd 
> really appreciate if you could help me figuring out what is on-going and 
> what I missed.
>
> Thank you very much for your help,
>
> Regards,
>
> Ashish
>
> P.S. The code has been compiled with the intel compiler version 2016.1.150 
> and its mkl and mpi libraries.
> I tried without optimization (-O0) and with (-O2) and both have the same 
> issues.
>
>  
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20170824/51eeeec4/attachment.htm>