LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Mailing List Archives
Re: [lammps-users] [Non-DoD Source] Re: Problem with Ackland Analysis (UNCLASSIFIED)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pascal Brault <pascal.brault@...2724...>
Date: Tue, 8 May 2018 10:12:43 +0200

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 ?

Attachment: lattice.lammpstrj
Description: Binary data

Kind regards

Pascal Brault
CNRS-Université d'Orléans

Le 7 mai 2018 à 03:54, Axel Kohlmeyer <akohlmey@...24...> a écrit :

On Sat, May 5, 2018 at 8:57 AM, Olivier Politano
<olivier.politano@...1102...> wrote:
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,

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



Le 4 mai 2018 à 23:00, Barnes, Brian C CIV USARMY RDECOM ARL (US)
<brian.c.barnes11.civ@...2733...> a écrit :


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:

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


Brian Barnes
US Army Research Laboratory

-----Original Message-----
From: Shumeyko, Christopher M CTR USARMY RDECOM ARL (US)


-----Original Message-----
From: Alexander Stukowski [mailto:stukowski@...503...]
Sent: Friday, May 4, 2018 11:20 AM
To: Axel Kohlmeyer <akohlmey@...36.....24...>
Cc: Barnes, Brian C CTR USARMY ARL (US) <brian.c.barnes11.ctr@...2733...>;
Olivier Politano <olivier.politano@...1102...>; LAMMPS Users Mailing
List <>
Subject: [Non-DoD Source] Re: [lammps-users] Problem with Ackland Analysis

All active links contained in this email were disabled. Please verify the
identity of the sender, and confirm the authenticity of all links contained
within the message prior to copying and pasting the address to a Web


The implementation of the Ackland analysis found in OVITO is, according to
my first assessment, is still based on the “old” algorithm version from
LAMMPS. The algorithm in OVITO hasn’t changed since the very first program
release as far as I can recall. The "n0 < 11” check, for example, mentioned
by Brian Barnes in his contribution, is missing in OVITO’s implementation of
the Ackland analysis.


On 4. May 2018, at 14:52, Axel Kohlmeyer <akohlmey@...24... <
Caution-mailto:akohlmey@...1125..... > > wrote:

On Fri, May 4, 2018 at 5:40 AM, Olivier Politano
<olivier.politano@...1102... <
Caution-mailto:olivier.politano@...1102... > > wrote:

Dear Lammps users,

We are still working with Lammps 12Apr13. When we perform an ackland
analysis with this version of LAMMPS, we obtain the following image for some
atomic configuration. BCC atoms are represented in blue and FCC atoms are


I went through the file « compute_ackland_atom.cpp » in the USER-MISC
directory and I found some modifications between the versions 12Apr13 and
7Dec15 (or later). However, I did not find mentions of these changes in the
webpage "Latest Features and Bug Fixes in LAMMPS » or in the source file.

after a little digging in the git repository and the mailing list archives,
i think i have found the origin of the change you noticed in this
contribution posted to the mailing list:

Caution- <
Caution- >

it comes with some detailed explanations, so please have a look.

So, I’m wondering if someone also noticed this drastic difference of result
for the Ackland analysis and if there is a bug or a problem with the newer
implementation of Ackland.

that e-mail claims to have removed some issues with the "old" implementation
and the changes were approved by the original contributor of compute

i am copying brian, who contributed these changes, in the hope, that he may
be able to comment on his changes and your observations.

and i am also copying alex, the author of ovito in the hope, that he can
provide some insight into what algorithm/implementation his code uses and
how that stacks up with what the code in LAMMPS does.

it would be fairly easy to roll back the changes, but unless there is some
tangible information that can prove what is correct for all cases and where
the problem is at the implementation level, it is difficult to make a choice




Check out the vibrant tech community on one of the world's most
engaging tech sites, < Caution- > !
Caution- < Caution- >
lammps-users mailing list < >
Caution- <
Caution- >


Dr. Axel Kohlmeyer  akohlmey@...24... < Caution-mailto:akohlmey@...24... >
Caution- < Caution- >
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.


Check out the vibrant tech community on one of the world's most
engaging tech sites,!
lammps-users mailing list

Dr. Axel Kohlmeyer  akohlmey@...24...
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
lammps-users mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature