[Top][All Lists]
[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