nebmake.pl

[Ramzi]

Hi,

I am doing cNEB calculations with Vasp 5.2 + vtstcode 2.04a of a vacancy diffusing through
a bulk material. I am relaxing all atoms in my system (i.e. no selective dynamics in vasp).
My runs are converging, albeit at a glacial pace. I have a number of questions about nebmake.pl,
because it is not totally clear to me what it can and can't do:

1- I have come across a great deal of warnings out there that if you are running a system
where all atoms are allowed to relax, you should ensure that all initial images have
the same center of mass (it seems to me they mean geometric center or centroid rather).
What is all this about and does nebmake enforce such a condition when it interpolates
the initial images ?

2- Assuming atom A in my starting configuration has left one side of the box and entered
through the opposite side in the final configuration, such that the distance between atom A
in the starting and final configurations is not the minimum image distance. Does nebmake check
for minimum image distances before interpolating between the starting and final configurations ?

3- Assuming atom A in my starting configuration has left one side of the box and did not enter
through the opposite side in the final configuration, such that the distance between atom A
in the starting and final configurations is the minimum image distance. I noticed that nebmake
in this case enforces the p.b.c. after doing the interpolation, thus entering atom A in the interpolated
images through the opposite side of the box. Why ?

Any feedback is greatly appreciated!

Ramzi

[graeme]

1) If there are no constraints on the system, it is possible for images to translate with respect to one another. This does not nessecarily lead to a problem, but if there is a lot of atomic motion during the relaxation of the band, the spacing between images can increase due to a translated centroid, and the resolution of the band can be reduced. If you see a minimum energy path with multiple images having an energy close to an endpoint, this is probably the issue.

2) The nebmake.pl script properly account for periodic boundary conditions and moves atoms by the smallest possible distance between the initial and final positions.

3) See (2); there is nothing special about the edge of the box and atomic motion across it.

[Ramzi]

Dear Graeme,

thanks for your quick reply. I have a couple of follow-up questions if I may:

graeme wrote:
> 1) If there are no constraints on the system, it is possible for images to translate
> with respect to one another. This does not nessecarily lead to a problem, but if
> there is a lot of atomic motion during the relaxation of the band, the spacing between
> images can increase due to a translated centroid, and the resolution of the band
> can be reduced. If you see a minimum energy path with multiple images having an
> energy close to an endpoint, this is probably the issue.

A couple of questions regarding the above:

a) Is it correct to say then that nebmake.pl does not check/ensure that all initial images
have the same geometric center (say as endpoint image 0)?

b) The cell drift in the various images might arise if all atoms are allowed to relax.
If I understand you correctly, it is this drift, *which might occur during NEB*, that could cause
a problem. What then is the advantage of ensuring all *initial* images have the same centroid ?
At least a couple of scripts out there make a big fuss about this condition.
Does this condition reduce the extent of possible drift during the NEB ?

Thanks.

Ramzi

[graeme]

The nebmake.pl does not make any check about the geometric center.

The problem with drift in the cell is that it creates a large distance between images (the drift distance times the number of atoms). The NEB ensures that the images are equally spaced, so drift can lead to a long path with poor resolution at the saddle. The climbing image certainly helps with this issue.