Yambo Community Forum

Posted: **Wed Mar 12, 2025 5:03 pm**

Dear developers,

I want to use Ypp Wannier interface to generate GW correction for Wannierization. However, the ypp generates an error as follows

Code: Select all

 <---> [01] MPI/OPENMP structure, Files & I/O Directories
 <---> MPI Cores-Threads   : 1(CPU)-256(threads)
 <---> [02] Y(ambo) P(ost)/(re) P(rocessor)
 <---> [03] Core DB
 <---> :: Electrons             : 8.000000
 <---> :: Temperature           : 0.950044E-3 [eV]
 <---> :: Lattice factors       :  4.66076   4.03634  23.30381 [a.u.]
 <---> :: K points              : 1261
 <---> :: Bands                 :  600
 <---> :: Symmetries            : 24
 <---> :: RL vectors            :  50547
 <---> [04] K-point grid
 <---> :: Q-points   (IBZ): 1261
 <---> :: X K-points (IBZ): 1261
 <---> [05] CORE Variables Setup
 <---> [05.01] Unit cells
 <---> [05.02] Symmetries
 <---> [05.03] Reciprocal space
 <---> [05.04] K-grid lattice
 <---> Grid dimensions      :  120  120
 <---> [05.05] Energies & Occupations
 <32s> [WARNING] [X] Metallic system
 <32s> [06] == Wannier 90 Interface ==
 <32s> K-table built correctly
 <32s> [RD./coarse_20x20//ndb.QP]------------------------------------------------------
 <32s>  Lattice constants                                :   4.66076   4.03634  23.30381
 <32s>  Coulomb cutoff potential                         : slab z
 <32s>  Electronic Temperature                           :  0.100000 [K]
 <32s>  Bosonic    Temperature                           :  0.100000 [K]
 <32s>  Green`s function   energies                      : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  wavefunctions                                    : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  PPA    diel. fun.  energies                      : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  wavefunctions                                    : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  QP tot states                                    :   528
 <32s>  GWo SC iterations                                : 0
 <32s>  GW  SC iterations                                : 0
 <32s>  QP @ state[ 40 ] b range                         :   1  12
 <32s>  QP @ state[ 41 ] K range                         :  1177  1177
 <32s>  QP @ state[ 41 ] b range                         :   1  12
 <32s>  QP @ state[ 42 ] K range                         :  1183  1183
 <32s>  QP @ state[ 42 ] b range                         :   1  12
 <32s>  QP @ state[ 43 ] K range                         :  1243  1243
 <32s>  QP @ state[ 43 ] b range                         :   1  12
 <32s>  QP @ state[ 44 ] K range                         :  1249  1249
 <32s>  QP @ state[ 44 ] b range                         :   1  12
 <32s>  GF energies kind                                 : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  GF WF`s kind                                     : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  Xs energies kind                                 : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s>  Xs WF`s kind                                     : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 <32s> - S/N 001517 ---------------------------------------------- v.05.01.01 r.21181 -
 <32s> QP db read, writing QP corrections in the .eig Wannier90 formatSegmentation fault (core dumped)

I think this error is because of the issue of GW calculations, although GW calculations are successful. However, the generated ndb.QP database has the QP states from 40 according to the ypp output. I also verified it by converting ndb.QP into the human-readable format using "ncdump". Indeed, due to some unknown reasons, the QP states start from 40. However, in o-*.qp file, the GW corrections are correct and start from the first state.

The error only happened for the coarse grid of 20x20, while the ypp Wannier interface works for 15x15 and other grids where the QP states always start from the first one. Perhaps this error will be solved if rerun GW calculations for 20x20, but I think it's good to understand what's the source of error (e.g. an MPI bug?).

The o-*qp.file is attached. As you can see, in this file, the k-point index starts from 1, while the above it starts from 1177.

o-coarse_20x20.qp.txt

Thanks for your help.

Best - Changpeng

Posted: **Thu Mar 13, 2025 9:31 am**

Dear Changpeng,

it seems an I/O problem. I do not have idea what's triggering this.
Can you share the GW report file, maybe from there we can have some hint.

Best,
Daniele

Posted: **Thu Mar 13, 2025 12:05 pm**

Dear Daniele,

Thanks for your help. Here is my GW report file.

r-coarse_20x20_HF_and_locXC_gw0_dyson_rim_cut_em1d_ppa.txt

Best,
Changpeng

Posted: **Thu Mar 13, 2025 5:59 pm**

Dear Changpeng,

the report shows the qp energies for all the bands you asked, but then in the header of the ndb.QP indeed seems that only a small fraction have been written on file.
I've never seen that. Probably something went wrong because of the large fragmentation of the QPkrange. We should investigate it.

What you can do is to try to divide the qp calculations in different runs and then merge the databases, either by using ypp or yambopy.

Best,

Daniele

Posted: **Thu Mar 13, 2025 6:49 pm**

Thanks Daniele. OK, I will try to divide the qp calculations.

Best - Changpeng

Posted: **Thu Mar 27, 2025 6:21 pm**

Dear Daniele,

I've completed the two separate GW calculations. Indeed, in this way, the QP states stored in ndb.QP database are correct. So the previous reported error could be due to many divisions of QP blocks.

Now I have another issue related to the merge of two ndb.QP database using ypp. My input is

Code: Select all

QPDBs                            # [R] Quasiparticle Databases
QPDB_merge                       # [R] Mergering
%Actions_and_names               # [QPDB] Format is "what"|"OP"|"prefactor"|"DB"|. OP can be +/-/x(only for Z)
"E" |"+" |"1" |"./coarse_20x20/ndb.QP1" |
"E" |"+" |"1" |"./coarse_20x20/ndb.QP2" |
%

I tried two cases: using only one cpu or multipole cpus and threads.
1) If only 1 cpu is used, the execution of ypp will never end. It got stuck but the code didn't exit. I waited for more than 1 hour and there is no further output. Please see the files named as *_single. In particular, checking the report file, it got stuck in the section of reporting Energies & Occupations, which stopped at k-point 45. Interestingly, the total number of k-points from the two QP database is 44. I am not sure if it's because the merge of QP databases do not support the sampling of discontinuous k-points in the defined k-grid, since I only sampled those on the coarse grid 20x20 out of the 120x120 grid.

2) If multiple cpus and threads are used, it will throw out the following warnings and stop:

Code: Select all

 <11s> P1: Merging...
 <11s> P1: [WARNING] Allocation of qp%S_total failed with code 5014
 <11s> P1: [WARNING] Attempt to allocate an allocated object
 <11s> P1: [WARNING] Object was already allocated, tough, not present in the archive.
 <11s> P1: [WARNING] Allocation of qp%GreenF failed with code 5014
 <11s> P1: [WARNING] Attempt to allocate an allocated object
 <11s> P1: [WARNING] Object was already allocated, tough, not present in the archive.
 <11s> P1: [WARNING] Allocation of qp%GreenF_W failed with code 5014
 <11s> P1: [WARNING] Attempt to allocate an allocated object

The report file looks the same compared to one-cpu case.

Then I tried to merge QP database using Yambopy and it's successful. However, I am not yet sure merging in this way is correct for "ypp Wannier interface". According to the output of merging using Yambopy, the second QP database is entirely merged into the first QP state range of the first database, and the number of QP blocks is still 22. I feel the correct QP database for "ypp Wannier interface" should be with 44 QP blocks which is the sum of two database.

Code: Select all

 QP_QP_@_state_1_K_range = 1, 1249 ;

 QP_QP_@_state_1_b_range = 1, 12 ;

Code: Select all

yambopy mergeqp ndb.QP1 ndb.QP2 -o ndb.QP
=========input=========
filename:     ndb.QP1
filename:     ndb.QP2
========output=========
filename:     ndb.QP
description:  QP @ K 001 - 1249 : b 001 - 012

ypp_output.zip

Thank you,
Changpeng

Posted: **Thu Mar 27, 2025 8:02 pm**

Just an update.

Then I tried to merge QP database using Yambopy and it's successful. However, I am not yet sure merging in this way is correct for "ypp Wannier interface". According to the output of merging using Yambopy, the second QP database is entirely merged into the first QP state range of the first database, and the number of QP blocks is still 22. I feel the correct QP database for "ypp Wannier interface" should be with 44 QP blocks which is the sum of two database.

The generated *.unsorted.eig from the merged QP database of Yambopy seems fine. The Wannierization is successful and Wannier interpolated band structure looks reasonable.

Best,
Changpeng

Yambo Community Forum

Ypp Wannier interface failed for GW calculations on selected coarse grid

Ypp Wannier interface failed for GW calculations on selected coarse grid

Re: Ypp Wannier interface failed for GW calculations on selected coarse grid

Re: Ypp Wannier interface failed for GW calculations on selected coarse grid

Re: Ypp Wannier interface failed for GW calculations on selected coarse grid

Re: Ypp Wannier interface failed for GW calculations on selected coarse grid

Re: Ypp Wannier interface failed for GW calculations on selected coarse grid

Re: Ypp Wannier interface failed for GW calculations on selected coarse grid