UT theoretical chemistry code forum

It looks fine to me. We may have changed the output at some point to
NEB: image is at an extrema
instead of explicitly saying that the image is the climbing image.

We'll add a message like then in the next update -- it makes sense to have one.

An integral of a surface density? No we have not implemented this. We are working on a representation of the surfaces, and could include the integration of surface charge if there was a good reason. What information can you gain from this? Or am I not understanding your goal; do you want to specify ...

This was a little trick to evaluate an empirical (EAM) force and use that to replace the DFT force. This way, there was no error in the force and we could compare exactly to another code. It is only turned on with a compiler flag and the linking of another library.

It sounds like you know more about these methods than we do. This sounds like a good suggestion.

Ah yes, you are right. The extrapolation for T->0 to get the energy is not done with the forces. So the forces are consistent with the free energy and not the T->0 energy.

It uses the force that is printed in the OUTCAR. This is the derivative of the energy, not the free energy.

yes it can; we have not seen any problems yet

Use the -p atom_index or -p bader_index

The CHGCAR is the charge density at each point in real space.

No, the CHG file does not have enough precision in many cases, and we do not support the analysis of it. If you want to analyze a particular structure, you will need to generate a CHGCAR file.

I you send us the dimer and/or NEB calculations, we'll take a look and try to see what's going on.

My guess is that the program has run out of memory. Can you post the command that you ran? If you asked it to print any of the Bader or Atomic volumes, try turning that off. You could also just monitor the memory use as it runs and see if it hits the machine limit. The calculation is basically done ...

Can you check to see if the asymmetry goes away with increasing grid density? If it does not, there is a problem. Without knowing your grid density, we can't know if a 0.02 e difference is a problem.

If you post the headers and a few atomic coordinates from each file type, we'll be able to debug the problem.

These dimer calculations do not look good. First, you can always set ALGO, LREAL, NSIM, NPAR ... to improve efficiency. The dimer calculations are not near a saddle, and they are not obviously converging towards one. Something doesn't look quite right here. Do you have ediff set to a low value (arou...