Re: [ESPResSo-users] iccp3m question

[Stefan Kesselheim]

Hi,

On Oct 6, 2014, at 6:21 AM, Xikai Jiang <address@hidden> wrote:

> I have tested the case using the same P3M parameters on 1 core and 8 cores, 
> but they still give different net charge in the system.
> 
> One way I find to reduce the net charge is to shift all atoms in the system 
> in x- and y- directions by a small amount (~0.1nm), I'm thinking is this 
> related to the wall atoms that ride on the domain decomposition boundary?

that is most likely right, but quite unfortunate. I'm quite sure, I have 
already identified the problem. 

Here is how the parallelism of ICDP3M works: The algorithm assumes the 
electrostatics solver, in this case P3M calculates the forces on all particles, 
including ghost particles, and that it is stored in the force property of the 
particle. The electric field is calculated by dividing the occurring forces by 
the particle charge. Then in each iteration, the algorithm calculates the new 
surface charge density based on the electric field times the normal vector. 
Multiplied by the area of the corresponding discretisation element, this yields 
the new charge to assign to the particle. As the forces on real particles and 
ghost particles are identical (to the bit), the charge update does not have to 
be communicated, but is consistent on all nodes. 
Then, a new iteration step can be performed. 

The iteration in iccp3m_iteration the loop over is executed over the local 
cells. This would be correct, if the local cells included the ghost cells. It 
is however possible that this assumption is wrong. Then, of course, the 
magnitude of the charges becomes inconsistent between the nodes, as it is not 
communicated. Of the other espresso guys someone should know. Can you help guys?

I very surprised that I have not found that problem earlier, but possibly that 
the distance from the boundary was always large enough in my cases. If you 
prepare a smaller test case, that makes it possible to check the stuff faster, 
it can try to fix the problem. On the other hand, it is probably easy to check 
that yourself: Just add a few printfs to iccp3m_iteration(). But I clearly 
recommend a smaller system for that. 

Cheers
Stefan