Proposed Bug Comments  [SOLVED]

Documentation, Web site and code modifications

Moderators: baguetl, routerov

Locked
NPike
Posts: 34
Joined: Fri Mar 18, 2016 1:15 pm

Proposed Bug Comments  [SOLVED]

Post by NPike » Wed May 18, 2016 1:27 pm

Hello all,

During some recent calculations I found instances where the bug, and the resulting comments, needed clarification or are incorrect and wanted to point them out for the benefit of others.

For example, while using fully-relativistic pseudo-potentials I received an error message that read
--- !ERROR
message: |
Pseudopotential input file requires linear radial mesh
starting at zero.
Action : check your pseudopotential input file.
src_file: Subroutine Unknown
src_line: 0
...

However, the real error in the calculation was not the pseudopotential file, but was an incorrectly set input variable nspinor. If possible, it would be nice to catch this error when Abinit reads in the pseudopotential file by comparing the value of nspinor and the extension switch. If they are the same then no error is given, if they are different then the program should break and the appropriate error message printed.

Additionally, during a phonon calculation the following error message occurred during a response function calculation.
--- !ERROR
src_file: Subroutine Unknown
src_line: 0
message: |
error in mvrecord
...
This error occurs when the wave functions of the previous steps in the response function calculations are not fully converged. Would it be possible to make the non-convergence of the wave function in a response function calculation an error warning? Since, if the wave function is not converged, then the results of the later steps in the calculation will necessarily contain errors.

Thanks!
Nicholas A. Pike
Research Scientist

User avatar
gmatteo
Posts: 291
Joined: Sun Aug 16, 2009 5:40 pm

Re: Proposed Bug Comments

Post by gmatteo » Wed May 25, 2016 6:19 pm

However, the real error in the calculation was not the pseudopotential file, but was an incorrectly set input variable nspinor. If possible, it would be nice to catch this error when Abinit reads in the pseudopotential file by comparing the value of nspinor and the extension switch. If they are the same then no error is given, if they are different then the program should break and the appropriate error message printed.


There was a bug triggered by the particular combination (nspinor==1, relativistic psp8 file with spin-orbit terms) that has been
solved in the new version 8.0.6.
Note that the code does not complain if you use the default value of nspinor (i.e. 1) in a calculation done with SOC pseudos.
The SOC projectors are simply ignored when the non-local part of the Hamitonian is applied.
You need to set nspinor=2 explicitly in the input file if you want to include SOC in the calculation.


Additionally, during a phonon calculation the following error message occurred during a response function calculation.
--- !ERROR
src_file: Subroutine Unknown
src_line: 0
message: |
error in mvrecord
...
This error occurs when the wave functions of the previous steps in the response function calculations are not fully converged. Would it be possible to make the non-convergence of the wave function in a response function calculation an error warning? Since, if the wave function is not converged, then the results of the later steps in the calculation will necessarily contain errors.


Strange. mvrecord usually indicates that your file is either corrupted/empty or that there's an inconsistency between the dimensions
of the WFK file and the dimensions of the actual calculation.

As concerns your suggestion:
Unfortunately the WFK file does not have enough info to understand
if the calculation was converged (too many tolerances can be in principle specified by the user).
For the time being, one has to check the output file of the GS run before using the WFK file for DFPT as
Abinit issues a warning if the SCF calculation didn't converge.

One could check the value of tolwfr reported in the WFK and issue a warning if the WFK is not "accurate" enough
but I would refrain from making the code stop

M

Locked