Dear lammps users,
I am trying to use reax/c with eam. I have 4 different type of atom treated with reax/c and 5th atom with eam potential. I am getting following error. I am not sure if this problem is memory related or some other issues. I am using ~300000 atoms on 1440 cores.
“ERROR on proc 2: Failed to allocate 9731128776 bytes for array pair:frho (…/memory.cpp:64)”
Similar message from other processors as well. I am attaching my input file, forcefield. I couldn’t attach datafile due to large size.
Pb_real.set (142 KB)
log (100 KB)
in.pb_k (1.62 KB)
ffield.reax (16.1 KB)
lmp_control (1009 Bytes)
Yes, there is not enough physical memory for EAM to allocate an array for frho. This usually occurs when you have too large a system, or you have bad initial configuration (most likely too dense).
Ray
Dear lammps users,
I am trying to use reax/c with eam. I have 4 different type of atom treated
with reax/c and 5th atom with eam potential. I am getting following error. I
am not sure if this problem is memory related or some other issues. I am
using ~300000 atoms on 1440 cores.
"ERROR on proc 2: Failed to allocate 9731128776 bytes for array pair:frho
(../memory.cpp:64)"
Similar message from other processors as well. I am attaching my input file,
forcefield. I couldn't attach datafile due to large size.
how about creating a simple test input first to validate each part of
your input?
e.g. something like this?
"""
units real
region box block 0 10 0 10 0 10
create_box 1 box
create_atoms 1 single 5.0 5.0 5.0
pair_style eam
pair_coeff * * Pb_real.set
run 0
"""
...and you will see, that this input cannot run. most likely because
your eam potential file is bogus or not in the right format.
no 300000 atoms on 1440 cores run needed to debug and fix. in general,
it is *strongly* recommended (and common sense dictates it, too), to
not start such a massive calculation without making small test runs on
the individual components to validate their correctness. if you waste
a few hours or days of computation on a desktop machine, no big
problem, and debugging/testing is fast.
axel.
Good point, Axel! Reax/c uses real units and EAM metal units. By using real units in a hybrid reax/EAM input, EAM is not building the frho list correctly.
Good point, Axel! Reax/c uses real units and EAM metal units. By using
real units in a hybrid reax/EAM input, EAM is not building the frho list
correctly.
that is a different story. the memory allocation fails with far too
large a number. frho allocation depends on parameters given in the
potential file and nothing else. that means, the potential file was
not correctly parsed, which in turn suggests, that the EAM potential
file is in the wrong format. if it was "only" in the wrong units,
LAMMPS would still be able to read it. only the results of the
simulations would be off.
i'm adding some checks to the EAM file reader routines, that will help
detect when people use an incorrectly formatted EAM potential file
like in this case. this will hopefully be included in the next LAMMPS
release.
as for the units, the lj/cut parameters are *very* suspicious, too.
they look like they were generated with a POOMA approach.
You have to create an EAM potential file with real units for it to at least
run. The correctness of the hybrid reax/EAM model is another question.
yes, that is another serious concern. especially, since it doesn't
look like there was a significant amount of testing the model involved
here.
axel.