GW's input made by Yambo is incomplete

[masoud2600]

Dear Yambo team,

I am a new user of Yambo. after a review of all exercises and tutorials on Yambo-wiki, I accomplished a PPA-GW for a small system, bulk ZnO. But when I move to a larger lattice Zn36O36 including 936 (up: 468, down: 468) electrons, 2936 KS states after successful initialization (p2y and yambo -i), Yambo could not provide a proper input which should be included the required variables. Inputs in both small and large lattices are made by

Code: Select all

yambo -x -p p -g n -F input.in -V all

Both calculations use the same PPs (ONCVPSP_SLA PW NOGX NOGC pseudos downloaded from DOJO), E_cut, sampling, and so forth at QE's level.
Input made for the large system has only a few lines as follows:

• StdoHash= 40 # [IO] Live-timing Hashes
  Nelectro= 936.0000 # Electrons number
  ElecTemp= 0.000000 eV # Electronic Temperature
  BoseTemp=-1.000000 eV # Bosonic Temperature
  OccTresh=0.1000E-4 # Occupation treshold (metallic bands)
  NLogCPUs=0 # [PARALLEL] Live-timing CPU`s (0 for all)
  DBsIOoff= "none" # [IO] Space-separated list of DB with NO I/O. DB=(DIP,X,HF,COLLs,J,GF,CARRIERs,OBS,W,SC,BS,ALL)
  DBsFRAGpm= "none" # [IO] Space-separated list of +DB to FRAG and -DB to NOT FRAG. DB=(DIP,X,W,HF,COLLS,K,BS,QINDX,RT,ELP
  MaxGvecs= 256389 RL # [INI] Max number of G-vectors planned to use
  #NoDiagSC # New setup for non-diagonal supercell

Could you please guide me? 
Best,
Masoud 
PS : I am using GPL Version 4.5.1 Revision 165 and I submitted jobs over 128 cores.

----------------------------------------------------------------------------
Masoud Mansouri
Ph.D. student at the University of Basque Country (UPV/EHU)
Donostia International Physics Center (DIPC)
Paseo Manuel de Lardizabal, 4
20018 Donostia – San Sebastián (Gipuzkoa) – SPAIN

[Daniele Varsano]

Dear Masoud,
if this happens it means that the setup step was not done or it did not run successfully.
I suggest you remove all the ndb.* databases in your SAVE directory, run the setup again (yambo -i) and check all is fine, next repeat the command you mention to generate the input file. If this is not successful please post in attachment the r_setup file and the generated input file with the few lines.

Best,
Daniele

[masoud2600]

Dear Daniele,
I double-checked everything. With the same procedure, proper input has been made for smaller lattice (Zn2O2), while made input for the larger one (Zn36O36) with identical PPs, ibrav, and so forth at QE level, is incomplete. Therefore, as you had asked I attached made input file to this post. The r_setup is a bit large to be attached, so I uploaded HERE.
Looking forward to hearing your comment(s),
Regards,
Masoud
----------------------------------------------------------------------------
Masoud Mansouri
Ph.D. student at the University of Basque Country (UPV/EHU)
Donostia International Physics Center (DIPC)
Paseo Manuel de Lardizabal, 4
20018 Donostia – San Sebastián (Gipuzkoa) – SPAIN

[Daniele Varsano]

Dear Masoud,
we will check if there's some problem of I/O dealing with your large databases. In the meanwhile, I think you can safely prepare an input file by hands, e.g. by copy/paste the gw input for the smaller system and editing it accordingly with the size of your system.
Best,
Daniele

[andrea.ferretti]

Dear Masoud,

what happens if you do not specify the -V all flag when generating the input ?
(this makes is much shorter). Then you may need to integrate it adding eg parallel flags
(or trying to use -V par instead of -V all)

All in all, my impression is that the system you are trying to address is very large and this may clash with some
properties of the machine you are using.

I'd recommend you to get familiar with production-level GW calculations of a much smaller size before attempting the very large calculation
you are mentioning. Moreover, as a guess, I think you may also need to use a much larger machine to run that (128 cores may take quite long).

Andrea

[masoud2600]

Dear Andrea
I had tried other verbosity keywords -V qp , RL in which all generate a blank input file. in case of -V par it has a single line

• NLogCPUs=0 # [PARALLEL] Live-timing CPU`s (0 for all)

I even tried

mpirun -np $NPROCS $YAMpath -x -p p -g n -V par -F gw_ppa_2.inp -Q

which made a similar input file.
I understand that GW is too expensive and to do the actual job I surely use richer resources. But I'm asking whether you think that 128 cores are not enough even to read databases?

Best,
Masoud
----------------------------------------------------------------------------
Masoud Mansouri
Ph.D. student at the University of Basque Country (UPV/EHU)
Donostia International Physics Center (DIPC)
Paseo Manuel de Lardizabal, 4
20018 Donostia – San Sebastián (Gipuzkoa) – SPAIN

[andrea.ferretti]

Dear Masoud,

no, I didn't mean that you need more than 128 cores to read DBs and create an input file (this operation you run in
serial and takes no time even for large systems).
Your problem is actually a misbehaviour of the code (miscompilation ?).

What I mean is that it is probably a better strategy to get acquainted with the code working on a
more treatable system. Does the code work in producing the input for smaller systems ?

Andrea

[masoud2600]

Dear Andrea,
In the former posts, I clearly declared that Yambo ON THE SAME MACHINE makes inputs for the smaller system and is not able to make inputs for the larger one.
Masoud

[Davide Sangalli]

Dear Masoud,
I think the reason is that the setup has problems on your big system and it is not working properly.

Inspecting your report on dropbox I see two possible issues:

(i) First

Code: Select all

G-vectors             [RL space]:  667385

with

Code: Select all

Shells, format: [S#] G_RL(mHa)

   [S10048]:256389(0.9513E+5) [S10047]:256365(0.9512E+5) [S10046]:256341(0.9512E+5) [S10045]:256293(0.
S10048]:256389(0.9513E+5)

(ii) Second

Code: Select all

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

It means yambo has having troubles in:
(i) finding closed shells for the G-vectors (thus the maximum allowed G is lowered from 667385 to 256389
(ii) Finding the q grid connecting your k-grid
Point (ii) in particular would activate many of the "yambo barriers". Each barrier prevents the execution of a specific kind of simulations ("runlevels" in the yambo langauge)
For non uniform k-grids gw is for sure affected. This is also why the input is not created.

You may try to compile p2y and yambo in double precision (./configure --enable-dp ... etc ... )
Then re-run p2y and yambo.

D.

[Daniele Varsano]

Dear Masoud,
Before trying to go in dp,
You can also try to rernu the setup adding the variable NoDiagSC after having deleted the previous ndb.* database. This should solve the problem of the sampling seen as non uniform.

Best,
Daniele