[Top][All Lists]

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

RE: [ESPResSo] Diffusion of a probe particle

From: Limbach, Hans Joerg, LAUSANNE, NRC-FS
Subject: RE: [ESPResSo] Diffusion of a probe particle
Date: Fri, 10 Aug 2007 17:17:19 +0200


> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On Behalf Of Olaf Lenz
> Sent: lundi, 6. août 2007 16:13
> To: ESPResSo users' mailing list
> Subject: [ESPResSo] Diffusion of a probe particle
> Hash: SHA1
> Hello!
> I'm currently computing diffusion constants of probe 
> particles in systems with different obstacles. For a start, I 
> just want to simulate free diffusion of non-interacting 
> particles without any obstacles and measure the mean-square 
> deviation (MSD).
> Using ESPResSo, this yields a number of problems which render 
> the simulation pretty inefficient. I want to ask whether any 
> of you has some more ideas on how to treat the problem efficiently.
> 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.
> 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. 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?
I guess the best choice is to set max_num_cells to roughly the number of 
particles (balance running through cells and running through particles, I even 
think Bernward wrote a command to optimize this) and set a dummy interaction 
with 0 interaction range and skin to (box/(n_part)^1/3)=size of the cells. This 
makes roughly one particle per box and a maximally large skin which reduces the 
number of times Espresso tries to setup new verlet lists (which of course will 
be empty all the time). This should be rather fast.
> 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?
> Using a large box length, I have also tried to disable the 
> Verlet lists.
I guess then Espresso does try to find interaction partners at every step (Also 
maximale Entschleunigung, sozusagen die Berner Variante ;-))
> - 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?
See above

> Best regards
>       Olaf
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFGtyx5tQ3riQ3oo/oRAoDUAJ4kPkZnq9Gggp7W75t5XbRhrbOI+ACgovIi
> OanAEH+aaH3u1DxScK9Zbe8=
> =rvhT
> _______________________________________________
> ESPResSo mailing list
> address@hidden

reply via email to

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