LAMMPS users and admins,
I am reporting what seems to be a bug I came across while trying to use the developer version of lammps. Most cases seems to work just fine, I have tested ADP and MEAM potentials, but an eam/alloy potential keeps segmentation faulting. The problem is not with the potential, as it currently runs normally with the stable lammps. I did not see any updates or edits to the eam/alloy in the recent changes to the lammps code, so I did not expect to see such an error.
Is this a known issue, or is there perhaps something particular about my build that may be causing such a thing?
Ben
Is this with all eam/alloy potentials or a specific one only?
Can you provide a simple/small input deck to reproduce the issue?
there are no known issues currently.
axel.
Axel,
I just now tried it with a provided eam/alloy potential in the lammps/potential directory and it seems to work fine.
However, the eam/alloy that works fine with the stable version, does not run. So it must be an error with the potential file, but in some way lammps has changed how it is reading in the input file or how it expects it to terminate.
I dont think you need the input deck, as lammps quits as soon as the pair coeff is specified and the potential file is read in.
I am using a NIST repository interatomic potential, so this isnt something of my own creation gone haywire. https://www.ctcms.nist.gov/potentials/entry/2013–Smirnova-D-E-Kuksin-A-Y-Starikov-S-V-et-al–U-Mo-Xe/
Ben
Axel,
I just now tried it with a provided eam/alloy potential in the lammps/potential directory and it seems to work fine.
However, the eam/alloy that works fine with the stable version, does not run. So it must be an error with the potential file, but in some way lammps has changed how it is reading in the input file or how it expects it to terminate.
yes, LAMMPS is checking now the return value of file reads. That allows us for example to detect damaged potential or restart files.
I dont think you need the input deck, as lammps quits as soon as the pair coeff is specified and the potential file is read in.
I am using a NIST repository interatomic potential, so this isnt something of my own creation gone haywire. https://www.ctcms.nist.gov/potentials/entry/2013–Smirnova-D-E-Kuksin-A-Y-Starikov-S-V-et-al–U-Mo-Xe/
ok. I don’t get a segmentation fault, but an error message (running with 1 CPU):
$ ./lmp -in in.eam
LAMMPS (3 Mar 2020)
using 1 OpenMP thread(s) per MPI task
Lattice spacing in x,y,z = 3.615 3.615 3.615
Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
1 by 1 by 1 MPI processor grid
Created 32000 atoms
create_atoms CPU = 0.00421786 secs
ERROR on proc 0: Unexpected end of file while reading file ‘/home/akohlmey/compile/lammps/build-gcc-fft/U_Mo_Xe.2013.eam.alloy’ (src/MANYBODY/pair_eam.cpp:798)
Last command: pair_coeff * * U_Mo_Xe.2013.eam.alloy U
when checking the file, it appears, it is one number short (obviously a 0.0). without the check for short reads, the last line that was read (also a 0.0) will be parsed multiple times. adding a 0.0 at the end makes the file read correctly and the results should be the same.
It may be worth reporting this to the NIST database and ask them to check and possibly correct the file, if the confirm the short file.
axel.