Re: symmetry mismatch with pw.x and kgrid.x

[Felipe H. da Jornada]

Hi Gary,

Could you also send me the output file from espresso? If using "use_all_frac" helps, this probably means that kgrid.x and pw.x found a different number of symmetries due to the FFT grid.

In your kgrid.inp, did you specify the FFTgrid from your quantum espresso scf calculation?

Best,

Felipe

On Tue, May 8, 2018 at 3:14 PM Gary Kedziora <gked...@gmail.com> wrote:

Actually

&SYSTEM

  use_all_frac = True,
/

is a work around.

On Tue, May 8, 2018 at 5:02 PM, Gary Kedziora <gked...@gmail.com> wrote:

Hi Felipe,

I'm trying a calculation with WSe2 and Espresso as the mean field method.  The error message is

ERROR: genwf_mpi: No match for rkq point:   0.300   0.100   0.901 in file WFNq

This seems to be stemming from kgrid.x using one set of symmetry matrices and pw.x using a different one.  epsilon.cplx.x is using the symmetry matrices from WFN which is made by pw.x, and these are different from the ones made by kgrid.x. 

In find_kpoint_match there is a kpoint with (0.300, 0.100, -0.901) but not (0.300, 0.100, 0.901).  Is it strange to have a negative kpoint value in the unfolded grid?  It seems like it. 

I attach the kgrid input (wfnq.in) and the Espresso input for wfnq (in) in case you can easily spot something from that.

Is there a work around for this type of behavior?

Thanks,

Gary

--

Felipe H. da Jornada
Postdoctoral Researcher
Lawrence Berkeley National Laboratory, and

Department of Physics, University of California, Berkeley

366 LeConte Hall #7300

Berkeley, CA 94720-7300

[Felipe H. da Jornada]

---------- Forwarded message ---------
From: Felipe H. da Jornada <jor...@berkeley.edu>
Date: Wed, May 9, 2018 at 8:23 AM
Subject: Re: symmetry mismatch with pw.x and kgrid.x
To: <gked...@gmail.com>

Hi Gary,

that's right, the problem was really with the FFT grid. If you search in the espresso output file, you'll see the following message:

     12 Sym. Ops., with inversion, found

          (note: 12 additional sym.ops. were found but ignored

           their fractional translations are incommensurate with FFT grid)

We must always be careful to put the correct FFT grid in kgrid.inp, otherwise kgrid.x will assume that there are more symmetries that can be used to reduce the k-points that what espresso actually finds. Also, keep in mind that kgrid.x doesn't write any symmetry information to the wavefunction file. Espresso is doing that. This is why we must provide the correct information for k-grid so that it knows exactly which symmetry that espresso is going to use.

This is also why the typical workflow is the following:

scf calculation -> read FFT grid that espresso likes -> kgrid.x -> nscf -> berkeleygw

Note that if you are using espresso < 6.0, you can use the "data-file2kgrid.py" utility under the Meanfield/ESPRESSO directory to automatically create the kgrid.inp file, including the FFT grid.

Best,

Felipe

On Wed, May 9, 2018 at 5:15 AM Gary Kedziora <gked...@gmail.com> wrote:

Hi Felipe,

I attached the output.  I did not used the Espresso FFT grid in kgrid input.  I used the grid from gsphere.py.   

I don’t see where Espresso is identifying a group number or symbol.  Pymatgen is giving me space group number 194 (P6_3/mmc) with the original representation of the structure.  Kgrid is getting that right without the FFT grid.

So it looks like the FFT grid may be the source of the discrepancy between the groups in the two codes.  When I run kgrid with the FFT grid used by Espresso it looks like the symmetries with the FFT grid that is produced by kgrid matches.  I attached the kgrid log for this case. I’ll look into that more carefully and verify for the full workflow.

Thanks!

Best regards,

Gary

[Felipe H. da Jornada]

Hi Gary,

could you please send me the input/output files for kgrid and the input/output files from QE? I suspect this is related to either a lack of precision in the kgrid.inp file, or that espresso is trowing out symmetries associated with a fractional translation.

Best,

Felipe

On Thu, May 10, 2018 at 2:01 PM Gary Kedziora <gked...@gmail.com> wrote:

Hi Felipe,

I ran into another problem where Espresso is finding 2 group transformations but kgrid is finding 3 with the exact same FFT grid and exact same structure, etc.  This one dies in read_format_header() with

if (product(kgrid(1:3)) > nk * ntran) call die("kgrid too large compared to unfolded nk")

In this case nk=2 from the WFN header, so it is less than the expected number of kpoints for the uniform grid.  In your suggested workflow, do you use a uniform full grid or folded grid in the nscf step?  We've been using band with a folded grid. 

This seems to be a bug in Espresso's symmetry detection and the workaround would be using no symmetry or something.  What do you think?

Thanks,

Gary

On Wed, May 9, 2018 at 11:23 AM, Felipe H. da Jornada <jor...@berkeley.edu> wrote:

Hi Gary,

that's right, the problem was really with the FFT grid. If you search in the espresso output file, you'll see the following message:

     12 Sym. Ops., with inversion, found

          (note: 12 additional sym.ops. were found but ignored

           their fractional translations are incommensurate with FFT grid)

We must always be careful to put the correct FFT grid in kgrid.inp, otherwise kgrid.x will assume that there are more symmetries that can be used to reduce the k-points that what espresso actually finds. Also, keep in mind that kgrid.x doesn't write any symmetry information to the wavefunction file. Espresso is doing that. This is why we must provide the correct information for k-grid so that it knows exactly which symmetry that espresso is going to use.

This is also why the typical workflow is the following:

scf calculation -> read FFT grid that espresso likes -> kgrid.x -> nscf -> berkeleygw

Note that if you are using espresso < 6.0, you can use the "data-file2kgrid.py" utility under the Meanfield/ESPRESSO directory to automatically create the kgrid.inp file, including the FFT grid.

Best,

Felipe

On Wed, May 9, 2018 at 5:15 AM Gary Kedziora <gked...@gmail.com> wrote:

Hi Felipe,

I attached the output.  I did not used the Espresso FFT grid in kgrid input.  I used the grid from gsphere.py.   

I don’t see where Espresso is identifying a group number or symbol.  Pymatgen is giving me space group number 194 (P6_3/mmc) with the original representation of the structure.  Kgrid is getting that right without the FFT grid.

So it looks like the FFT grid may be the source of the discrepancy between the groups in the two codes.  When I run kgrid with the FFT grid used by Espresso it looks like the symmetries with the FFT grid that is produced by kgrid matches.  I attached the kgrid log for this case. I’ll look into that more carefully and verify for the full workflow.

Thanks!

Best regards,

Gary

On May 8, 2018, at 6:27 PM, Felipe H. da Jornada <jor...@berkeley.edu> wrote:

[gked...@gmail.com]

Hi Felipe,

I didn't realize this was on the Google group....

I have investigated this more since we last corresponded.  The problem is not due to precision. I am using 9 decimal places for k-point grids, coordinates, etc.  It is really due to a mismatch in the way Quantum Espresso (QE) pw.x and BGW detect symmetry and with relying on the symmetry transformation matrices from QE via the WFN headers.  I have tried reducing the threshold for symmetry detection in pw.x and that also does not help.

If I used a primitive cell for MoS2 that is rhombohedral (a=b=c=6.39, alpha=beta=gama=28.7), kgrid.x correctly gets space group 160 for the crystal, with 6 transformations with the FFT grid and 2 symmetries that reduce the k-points:

r02 =     0   0   1     0   1   0     1   0   0
r03 =     0   1   0     1   0   0     0   0   1
r04 =     0   1   0     0   0   1     1   0   0
r05 =     1   0   0     0   0   1     0   1   0

QE found no symmetry with the symmetry-reduced kgrid (in irreducible wedge) and the full kgrid.

If I used a conventional cell pw.x found 6 symmetry operators; kgrid.x found the correct symmetry of the crystal with only the identity element for the FFT grid which was obtained from pw.x (30 30 180).  No operators reduce the k-point grid.

I'm not sure about the best way to handle this.  It seems like one viable option would be to have BGW rely on its own symmetry analysis and not on the transformation matrices from QE.

What do you think?  I can still provide test cases or help in other ways.

Best,
Gary