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 16:55:24 +0200

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 

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

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


-----Original Message-----
From: Axel Kohlmeyer [mailto:akohlmey@...24...] 
Sent: Sunday, May 6, 2018 9:55 PM
To: Olivier Politano <olivier.politano@...1102...>
Cc: Barnes, Brian C CIV USARMY RDECOM ARL (US) <brian.c.barnes11.civ@...5608...3...>; Shumeyko, Christopher M CTR USARMY RDECOM ARL (US) <christopher.m.shumeyko.ctr@...2733...>; lammps-users@lists.sourceforge.net
Subject: Re: [lammps-users] [Non-DoD Source] Re: Problem with Ackland Analysis (UNCLASSIFIED)

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 browser.  




----

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


> 
> Regards,
> 
> Olivier
> 
> 
> 
> Le 4 mai 2018 à 23:00, Barnes, Brian C CIV USARMY RDECOM ARL (US) 
> <brian.c.barnes11.civ@...2733...> a écrit :
> 
> 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:
> Caution-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
> 
> -----Original Message-----
> From: Shumeyko, Christopher M CTR USARMY RDECOM ARL (US)
> 
> (redacted)
> 
> -----Original Message-----
> From: Alexander Stukowski 
> [Caution-mailto:stukowski@...503...]
> Sent: Friday, May 4, 2018 11:20 AM
> To: Axel Kohlmeyer <akohlmey@...24...>
> Cc: Barnes, Brian C CTR USARMY ARL (US) 
> <brian.c.barnes11.ctr@...2733...>; Olivier Politano 
> <olivier.politano@...1102...>; LAMMPS Users Mailing List 
> <lammps-users@lists.sourceforge.net>
> 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 browser.
> 
> 
> ________________________________
> 
> 
> 
> 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.
> 
> 
> -Alex
> 
> 
> On 4. May 2018, at 14:52, Axel Kohlmeyer <akohlmey@...24... < 
> Caution-Caution-mailto:akohlmey@...24... > > wrote:
> 
> 
> 
> On Fri, May 4, 2018 at 5:40 AM, Olivier Politano 
> <olivier.politano@...1102... < 
> Caution-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 green.
> 
> 
> [...]
> 
> 
> 
> 
> 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-https://sourceforge.net/p/lammps/mailman/message/34258
> 128/ < 
> Caution-Caution-https://sourceforge.net/p/lammps/mailman/message/34258
> 128/ >
> 
> 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 ackland/atom.
> 
> 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 here.
> 
> axel.
> 
> 
> 
> 
> 
> Regards,
> 
> Olivier
> 
> 
> 
> 
> ----------------------------------------------------------------------
> -------- Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org < 
> Caution-Caution-http://Slashdot.org > !
> Caution-Caution-http://sdm.link/slashdot < 
> Caution-Caution-http://sdm.link/slashdot > 
> _______________________________________________
> lammps-users mailing list
> lammps-users@lists.sourceforge.net <
> Caution-Caution-mailto:lammps-users@lists.sourceforge.net > 
> Caution-Caution-https://lists.sourceforge.net/lists/listinfo/lammps-us
> ers < 
> Caution-Caution-https://lists.sourceforge.net/lists/listinfo/lammps-us
> ers >
> 
> 
> 
> 
> 
> 
> --
> 
> Dr. Axel Kohlmeyer  akohlmey@...24... < 
> Caution-Caution-mailto:akohlmey@...24... >
> Caution-Caution-http://goo.gl/1wk0 < 
> Caution-Caution-http://goo.gl/1wk0 > College of Science & Technology, 
> Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.
> 
> 
> CLASSIFICATION: UNCLASSIFIED
> 
> 
> CLASSIFICATION: UNCLASSIFIED
> ----------------------------------------------------------------------
> -------- Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! 
> Caution-http://sdm.link/slashdot 
> _______________________________________________
> lammps-users mailing list
> lammps-users@lists.sourceforge.net
> Caution-https://lists.sourceforge.net/lists/listinfo/lammps-users
> 
> 



--
Dr. Axel Kohlmeyer  akohlmey@...24...  Caution-http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.


CLASSIFICATION: UNCLASSIFIED
<ack_axel.png>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
lammps-users mailing list
lammps-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lammps-users