I've been trying to write a new dump style that creates some dummy atoms,
checks their positions relative to the existing atoms, outputs the atoms
(or not) according to neighboring criteria, and deletes the dummy atoms.
The core concept is similar to the "overlap" routine in DeleteAtoms, but
instead of deleting it just adds the atoms to a group.
However, I've had significant trouble getting a neighbor list that's
updated after the dummy atoms are created and that preserves group
memberships for the ghost atoms (such as is done in "delete atoms
overlap"). I read an earlier post indicating that dumps by themselves
can't request neighbor lists:
http://lammps.sandia.gov/threads/msg03748.html
which explains why neighbor->request(this) always returns 0, and some of
the pointers in neighbor->requests[0] don't actually point anywhere
(i.e., they're set to NULL).
I've tried simply using something like
NeighList *neighbor_list = neighbor->lists[0];
but then the resulting neighbor list includes ghost atoms that aren't
labelled according to the group the real atom is in (presumably because
the dummy atoms were added since the last time the neighbor list was
rebuilt) and/or the atoms aren't wrapped around the periodic boundaries
(e.g., the distance between an atom and its "neighbor" is greater than
sqrt(3)/2 * boxlength in a cubic simulation).
What is the best way to force a neighbor list rebuild in this situation?
After reading the post linked above, I think perhaps it might work to
define a compute that does the bulk of the grunt-work, and then let the
dump simply output without doing any neighbor list work. Based on my
reading, computes CAN request neighbor list builds, and those builds are
done every time the dump requests the results of the compute (which would
work). However, I wanted to ask before taking even MORE time to learn how
computes are encoded....
Thanks in advance.
Karl D. Hammond
Off the top of my head, there are several problems with what
you are trying to do:
a) dumps have no connection to neighbor lists, and the Neighbor
class knows nothing about dumps
b) adding/deleting atoms at the point in time of a dump would
be tricky
c) dumping info about atoms that don't really exist seems tricky/odd
as well
There might be other ways to do what you want, but I don't really
know what you're trying to do.
The rules-of-thumb I would follow are:
a) the only good time to add/delete atoms is right before neighboring
is done, in a fix. This is what fix evaporate and fix deposit do,
for example.
b) the only place to request neigh lists be built are from a fix
or compute (or pair style).
c) If you make a fix or compute that calculates what you want
as a per-atom quantityy, then dumps of that quantity will just work.
d) You might think about defining dummy atoms (your points in space?)
at the outset of your simulation, have them not participate in pair computations
or other fixes, but be used by a new fix you write which invokes
a neighbor list and computes the per-site info you want.
Steve
The gist of what I'm trying to do is create a dump command that outputs
atoms that are farther off-lattice than a given distance and marks "empty"
sites as vacant. These kinds of vacancy/interstitial outputs are very
common in high-energy solid-state physics and radiation damage
simulations. We've been doing this by post-processing for cubic lattices,
which is relatively straightforward, but for long/large simulations it
produces VERY large files with mostly throwaway data in them.
Thank you very much for your insight---I'll keep working on it. I'm not
sure what this will look like by the end, but it may end up as a
combination of a new dump style and new compute style or a new fix style,
coupled together.
Karl
Here is another idea that might help. All of the dump
commands except one really work with one line
of output per atom, which sounds different than what
you have. The exception is dump local. In its most
general form it dumps arbitrary lines of output that each
processor creates for it. It might be a line per pairwise
interaction or per bond. But it could also be
just about anything. If you wrote a compute that calculated
what you describe: list of off-lattice atoms plus
a list of vacant sites (which sound like they have
nothing to do with atoms), then the compute could
create such an array of quantities (lines and oolumns of the dump file)
which dump local would output. Each processor
could create some arbitrary number of these lines (stored in
the compute) and it should work. See how compute pair/local
or compute bond/local does this.
Steve