UT theoretical chemistry code forum

Can you put your calculation somewhere that we can get to it?

I couldn't find your results but: 1. POTIM = 0.01 is rather small, usually 0.1 is more reasonable as a first guess. Depending on your system then some of the constrained atoms can have considerable forces, which are not apart of the force minimization criteria. The NEB routine has the some convergen...

The best you can do is, using the same input parameters (same INCAR, KPOINTS and simulation cell), to calculate the the electron density around a single C atom and then a single B atom. Then compare these number to whatever the Bader partitioning gave for each atom in the system of interest. The dif...

Are you running it as (with the CVS code):

./bader -p all_atom CHGCAR

?

Try (with the proper line indentation): ----------------------------------------- OBJS = kind_mod.o \ matrix_mod.o \ ions_mod.o \ options_mod.o \ charge_mod.o \ chgcar_mod.o \ cube_mod.o \ io_mod.o \ bader_mod.o \ voronoi_mod.o %.o %.mod : %.f90 $(FC) $(FFLAGS) -c $*.f90 bader: $(OBJS) main.o rm -f ...

I don't think it affects the rest of the code, forces and energies should remain the same. But just to be on the safe side then I always build this executables (which for historical reason we call vasp.TOTAL) and use it exclusively when generating CHGCARs with added partial number of core electrons....

This is not an uncommon problem when using pseudo potentials, though there seems to something else going on as well here. At least the minimum distance to the Bader surface for the B atoms is calculated to be rather large. First thing to try is to add electron density around the B atoms in the hope ...

As an empirical rule of thumb I have found it to be sufficient resolution of the MEP (in most cases) to have about 0.5 Ang's between the images, and preferably no more than 1.0 Ang.

In this case, think of the Voronoi scheme as a Bader scheme, except all the atoms have now the same electron negativity.

Sorry for the late reply, somehow I missed this one. There used to be an option to restart the dynamical matrix calculations. But we removed the script(s) under the suspicion that they didn't work properly. I guess they can be dug out again if you still want to have a go at it

Actually the Opteron cluster is Graeme's personal cluster (and his research group's) and I have not used it that much. I think the only things (VASP included) that I have complied there have been using Graeme's makefiles and pgf90. Maybe he will know some more about using ifort with amd processors. ...

Also, it is usually better to start with IBRION = 3. What is the length of the path? When estimating the local tangent to the path then it is best not to have the image too far from each other. Personally I try not to have images further than about 0.5 A from their neighbors.

I have used MKL exclusively on various types of Intel processors (both-32 and 64-bit) and never found any problems with it.

Does the problem still persist after the code as been recompiled using the proper ACML libraries instead of MKL?

Clearly the job has not converged to a saddle point since the forces are not particularly small. Did the job finish normally (perhaps NSW=1) or did it just simply die or hang after one step? If the latter then you need to look into how the executable was compiled. Given the great variety of architec...

The final coordinates are of course given in the CONTCAR, XDATCAR and OUTCAR and the energy is obtained by <grep "energy without entropy" OUTCAR> as always. What should happen though is that the current coordinates at each step are written to the lanczos.out file as the run progresses. Doe...