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

**URL:** <https://discourse.abinit.org/t/phonon-energies-in-abinit-output-file-are-zero-for-all-modes-at-all-qpts-but-energies-in-annaddb-calculation-from-ddb-file-are-normal/3367>\
**Category:** Response calculations\
**Created:** [June 28, 2023, 11:35pm UTC](https://discourse.abinit.org/t/phonon-energies-in-abinit-output-file-are-zero-for-all-modes-at-all-qpts-but-energies-in-annaddb-calculation-from-ddb-file-are-normal/3367 "2023-06-28T23:35:47Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tyst3273](https://discourse.abinit.org/letter_avatar_proxy/v4/letter/t/dbc845/32.png) [@tyst3273](https://discourse.abinit.org/u/tyst3273)\
**Post date:** [June 28, 2023, 11:35pm UTC](https://discourse.abinit.org/t/phonon-energies-in-abinit-output-file-are-zero-for-all-modes-at-all-qpts-but-energies-in-annaddb-calculation-from-ddb-file-are-normal/3367/1 "2023-06-28T23:35:48Z")

</div>

Hi abifriends,

See the attached input file.  
[run.abi](https://discourse.abinit.org/uploads/short-url/jU22IeqN3jAWvm3CHh1IpKSHX2Q.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

```

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

---

<div class="post-metadata">

**Author:** ![mverstra](https://discourse.abinit.org/user_avatar/discourse.abinit.org/mverstra/32/92_2.png) [@mverstra](https://discourse.abinit.org/u/mverstra)\
**Post date:** [June 29, 2023, 9:33am UTC](https://discourse.abinit.org/t/phonon-energies-in-abinit-output-file-are-zero-for-all-modes-at-all-qpts-but-energies-in-annaddb-calculation-from-ddb-file-are-normal/3367/2 "2023-06-29T09:33:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tyst3273](https://discourse.abinit.org/letter_avatar_proxy/v4/letter/t/dbc845/32.png) [@tyst3273](https://discourse.abinit.org/u/tyst3273)\
**Post date:** [June 29, 2023, 3:36pm UTC](https://discourse.abinit.org/t/phonon-energies-in-abinit-output-file-are-zero-for-all-modes-at-all-qpts-but-energies-in-annaddb-calculation-from-ddb-file-are-normal/3367/3 "2023-06-29T15:36:04Z")

</div>

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](https://docs.abinit.org/guide/respfn/)):

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](https://discourse.abinit.org/uploads/short-url/apQ8vVU7knD5YDWUCeevDaDHg1Y.abo) (131.9 KB)  
[run.log](https://discourse.abinit.org/uploads/short-url/35GCr8yAibgFkvnYgPF85m2Z8Tf.log) (318.8 KB)

Thanks!  
Ty

---

<div class="post-metadata">

**Author:** ![mverstra](https://discourse.abinit.org/user_avatar/discourse.abinit.org/mverstra/32/92_2.png) [@mverstra](https://discourse.abinit.org/u/mverstra)\
**Post date:** [June 29, 2023, 4:44pm UTC](https://discourse.abinit.org/t/phonon-energies-in-abinit-output-file-are-zero-for-all-modes-at-all-qpts-but-energies-in-annaddb-calculation-from-ddb-file-are-normal/3367/4 "2023-06-29T16:44:00Z")

</div>

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
