<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 27/12/2010 9:22 AM, WU Yanbin wrote:
<blockquote
cite="mid:AANLkTikhD6k+ad2Q+Mb0aaQbQi5p7VhOxSao7z2k8oNt@mail.gmail.com"
type="cite">Hi, Mark,<br>
<br>
Thanks for the reply.<br>
<br>
As suggested, I tried a "water in vacuum" case. Initially the
water droplet is a cubic 4nm-by-4nm-by-4nm water box, located in
the middle of the simulation box. Everywhere else is just vacuum.
The simulation box size is 8nm by 8nm by 8nm. SPC/E model is used
to describe interaction between water molecules.<br>
<br>
Such system is first equilibrated with "steep" option.<br>
<br>
The "mdrun" simulation goes with no problem with parallel running
on 32 cpus, even though there are occasionaly one or two water
molecules move very fast (Mean square displacement being 200 times
fast than bulk water) in the vacuum.<br>
</blockquote>
<br>
OK, that sounds like behaviour that might be expected... some
molecules evaporate. Check the trajectory to be confident this is
the situation.<br>
<br>
<blockquote
cite="mid:AANLkTikhD6k+ad2Q+Mb0aaQbQi5p7VhOxSao7z2k8oNt@mail.gmail.com"
type="cite">
<br>
When I switch to 64 cpus, the error "X particles communicated to
PME node Y are more than a cell length out of the domain
decomposition cell of their charge group" appears.<br>
</blockquote>
<br>
The most plausible reason for this is that the above evaporated
molecules are moving so fast that they're doing what the error
message says - travelling more than width of a box in one
integration step. The DD implementation is predicated on that being
impossible.<br>
<br>
You might succeed by arranging for the largest possible internal DD
cell diameter, i.e. a 4x4x4 DD. mdrun -npme 0 might choose this,
otherwise use the hidden options to mdrun (use mdrun -hidden) to use
that DD with -npme 0.<br>
<br>
Otherwise, you'll need to accept the fact that there are
"engineering" constraints on efficient parallelization algorithms,
and not every situation can be catered for. For example, a
simulation of a bulk LJ fluid would fail if you used so many
processors that the cell diameter was too small with respect to the
distribution of particle speeds.<br>
<br>
Mark<br>
<br>
<blockquote
cite="mid:AANLkTikhD6k+ad2Q+Mb0aaQbQi5p7VhOxSao7z2k8oNt@mail.gmail.com"
type="cite"><br>
Below is the parameter file I'm using.<br>
<br>
------------------------------------<br>
integrator = md<br>
tinit = 0<br>
dt = 0.002<br>
nsteps = 5000000<br>
<br>
comm-mode = Linear<br>
nstcomm = 1<br>
comm-grps = <br>
<br>
energygrps = <br>
<br>
nstlist = 1<br>
ns_type = grid<br>
pbc = xyz<br>
rlist = 1.5<br>
<br>
coulombtype = PME<br>
rcoulomb-switch = 0<br>
rcoulomb = 1.5<br>
epsilon-r = 1<br>
<br>
vdw-type = Cut-off ;Switch<br>
rvdw-switch = 1.0<br>
rvdw = 1.5<br>
<br>
fourierspacing = 0.12<br>
fourier_nx = 0<br>
fourier_ny = 0<br>
fourier_nz = 0<br>
pme_order = 4<br>
ewald_rtol = 1e-05<br>
ewald_geometry = 3d<br>
epsilon_surface = 0<br>
optimize_fft = no<br>
<br>
Tcoupl = nose-hoover<br>
tc-grps = System<br>
tau_t = 1.0<br>
ref_t = 300<br>
<br>
Pcoupl = no ;Parrinello-Rahman ;no ;berendsen<br>
Pcoupltype = isotropic<br>
tau_p = 1.0<br>
compressibility = 4.5e-5<br>
ref_p = 1.0<br>
<br>
gen_vel = no<br>
gen_temp = 300<br>
gen_seed = 2008<br>
<br>
constraints = none<br>
constraint-algorithm = Lincs<br>
Shake-SOR = no<br>
shake-tol = 1e-04<br>
lincs-order = 4<br>
lincs-warnangle = 30<br>
<br>
energygrp_excl = <br>
------------------------------------<br>
<br>
Is there any parameters configuration wrong with the simulation?
Or is there any way to go around this error?<br>
<br>
Any tip is appreciated.<br>
Thank you.<br>
<br>
Best,<br>
Yanbin<br>
<br>
<br>
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 02 Dec 2010 17:24:18 +1100<br>
From: Mark Abraham <<a moz-do-not-send="true"
href="mailto:Mark.Abraham@anu.edu.au">Mark.Abraham@anu.edu.au</a>><br>
Subject: Re: [gmx-users] How to suppress the error "X
particles<br>
communicated to PME node Y are more than a cell
length out of the<br>
domain decomposition cell of their charge group"<br>
To: Discussion list for GROMACS users <<a
moz-do-not-send="true" href="mailto:gmx-users@gromacs.org">gmx-users@gromacs.org</a>><br>
Message-ID: <<a moz-do-not-send="true"
href="mailto:4CF73B92.40003@anu.edu.au">4CF73B92.40003@anu.edu.au</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 2/12/2010 4:16 PM, WU Yanbin wrote:<br>
> Dear GMXers,<br>
><br>
> I'm running a simulation of water contact angle
measurement on top of<br>
> graphite surface.<br>
> Initially a water cubic box is placed on two-layer
graphite surface<br>
> with the rest of the box being vacuum. The water droplet
is relaxed<br>
> during the simulation to develop a spherical shape.<br>
><br>
> An error of "X particles communicated to PME node Y are
more than a<br>
> cell length out of the domain decomposition cell of their
charge<br>
> group" was encountered.<br>
> And I have read the suggested solutions at the link below<br>
> <a moz-do-not-send="true"
href="http://www.gromacs.org/Documentation/Errors#X_particles_communicated_to_PME_node_Y_are_more_than_a_cell_length_out_of_the_domain_decomposition_cell_of_their_charge_group"
target="_blank">http://www.gromacs.org/Documentation/Errors#X_particles_communicated_to_PME_node_Y_are_more_than_a_cell_length_out_of_the_domain_decomposition_cell_of_their_charge_group</a>.<br>
><br>
> I guess the reason for this error in my case is because
of the vacuum<br>
> such that the water molecules at the boundary of the
droplet can move<br>
> fast. I have check the trajectory and the simulation is
OK.<br>
<br>
I doubt the simulation is OK. This error message is one of
several that<br>
can happen when the system is not well-enough conditioned for
the MD to<br>
be stable. See <a moz-do-not-send="true"
href="http://www.gromacs.org/Documentation/Terminology/Blowing_Up"
target="_blank">www.gromacs.org/Documentation/Terminology/Blowing_Up</a>.<br>
Here, you have atoms moving much faster than GROMACS was
engineered to<br>
expect.<br>
<br>
You should be confident that a water drop in a vacuum, and
your graphite<br>
surface are both stable on their own before you try the
wetting simulation.<br>
<br>
><br>
> For this situation, is there a way of suppressing this
error? Or what<br>
> else can I do?<br>
<br>
Work out why it's poorly conditioned.<br>
<br>
Mark<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>