Removing atoms from a group

Right now there are two ways that I know of to remove atoms from a static
group: (1) delete the group and create it again, or (2) make the group
dynamic, somehow set the condition for being in the group to "false" for
all the atoms you want to delete, wait for the group to be dynamically
updated, and then making the group static again. I haven't ever tried the
latter, but I would guess it would work (?).

Does it make sense to have a "clear" key word, e.g.,
   group mygroup clear
that would keep the group defined (thus keeping fixes, dumps, etc. happy)
but would clear the group's member list so the user can "start over" in
terms of the actual members of the group? The following lines in
group.cpp seem to do the trick if I add them right after the check for the
"delete" key word:

/* BEGIN ADDED LINES */
else if ( strcmp(arg[1],"clear") == 0 ) {
   int igroup = find(arg[0]);
   if (igroup == -1) error->all (FLERR,"Could not find group clear group ID");
   if (igroup == 0) error->all (FLERR,"Cannot clear group all");
   int *mask = atom->mask;
   int nlocal = atom->nlocal;
   int bits = inversemask[igroup];
   for (i = 0; i < nlocal; i++) mask[i] &= bits;
   return;
}
/* END ADDED LINES */

Would there be any obvious side effects to such a change? It might be
useful for things like changing the atoms that are dumped using a
"run XXX every XXX ..." command, for example, or for redefining the atoms
in a compute/fix/dump between runs without having to redefine the
compute/fix/dump itself.

Karl D. Hammond
University of Tennessee, Knoxville

karl,

i don't see much of a technical issue, whether you add or remove an
atoms from a group. the removal just hasn't been programmed. i don't
see much of a principal problem for either.

[...]

Would there be any obvious side effects to such a change? It might be
useful for things like changing the atoms that are dumped using a
"run XXX every XXX ..." command, for example, or for redefining the atoms
in a compute/fix/dump between runs without having to redefine the
compute/fix/dump itself.

now *that* may cause problems. there is a reasons why by default fixes
do not access dynamic groups by default. many fixes need to do special
memory allocations and initialization during the setup() phase, that
assumes that things don't change afterwards. for dumps there is also
the "dump_modify thresh" option

axel.

Added a clear option to the group command.
Will be in the next patch.

As Axel indicated this is probably a new way
to shoot your simulation in the foot, if you
invoke it in the middle of a run.

Steve