NaN in QP energies with W-RIM

[csk]

Dear all!

When using the "rim_w" method for my system (also described in viewtopic.php?t=2717), I get NaN values for the QP corrections.

First of all, there seems to be a dependence where exactly in the input file I place the "rim_w" keyword, is this to be expected? I.e. if I put it after "rim" I get an error.
Should I do this calculation in consecutive steps? So far, I do the calculations from scratch in a new -J folder...

Then it seems to work for the HF part, but I get NaN values in the G0W0 part... Do you have any suggestions where to look for tracing this error?

In addition, there seems to be a warning in part [02.04] about the k-grid. Should I ignore this or is there a problem?

Thanks for your help!
Christian

[Daniele Varsano]

Dear Christian,

First of all, there seems to be a dependence where exactly in the input file I place the "rim_w" keyword, is this to be expected? I.e. if I put it after "rim" I get an error.
Should I do this calculation in consecutive steps?

The order should be irrelevant, what error do you get?

Not easy to spot the problem:
You have the warning saying that compatible grid is 3D:

Code: Select all

Compatible Grid is   : 3D

but then a compatible 2D grid is found:

Code: Select all

 Found compatible q grid: 2D  

In any case, I suggest you to check your k points grid.
Then, having only 2 q points, I'm not sure, but this can cause problems in the interpolation.

Unrelated with your problem:

Code: Select all

NGsBlkXp= 6                RL 

This is a very small value, and it is most probably far from convergence:

Code: Select all

X_and_IO_CPU= "2 1 2 4 3"     # [PARALLEL] CPUs for each role
X_and_IO_ROLEs= "q g k c v"       # [PARALLEL] CPUs roles (q,g,k,c,v)
SE_CPU= " 2 2 12"       # [PARALLEL] CPUs for each role
SE_ROLEs= "q qp b"         # [PARALLEL] CPUs roles (q,qp,b)

My suggestion is to avoid to assigns MPI task on "q" role as it is highly inefficient.

Best,

Daniele

[csk]

Dear Daniele!

Thanks for your quick reply!

I will remove the parallelization over "q"; the small value for "NGsBlkXp" was just for testing purposes to see if I can get the method running, in an actual calculation this will be something like 10 Ry...

The system has a fairly large unit cell ( ca. 21 Ang., 13 Ang. and 24 Ang. lengths of unit cell vectors) so I thought it might be OK to start the k-mesh convergence with 1x2x1 k-points and then increase to 3x5x1 etc., but I will try a finer mesh now and keep also an eye on the k-grid output.

But if there was a problem with the k-grid or some k-interpolation in "w_rim", shouldn't it affect the HF part as well?

Cheers,
Christian

[Daniele Varsano]

Dear Christian,

yes please make the tests and report if the problem persists we will have a deeper look on what's going wrong.

But if there was a problem with the k-grid or some k-interpolation in "w_rim", shouldn't it affect the HF part as well?

Actually not as the HF part contains the base potential which is analytic (also for 2D slab) so interpolation is not needed.

Best,
Daniele

[csk]

Hi!

This week I could continue the testing and wanted to try the 3x5x1 mesh since this would be most commensurable to my cell. However, I am getting the error

Code: Select all

[RL indx] X grid is not uniform. Gamma point only.

and then Yambo only computes the RIM part and then finishes. Apparently there is something wrong with the k-mesh. I also tried the suggestion to delete the SAVE/ndb.* files, execute

Code: Select all

yambo -i -V all

uncomment "NoDiagSC" in yambo.in and then run the setup by executing yambo again. This time, I get the following errors in the setup logfile:

Code: Select all

[ERROR] STOP signal received while in[03] Transferred momenta grid and indexing
[ERROR] [RL indx] error in mapping

For my cell, I can only use "ibrav = 0" and set the cell explicitly in QE. The k-mesh is generated with

Code: Select all

K_POINTS automatic
3 5 1 0 0 0

and looks like the following (which seems perfectly fine to me?):

Code: Select all

                       cryst. coord.
        k(    1) = (   0.0000000   0.0000000   0.0000000), wk =   0.0666667
        k(    2) = (  -0.0000000   0.2000000   0.0000000), wk =   0.0666667
        k(    3) = (  -0.0000000   0.4000000   0.0000000), wk =   0.0666667
        k(    4) = (   0.3333333  -0.0000000   0.0000000), wk =   0.1333333
        k(    5) = (   0.3333333   0.2000000   0.0000000), wk =   0.0666667
        k(    6) = (   0.3333333   0.4000000   0.0000000), wk =   0.0666667
        k(    7) = (   0.3333333  -0.4000000   0.0000000), wk =   0.0666667
        k(    8) = (   0.3333333  -0.2000000   0.0000000), wk =   0.0666667
        k(    9) = (   0.4000000  -0.2000000   0.0000000), wk =   0.0666667
        k(   10) = (   0.8000000  -0.4000000   0.0000000), wk =   0.0666667
        k(   11) = (   0.7333333  -0.2000000   0.0000000), wk =   0.0666667
        k(   12) = (   1.1333333  -0.4000000   0.0000000), wk =   0.0666667
        k(   13) = (  -0.4666667   0.4000000   0.0000000), wk =   0.0666667
        k(   14) = (  -0.0666667   0.2000000   0.0000000), wk =   0.0666667

So what am I doing wrong or how could I get Yambo to work with this (or a similar, shifted) mesh?
I also attach the input-, log- and report files of the first mentioned test run to this post.

Thank you very much,
Christian

[Daniele Varsano]

Dear Christian,

it is possible that QE is adding k points to fulfil the symmetries. It seems strange, you have 14 k points with a 3x5 grid with inversion symmetry.
Can you post your scf/nscf QE input file?
A possible solution could be to generate a compatible grid by hand (there are tool to do that with ypp) and provide to the QE input manually instead of using the automatic option.

Best,
Daniele

[csk]

Dear Daniele!

Thanks for your reply!

Here I attach the nscf input- and output files (the latter I cut after the relevant output due to file size limitations...).

Can you maybe post how I can obtain the k-mesh with ypp?

Best,
Christian

[csk]

Update:

The "unusual" k-mesh seems to come from the fact that I used "nscf" and not "bands" for the QE calculation mode, which can, for some reason cause this behavior of adding extra k-points. In the meantime, I have also tried to explicitly set the k-points in QE, e.g. for a 2x3x1 mesh:

Code: Select all

K_POINTS crystal
    6
  0.000000000  0.000000000  0.000000000   1.0
  0.000000000  0.333333333  0.000000000   1.0
  0.000000000  0.666666667  0.000000000   1.0
  0.500000000  0.000000000  0.000000000   1.0
  0.500000000  0.333333333  0.000000000   1.0
  0.500000000  0.666666667  0.000000000   1.0

Even then, I encounter similar problems in the setup, as you can see by the attached setup report file. Basically, Yambo WRONGLY assumes the 6 k-points of the full BZ are from a IBZ in this step

Code: Select all

[02.04] K-grid lattice
  ======================
  Using the new bz sampling setup
   System with reduced dimensionality
   Smallest q vectors (crystal coordinates) :
        0.500000      0.333333      0.000000
  Compatible Grid is   : 2D
  Base K vectors       :  K_min[ 1 ]  K_min[ 2 ]  K_min[ 3 ]
  K_min[ 1 ] :  0.500000 -0.333333  0.000000 [rlu]
  K_min[ 2 ] :  0.50000      0.64400E-09   0.0000     [rlu]
  Grid dimensions      :  2  3
  K lattice UC volume  :  0.001209 [a.u.]

  IBZ K-points :   6
  BZ  K-points :  10

  K/Q-points units:
  rlu = crystal or reduced units; cc = cartesian coordinates; iku = interal k-units
  K [1]:  0.000000  0.000000  0.000000 [rlu]            : wf components:  268403
  K [2]: -0.929070E-8  0.333333      0.00000    [rlu]        : wf components:  268326
  K [3]: -0.185814E-7  0.666667      0.00000    [rlu]        : wf components:  268326
  K [4]:  0.50000      0.64400E-09   0.0000     [rlu]        : wf components:  268400
  K [5]:  0.500000  0.333333  0.000000 [rlu]        : wf components:  268315
  K [6]:  0.500000  0.666667  0.000000 [rlu]        : wf components:  268315

and then the correct BZ/IBZ in this step, where it also complains that both are not compatible, therefore resort to Gamma only:

Code: Select all

[03] Transferred momenta grid and indexing
 ==========================================

  System with reduced dimensionality
  Smallest q vectors (crystal coordinates) :
       0.500000      0.333333      0.000000

 IBZ Q-points :   4
 BZ  Q-points :   6

 K/Q-points units:
 rlu = crystal or reduced units; cc = cartesian coordinates; iku = interal k-units

 Q [1]:  0.000000  0.000000  0.000000 [rlu]
 Q [2]: -0.154183E-7  0.333333      0.00000    [rlu]
 Q [3]:  0.50000      0.64400E-09   0.0000     [rlu]
 Q [4]: -0.500000  0.333333  0.000000 [rlu]
 [RL indx] Q BZ pts are /= from X grid BS pts. Gamma point only.

 [WR./SAVE//ndb.kindx]-----------------------------------------------------------
  Fragmentation                                    : no
  Polarization last K ( bz)                        :  10
  Polarization last K (ibz)                        :   6
  QP states                                        :   1   6
  X grid is uniform                                : no
  Grids (string)                                   :  X
  Grids (int-vector)                               :  1  0  0  0

So how does one set up the k-mesh correctly in this case (ibrav=0)?
Another thing that I don't understand is, why Yambo butchers the numbers in RLU, e.g. "0.000000000 0.333333333 0.000000000" becomes "-0.929070E-8 0.333333 0.00000"? Could this be a reason why the X grid is not uniform? How can I avoid this?

Thanks,
Christian

[claudio]

Dear Christian

first of all I advice you to always use 'nscf´ instead of 'bands' and if it possible use
a defined ibrav instead of ibrav=0.

If you provide a directly the k-points grid, in you case 2x3x1 = 6 k-points,
you have to tell to Yambo not to use symmetries otherwise it will try to use them to check the k-points
that are not generated by QE with symmetries but explicitelly put in input.

You can do this by doing

p2y -nosym

and check if it works.
In addition in the setup of Yambo there is an additional procedure to read strange cell, by doing "yambo -setup -V all"
you will get all possible options, just uncomment:

#NoDiagSC # New setup for non-diagonal supercells

let us know
best
Claudio

[csk]

Dear Claudio!

Thanks for your reply! Unfortunately I generally cannot use other cells than ibrav=0, however, I do make sure that by generating the espresso input file with ASE, enough digits are set (which is probably the most common problem when using ibrav=0) and QE is able to detect the symmetries. Setting "p2y -nosym" is a valuable information, thanks I will try that as well.

In the best case scenario, I would of course like to use a symmetry reduced IBZ. Can you elaborate more on why I should use "nscf" and not "bands"in QE? To give a specific example: if I set

Code: Select all

K_POINTS automatic
2 3 1 0 0 0

and use "bands" in the above system, I get a symmetry-reduced IBZ of 4 K-points. If I use "nscf" I get even more K-points than the full BZ, namely 14 if I remember correctly. I have also observed this behavior of "nscf" in other projects before... I should also say that I set "force_symmorphic = .true."

When I proceed as in the example above, I am able to get Yambo runnig, but ONLY if i do the follwing:
1) p2y
2) yambo -i -V all. Then I uncomment "NoDiagSC" (which you also suggest) but, depending on the system I also have to comment out the parts containing "IkSigLim" and "IkXLim" in "yambo.in", since here sometimes the wrong number are found? Strangely enough, I also have to comment out the variable "QptCoord" to get it to work...
3) yambo

Where can I read about how Yambo sets up the K- and Q-meshes in order to understand why this is so involved?

Thanks a lot for your help,
Christian