[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?
Cheers,
Axel
--
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