Phonon energies in abinit output file are zero for all modes at all qpts, but energies in annaddb calculation from DDB file are normal

Hi abifriends,

See the attached input file.
run.abi (1.3 KB)

I noticed that when calculating phonons with DFPT, the energies printed to the *abo and log files are identically zero:
Phonon wavevector (reduced coordinates) : 0.25000 0.00000 0.00000
Phonon energies in Hartree :
0.000000E+00 0.000000E+00 0.000000E+00
Phonon frequencies in cm-1 :

  • 0.000000E+00 0.000000E+00 0.000000E+00

This happens for all qpts I calculated on a 4x4x4 grid. However, if I merge the DDB files for all qpts and calculate dispersions etc. with anaddb, the phonons are stable and close to experiment. I don’t know if this is a bug or not, but it did cause me a lot of distress trying to figure out why my calculation was (falsely) unstable!

For reference, here is the version/compilation options I am using:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

=== Build Information ===
Version : 9.8.4
Build target : x86_64_linux_gnu9.4
Build date : 20230620

=== Compiler Suite ===
C compiler : gnu9.4
C++ compiler : gnu9.4
Fortran compiler : gnu9.4
CFLAGS : -g -O2
CXXFLAGS : -g -O3 -mtune=native -march=native
FCFLAGS : -g -ffree-line-length-none -I/usr/include/mkl
FC_LDFLAGS :

=== Optimizations ===
Debug level : basic
Optimization level : aggressive
Architecture : intel_xeon

=== Multicore ===
Parallel build : yes
Parallel I/O :
openMP support :
GPU support :

=== Connectors / Fallbacks ===
LINALG flavor : mkl
FFT flavor : dfti
HDF5 : yes
NetCDF : yes
NetCDF Fortran : yes
LibXC : yes
Wannier90 : yes

=== Experimental features ===
Exports :
GW double-precision :

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Default optimizations:
-O3 -mtune=native -march=native -funroll-loops -faggressive-function-elimination

Optimizations for 43_ptgroups:
-O0

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CPP options activated during the build:

                CC_GNU                   CXX_GNU                    FC_GNU

             HAVE_DFTI HAVE_FC_ALLOCATABLE_DT...             HAVE_FC_ASYNC

     HAVE_FC_BACKTRACE  HAVE_FC_COMMAND_ARGUMENT      HAVE_FC_COMMAND_LINE

    HAVE_FC_CONTIGUOUS           HAVE_FC_CPUTIME              HAVE_FC_EXIT

         HAVE_FC_FLUSH             HAVE_FC_GAMMA            HAVE_FC_GETENV

HAVE_FC_IEEE_ARITHMETIC HAVE_FC_IEEE_EXCEPTIONS HAVE_FC_INT_QUAD

         HAVE_FC_IOMSG     HAVE_FC_ISO_C_BINDING  HAVE_FC_ISO_FORTRAN_2008

    HAVE_FC_LONG_LINES        HAVE_FC_MOVE_ALLOC  HAVE_FC_ON_THE_FLY_SHAPE

       HAVE_FC_PRIVATE         HAVE_FC_PROTECTED           HAVE_FC_SHIFTLR

     HAVE_FC_STREAM_IO            HAVE_FC_SYSTEM          HAVE_FORTRAN2003

             HAVE_HDF5        HAVE_LIBPAW_ABINIT      HAVE_LIBTETRA_ABINIT

            HAVE_LIBXC         HAVE_LINALG_AXPBY        HAVE_LINALG_GEMM3M

     HAVE_LINALG_GEMMT  HAVE_LINALG_MKL_IMATCOPY   HAVE_LINALG_MKL_OMATADD

HAVE_LINALG_MKL_OMATCOPY HAVE_LINALG_MKL_THREADS HAVE_LINALG_SCALAPACK

              HAVE_MPI                 HAVE_MPI2       HAVE_MPI_IALLGATHER

   HAVE_MPI_IALLREDUCE        HAVE_MPI_IALLTOALL       HAVE_MPI_IALLTOALLV

       HAVE_MPI_IBCAST         HAVE_MPI_IGATHERV        HAVE_MPI_INTEGER16

           HAVE_MPI_IO HAVE_MPI_TYPE_CREATE_S...               HAVE_NETCDF

   HAVE_NETCDF_FORTRAN                HAVE_NUMPY             HAVE_OS_LINUX

     HAVE_TIMER_ABINIT            HAVE_WANNIER90

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hello Tyst,

most of your file looks normal. Your output would be useful to see what you mean. The strange thing you do is a DS3 which is non self consistent while you do not have the perturbed density yet. This probably does nothing useful, then DS4 completes the calculation reading in the WFQ (why?) from DS3 and basically restarting from 0.

The frequencies sometimes appear 0 (or some 0 and others not) in the abinit output if only some perturbations have been done (1 atom out of 3 or 1 direction out of x y z) and the dynamical matrix is incomplete. Merging the DDB and running anaddb completes the full dynmat and gets all of the phonons.

Thanks for the reply!

This file was hacked together from my normal workflow, so some things might be not quite right … but DS3 is an NSCF calculation for wavefunctions on k+q grid. I do this following the abinit helpfile ‘Respfn’ (Respfn - abinit):

When one considers the response to an atomic displacement for a general q point, the following procedure is suggested:

  • first, a self-consistent ground-state computation with the restricted set of k-points in the Irreducible Brillouin Zone
  • second, a non-self-consistent ground-state run with the set of k+q points, that might be reduced thanks to symmetries
  • third, a self-consistent response-function computation of the atomic displacement perturbation, with the full set of k-points

Is it normal for all modes to be zero energy, even with symmetry? If this is normal, I am happy to accept your answer as the solution. However, I haven’t seen this in calculations on other materials before (even Al which is very high symmetry).

Here is the output (abo) and log file!
run.abo (131.9 KB)
run.log (318.8 KB)

Thanks!
Ty

I think the issue is that you have 1 atom and are imposing the ASR for a non 0 q vector. The code then sets everything to 0 as it has no other information (eg at Gamma etc). If you remove rfasr for the q=1/4 0 0 it should show up in the log file. At any rate your DDB and anaddb run are fine