Wrong symmetries when conventional cell

[cverdi]

Dear SSCHA developers,

I am running into a problem related to symmetries: when calling dyn.Symmetrize(), I get the message:
find_sym: Not a group! symmetry disabled
and as a result, of course the q stars are wrong (no symmetries) and the code stops.
This happens sometimes if the unit cell used is not a primitive cell but a conventional cell. This is important in order to use the same supercells for different phases.
In my specific example, the system is ZrO2: cubic ZrO2 is fcc with 3 atoms, and the conventional cell is simple cubic with 12 atoms. This works, but when I then include a tetragonal displacement of the O atoms, I get the above errors. The unit cell is reported below.
Note that when running either QE or Vasp using this unit cell, symmetries are correctly detected.
I suspect the culprit is the fact that SSCHA uses some older QE symmetry modules, and this would be fixed by updating them.
It would be great if you have any more suggestions or insights for solving this problem.
I am also attaching the dynamical matrices in case you want to reproduce the problem.

ZrO2
5.06856187097697
1.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 1.0000000000000000 0.0000000000000000
0.0000000000000000 0.0000000000000000 1.0000000000000000
Zr O
4 8
Direct
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 0.5000000000000000 0.5000000000000000
0.5000000000000000 0.0000000000000000 0.5000000000000000
0.5000000000000000 0.5000000000000000 0.0000000000000000
0.2500000000000000 0.7500000000000000 0.2100000000000000
0.7500000000000000 0.2500000000000000 0.2100000000000000
0.2500000000000000 0.7500000000000000 0.7100000000000000
0.7500000000000000 0.2500000000000000 0.7100000000000000
0.2500000000000000 0.2500000000000000 0.7900000000000000
0.7500000000000000 0.7500000000000000 0.7900000000000000
0.2500000000000000 0.2500000000000000 0.2900000000000000
0.7500000000000000 0.7500000000000000 0.2900000000000000

Thank you!

Best,
Carla Verdi
dyn.tar.gz

[mesonepigreco]

Dear Carla,
Sorry for the delay in my reply.
This usually happens when you have a supercell and the quantum espresso code for symmetries on which CellConstructor is based is not able to recognize the Group. You can employ the SPGLIB function for the symmetry by replacing Symmetrize() with Symmetrize(use_spglib = True).
Indeed, you need to have spglib installed (pip install spglib should do the trick).

You can also set this as an option in the sscha minimization (that symmetrization is always done with spglib) setting the use_spglib = True of the SSCHA_Minimizer object (if you are using the python script), otherwise adding the option use_spglib = .true. in the namelist input file.

[cverdi]

Dear Lorenzo,

Thank you for your answer! I hadn't noticed the use_spglib option :)
I see in a comment that the spglib is slower, indeed in my case the 'Time elapsed to symmetrize the gradient' is of the order of minutes vs less than a second.

Btw, there's a tiny bug in case one uses the namelist input file: in setup_from_namelist in SchaMinimizer.py, you'd need to call
self.dyn.Symmetrize(use_spglib = self.use_spglib)

Thanks,
Carla

[mesonepigreco]

Dear Carla,
The SPGLIB symmetrization works in real space, i.e., the dynamical matrix (and its gradient) are generated in real space on the supercell and then symmetrized, while the symmetrization with quantum espresso works in the reciprocal space, where the dynamical matrix (and the gradient) are sparse thanks to the Block theorem. Therefore, if you have a calculation including only 1 q point (Gamma), the time is almost the same. However, if you have a lot of q points, the symmetrization with espresso is much faster. It is a bit of a pain to implement it in q space with SPGLIB, but we will probably do it in a future version. Maybe we can, as you suggested, update the QE subroutines to those that can also recognize symmetries on the supercells. We have this in the roadmap toward version 2.0.

In any case, the last version of the code (1.1) implements the line-minimization, and we are almost ready to release the 1.2 which will improve it even further. With this new algorithm, each population should converge in between 10 and 60 steps, which probably reduces a lot the time.

Anyway, thanks for spotting the issue on the namelist input file.
Bests,
Lorenzo