Hello LAMMPS Developers,
I think I have encountered a bug in the read_dump command.
In my script, I needed to dump a group of atoms into a file, delete those atoms and then read it again for some reason, and I had to do it several times after adjusting some parameters in between each cycle.
I noticed that when I use MPI with 4 processors, the atoms are read incorrectly. Here is a snippet from the log file:
read_dump V30-graphene.dump 0 x y z add yes format native
orthogonal box = (-25.3947 -25.1342 -20) to (25.3947 25.1342 100)
1008 atoms before read
1008 atoms in snapshot
0 atoms purged
504 atoms replaced
0 atoms trimmed
504 atoms added
1512 atoms after read
run 0
I am not sure why half of the atoms (504) were supposedly replaced because after dumping 1008 atoms, I had deleted them, so the atoms that are present now are not the same as those that are being read-in.
However, when I just use one processor, the atoms are read correctly. Here is the snippet from the log file:
read_dump V30-graphene.dump 0 x y z add yes format native
orthogonal box = (-25.3947 -25.1342 -20) to (25.3947 25.1342 100)
1008 atoms before read
1008 atoms in snapshot
0 atoms purged
0 atoms replaced
0 atoms trimmed
1008 atoms added
2016 atoms after read
run 0
I haven't modified my code in these two runs, so I am pretty sure this is a bug in the read_dump command, maybe with the use of one of the MPI functions. I am sorry, I am not able to identify the error in the code myself, because I am a beginner at developing code.
Please let me know if this problem can be solved.
Thanks!
Best Regards,
Nitant Gupta
How do you delete the atoms before the read_dump that
says it is replacing some atoms? And how do you
know that the atoms you think you deleted were
in fact deleted? Can you verify how many atoms
are in the system with a print command of
a variable that stores the total # of atoms?
It is possible that when you
run on 1 procs vs 4 procs that the deletion of
atoms could work differently, depending on how
you do it.
Steve
Dear Steve,
Thank you for replying.
I used the delete_atoms command with style group to delete the group of atoms. Basically, I have two layers of graphene, and I have grouped them separately. I just use the delete_atoms command to delete the top layer (group). This is the snippet from the log file (it is the same for both the cases that I showed earlier):
delete_atoms group gGrapheneNoBubble
Deleted 1008 atoms, new total = 1008
run 0
I started with 2016 atoms, I deleted 1008 atoms belonging to one group and then I tried reading them again using read_dump with 1 and 4 processors, and I got different results.
Is there any other way to delete the atoms that can be used to eliminate this problem?
Best Regards,
Nitant
Quoting Steve Plimpton <[email protected]>:
I’m guessing the read_dump command is doing the right thing,
but that your atom IDs are different on one proc vs 4 procs.
This can happen if you use create_atoms to define them,
or if you renumber the atoms after deleting them (see options
on delete_atoms).
So unless the dump file you are reading in was written
on the same # of procs, its IDs may be different from
what you expect.
Steve
I’ll add that you can debug this by dumping out (to a different file)
the atoms after you have deleted, right before you do the
read_dump and seeing if the IDs do indeed match what is
in the dump file that you are about to read. If they do,
that is why they are getting replaced.
Steve
Dear Steve,
Thank you. With the help of your suggestion I was able to resolve the issue. Indeed it was the delete_atoms command which was reassigning some of the atom IDs after deletion. It wasn't apparent from the manual that I should explicitly use the "compress no" option to not let it happen. It is still strange, though, why it happens on 4 processors and not on 1 processor.
Anyway the problem is resolved, so thanks again!
Best Regards,
Nitant
Quoting Steve Plimpton <[email protected]>:
The way that atoms are renumbered after a delete is different
depending on the number of procs. So the behavior now
makes sense I think. Your script should not rely on knowing
which atoms have which IDs after renumbering, only that they
are consecutive from 1 to Nnew.
Steve