Dipole correction & number of cores - bug ?
mattwa... at gmail.com
Thu Aug 24 23:39:55 CEST 2017
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?
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,
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CP2K-user