Page 1 of 1
Questions about NEB
Posted: Wed Sep 27, 2006 2:50 am
by Nguyen
Hi,
First, thank you very much for the VTST code, this is really an interesting tool. However, I have 3 questions about the NEB method.
1) Can I compute more than one image on one CPU? For example, I only have 4 cpus, but I would like to compute 8 images.
2) Is it safe to only use one (climbing) image to find the saddle point? For example, I have my first end-point in 00, my second end-point in 02, and I would like to allow my 4 cpus to compute the saddle point in 01.
3) What energy should be used for EFIRST and ELAST? Should it be the "free energy (F)" or should it be "E(sigma->0)" ?
Thank you in advance for your help,
Nguyen
Posted: Wed Sep 27, 2006 5:07 am
by graeme
1. You can run more than one image per processor by doubling the number of mpi jobs per processor. It is not a particularly good way to run, but if you want to, there is no reason that should not work.
2. For simple paths, you can often get away with the one climbing image. All of the low energy diffusion events for a test system (see web page) converged with 1 image. The NEB performance numbers are given in the first reference at the bottom of the page.
http://theory.cm.utexas.edu/henkelman/research/review/
3. This is a very good point. The energy used to define the tangent in the NEB routine is the free energy F, not the E(sigma->0). We use the free energy in the NEB routine because it is consistent with the forces. In principle, it may be better to use the sigma->0 extrapolated energy, but this is not what we have done.
NEB analysis, distance between images is zero!?
Posted: Sat Mar 24, 2007 8:04 pm
by aakbarz
I have run some NEB, of course I should mention the runs were only for 10 to 20 SCF iterations. I thought just to give it a try to analyze the data, although I knew that the calculations are not fully converged and not realible.
When I ran nebresults.pl, in the neb.dat file, the distance between images is zero, whereas in the OUTCAR's you see them as well as in the file nebef.dat.
What might be the cause of this? Also what is the dimension of the distance between images? is it angstrom?
Thanks,
[quote="graeme"]1. You can run more than one image per processor by doubling the number of mpi jobs per processor. It is not a particularly good way to run, but if you want to, there is no reason that should not work.
2. For simple paths, you can often get away with the one climbing image. All of the low energy diffusion events for a test system (see web page) converged with 1 image. The NEB performance numbers are given in the first reference at the bottom of the page.
http://theory.cm.utexas.edu/henkelman/research/review/
3. This is a very good point. The energy used to define the tangent in the NEB routine is the free energy F, not the E(sigma->0). We use the free energy in the NEB routine because it is consistent with the forces. In principle, it may be better to use the sigma->0 extrapolated energy, but this is not what we have done.[/quote]
Posted: Sat Mar 24, 2007 8:22 pm
by graeme
It may be because the nebresults.pl is looking for the CONTCAR files. Once an ionic step has completed, the distances should be there.
The distances are RMS distances between all the atoms, in Angstoms.
Posted: Thu Apr 19, 2007 9:27 pm
by Nguyen
Hi,
I'm trying to run 8 images on 4 cpus, but this doesn't seem to work (only the first 4 images are taken into account). I was hoping after the first ionic step that vasp would compute the 4 other images, and then apply the NEB code, but it's not the case.
I tried to set images=8 with npar=1,4, or 8, but I got the same result: only 4 images are computed (01 to 04).
So my question is: how can compute a MEP containing 8 images with only 4 cpus? Is it possible?
Thank you,
Nguyen
Posted: Thu Apr 19, 2007 10:05 pm
by graeme
This is possible, but it needs to be set by your queuing system or mpirun initiation of the job (not npar). My guess is that your job has been given 4 mpi slots to run on, since you have 4 processors. If you are running directly, you can use mpirun -np 8, and duplicate the nodes in your mpi machine-file list. If you are running the job through a queue, the queue will need to allow more than one mpi process on each processor. But again, this is not set by vasp. Vasp will allow at most 1 image per mpi slot, so you need 8 of these, even if they are running on 4 processors.
Posted: Thu Apr 19, 2007 10:28 pm
by Nguyen
Dear Graeme,
Thank you very much for your answer, this was the trick. I now use mpirun -np 8, and it's working fine. However, what would be the best value for NPAR?
On this SGI Altix computer, when I use 4 cpus to run a regular VASP job, I usually get a 25% speedup if I set NPAR, LPLANE, and NSIM to:
NPAR= 1
LPLANE= .TRUE.
NSIM= 1
However, I don't know what would be the best settings now that I'm using just half of a cpu to compute one image. Any idea?
Thank you,
Nguyen
Posted: Thu Apr 19, 2007 11:01 pm
by graeme
I think you would have to test it to know for sure. My guess is npar=1 would be best (a higher values doesn't really make sense), and the other values the same.
Posted: Fri May 11, 2007 5:09 pm
by Nguyen
Hello,
I'm now trying to run 16 images on 4 cpus. This is working fine, since the altix is a very good computer for VASP, even if there are 4 images per cpu.
However, there is something strange in my results, which I can't solve. I'm computing the NEB for a molecule dissociation above a surface, and the end points I chose are:
1) The molecule above the surface, at z = 4 A (where z is the center of mass of the heaviest body)
2) The product state, where z is around 2 A
Everything is well converged for and after the TS, where all the forces are below 0.01 eV/A, however the first part of the MEP doesn't converge. Some relative energies become negative, and that's because some images move above z = 4 A. And in fact, I guess that's because the true minimum is well above z = 4 A, in the asymptotic zone at around z = 8 A.
I could increase the number of images, but this is not really a solution, since I'm not interested to find the MEP between z = 4 and 8 A, and I don't have the cpu power for that.
I have also tried to fix z for my first images (between z = 4 A and just before the TS), but this does not really help. It seems this introduce a huge force at the junction (where the flag in z changes from True to False).
Is there anything else I can do?
Thanks for your help,
Nguyen
Posted: Sun May 13, 2007 4:24 am
by graeme
It is a little dangerous to use an endpoint which is not converged to a true minimum. In this case, it is possible that other images will fall into a true minumum (have a negative energy, in your example).
The climbing image helps with these kinds of problems. If the climbing image has converged, you have the energy of the saddle point, even if the initial image is not converged. A more careful optimization of the initial state will give you a better barrier, but this is not essential to finding the saddle point.
Posted: Mon May 14, 2007 8:02 pm
by Nguyen
Dear Graeme,
Thank you very much for your reply. In my example, I indeed use the CI-NEB method, and the TS is fully converged (forces are below 0.01 eV/A). To get the "true" energy value of the TS, I don't use the energy of my first end-point, which is not a true minimum, but I compute the asymptotic energy, far above the surface (the true minimum), and make the difference.
The problem here, is if I would like to place the first end-point at a true minimum, I would need much more intermediate images (or decrease the image spacing), and that's something I can't do, because I don't have the cpu power, and I need a good resolution around the saddle point. Thus, I was wondering if there was a way to prevent the first images to move above my first end-point, in the direction of the true minimum, but it seems it's unfortunately not possible.
Nguyen
Posted: Tue May 15, 2007 5:01 am
by graeme
The simple answer is probably that there is no automatic way to do what you want. We have played around with variable spring forces to give higher resolutions at higher energies, but our feeling is that there are few cases in which you would bother to set this up.
Once you have the saddle point, it is fairly easy to get the minimum energy path. Two conservative optimizations (with our optimizers, setting MaxMove small) will take you from the saddle to the initial and final states, tracing out the minimum energy path.
Also, once you have some intermediate images converged along the path, you can start a band between those points, with little risk of points leaving the minimum energy pathway. For example, if you have 4 points, and point 3 is at the saddle, you can start a 4 image band between points 2 and 4, and get better resolution around the saddle that way.