ABINIT Discussion Forums

Dear ABINIT friends,

The STRING method calculation could proceed into a new TIME STEP. See output of

$tailf pd.txt >

<snip>
....

------------------------------------------------------------
STRING METHOD:
Average[Abs(Etotal(t)-Etotal(t-dt))]= 8.062E-02 Hartree
Moving images of the cell...


================================================================================
STRING METHOD - TIME STEP 3
================================================================================
</snip>

However, there was a very unexpected error message:

$tail -n30 pd.log >

<snip>
...
FFT (fine) grid used in SCF cycle:

getcut: wavevector= 0.0000 0.0000 0.0000 ngfft= 64 64 250
ecut(hartree)= 40.000 => boxcut(ratio)= 2.04053

--- !ERROR
src_file: chkpawovlp.F90
src_line: 177
mpi_rank: 0
message: |
PAW COMPENSATION DENSITIES ARE OVERLAPPING !!!!
There are 12 pairs of overlapping atoms.
The maximum overlap percentage is obtained for the atoms 19 and 21.
| Distance between atoms 19 and 21 is : 3.32856
| PAW radius of the sphere around atom 19 is: 2.51232
| PAW radius of the sphere around atom 21 is: 1.41465
| This leads to a (voluminal) overlap ratio of 4.94 %
THIS IS DANGEROUS !, as PAW formalism assumes non-overlapping compensation densities.
...


--- !ERROR
src_file: chkpawovlp.F90
src_line: 189
mpi_rank: 0
message: |
Action: 1- decrease cutoff radius of PAW dataset
OR 2- ajust "pawovlp" input variable to allow overlap (risky)
...

</snip>

According to the following input parameter, the error should __not__ occur:

$ grep pawovlp pd.in
pawovlp 6

A maximum of 6% overlap should be allowed.

Where can I do a bug report?

Dear Willem,
This is indeed strange, I never got this problem.
What about putting larger pawovlp, e.g. 10?
All the best,
Eric

Dear Eric and ABINIT friends,

It is not only strange, it does not make sense. Since even the default value of pawovlp = 5, which enables an overlap of at least 5%, was not passed. So even if the code would neglect the input, then the default value should be applicable. Though I already reported an issue about the default value of pawovlp.

So, to my opinion, something is wrong in the code. Hence my request of filing a bug report.

If pawovlp = 6 does not work. Why should I expect that setting pawvolp = 10 will work? The overlap ratio was 4.94%, which is clearly less than 10%, 6%, and even 5%.

Dear Willem,
Yes, sounds there is a small bug here, my proposition was to allow you to run your calculation, not as a fix of the bug We'll look at that internally with the dev. Thanks for reporting it.
Best wishes,
Eric

Dear Eric and ABINIT friends,

After reading your reply once more, I realised that I already tried to run the calculation with an increased pawovlp value.

I set it to 9 and got the overlap error message: overlap ratio of 13.12 %
So the error message was logical this time.

I had to stop the research with this system and set of parameters, since it took too long before an error message appeared. This is not handy for exploration of the functionality of ABINIT.

$ grep pawovlp pd.in
pawovlp 9

$ grep pawovlp pd.log
pawovlp 9.0000000000E+00

$ tail -n20 pd.log
The maximum overlap percentage is obtained for the atoms 19 and 21.
| Distance between atoms 19 and 21 is : 3.07159
| PAW radius of the sphere around atom 19 is: 2.51232
| PAW radius of the sphere around atom 21 is: 1.41465
| This leads to a (voluminal) overlap ratio of 13.12 %
THIS IS DANGEROUS !, as PAW formalism assumes non-overlapping compensation densities.
...


--- !ERROR
src_file: chkpawovlp.F90
src_line: 189
mpi_rank: 0
message: |
Action: 1- decrease cutoff radius of PAW dataset
OR 2- ajust "pawovlp" input variable to allow overlap (risky)
...


leave_new: decision taken to exit ...

Dear Willem,
I agree that this is not convenient to have a stop of the code, a warning would be better. The dev might have been too conservative with this.
What I'm doing is to set very large value of pawovlp (e.g. 25) during relaxation because the calculation goes sometimes to crazy jump before finding the ground state, in which the pawovlp is not so large at the end.
What is important is to be sure that, once the relaxation is finished, that this overlap is not too large; this will be very important to compute crystal properties afterwards (as he error message said, the result might be not correct).
Another comment is that often in my cases, when the pawovlp goes huge like that, it is because something is not converged (either k-points or ecut) or because I started from a structure that was very far from the ground state one.
Hopefully this can help, maybe in the future we will turn the error stop to a simple warning if it appears to be OK in most of the cases (and if the user is aware of what he is doing ).
Best wishes,
Eric

Dear Eric and ABINIT friends,

I like your idea with setting pawovlp to a large value at the start of the investigations and the decrease the value to zero at the end. At least close to zero, when the system and parameters are used to calculate physical/chemical properties. It makes sense and fits into a total workflow.

That said, it is important that the parameter setting of pawovlp will be honoured by ABINIT. This is not always the case and I hope/believe that developers will have a close look to my reports about this issue.

For a beginner, it is best to get a stop instead of a warning. The learning effect is more efficient when the frustration is large . I'm a chemist by training and I do remember my time in the lab. :)

And indeed you were right that the error message, related to pawovlp, can be an indication of some other error: Another Nudged Elastic Band calculation (not the initial one of this thread) stopped because of the mentioned error. It appeared that the atoms in the initial and final state were not correctly aligned. They were correctly mapped, but due to the boundary conditions, the coordinates of the atoms did not fit in all cases. I had to manually adjust.

Thank you for your response, it is really helpful.

pawovlp -1 could also be used to avoid the stop...
Best wishes,
Eric

ebousquet wrote:Dear Willem,
I agree that this is not convenient to have a stop of the code, a warning would be better. The dev might have been too conservative with this.
What I'm doing is to set very large value of pawovlp (e.g. 25) during relaxation because the calculation goes sometimes to crazy jump before finding the ground state, in which the pawovlp is not so large at the end.
What is important is to be sure that, once the relaxation is finished, that this overlap is not too large; this will be very important to compute crystal properties afterwards (as he error message said, the result might be not correct).
Another comment is that often in my cases, when the pawovlp goes huge like that, it is because something is not converged (either k-points or ecut) or because I started from a structure that was very far from the ground state one.
Hopefully this can help, maybe in the future we will turn the error stop to a simple warning if it appears to be OK in most of the cases (and if the user is aware of what he is doing ).
Best wishes,
Eric

Dear Eric,

Your information is very useful to me, but I have a little question: where can we find the pawovlp value of the last step? log file? or out file?

Your reply is appreciated.
Thank you very much.

Best regards
Ke Tong