Hi,
I am working on Alumina which has a hexagonal structure. I have lattice constants and want to simulate bulk melting temperature. When I create a simulation box which is 2x2. There should be 120atoms (30 atoms in the unit cell). But the simulation box contains only 119. I read the documentation page on non-orthogonal simulation box which says lattice spacing might not be an integer. Could anyone tell me how to create proper non-orthogonal crystal lattice slab?
You need to provide more info about what commands you are using
that produce 119 atoms instead of 120.
Steve
Thank you. I have given the input script here.
units metal
atom_style full
boundary p p p
variable a equal 4.7589
variable b1 equal -2.37945
variable b equal 4.1213283
variable c equal 12.990
variable st equal 1000
variable cs equal 3
variable ca equal v_csv_a
variable cb1 equal v_csv_b1
variable cb equal v_cs*v_b
variable cc equal v_c
Create atoms
lattice custom 1 a1 4.7589 0.0 0.0 &
a2 -2.37945 4.1213283 0.0 &
a3 0.0 0.0 12.990 &
basis 0.306 0.0 0.25 basis 0.0 0.306 0.25 basis 0.694 0.694 0.25 basis 0.694 0.0 0.75 basis 0.0 0.694 0.75 &
basis 0.306 0.306 0.75 basis 0.0 0.0 0.352 basis 0.0 0.0 0.648 basis 0.0 0.0 0.852 basis 0.0 0.0 0.148 &
basis 0.639 0.667 0.917 basis 0.333 0.973 0.917 basis 0.027 0.361 0.917 basis 0.027 0.667 0.417 basis 0.333 0.361 0.417 &
basis 0.639 0.973 0.417 basis 0.333 0.667 0.019 basis 0.333 0.667 0.315 basis 0.333 0.667 0.519 basis 0.333 0.667 0.815 &
basis 0.973 0.333 0.583 basis 0.667 0.639 0.583 basis 0.361 0.027 0.583 basis 0.361 0.333 0.083 basis 0.667 0.027 0.083 &
basis 0.973 0.639 0.083 basis 0.667 0.333 0.685 basis 0.667 0.333 0.981 basis 0.667 0.333 0.185 basis 0.667 0.333 0.481
#region box block -30.0 60.0 -30.0 60.0 -30.0 60.0 units box
region box1 prism 0.0 {ca} 0.0 {cb} 0.0 {cc} {cb1} 0 0 units box
box tilt large
create_box 2 box1
create_atoms 2 region box1 basis 1 2 basis 2 2 basis 3 2 basis 4 2 basis 5 2 basis 6 2 basis 7 1 basis 8 1 basis 9 1 basis 10 1 &
basis 11 2 basis 12 2 basis 13 2 basis 14 2 basis 15 2 basis 16 2 basis 17 1 basis 18 1 basis 19 1 basis 20 1 &
basis 21 2 basis 22 2 basis 23 2 basis 24 2 basis 25 2 basis 26 2 basis 27 1 basis 28 1 basis 29 1 basis 30 1
mass 1 26.981539
mass 2 15.9994
#Define Potential
pair_style vashishta
pair_coeff * * AlO.vashishta Al O
There is a lot going on here, so it is hard to tell what exactly is the problem. However, the likely source is that you are defining lattice points that lie exactly on the box boundary (x=0.0 or y=0.0). Round-off error in triclinic cell computations can sometimes result in these atoms lying slightly outside the box, in which case they are not created (this is a necessary feature of create_atoms region). The solution is to slightly change either the lattice origin or the box dimensions. The first is less disruptive. Just add
origin 0.001 0.001 0.001 &
to the lattice command.
Aidan
Thank You. But the basis are defined using the lattice vectors. So even though I may shift the origin it just results in a lengthening of the lattice vectors. Yes, I think increasing the box size will get the missing atom back. But, Ideally speaking, this should not happen when all the atoms defined lie inside the unit cell. I mean all coefficients of the basis vectors are positive and less than 1.
you are missing the point here.
when your box corners and sides are *exactly* on the position of
lattice points, those atom are *not* inside the box.
they are essentially ambiguously define and LAMMPS uses some
particular checks to make certain, those are consistent and not double
counted or twice excluded. however, this only works reliably with
simple cubic geometries. for many other cases, floating point math
truncation will make numbers, that should be exactly the same no
longer exactly the same (they can be different by as little as a
single bit in the mantissa). since the box's origin location in a
periodic system is invariant to translation it is sufficient to lift
the ambiguity, by simply translating either the box or the lattice by
a small margin that is larger than the largest rounding or truncation
error. 0.1 is a common choice.
this issue has been discussed many time before and the recommendation
has been always the same. please search the mailing list archive, if
you don't believe me.
axel.
Thank you, Sir, for the clarification. I apologize and will go through the mailing list archive more rigorously next time.
Regards,
Prasanna