Hello,
I am currently using both fix deposit (on a set of single-site species) and fix evaporate (on a set of small rigid molecules).
I am working with a custom fix at the pre_force stage that performs a conversion from local atom ID to tag ID (to perform computations), and then a conversion from tag ID back to local atom ID (to populate per-atom properties). The mapping between local and tag IDs is updated every timestep.
If only fix deposit is used, then everything works fine. However, the addition of fix evaporate causes some havoc to occur with the tag IDs used in the custom fix. After attempts at troubleshooting, I saw that the tag IDs to begin to exceed the total number of atoms, but I was stuck on why this is the case.
To address this issue, I am trying to invoke the functions of reset_atom_ids and reset_mol_ids at the beginning of the pre_force fix (at every timestep). If this is possible, how exactly would I reference these functions from a fix?
I am also trying to understand why the combination of fix deposit and fix evaporate would cause this issue with the tag IDs, but have been stuck so far and would appreciate if there are any pointers as to why this could be happening.
Thank you,
Anne
I don’t understand why you need your own mapping between atom ID and local atom index. that is already provided by LAMMPS.
for the local index i, atom->tag[i] will return the atom ID and atom->map(atomid) will return either the index i or -1 depending on whether an atom is present.
it is perfectly valid for the atom ID to be larger than the number of atoms.
axel.
I am also trying to understand why the combination of fix deposit and fix evaporate would cause this issue with the tag IDs, but have been stuck so far and would appreciate if there are any pointers as to why this could be happening.
that is how those fixes are programmed. fix evaporate will just eliminate atoms (and thus their IDs are gone), while fix deposit will append atom (and molecule) IDs at the upper end (to avoid conflicts and expensive searches (in parallel!!) on which atom IDs are available “in the holes”).
axel.
Thanks Axel,
I’ll look into atom->map as suggested.
Do you know if such a combination of deposit and evaporate is likely to cause problems with the underlying local and tag ID sequences over time, or are there safeguards in place? (Particularly with deposit working on single sites and evaporate working on rigid molecules. )
I’m trying my best to understand the underlying code, but am a bit stuck on detecting whether issues with the constant ID elimination/addition will arise.
Thank you,
Anne
I am not aware of any particular limitations along the lines you are asking about. that should be especially the case for your scenario where the groups of particles deposited and those evaporated do not overlap. Restrictions should be the same as they are when each of the fixes is used individually only.
axel.
1 Like