nG charge and nG shells depends upon lattice constnat

[cms]

Hi everyone I ma using Yambo-5.2.2 with quantum espresso 7.3.
Interestingly it is found that when i slightly change the lattice constant from 3.6 ang to 3.7 ang then the r_setup file changes and major change occures in nG charge and ng Shell in the r_setup file. These are
with a=3.36052
nG shells : 2968
nG charge : 53523
nG WFs : 28071
nC WFs : 22254

with a=3.3783
nG shells : 5705
nG charge : 111443
nG WFs : 28351
nC WFs : 22530

Due to increase in nG charge and nG shells it is hard to compute the G0W0 calculations.
So my questions is that these parameters depends upon lattice constant or not.
I am attaching herewith the input files for both cases.

Please suggest any help.

[Daniele Varsano]

Dear cms,

please sign your post with your name and affiliation, this is a rule of the forum, and you can do once for all by filling the signature in your user profile.

The number of g vector do depend on the cell size, they are the g vector contained in a sphere of radius G^2/2 < Ecut and they are discretized as (2pi/L).
Anyway, in your case you just slight changed your cell and the number are very similar:

setup-1

Code: Select all

G-vectors                                        :  177783 [RL space]
Components                                       :  22254 [wavefunctions]

setup-2

Code: Select all

 G-vectors                                        :  179691 [RL space]
 Components                                       :  22530 [wavefunctions]

you should not have particular problem in performing GW calculation in the two cases.

Best,
Daniele

[cms]

Thanks Dr. Varsano for quick reply.

The actual problem is that in GW input file the value of EXXRLvcs and VXXRLvcs changes drastically in two cases. So I have to reduce the number of bands in GW input file.
Kindly suggest any help.

Thanks and regards

Yours sincerely

Mr. P. Kumar
JNU, India

[Daniele Varsano]

Dear P. Kumar,

as stated before, the two setups are very similar, it seems that in the first setup MaXGvecs was fixed by input (and it is not a good idea).
Anyway, the exchange part of the self energy includes only occupied states, so the problem should be somewhere else.
Can you post your input/report/log files and the eventual error message you get in the larger case?

Best,
Daniele

[cms]

The input file for GW are generated via following command
yambo -gw0 p -g n -r -F gw.in

Please help

Yours sincerely

P. Kumar

[Daniele Varsano]

Dear Kumar,

do you get any error message in your script output file?

In order to spot the problem, I suggest you the following:
1) Reduce the %QPkrange to very few qp calculation, e.g.

Code: Select all

%QPkrange                        # [GW] QP generalized Kpoint/Band indices
1|1|5|15|
%

and see if it runs.

2) Alternatively reduce the EXXRLvcs (in general, you do not need to include them all, but you need to verify the convergence). Try to set as in the previous calculation and see if it runs.
3) Set your parallelization strategy as.
SE_CPU= "1 1 4" # [PARALLEL] CPUs for each role
SE_ROLEs= "q qp b" # [PARALLEL] CPUs roles (q,qp,b)
this will help to distribute the memory.
4) Please note that calculation stop in the exchange part, so there is no need to lower the number of bands
5) Note, you are using the rim_cut, but you are not using no cutoff coulomb potential, and no random integration. Your system is 2D so I imagine you want to use a cutoff coulomb potential, e.g.CUTGeo= "slab z" , and you can set RandQpts=1000000
6) Note, you are using NGsBlkXp= 1 RL, which is totally under convergence.

Best,
Daniele