Each time step that fix_gcmc is called, one of the first things that is
done in pre_exchange() is a call to update_gas_atoms_list(). If
molecules and regions are being used, this creates a list of all the
molecules that have a COM in the defined region. For each MC move
(besides insertion), a random molecule is chosen from the created list
(which is updated after each move). Therefore, a translation MC move can
only happen to a molecule which is on the list, and again to be on the
list the COM must be inside the region. So a check of whether a molecule
is inside the region is made through the creation of the gas list.
Yes, you are right. I could debug through the fix_gcmc invocation and
pre_exchange() is supposed to get a list of atoms/molecules within the
region. This seems to work for almost all cases but I could until now
not identify the reasons for doing otherwise on very rare occasions.
There seems to be a problem somewhere connected to regions+pbc mapping
in cases of slab geometries. I can provide a rather simple input file
where (to be seen in the log file attached) perfectly valid molecules
(spc water) are garbled in domain->unmap() for unknown reasons. I added
some debug output to FixGCMC::attempt_molecule_rotation_full() and
simply did not accept the move that lead to garbled coordinates. This
way one can see very frequently those mis-mappings in the case provided
in the input file.
I tried to simplify the case as much as possible and ended up with a
slab of 75 x 75 x 30 A where z is the non-periodic dimension. This
system is divided along z into three equal volumes where the middle
volume serves as the insertion/deletion region. This is a simple
gcmc run, no hybrid-md necessary.
z (0..30)
^
---------------------------|
>
. . . . . . . . . . . . . .|
insert / delete |
. . . . . . . . . . . . . .|
>
---------------------------|-> x/y (0..75)
The mis-mapping of atoms in a molecule always occurs if the c.o.m
of the molecule is close to one side of a (x/y-) periodic boundary,
and the atom to be considered is also close or on the opposite.
example - both com and atom at the y boundary:
atom[46],
orig[]=19.0777,0.341809,14.2008,
com_xcm[]=18.6022,4.83711,13.4173,
unmap[]=0.475507,70.5047,0.783526, !!
after attempted rotation in attempt_molecule_rotation_full():
rot[]=32.0765,70.0295,-9.82383,
remap[]=32.0765,70.0295,-9.82383
coordinates are garbled.
example 2: com at the +x-boundary, atom at the opposite boundary:
atom[449],
orig[]=0.269543,51.2352,19.9119,
com_xcm[]=70.1756,51.5687,19.8013,
unmap[]=-69.9061,-0.333438,0.110587, !!
after attempted rotation in attempt_molecule_rotation_full():
rot[]=3.40587,48.5915,-0.690678,
remap[]=3.40587,48.5915,-0.690678
coordinates are garbled.
The distances of the atoms from the com of the molecules do
not match the normal size of the water molecules (too far away).
This would probably suggest there have been undetected errors
before which lead to these suspicious coordinates/mappings.
The molecules do not come close to the z boundaries of the
slab within the simulation time.
Now that's how it's supposed to work, do you have a simplistic input
script showing the behavior (infinite loop) that you described in your
post?
Please see the attachment (rename to .zip). I did not see the
infinite loop on translation in other systems than the complete
configurations but this is probably related to the problem
described in the simple system above.
Thanks & Regards
M.
=>
regions_simple.zip.rename (34.6 KB)