Is there a way to steadily increase the temperature in a simulation? For example if I created a box filled half with Fe and half with Cr and wanted to simulate melting them together across a range of temperatures (from say about room temp at 300K to about melting at 2000K)?
Looking through the literature something like this looks to be possible (I’ve seen works using LAMMPS to simulate annealing etc.). Is the “fix temp/rescale command” what I’m looking for (http://lammps.sandia.gov/doc/fix_temp_rescale.html)?
I’ve pasted a slightly modified and annotated version of the basic Melt example (to include msd and an output for msd); since this is my starting point for getting things set up for larger systems and I may very well be missing the blindingly obvious.
Is there a way to steadily increase the temperature in a simulation? For
example if I created a box filled half with Fe and half with Cr and wanted
to simulate melting them together across a range of temperatures (from say
about room temp at 300K to about melting at 2000K)?
Looking through the literature something like this looks to be possible
(I've seen works using LAMMPS to simulate annealing etc.). Is the "fix
temp/rescale command" what I'm looking for
(http://lammps.sandia.gov/doc/fix_temp_rescale.html)?
no. temp/rescale is bad. very, *very* bad. better to use one of the
other, more gentle methods to control temperature (fix nvt, fix nve +
fix langevin, fix nve + fix temp/berendsen etc.).
I've pasted a slightly modified and annotated version of the basic Melt
example (to include msd and an output for msd); since this is my starting
point for getting things set up for larger systems and I may very well be
missing the blindingly obvious.
I have been looking at indentation simulations, and since many experimental tools actually control the load (and loading rate) rather than the position of the indenter, I decided to implement a load control via a feedback from the “compute group/group” function. [Actually, this is important because the methods of Oliver and Pharr require a hold at constant load for relaxation purposes.]
So in my setup I have a block of atoms, the lowest few layers of which are frozen to stop the block moving away, and a rigid indenter, which has its velocity controlled by “fix move”. The interaction between the block and the indenter is a L-J with parameters so that it is essentially repulsive. So now the velocity is a function of the difference between the load experienced and the load desired. I have visualised the setup, and it behaves as expected.
What I noticed was that I would get irregular issuances of
“
[I note that **neighbour** is spelt badly in the code]
The issuances of the warning do not coincide with a particularly large velocity of the indenter. Indeed, the problem does not usually manifest during the earliest part of the run, when the velocity is demanded to be highest.
So I looked at what was causing it, and how to deal with it. In so doing, I found that if I set the velocity to a constant, or to some variable independent of the indenter, no such warnings ensue.
I can minimise the problem by setting the neighbour skin to be large (>7.0 \AA) (I am using a copper EAM with a 6.5 \AA cutoff), but even if I use nve/limit the problem persists unless I set the nve/limit at 0.0001 \AA, which causes the simulation to be bogus.
It may be that I am using the variables and fix move in a way that was not originally intended. If so I will try to minimise the problem and I will need to check that what I get is sensible before moving on. I have checked various versions of the code, up to 1 Feb 2014, and the behaviour (and mis-spelling) is consistent.
Note that it’s a warning, not an error. Compute group/group
is expected to be used occasionally, but you are probably
using it often, like every step. The warning is occurring,
b/c LAMMPS detects that atoms have moved more than
half the skin distance since the last time neighbor lists
were formed. Are you also getting Dangerous neighbor
counts at the end of the run? Those are the same thing
for the pair style neigh lists. The solution is likely
to be more conservative in when you form neigh lists.
E.g. see if the warnings go away, when you delay 0 and
check every step via neigh_modify.
I do not get any dangerous rebuilds in the end of run summary.
I have already set my neighbour list rebuilds to every step via this line
neigh_modify exclude type 2 2 every 1 delay 2 check yes
I have also tried reducing the timestep by a factor of 10; this did not cure the problem, but it occurred at a different time (not step*10)
I can try forcing the rebuilds by removing the check, and set delay to 0.
hmmm - that’s puzzling. If you can send a small, simple
example script that does this, I will instrument the section
that generates the warning and try to see why. Seems odd
if their are no dangerous reneighborings.
I have enclosed a simple script which runs quickly on 2 or more PEs.
Furthermore,
Changing delay to 0 did not make any difference. Changing the frequency of neighbour list builds changes the frequency of error.
Removing the ‘exclude type’ for the indenter did not make any difference, but that’s probably because I set the type 2-2 interaction to ‘none’ in the pair style.
What I did find was that changing ‘check’ to ‘no’ fixed the problem. With check no I could build neighbour lists every 1000 steps with no dangerous builds. I could also reduce the skin size to 3.0 \AA without error, but with a 0.1% change in the energy.
In your case the warning is harmless. It’s happening on
timestep when neigh lists are going to be re-built anyway.
B/c you are requesting it early in the timestep (via fix move)
before neigh list rebuilds are checked for.
For now, I’m just going to comment out this warning check.
It was for some odd problematic case I can no longer reproduce.
So I’ll wait til it shows up again to worry about it.
