[Q-e-developers] bug in phonon code?

Stefano de Gironcoli degironc at sissa.it
Wed Dec 19 11:04:40 CET 2012


Dear Giovanni, dear Andrea

    I'm looking into your calculations...
    in particular 01_vcrelax and 02_vcrelax aida.out
    inspecting the structure with xcrysdens it does not look to me  
that the structure has cubic symmetry... or at least Ti atoms appear  
not to be aligned in neighboring cells...
    in the spglib code you use to recognize the symmetry is there a  
threshold in the acceptance of the symmetry operations ?
    did you relaxed the structure after translating it ? if there is  
some symmetry breaking that want to  develop now that you removed the  
symmetry you should allow for it.
    are you sure the system insulating... ? if you mistreat a metal as  
an insulator results are unpredictable.

stefano


Quoting Giovanni Pizzi <giovanni.pizzi at epfl.ch>:

> Dear developers,
> we are experiencing a problem with the phonon code. We think that  
> this may be a serious bug.
> Here a short description of the problem; below, a more detailed  
> description follows. Attached, all relevant inputs and outputs of  
> the 5 calculations of interest.
>
> Short description:
> * We have a 40-atom cell with cubic cell (and cubic space group).  
> pw.x recognizes 6 symmetries (folder 01_... for the vc-relax, and  
> 02_... for the restart from that vc-relax). However, then when ph.x  
> starts (folder 03_...), it crashes with "Error in routine  
> set_irr_sym (1422): wrong representation".
> * As a workaround, we slightly translate the system (folder 04_...).  
> Then, pw.x just finds one symmetry (the identity), and subsequently  
> ph.x starts and computes the phonons. We ask for the phonons on a  
> 2x2x2 q-mesh, and since no symmetries are found, all 8 qpoints are  
> evaluated (folder 05_...).
> * Since the system has cubic symmetry (even if pw/ph don't detect  
> it), we expect that the frequencies found on equivalent q-points  
> should be the same. This should be the case for the following q  
> points (see folder 05_...):
>        N         xq(1)         xq(2)         xq(3)
>        2   0.000000000   0.000000000  -0.061601673
>        3   0.000000000  -0.061601673   0.000000000
>        5  -0.061601673   0.000000000   0.000000000
>
> Instead, while the frequencies of qpoints 2 and 3 are similar within  
> 1 cm^-1, the frequencies at qpoint 5 are quite off (there is a  
> negative frequency -928.641695 [cm-1], and also a new maximum-energy  
> frequency of 4496.358033 [cm-1], while q points 2 and 3 have  
> frequencies in the range 70-740 [cm-1].
>
> Could anyone help us in finding where the bug lies?
>
> Best,
> Andrea Cepellotti and Giovanni Pizzi
> THEOS (Theory and Simulation of Materials), EPFL, Switzerland
>
>
> P.S.: longer description of what we did with some more details:
> the attached zip has 5 folders, starting with an incremental number  
> 01_, 02_, ...
> * The first calculation (01_) is a vc-relax of the cell.
> * The second calculation (02_) is a vc-relax, restarted from the  
> coordinates of 01_ (the volume changed significantly during the  
> vc-relax and we had to restart the calculation with the  
> newly-calculated G-vectors)
> Both these cells have a cubic cell (defined with ibrav=0) and a  
> cubic space group: I-43m (217), checked using the 'spglib' code.
> * we start a phonon calculation (03_) from the results of 02_: the  
> calculation crashes as described above.
> * we take the relaxed coordinates of job 02_ and translate them by  
> the vector (0.01, 0.02, 0.03) angstrom. With these new coordinates,  
> we perform an scf calculation (job 04_).
> Note that also this system is correctly recognized by the spglib  
> code to have the same cubic space group of before: I-43m (217)
> * we perform a phonon calculation (job 05_) from the scf of job 04_.  
> Due to queue limitations on our supercomputer, the calculation was  
> run at steps of 23 hours (and stopped using the max_seconds flag)  
> and then restarted multiple times. The output file of the first run  
> is called 'aida.out', the subsequent restarts are called  
> 'aida-recover-N.out' with N ranging from 1 to 12.






More information about the developers mailing list