Large difference between RIM and Real RL volume based on Random Integration Method

[lyzhao]

Dear all,
I use Random Integration Method for 2D system.
Parts of output of Random Integration Method are as follows

Code: Select all

  [WR./gw_qp_t1//ndb.RIM]---------------------------------------------------------
   Brillouin Zone Q/K grids (IBZ/BZ)                :   57  196   57  196
   Coulomb cutoff potential                         : none
   Coulombian RL components                         :  101
   Coulombian diagonal components                   : yes
   RIM random points                                :  1000000
   RIM  RL volume             [a.u.]                :  0.175025
   Real RL volume             [a.u.]                :  0.365262
   Eps^-1 reference component                       : 0
   Eps^-1 components                                :  0.000000  0.000000  0.000000
   RIM anysotropy factor                            :  0.000000
  - S/N 007829 ---------------------------------------------- v.05.02.01 r.22792 -

  Summary of Coulomb integrals for non-metallic bands |Q|[au] RIM/Bare

  Q [1] 0.100000E-4 0.764535 * Q [2] 0.110190 0.510448
  Q [9] 0.112410 0.518699 * Q [21] 0.189556 0.488613
  Q [10] 0.193426 0.492043 * Q [3] 0.220380 0.486777
  Q [22] 0.224819 0.489923 * Q [20] 0.289836 0.483158
  Q [11] 0.294067 0.484321 * Q [23] 0.296576 0.485131
  

I notice a large difference between RIM and Real RL volumes, so it is not available as mentioned in the tutorial.
The RIM/Bare is very different from 1.
Which parameter should I adjust?
I have tried to increase RIM random points to larger number such as 2000000, 10000000, but the issue still.

Best regards.

[Daniele Varsano]

Dear Youzhao,

can you please post your input and report file?

Best,
Daniele

[lyzhao]

Dear Daniele,
Thanks for your quick reply.
The input and report files are attached

Best regards.

[Daniele Varsano]

Dear Youzhao,

I do not exactly what's wrong there, but I noticed you are asking for

Code: Select all

CUTGeo= "box Z"  

and then % CUTBox was not assigned.

If you want to use the box you need to set something like:

Code: Select all

% CUTBox
 0.000000 | 0.000000 | 35.000000 |        # [CUT] [au] Box sides
%

or you can use "slab z".

I suggest you to remove all the old databases (ndb*) and retry from scratch with the amended input, not sure anyway if it solves the problem.

Best,
Daniele

[lyzhao]

Dear Daniele,
Thanks for your quick help.
I am sorry for my mistake in setting CUTGeo.
Following your steps, the issue still occur.

More infos, I attach the pwscf input files (scf and nscf) and yambo-related files.

Best regards.

[Daniele Varsano]

Dear Youzhao,

I have reproduced your problem, we will look into it soon.

Best,
Daniele

[Daniele Varsano]

Dear Youzaho,

the problem is related to your definition of the unit cell and Yambo get confused.
Try to describe your system using a definite ibrav.
I juste tested that setting:

Code: Select all

CELL_PARAMETERS {bohr}
    3.992532   -2.367633   0.
    3.992532    2.367633   0.
    0.000000    0.000000   35.920483

the problem disappears. Of course, if you want to use this cell you will need to modify you ATOMIC_POSITION accordingly. Also please note that using this cell you do not need to specify NoDiacSC in the setup input file.

Best,
Daniele

[lyzhao]

Dear Daniele,
Great thanks for your time.
Your modification leads to a change of geometric parameter and lattice.
For reference, I attach my cell (vesta_geo_LanYouZhao.cif) and your cell (vesta_geo_Daniele_Varsano.cif) files, which can be viewed by free software VESTA (http://jp-minerals.org/vesta/en/).
Your cell seems to be triclinic with a=b=2.455494, c=19.00, alpha=beta=90, gamma=61.33 (seems to be monoclinic),
and with P1 symmetry, which can be used to run calculation with no issue.
After finding symmetry of your cell, I got lattice of Monoclinic-beta with a=4.22, b=2.50, c=19.46, alpha=gamma=90,beta=102.53, and with Cs symmetry. (see vesta_geo_Daniele_Varsano_findsym.cif),
which is similar to my original cell (vesta_geo_LanYouZhao.cif). So, if I use vesta_geo_Daniele_Varsano_findsym.cif to run calculation,
I will meet the same issue as mentioned above.
Note for reference: I want to study the defect by translating one of layer of bilayer BN, (AB-stacked BN with C3v symmetry, see BN_2L.cif)
Maybe it was the perturbation that confused the Yambo, or other reasons.

Best regards.

[Daniele Varsano]

Dear Youzhao,

The cell I was proposing was just a test to understand where Yambo got confused.
My suggestion is to define your cell using a bravais lattice (ibrav) different from zero. This should avoid Yambo to get confused.

Best,
Daniele

[lyzhao]

Dear Daniele,
Great thanks for your time.
I try to use the definite ibrav, but it let me go back to the issue of "X grid is uniform is no" as reported in previous post
viewtopic.php?t=2655
and I meet a new issue when runing yambo.
my steps are as follows:
1. yambo
the issue is "X grid is not uniform. Gamma point only."
2. delete SAVE/ndb.*, yambo -i -V all, uncomment "#NoDiagSC ....", yambo
yambo seems to crash as follow,

Code: Select all

 <---> [01] MPI/OPENMP structure, Files & I/O Directories
 <---> [02] CORE Variables Setup
 <---> [02.01] Unit cells
 <---> [02.02] Symmetries
 <---> [02.03] Reciprocal space
 <---> Shells finder |########################################| [100%] --(E) --(X)
 <---> [02.04] K-grid lattice
 <---> Using the new bz sampling setup
 <---> Grid dimensions      :   3   6   2
 <---> [02.05] Energies & Occupations
 <---> [03] Transferred momenta grid and indexing

[ERROR] STOP signal received while in[03] Transferred momenta grid and indexing
[ERROR] [RL indx] error in mapping
[lyzs6:129527] *** Process received signal ***
[lyzs6:129527] Signal: Segmentation fault (11)
[lyzs6:129527] Signal code: Address not mapped (1)
[lyzs6:129527] Failing at address: 0x1b
[lyzs6:129527] [ 0] /lib64/libpthread.so.0(+0xf630)[0x2b656fb16630]
[lyzs6:129527] [ 1] yambo[0x8d7d7b]
[lyzs6:129527] [ 2] yambo[0x8d7f39]
[lyzs6:129527] [ 3] yambo[0x8d86a4]
[lyzs6:129527] [ 4] yambo[0x8d8779]
[lyzs6:129527] [ 5] yambo[0x853065]
[lyzs6:129527] [ 6] /lib64/libc.so.6(+0x39ce9)[0x2b656fd5cce9]
[lyzs6:129527] [ 7] /lib64/libc.so.6(+0x39d37)[0x2b656fd5cd37]
[lyzs6:129527] [ 8] /lib64/libgfortran.so.5(_gfortran_stop_string+0x11)[0x2b656e361131]
[lyzs6:129527] [ 9] yambo[0x6e9220]
[lyzs6:129527] [10] yambo[0x653932]
[lyzs6:129527] [11] yambo[0x65924e]
[lyzs6:129527] [12] yambo[0x4094d5]
[lyzs6:129527] [13] yambo[0x6f9ee1]
[lyzs6:129527] [14] yambo[0x407696]
[lyzs6:129527] [15] /lib64/libc.so.6(__libc_start_main+0xf5)[0x2b656fd45555]
[lyzs6:129527] [16] yambo[0x407727]
[lyzs6:129527] *** End of error message ***
Segmentation fault (core dumped)

3. delete SAVE/ndb.*, yambo -i -V all, uncomment "#NoDiagSC ...." and delete the following line

Code: Select all

%QptCoord                        # [KPT] [iku] Q-points coordinates (compatibility)
 0.000000| 0.000000| 0.000000|
%

then yambo, and yambo crashes as above.

The related file are attached.
Notes: for this system, to use a definite ibrav, I use the conventional cell not the smallest primitive cell (which I don't know how to define with a definite ibrav in PW).
Based on these tests and my other experience, yambo seems not to be very capable of handling the monoclinic lattice. (I am not sure but guess)

Best regards.