[Non-DoD Source] Re: Problem with Ackland Analysis (UNCLASSIFIED)

LAMMPS LAMMPS Mailing List Mirror
1

CLASSIFICATION: UNCLASSIFIED

Thanks for the heads up, Chris. It has been quite some time since I've thought about the Ackland code, and unfortunately I don't have my old postdoc email address or archives from when that change was made. But yes, I wrote that patch. The algorithm itself is described in table II of Ackland and Jones, doi: 10.1103/PhysRevB.73.054104 . The original lammps-users thread discussing my change is available at: http://lammps.sandia.gov/threads/msg55921.html

I believe the original LAMMPS implementation was missing part of step (v) from table II in the paper, and other small discrepancies. I have not examined the Ovito implementation and therefore cannot comment on it. I do enjoy using Ovito (Hi, Alex S.! Nice work).

If there is a question of correctness, I would recommend referencing the Ackland/Jones paper and determining where the implementation, in any program, differs from algorithm described in the text. The n0 < 11 test, for example, is explicitly in the paper. I believe my patch improved the correctness of the LAMMPS implementation, and was trying to help based on a problem I encountered when analyzing my simulation. But, it's possible that someone else's analysis may encounter a difficulty in another part of the implementation.

cheers,

Brian Barnes
US Army Research Laboratory

2

In our case, the new implementation of Ackland in LAMMPS gives incorrect results as it identify fcc instead of bcc lattice. May be other groups also encounter such difficulties.

I was wondering if it would not be possible to keep both implementations and add a flag to the compute ackland command so that the user can choose which version to use.

Regards,

Olivier

3

In our case, the new implementation of Ackland in LAMMPS gives incorrect
results as it identify fcc instead of bcc lattice. May be other groups also
encounter such difficulties.

I was wondering if it would not be possible to keep both implementations and
add a flag to the compute ackland command so that the user can choose which
version to use.

i have just added such an option and included it in a pending pull
request, since it as if possibly neither version is 100% correct, and
so it is better to have a choice where the compute is incorrect until
the situation is fully resolved.

with that in mind, i would very much appreciate it, if one (or
multiple?) of you could check it out.
i am including a minimal test input below, and i was expecting that
for something this simple, both variants would report the same result,
but they didn't.
hopefully, this helps to figure out where things go south.

thanks in advance,
      axel.

units metal
atom_style atomic
lattice fcc 3.5

region box block 0 21 0 21 0 84 units box
create_box 4 box

region one block 0 21 0 21 0.1 21.1 units box
create_atoms 1 region one

lattice bcc 3.5
region two block 0 21 0 21 21.1 42.1 units box
create_atoms 2 region two

lattice sc 3.5
region three block 0 21 0 21 42.1 63.1 units box
create_atoms 3 region three

lattice hcp 3.5
region four block 0 21 0 21 63.1 84.1 units box
create_atoms 4 region four

pair_style eam
pair_coeff * * Ni_u3.eam

compute 1 all ackland/atom legacy no
dump 1 all custom 1 lattice.lammpstrj type c_1 x y z

run 0

uncompute 1
compute 1 all ackland/atom legacy yes

run 1

4

Hi Axel, Hi all
I did the test with the current (without legacy option) compute ackland/atom. I use the 8 March Lammps version on MacOSX High Sierra last version
I save only type and Ackland c_1 values for clarity.
The file is attached
Recall that :
c_1 values means :

  • 0 = UNKNOWN
  • 1 = BCC
  • 2 = FCC
  • 3 = HCP
  • 4 = ICO
    How to implement the legacy option ? patching from GitHub ?

lattice.lammpstrj (9.04 KB)

5

CLASSIFICATION: UNCLASSIFIED

Hello Axel,

Thank you for providing a test. I slightly modified it to use a LJ potential and simply used the lattice constant and pair definition from LAMMPS' "in.melt" example file. I also modified it to use the current ackland syntax as I do not have your update yet. Attached is an ovito visualization of the result, colored by LAMMPS ackland result (using 22 Feb 18 LAMMPS, current ackland). The color scheme was viridis in ovito, which corresponds to purple = UNKNOWN, green = FCC, blue = BCC, yellow = HCP. Input file pasted below.

As you can see, in all regions, ackland detects the lattice types correctly (with SC as UNKNOWN). Some atoms are unknown at the interface between regions, or near the boundary of the box. I think the latter is because the lattice constant as defined in the input is not an exact multiple of the box length, hence, atoms near a boundary are not in a bulk crystal environment. As your example contains multiple lattice types in one box, I did not worry about the boundaries.

cheers,

Brian

units lj
atom_style atomic
boundary p p p

lattice fcc 0.8442

region box block 0 21 0 21 0 84 units box
create_box 4 box

region one block 0 21 0 21 0.1 21.1 units box
create_atoms 1 region one

lattice bcc 0.8442
region two block 0 21 0 21 21.1 42.1 units box
create_atoms 2 region two

lattice sc 0.8442
region three block 0 21 0 21 42.1 63.1 units box
create_atoms 3 region three

lattice hcp 0.8442
region four block 0 21 0 21 63.1 84.1 units box
create_atoms 4 region four

mass 1 1.0
mass 2 1.0
mass 3 1.0
mass 4 1.0

pair_style lj/cut 2.5
pair_coeff * * 1.0 1.0 2.5

compute 1 all ackland/atom
dump 1 all custom 1 lattice.lammpstrj id type c_1 x y z

fix 1 all nve

run 0

ack_axel.png

6

Dear Brian
This was exactly my feeling when sending my result file : 0 are sc and boundry.
So the ackland sheme actually implemented works good.
Thanks a for the OVITO picture : this is a very clear demonstration.
Best regards

Pascal