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