orient in hcp lattice

Hi everybody,

I’ve encountered an error when I was trying to define an hcp lattice with a specific orientation. I think the problem is the same as Anurag mentioned here (http://lammps.sandia.gov/threads/msg46959.html). I think he’s right about lammps. What lammps is doing to check the orthogonal condition is correct when a1=a2=a3, but in other situations before calculating dot produc, it should first multiply every component by their respective spacings. For example (q w e) and (r t y) should first be changed into (q.a1 w.a2 e.a3) and (r.a1 t.a2 y.a3) then dot product should be calculated.

I’m using LAMMPS (17 Dec 2013-ICMS).

Isn’t it a bug?

Hi everybody,

I've encountered an error when I was trying to define an hcp lattice with a
specific orientation. I think the problem is the same as Anurag mentioned
here (http://lammps.sandia.gov/threads/msg46959.html). I think he's right
about lammps. What lammps is doing to check the orthogonal condition is
correct when a1=a2=a3, but in other situations before calculating dot
produc, it should first multiply every component by their respective
spacings. For example (q w e) and (r t y) should first be changed into (q.a1
w.a2 e.a3) and (r.a1 t.a2 y.a3) then dot product should be calculated.
I'm using LAMMPS (17 Dec 2013-ICMS).
Isn't it a bug?

please follow the discussion in the mailing list to the very end and
you'll see that anurag was wrong. this is a rather fundamental feature
in LAMMPS and it is not likely that such a fundamental issue would
have gone unnoticed for such a long time.

in any case, when you believe there is a bug in LAMMPS you need to do
two more things:
- try with the very latest version. bugs are fixed as soon as they are
known and a fix is been found.
- provide a minimal input that reproduces the suspected issue and a
proof why you disagree.

axel.

Hi,

I did install the latest version today, it says 27 May 2014, and the issue still remains unsolved.

I tried two different scripts and I think there is a problem. I am attaching those two and respective log files, also I’m providing a picturet describing why I think in this way.

Mehdi.

arbit.in (2.23 KB)

log.lammps.arbit (3.85 KB)

log.lammps.pyramid (939 Bytes)

Mg.eam.fs (745 KB)

pyramid.in (2.23 KB)

orient.JPG

Hi,

I did install the latest version today, it says 27 May 2014, and the issue
still remains unsolved.

the latest version is currently 11 Sep 2014, as shown at:
http://lammps.sandia.gov/bug.html

I tried two different scripts and I think there is a problem. I am attaching

have you followed the discussion in the mailing list archives all the
way? please note that the thread continues in a separate thread entry.
the outcome was that there was a misinterpretation of what LAMMPS
does.

Hi Axel,

Sorry to bother you. I did read the discussion (the last reply was by Ray Shan, Jul 12 2014, 13:26), and I still think the same.
I got the most recent release (11 Sep 2014-ICMS) and the results are the same. I hope you got the attached files in previous email. If so, would you please have a look at them and may run it for yourself. For further clarification, the issue is not even crystallographic, it’s mathematical. The formula used for measuring angle between two vectors is based on this assumption that units in x, y, and z directions have the same length, which is not the case here (I think that’s the point Anurag was trying to make by saying the structure is orthorhombic).

Mehdi.

Hi Axel,
Sorry to bother you. I did read the discussion (the last reply was by Ray
Shan, Jul 12 2014, 13:26), and I still think the same.
I got the most recent release (11 Sep 2014-ICMS) and the results are the
same. I hope you got the attached files in previous email. If so, would you
please have a look at them and may run it for yourself. For further
clarification, the issue is not even crystallographic, it's mathematical.

like i said before, it often also happens that people make the wrong
assumption what LAMMPS does and what the input means.

i don't have the time to work through your files.

just had a quick look at the documentation, and it is quite clear: the
three orient vectors *have* to be orthogonal and it doesn't matter
what your basis vectors are. those three vectors (defaulting to 1 0 0,
0 1 0, and 0 0 1, respectively) represent a transformation matrix
(after normalization). if the three orient vectors would not be
orthogonal, that transformation would include a deformation.

axel.