espressomd-devel
[Top][All Lists]
Advanced

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

Re: [ESPResSo-devel] Some user feedback


From: Axel Arnold
Subject: Re: [ESPResSo-devel] Some user feedback
Date: Wed, 4 Feb 2009 14:55:07 +0100
User-agent: KMail/1.7.1

Hi!

Thanks for the suggestions. Now we just need some volunteers to implement 
things :-). I have commented some of them below, because not everything is 
possible as easily as it looks on a first glimpse.

Am Mittwoch 04 Februar 2009 12:21 schrieb Kai Grass:
> - Pore constraint doesn't check absolute coordinates, i.e. if you
> have a pore at say (L-0.5) with a interaction range of 1, particles
> that come from the next box only "see" the pore once they are in the
> primary simulation box (at L). Same might apply for cylinder, but is
> not a problem for walls due to their orientation.

Periodicity and constraints is a permanent source of problems and has been 
discussed before, without finding the perfect solution. Checking absolute 
coordinates for the constraints is never a good idea: for example, if you 
have a pore perpendicular to the z-coordinate, then particles that are more 
than one box-length away from the pore will not feel it at all (because the 
pore has a finite extension in z). However, due to PBC, the particles would 
still interact, i. e., for the system it would look like there are particles 
inside the walls of the pore. 

However, what indeed is inconvenient is that you cannot place a pore across 
the box boundaries; in this case, you need to pores, one at the lower 
boundary and one at the higher one. To do this directly in the C-routines is 
not so simple.

> - Writevsf runs out of "labels (O,C,N,Fe,...)" if too many (>6?)
> different types are used. Currently just blanks are written to the
> structure file which renders it useless as the format is screwed up.
> There should at least be a warning, better a default type that is used.

> Inconveniences:
> - Constraint use only LJ potential. This might cause problems if you
> have a confined system with high particle density and you are forced
> to use LJ-force cap for equilibration. Can be circumvented by using a
> different potential for inter particle interactions and constraints.

Since quite some time the wall-particle interaction is just a nonbonded 
interaction, and can be different from LJ (e.g. soft sphere or so). However, 
in any case, you need different interactions for wall-particles and 
particles-particles, if you want to apply different parameters. 

> Feature requests:
> - Fully delete interactions, instead of just setting epsilon=0 or
> r_cut=0

You cannot delete interactions by construction, because Espresso uses an 
interaction matrix. Therefore, the number of interactions is always equal to 
the number of particletypes^2. Just that typically most of them have r_cut=0.

By construction, Espresso loops over all pairs of particles within a certain 
distance, and then checks what the interactions between two individual 
particles are according to their type. That is a simple and fast table 
lookup: ia_params[type1*n_particle_types + type2]. Using a list or similar 
where interactions can be deleted would mean to go through the whole list of 
interactions to find the active ones, which for typical systems with 3-4 
configured interactions would be much slower.

So, we could add a feature "inter 0 0 lennard-jones off", but that would 
simply set the cutoff of the nonbonded interaction to 0.

> - Different cell systems for different interactions (don't know if
> the speed up outweighs the additional overhead)

That is in fact not quite so easy. "Cell system" in terms of Espresso refers 
to an organization scheme of the particles in memory. For example, the domain 
decomposition really stores particles in small memory segments according to a 
spatial decomposition, while the atom decomposition stores them in one big 
memory segment per processor. It also decides which particles exist as ghosts 
from other processors. Therefore, particles can never be organized according 
to more than one cell system. However, one could add something like a linked 
cells on top of a cell system. This will be however something quite 
challenging to implement. Any volunteers? :-)

> - Different Langevin friction for different particle types, i.e. to
> model different sized particles

That should be easy to do, you just need to add a table of langevin 
parameters. Again, we need volunteers for that...

> PS: Is there a reason why www.espresso.mpg.de is down?
Hmm, probably has to do with the reorganization of the servers at MPI-P. 
Torsten should know that, but seems to take much longer than anticipated.

Axel

-- 
Dr. Axel Arnold 
Fraunhofer SCAI
Schloss Birlinghoven, 53754 Sankt Augustin, Germany
Tel: +49 2241 14 2575



reply via email to

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