Problem with Windows Version: Energy/Stress Calculation

LAMMPS LAMMPS Mailing List Mirror
1

I have run into trouble with the LAMMPS windows executable. When doing a simple calculation of energy as a function of lattice parameter, my results differ significantly from the result from a Linux version. With small changes in lattice parameter, I get a large fluctuation in energy (see below):

Lattice Potential Eng. Box Length
3.46 -6082.514327 24.22
3.47 -6012.025551 24.29
3.48 -6095.449002 24.35999999
3.49 -6021.19394 24.42999999
3.5 -6102.997554 24.49999999

These spikes in energy do not appear when running on Linux. And, they are accompanied with a deviation in shear stress:

Press Volume PotEng Pxx Pyy Pzz Pxy Pxz Pyz Lx Ly Lz
102095.85 14207.655 -6082.5143 102095.85 102095.85 102095.85 -4.3350925e-011 -1.3113132e-011 -3.7827262e-011 24.22 24.22 24.22
76320.432 14331.2 -6012.0256 77526.832 76733.11 74701.354 3722.7466 2766.1006 1601.5653 24.29 24.29 24.29
65534.737 14455.458 -6095.449 65534.737 65534.737 65534.737 -4.3005358e-012 -1.5274444e-011 -1.3699379e-011 24.36 24.36 24.36

I have been able to reproduce this issue with different versions of Windows executables from the LAMMPS website (May 2011 and the most recent), and ones that I compiled myself (July 2009 and 10 April 2012). This occurs regardless which Ni EAM potential I use and whether I am on Windows XP or 7. The offending input file is appended below. This script is being used for a atomistic modeling course, which is taught in a Windows computer lab.

Do you what could be causing this, or recommend changes to this input file to avoid it?

Thanks,
Logan

variable ncells index 7
variable a0 index 3.52
variable del index 0.01
variable numrep index 30

units metal
boundary p p p
atom_style atomic

lattice fcc 1
region 1 block 0.0 \{ncells\} 0\.0 {ncells} 0.0 ${ncells}
create_box 1 1
create_atoms 1 box

mass 1 58.6934
pair_style eam/alloy
pair_coeff * * Ni.johnson.txt Ni

# Calculations for scaling box during loop
# a - Lattice parameter
# back - To scale back to 1
variable a equal "v_a0-v_numrep/2*v_del+(v_loopvar-1)*v_del"
variable back equal "1/v_a"
variable l equal lx
variable p equal pe
thermo_style custom step temp press vol pe etotal pxx pyy pzz pxy pxz pyz lx ly lz

# Loop through several lattice parameters
variable loopvar loop ${numrep}
label loop

displace_box all x scale $a y scale $a z scale a run 0 print "\#OUTPUT\# {a} \{p\} {l}"
displace_box all x scale \{back\} y scale {back} z scale ${back}

next loopvar
jump in.strain.txt loop

2

Maybe Paul can look at this to see if he
can reproduce the problem.

Steve

3

I'm on travel this week, but I can look into this further when I get back. In the meanwhile, Logan, I'm curious if you can isolate the problem to specific a LAMMPS command that might not be working right in the Windows environment, or if the problem appears to be more pervasive. I'm also wondering if it could be related to a 32 bit vs 64 bit issue, especially if this problem is highly sensitive to floating point precision.

Paul

4

I found a simple workaround: Using "change_box ... delta" instead of "change_box ... scale" to impart a stain on the cell yields identical results on Linux and Windows.

Best,
Logan

5

Also, note that the "displace_box" command that was causing problems in your original input script has been deprecated in the current version of the LAMMPS source code (see 9 Feb 2012 patch here: http://lammps.sandia.gov/bug.html). Of course, we'll need to update the Windows executable beyond that patch for this change to take effect for users of the Windows executables. In the meanwhile, I'd recommend using the "change_box" command instead of the "displace_box" command, as you've already discovered.

Paul