[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo] Diffusion of a probe particle

From: Axel Arnold
Subject: Re: [ESPResSo] Diffusion of a probe particle
Date: Mon, 6 Aug 2007 20:15:13 +0200
User-agent: KMail/1.8.2

Hi all!

On Monday 06 August 2007 16:13, Olaf Lenz wrote:
> The main problem seems to originate from the following:
> On the one hand, when I set up a single probe particle and let it
> diffuse, the script needs to return control to the Tcl level very often,
> so that I get a very significant time overhead. The only solution to
> this that I see would be to implement the measurement of the MSD in C so
> that the simulation does not have to return to the Tcl level. This would
> however neither be simple nor in the spirit of ESPResSo, so I would like
> to avoid this.

Well, why is not in the spirit of Espresso? I mean, the MSD would be a nice 
feature. The problem is a bit how to implement it, because we a memory for 
the last 1000 or so positions for each particle. On a single CPU, one could 
use the config array, but in parallel, that would be pretty inefficient. 
Nevertheless, it is doable.

> On the other hand, when I set up a larger number of probe particles
> (e.g. 10000), this also seems to create a time overhead, even though the
> particles do not interact, and the memory requirements are still far
> from any hard memory limits (approx 10 MB). Apparently, the particles
> are somehow included in the Verlet-list of the other particles, even
> though they do not interact.

Yes, they are. Currently, we build up the Verlet according to one interaction 
range for all particles, i.e., the interaction range is dictated by the most 
longranged interaction. That is not ideal; assuming you have two huge 
colloids in your system, then the interaction range for all particles will be 
twice the size of the two colloids. Even for particles that do not interact 
at all, you actually get the largest necessary Verlet cutoff.

> To get rid of this problem, I tried to make 
> the box length as large as possible (e.g. box_l=1000). This should cause
> the particles to be far from each other so that they do not occur in
> each other's Verlet lists any more. This did indeed reduce the problem,
> but still a large number of particles significantly slows down the
> simulation. Also, changing the Verlet skin affected the timing.
> Where, exactly, does this overhead for larger particle numbers come from?

How many cells did you then have? Espresso loops over cells, and then over the 
particles in the cells. Assuming that you have an interaction range of 2, you 
have in the worst case 500^3=125.000.000 cells, which would not even fit into 
memory. In practice, that doesn't happen, since the number of cells is 
limited by max_num_cells, but depending on what you put there, the 
cell-looping can still take quite some time. On the other hand, a small 
max_num_cells, which is the default, causes large cells, which also makes 
things really slow.

> Furthermore, making the box size very large will not work any more as
> soon as obstacles of a certain density are introduced. Either it is
> necessary to create lots of replicas of the obstacles, or I have to make
> the box relatively small - both methods would make the simulation slow
> again. Does anyone have an idea how to handle this?

Well, I wanted to calculate the MSD for completely free particles, there were 
no interacting ones. So, I simply commented out the force calculation... Not 
nice, but helps.

> Using a large box length, I have also tried to disable the Verlet lists.
> From my understanding, this should speed up the simulation, as no Verlet
> list update would ever be required and the size of the default cell
> lists should be small enough not to contain any neighboring particles.
> However, this did not seem to be the case. Instead, the simulation was
> significantly slower (factor 3 or so). Can anybody explain this to me?

Hmm, that is again a question of max_num_cells, and how many cells you 
actually had. From what you tell, I guess you have the default max_num_cells. 
Can you try playing around with it, like setting it to 10000 or more?


Dr. Axel Arnold
FOM Institute for Atomic and Molecular Physics
Kruislaan 407                                   Phone: +31 20 6081 275
1098 SJ Amsterdam, The Netherlands              E-mail: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]