Convergence of minimize vs. box size

Hey everybody,

right now i'm encountering some convergence problems using the minimize command of lammps 1.Dec2010 with a valence force field potential for solids:
When i use a simulation box with equal sizes in x/y/z the time needed for minimization is just reasonable. lets say 20 minutes for approximately 750000 atoms.
When i reduce the size of my simulation box in one dimension, lets say z = 1/2x = 1/2y the computation needs incredible more time (20 hours and counting), even though the total number of atoms is reduced by a factor of 1/2.
In my understanding that make just no sense.
Can anybody explain this behaviour to me?
Thanks

Kind regards,
Elias

Hey everybody,

right now i'm encountering some convergence problems using the minimize
command of lammps 1.Dec2010 with a valence force field potential for solids:
When i use a simulation box with equal sizes in x/y/z the time needed
for minimization is just reasonable. lets say 20 minutes for
approximately 750000 atoms.
When i reduce the size of my simulation box in one dimension, lets say z
= 1/2x = 1/2y the computation needs incredible more time (20 hours and
counting), even though the total number of atoms is reduced by a factor
of 1/2.
In my understanding that make just no sense.
Can anybody explain this behaviour to me?

hard to say based on the number of atoms alone.
there are a number of possible explanations and
factors that affect minimization. some are technical
issues, some are systematic.

minimization of a system with that many degrees
of freedom is actually a quite complex task.

axel.

I tried with different numbers of atoms/box sizes, ranging from a few thousand to several millions, all showing the same behaviour (all other options unchanged): the case with a box with equal sidelengths runs much faster than the more general case of different sidelengths, so this seems to be indeed systematic.

I tried with different numbers of atoms/box sizes, ranging from a few
thousand to several millions, all showing the same behaviour (all other
options unchanged): the case with a box with equal sidelengths runs much
faster than the more general case of different sidelengths, so this seems to
be indeed systematic.

yes, but as i was trying to explain. it is impossible
to say anything specific and particularly suggest
ways how to avoid bad convergence behavior, without
knowing anything but the number of atoms.

too much of this can be influenced but the details
of the force field used, the choice of convergence
parameters, the choice of cutoff, even the use of
parallelization (or not).

the more symmetric your configuration is, the
higher the chances that forces will cancel due
to symmetry contraints and thus you implicitly
reduce the number of degrees of freedom and
thus get better convergence.

axel.

I would try the current version. There have been
some enhancements to the minimizers since last Dec.

Steve

What are you using for your parameters in the
fix box/relax command for the minimize in
the 2 cases?

Steve

I dont use the command at all. I just set boundary conditions via

'boundary p p p'

and define the box as

fprintf(fid,' %e %e xlo xhi\n',-adbox,boxsize(1));
fprintf(fid,' %e %e ylo yhi\n',-adbox,boxsize(2));
fprintf(fid,' %e %e zlo zhi\n\n',-adbox,boxsize(3));

where boxsize(i) is definied as boxsize(i)+adbox. So i leave a certain amount of empty space in all directions (to be more precise, adbox = 1/2 of my lattice constant) to simulate the situation of periodicity in a crystal correct.
During different runs i dont change anything here except the value of boxsize(3) for example, so in the one case boxsize might be equal to (100,100,100) and equal to (100,100,50) in the other case.

I hope thats the correct way of doing this?

Elias

If you're saying you just fill a periodic box (of any size/shape) with atoms
and do a standard minimization w/out relaxing the box itself via fix
box/relax, then
LAMMPS doesn't care. Unless you try to minimize to extremely
high tolerance, I don't imagine one run would take longer than any
other.

Steve