Regarding_retaining_same_particle_identities

Hello,

LAMMPS version I currently use is 17Nov2016.

I want to use a fixed boundary (style f) for a simulation, and also retain the particle-ID’s set at the first time step throughout the simulation.

One way to do this would be to use; neigh_modify once yes , but I am also instructing LAMMPS to write restart files and apply the fix_deposit command, which according to the manual will relist the neighbours - thereby changing the ID from the top.

Is there a way to retain the same particle-IDs, given the above conditions.
Could the boundary style m, be useful for this, but then how to ascertain which atoms crossed the boundary.

Regards
-Hari Tejas S Iyer

Hello,

LAMMPS version I currently use is 17Nov2016.

I want to use a fixed boundary (*style f*) for a simulation, and also
retain the particle-ID's set at the first time step throughout the
simulation.

One way to do this would be to use; *neigh_modify once yes* , but I am
also instructing LAMMPS to write restart files and apply the fix_deposit
command, which according to the manual will relist the neighbours - thereby
changing the ID from the top.

​you are mixing up two completely different things. assignment of atom IDs
is completely un​related to neighbor listing. not recomputing neighbor
lists is a very bad idea and makes no sense at all for a system when you
deposit atoms (don't you want those newly added atoms to interact? they
have to be in and have a neighbor list for that).

fix deposit gives you a choice for how it will determine what atom ID is
assigned to a new particle, but that choice has absolutely no impact on
neighbor list construction. an atom ID is a property the will stay an atom
for as long as it isn't removed from it (e.g. by passing through a fixed
boundary or explicitly deleted). the "id" keyword for fix deposit matters
only in this latter case.

Is there a way to retain the same particle-IDs, given the above conditions.

​atoms do *not* change atom IDs unless you explicitly reassign them.​

Could the *boundary style m*, be useful for this, but then how to
ascertain which atoms crossed the boundary.

​this is another confused statement​. with boundary "m", there is no
periodicity and the box is automatically extended, so atoms _by
construction_ cannot cross boundaries. however, this has absolutely nothing
to do with atom IDs.

​if you believe that LAMMPS ​is not behaving in the way i have just
outlined (and what the manual really says), please provide a small(!) test
input deck to demonstrate it and explain how you determine that the code is
not matching what the documentation says.

axel.

Thanks, I understand now. just rechecked the output I was loosing the last atoms from the end of the initial list while using boundary style f. And I guess I misunderstood rebuilding of a neighbour list as a relisting where ids are reassigned, now I know that the ids are unique. I was worried that the atom ids might change if i loose atoms over a fixed boundary.

As for my question, I should use boundary style s/m to avoid particle deletion.

Would it be correct to say, that style m changes the box size and includes the atoms across the boundary in further interactions no matter how far they spread, and style s just shows spread atoms instead of deleting them as happens in style f.

Regards
Hari Tejas S Iyer

Thanks, I understand now. just rechecked the output I was loosing the last
atoms from the end of the initial list while using boundary *style f*.
And I guess I misunderstood rebuilding of a neighbour list as a relisting
where ids are reassigned, now I know that the ids are unique. I was worried
that the atom ids might change if i loose atoms over a fixed boundary.

As for my question, I should use boundary *style s/m* to avoid particle
deletion.

Would it be correct to say, that *style m* changes the box size and
includes the atoms across the boundary in further interactions no matter
how far they spread, and *style s* just shows spread atoms instead of
deleting them as happens in *style f*.

​m and s are mostly the same. the only difference is that with m the box
will not shrink below its initial size.​