Dear lammps users,
I have used the lattice custom command to create the hexagonal structure of Fe2O3. I've tried to use the region prism command to create a matching hexagonal simulation box, and then fill it with create_atoms. Which seems to be possible according to the doc page, using an xy tilt factor of -0.5.
But visualization shows that the resulting structure differs from the expected unit cell. The lattice looks good, but the overall shape is different: a few atoms are missing at some of the box edges and some others show up at other edges. As if the box shape didn't quite match that of the cell.
Here are the commands I used. What did I do wrong?
lattice custom 1 a1 5.039 0.0 0.0 a2 -2.5195 4.363902 0.0 a3 0.0 0.0 13.77 &
basis 0.00000 0.00000 0.143 &
etc.
basis 0.63063 0.96397 0.41667 &
orient x 1 0 0 orient y 0 1 0 orient z 0 0 1 &
spacing 5.039 5.039 13.77
region box prism 0 1 0 1 0 1 -0.5 0.0 0.0
create_box 2 box
create_atoms 1 box basis 1 1 etc.
Any help would be greatly appreciated.
Dear lammps users,
I have used the lattice custom command to create the hexagonal structure
of Fe2O3. I've tried to use the region prism command to create a
matching hexagonal simulation box, and then fill it with create_atoms.
Which seems to be possible according to the doc page, using an xy tilt
factor of -0.5.
But visualization shows that the resulting structure differs from the
expected unit cell. The lattice looks good, but the overall shape is
different: a few atoms are missing at some of the box edges and some
others show up at other edges. As if the box shape didn't quite match
that of the cell.
Here are the commands I used. What did I do wrong?
it is the same story over and over again. 
you placed the simulation box to coincide *exactly* with the lattice
points which makes the test whether atoms would are within that region
or not subject to floating point precision and truncation issues.
think about is. if an atom is *exactly* on the border, should it be
included or not? LAMMPS does handle this case consistently in case
that position can be computed with the same precision. but due to
limitations of floating point math, that exact number may not be
representable and then it depends on which possible representative
number is used. if you have non-orthogonal boxes, regions and custom
lattices, things get worse, because there are more floating point math
operations involved.
the situation can be easily resolved by moving your box by 0.1 unit so
that there is no more ambiguity about whether an atom is inside or
outside and it is not affected by floating point math truncation.
axel.
Thank you Axel, your answer was useful. Apart from the floating point precision issue, there was a mistake in the box geometry.
Jonathan