Bug in atom_modify with (admittedly unusual) delete_atoms command

I found a bug today with delete_atoms when it's combined with an atom map.
Admittedly, it's a fairly rare circumstance: it happens because I ran
delete_atoms when there WERE no atoms. The following four lines will
reproduce it:

atom_modify map array
region simbox block 0 1 0 1 0 1 units box
create_box 1 simbox
delete_atoms group all

Note that the "hash" map style will do it, too. The result is a
segmentation fault on any partition which has not had any atoms created.

Note that I found this by recycling an old NEB simulation file, which I
realized would have failed later because the syntax changed. Someone
actually sent me a message telling me, personally, about that feature, and
I'm just now getting to testing it. Sorry....

In this case, I had created atoms on one partition to create the product
state file, then deleted them. However, I deleted the atoms on all
partitions, even those that didn't have any created in the first place.
This setup worked fine with an older version (from last summer, for
example), but breaks with the modifications made to atom_map.cpp some
months ago.

Thanks!

Karl D. Hammond
University of Tennessee, Knoxville
[email protected]...

"You can never know everything, and part of what you know is always
   wrong. A portion of wisdom lies in knowing that. A portion of courage
   lies in going on anyway."
"Nothing ever goes as you expect. Expect nothing, and you will not be
   surprised."

I found a bug today with delete_atoms when it's combined with an atom map.
Admittedly, it's a fairly rare circumstance: it happens because I ran
delete_atoms when there WERE no atoms. The following four lines will
reproduce it:

atom_modify map array
region simbox block 0 1 0 1 0 1 units box
create_box 1 simbox
delete_atoms group all

Note that the "hash" map style will do it, too. The result is a
segmentation fault on any partition which has not had any atoms created.

yup. there is a related problem that was just fixed in the 2Apr2014
patch. there are probably multiple ways to address your issue. here is
my suggestion that goes on top of that patch.

[[email protected]... src]$ git diff
diff --git a/src/atom.cpp b/src/atom.cpp
index 2280943..84a4031 100644
--- a/src/atom.cpp
+++ b/src/atom.cpp
@@ -161,9 +161,9 @@ Atom::Atom(LAMMPS *lmp) : Pointers(lmp)

   tag_enable = 1;
   map_style = map_user = 0;
- map_tag_max = 0;
+ map_tag_max = -1;
   map_maxarray = 0;
- map_nhash = 0;
+ map_nhash = -1;

   max_same = 0;
   sametag = NULL;
@@ -1848,9 +1848,9 @@ bigint Atom::memory_usage()
   memory->destroy(memstr);

   bytes += max_same*sizeof(int);
- if (map_style == 1)
+ if (map_style == 1 && map_tag_max >= 0)
     bytes += memory->usage(map_array,map_maxarray);
- else if (map_style == 2) {
+ else if (map_style == 2 && map_nhash >=0) {
     bytes += map_nbucket*sizeof(int);
     bytes += map_nhash*sizeof(HashElem);
   }
diff --git a/src/atom_map.cpp b/src/atom_map.cpp
index 1d16cd7..13e1df8 100644
--- a/src/atom_map.cpp
+++ b/src/atom_map.cpp
@@ -291,7 +291,7 @@ int Atom::map_style_set()

   // map_tag_max = max ID of any atom that will be in new map

- tagint max = 0;
+ tagint max = -1;
   for (int i = 0; i < nlocal; i++) max = MAX(max,tag[i]);
   MPI_Allreduce(&max,&map_tag_max,1,MPI_LMP_TAGINT,MPI_MAX,world);

this should be fixed in the next patch

Steve