Yambo Community Forum

Posted: **Sun Feb 08, 2026 9:28 am**

Dear all,
When I was running a G1W0 calculation, I copied into the G1W0 directory all the files generated during my G0W0 run (ndb.HF_and_locXC, ndb.dipoles, ndb.pp*, ndb.cutoff, ndb.RIM, ndb.RIM_W). In the G1W0 input, I used the parameter `GfnQPdb` to read the quasiparticle energies produced by the G0W0 calculation, i.e., `GfnQPdb = "E < ./360b_15Ry/ndb.QP"`.
However, the results I obtained are very strange: compared with G0W0, the G1W0 result not only fails to open the band gap, but instead closes it.
I would like to know whether this is due to an operational mistake in my self-consistent evGW0 procedure, or because the number of bands stored in `ndb.QP` from G0W0 and used for G1W0 is too small (only a dozen or so bands around the Fermi level, though this is sufficient for BSE calculations).
Below I attach the G1W0 input file and the corresponding .r file. Thank you in advance for your help!

testg1w0_ppa_360b_15Ry.in.txt

r-testg1w0_360b_15Ry_HF_and_locXC_gw0_dyson_rim_cut_rim_w_em1d_ppa_el_el_corr.txt

Posted: **Sun Feb 08, 2026 4:37 pm**

Dear Xiangjun,

indeed, the results are strange.
But, I see nothing wrong in your input file. About your procedure, please see here a tutorial on the procedure:
https://wiki.yambo-code.eu/wiki/index.p ... alues_only

e.g. I would let the dipoles to be recalculated with the updated energies, but this should be a very minor issue.
Please note, your system starting point is a metal, but after the first iteration the gap open and yambo seems to take into account correctly of the new occupation numbers (see report Energies & Occupations section before and after reading the database). Anyway, is your system hexagonal Bi monolayer? If so, I think also the DFT band structure should have a gap (very small!). Because of that I would also let the HF part of the self energy to be recalculated with the new occupation numbers.

What is instead quite surprising and suspicious, is the execution time for your calculation. Your system it is not particularly large, and the execution times are extremely large. You should probably check if there is something odd in the compilation.

My suggestion is to check your compilation, compile the code in single precision, and repeat the procedure as indicated in the tutorial (avoiding recompiling the screening) and eventually check the role of QPkrange. For these checks I would also remove the spin-orbit coupling to make the calculation more handy.

Best,

Daniele

Posted: **Mon Feb 09, 2026 3:10 pm**

Daniele Varsano wrote: Sun Feb 08, 2026 4:37 pm Dear Xiangjun,

indeed, the results are strange.
But, I see nothing wrong in your input file. About your procedure, please see here a tutorial on the procedure:
https://wiki.yambo-code.eu/wiki/index.p ... alues_only

e.g. I would let the dipoles to be recalculated with the updated energies, but this should be a very minor issue.
Please note, your system starting point is a metal, but after the first iteration the gap open and yambo seems to take into account correctly of the new occupation numbers (see report Energies & Occupations section before and after reading the database). Anyway, is your system hexagonal Bi monolayer? If so, I think also the DFT band structure should have a gap (very small!). Because of that I would also let the HF part of the self energy to be recalculated with the new occupation numbers.

What is instead quite surprising and suspicious, is the execution time for your calculation. Your system it is not particularly large, and the execution times are extremely large. You should probably check if there is something odd in the compilation.

My suggestion is to check your compilation, compile the code in single precision, and repeat the procedure as indicated in the tutorial (avoiding recompiling the screening) and eventually check the role of QPkrange. For these checks I would also remove the spin-orbit coupling to make the calculation more handy.

Best,

Daniele

Dear Daniele,
Thanks for your help!!!

Posted: **Wed Feb 11, 2026 7:21 am**

Dear Daniele,

How can I install a single-precision build of Yambo 5.3.0 ?

Posted: **Thu Feb 12, 2026 8:54 am**

Dear Xiangjun,

Single precision is the default. If you have a DP calculation is because you you configured with the --enable-dp option. You need to remove it in the configuration options.

Best,

Daniele

Posted: **Thu Feb 12, 2026 5:20 pm**

Dear Daniele,
I compiled the single-precision version of Yambo 5.3.0 using the code below,

./configure --enable-memory-profile --enable-iotk --enable-slepc-linalg --enable-time-profile --with-blas-l
ibs="-lmkl_intel_lp64 -lmkl_sequential -lmkl_core" --with-lapack-libs="-lmkl_intel_lp64 -lmkl_sequential -lmkl_core" --with-blacs-libs=
"-lmkl_blacs_intelmpi_lp64" --with-scalapack-libs="-mkl_scalapack_lp64" --with-fft-libs="-mkl" --with-p2y=4.0 FCFLAGS="-O2 -limf -assum
e bscc -nofor_main" --prefix=/public1/home/sch2430/software-sch2430/new/yambo-5.3.0/install

but I found that a WAENING occurs during initialization (this does not happen with the double-precision Yambo 5.3.0).

<---> [02.03] Reciprocal space
<---> Shells finder |########################################| [100%] --(E) --(X)
<---> [WARNING] Found non closed shells. Max cutoff will be reduced.
<---> [WARNING] Set Gthresh>1.E-5 in input to avoid this. Too big Gthresh will pack shells together
<---> [02.04] K-grid lattice

In addition, the parameters in the input files generated by the single-precision Yambo are different from those generated by the double-precision version.

Double precision:
EXXRLvcs= 79189 RL # [XX] Exchange RL components
VXCRLvcs= 79189 RL # [XC] XCpotential RL components
Single precision:
EXXRLvcs= 44565 RL # [XX] Exchange RL components
VXCRLvcs= 44565 RL # [XC] XCpotential RL components

Moreover, the GW results from single-precision Yambo 5.3.0 contain NaNs.

r-gw_HF_and_locXC_gw0_em1d_ppa_el_el_corr.txt

I also tried compiling the single-precision Yambo 5.2.1, and found that the same initialization [WARNING] occurs, and it likewise generates input files with parameters different from the double-precision version (the same as in the single-precision 5.3.0 case). However, the GW results from single-precision Yambo 5.2.1 no longer produce NaNs.

r-gw60_HF_and_locXC_gw0_dyson_em1d_ppa_el_el_corr.txt

I am very confused and unsure whether there is an issue with how I compiled the single-precision Yambo, or whether the SAVE folder generated from my Quantum ESPRESSO calculations using the p2y command is problematic. I would greatly appreciate your guidance.

Posted: **Fri Feb 13, 2026 11:32 am**

Dear Daniele，
I carried out some additional tests. For single-precision Yambo 5.3.0, I generated the initialization input file using `yambo -i -V all`, and by changing Gthresh from `0.100000E-4` to `0.100000`, I finally managed to eliminate the warning. However, the subsequent GW calculation still produced NaN results.

For single-precision Yambo 5.2.1, I increased Gthresh in the initialization input file and modified `MaxGvecs=79189`. The warning then disappeared, but the GW results remained identical to those obtained previously with `MaxGvecs=44565`.

Does the appearance of a warning like [WARNING] Found non closed shells. Max cutoff will be reduced during initialization indicate that the initial structure itself is problematic and therefore not supported for calculations?

Posted: **Mon Feb 16, 2026 8:48 am**

Dear Xiangjun,

the warning is not problematic. Identification of the shells relies on the assigned threshold and precision of the calculations. Gthresh=0.1 anyway would be rather high. In brief, I would not worry about the warning and worming with MaxGvecs=44565 is not an issue.

More problematic is the NAN that should not appear.

Please note your system is seen as metallic: is this expected?

The NAN appears in the correlation part of the self energy, not easy to spot the problem.
I suggest you to download the last version of the code 5.4 (still beta) and see if the problem persists:

https://github.com/yambo-code/yambo/tree/5.4

Best,

Daniele

Posted: **Mon Feb 16, 2026 1:38 pm**

Dear Xiangjun,

addendum: is it possible you defined lattice parameters explicitly in your QE input (e.g. a and c)? We have experienced issues similar to what you are reporting in this case, and the problem is solved assigning your unit cell using celldm(1) etc...

Best,

Daniele

Posted: **Thu Feb 26, 2026 5:48 am**

Daniele Varsano wrote: Sun Feb 08, 2026 4:37 pm Dear Xiangjun,

indeed, the results are strange.
But, I see nothing wrong in your input file. About your procedure, please see here a tutorial on the procedure:
https://wiki.yambo-code.eu/wiki/index.p ... alues_only

e.g. I would let the dipoles to be recalculated with the updated energies, but this should be a very minor issue.
Please note, your system starting point is a metal, but after the first iteration the gap open and yambo seems to take into account correctly of the new occupation numbers (see report Energies & Occupations section before and after reading the database). Anyway, is your system hexagonal Bi monolayer? If so, I think also the DFT band structure should have a gap (very small!). Because of that I would also let the HF part of the self energy to be recalculated with the new occupation numbers.

What is instead quite surprising and suspicious, is the execution time for your calculation. Your system it is not particularly large, and the execution times are extremely large. You should probably check if there is something odd in the compilation.

My suggestion is to check your compilation, compile the code in single precision, and repeat the procedure as indicated in the tutorial (avoiding recompiling the screening) and eventually check the role of QPkrange. For these checks I would also remove the spin-orbit coupling to make the calculation more handy.

Best,

Daniele

Dear Daniele,
I think I’ve figured out where my calculation went wrong. I copied all files except `ndb.QP` into the folder used for the G1W0 run, but during the G1W0 calculation Yambo directly reads `ndb.HF_and_locXC`. Judging from the formalism, this seems incorrect: it should read the quasiparticle energies modified by `GfnQPdb` and then recompute `ndb.HF_and_locXC`.

I performed another test: I did not copy `ndb.HF_and_locXC` into the folder for the G1W0 run. In this case, the report file shows that a new `ndb.HF_and_locXC` is generated and it is different from the original one, and the results look more reasonable.

I also have another question. In my G0W0 calculation, I used `rim_cut` and `rim_w`. Do I still need to use them in G1W0? If I do, it seems to make the band gap obtained during the self-consistent iterations too large. If I do not use `rim_cut` and `rim_w` in G1W0, can I still directly reuse the `ndb.pp*` files generated by the G0W0 run that did use `rim_cut` and `rim_w`? In other words, are the `ndb.pp*` files themselves affected by `rim_cut` and `rim_w`?

Thanks for your help!!!

Yambo Community Forum

evGW

evGW

Re: evGW

Re: evGW

Re: evGW

Re: evGW

Re: evGW

Re: evGW

Re: evGW

Re: evGW

Re: evGW