Recently I was performing some cluster-impact simulations using different eam potentials. At the early stages of contact the optimized version of eam/alloy/opt leads to an exploding system: single particles are accelerated to very high velocities and the energy conservation breaks down. On the other hand using eam/alloy with the same setfl potential file the simulation runs smoothly.
So it seems, that the optimized eam/alloy/opt potential doesn’t work for high energy impacts. Is this a bug or a non-feature?
This shouldn't happen, but I didn't write the opt versions so
I can't say for sure. Can you post a simple, small input
script/data file that shows the problem? Hopefully in a few
timesteps ?
Recently I was performing some cluster-impact simulations using
different eam potentials. At the early stages of contact the
optimized version of eam/alloy/opt leads to an _exploding_ system:
single particles are accelerated to very high velocities and the
the files of the opt-package use very aggressive codings and in some
cases violate current c++ standards, e.g. ANSI aliasing requirements,
bordering on being plain wrong (e.g. the use of the restrict qualifier).
so there are high chances that a compiler gets irritated or makes wrong
assumptions with high optimization levels. if you use the GNU compilers
using -fno-strict-aliasing is strongly recommended. you can have a look
at the platform makes for intel, openmpi, serial_debug to see how to do
this selectively for a subset of files (so you don't lose too much speed).
Thanks for the quick reply! Unfortunately the script is not that small and it needs a couple of timesteps until the simulation breaks. So I’ll check out the compiler settings (gnu 3.4).
Typical potentials (including EAM) are no longer physically meaningful above few eVs and have to be splined to a Universal potential or equivalent above that energy.
Even with a potential splined to a proper high energy potential, you have to use a variable time step option to keep energy conservation during hard collisions. LAMMPS now has this option.
Sorry if someone already responded with this info.
Re: Axel's comments, I would be surprised if eam/alloy
works in some cases but not in others. If it breaks
due to compiler optimiziation, then I imagine it would
give garbage on any problem. So it is odd to me
that you only see issue for hi-energy impacts and that
you don't see the same issues with regular EAM (a la
Eduardo's comment).
The potential I use is no simple EAM potential but has exactly the properties described by Eduardo. But Axel was right! It was a compiling-problem. Once I compile eam/alloy/opt with
-fno-strict-aliasing
it works and leads to identical results as eam/alloy. The compiler I used is:
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Sorry for digging out this old thread ...
I would like to have references for the splining to a Universal
potential. I guess you mean a ZBL like repulsive potential. Have such
potentials been constructed for standard metals for which EAM-based
potentials valid at low energy impacts exist?
I would like to repeat the simulations reported by Eduardo, et. al.
(E. M. Bringa, J. U. Cazamias, P. Erhart, J. St¨olken, N. Tanushev, B.
D. Wirth, R. E. Rudd, and M. J. Caturla. Atomistic shock hugoniot
simulation of single crystal copper. Jnl. Appl. Phys.,
96(7):3793–3799, (2004)) for different metals.