Quantum Espresso version for Yambo 4.4.0

[Longjun Xiang]

Dear developers:

What's the most suitable version of quantum espresso to use Yambo 4.4.0?

[claudio]

You can use QE 6.1

best
Claudio

[Daniele Varsano]

Dear Longjun,

the last available version 6.4.1 should be totally compatible, as the previous version as well, did you experience any problem? In this case can you report on that?

Best,
Daniele

[Longjun Xiang]

Yes, I met a problem at the database generation step with p2y. The DFT data are calculated with qe-6.4.1 and qe-6.3Max.

[xianglj@HPC-Login-SPST XXX.save]$ p2y


__ __ _______ __ __ _______ _______
| | | || _ || |_| || _ || |
| |_| || |_| || || |_| || _ |
| || || || || | | |
|_ _|| || || _ | | |_| |
| | | _ || ||_|| || |_| || |
|___| |__| |__||_| |_||_______||_______|


<---> DBs path set to .
<---> detected QE data format: qexsd
<---> == PWscf v.6.x generated data (QEXSD fmt) ==
<---> Header/K-points/Energies... done
<---> Cell data...
<---> [WARNING]Two or more crystal strcutures fit the given cell done
<---> Atomic data... done
<---> Symmetries...[SI no]......[-I no]...[TR yes]
<01s> XC functional...Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
<01s> EXX fraction... 0.000000
<01s> EXX screening... 0.000000
<01s> K-points mesh... done
<01s> RL vectors... done
<01s> IGK arrays... done
<01s> Energies... done
<01s> :: Electrons : 334.0000
<01s> :: Temperature [ev]: 0.000000
<01s> :: Lattice factors [a.u.]: 12.35200 10.69715 57.32563
<01s> :: K-points : 52
<01s> :: Bands : 800
<01s> :: Spinor components : 2
<01s> :: Spin polarizations : 1
<01s> :: Spin orbit coupling : yes
<01s> :: Symmetries [spatial]: 1
<01s> :: [T-rev]: yes
<01s> :: Max WF components : 59487
<01s> :: RL vectors (WF): 71657
<01s> :: RL vectors (CHARGE): 475813
<01s> :: XC potential : Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
<01s> :: Atomic species : 3
<01s> :: Max atoms/species : 14
<01s> == DB1 (Gvecs and more) ...
<01s> ... Database done
<01s> == DB2 (wavefunctions) ...
<07m-53s> [p2y] wfc_io |########################################| [100%] 07m-51s(E) 07m-51s(X) done ==
<07m-53s> == DB3 (PseudoPotential) ...########################################################################################################################
# WARNING: there are pending errors
# PENDING ERROR (ierr=1)
# ERROR IN: iotk_open_read (iotk_files.F:663)
# CVS Revision: 1.20
# unit
file=.//data-file.xml
binary=F
iostat=29
# PENDING ERROR (ierr=2)
# ERROR IN: iotk_scan_empty (iotk_scan.F:440)
# CVS Revision: 1.23
# Tag not found
namel=fft_grid
# PENDING ERROR (ierr=3)
# ERROR IN: iotk_scan_empty (iotk_scan.F:440)
# CVS Revision: 1.23
# Tag not found
namel=fft_smooth
# FROM IOTK LIBRARY, VERSION 1.2.0
# UNRECOVERABLE ERROR (ierr=4)
# ERROR IN: iotk_getline (iotk_scan.F:1010)
# CVS Revision: 1.23
#
iostat=-1
# ERROR IN: iotk_scan_tag (iotk_scan.F:745)
# CVS Revision: 1.23
# ERROR IN: iotk_scan (iotk_scan.F:934)
# CVS Revision: 1.23
# ERROR IN: iotk_scan_begin (iotk_scan.F:94)
# CVS Revision: 1.23

What's the problem I confront?

[andrea.ferretti]

Dear Longjun,

just to clarify the issue: yambo is meant to be compatible with ALL releases of Quantum ESPRESSO (especially all new ones).
This said, there could be temporary issues coming from QE releasing a new version of the code with small incompatibilities in the datafiles.
We try to check for this ahead of time before the QE releases but it could happen. In case, we try to fix them as soon as possible.

Now: Let's focus on qe-6.4.1, which is quite recent and meant to work (while I would drop qe-6.3MaX, which is a beta pre-release).
Yambo detects QEXSD fmt, which is correct (being the default since QE-6.2, I think). Nevertheless, p2y then searches for data-file.xml, which
comes from the previous QEXML fmt.
This may come from running multiple versions of QE in the same folder (= using the same prefix and outdir).
Was this the case in your runs ?

If so, one quick thing to check is to remove the $prefix.save dir created by QE, and re-create it from scratch just using qe-6.4.1 .
Then try again with p2y.

If the problem persists, pls send in scf, nscf input files in order to reproduce the problem (this is the only way we can help)

take care
Andrea

[Longjun Xiang]

I am using the same QE version (6.4.1) to perform scf and also nscf calculation and using the p2y to generate database in Yambo4.4.0 suite. I have uploaded the input files, hoping you can help me to figure out my problem.

[andrea.ferretti]

quick follow up:
I was able to reproduce the problem.
Now looking into it.

Andrea

[andrea.ferretti]

Hi again,

the issue is basically related to the relative position of two tags (PP_LOCAL and PP_NLCC) present in one of your pseudopotentials.
BTW: since you renamed your pseudos (very bad practice!), I replaced them with Mo.rel-pz-oncvpsp.UPF, S.rel-pz-oncvpsp.UPF, leading to a problem when processing the S pseudo
(no NLCC for Mo there).

Below is a patch that fixes the problem in my case. We'll be running some more tests and then the patch will end up also in the github repo.
Pls note that this problem is not dependent on the specific version of qe used (I've checked both qe-6.4.1 and qe-6.5 and it works fine with me).

Take care
Andrea

===========

Code: Select all

diff --git a/lib/qe_pseudo/read_upf_v2.F b/lib/qe_pseudo/read_upf_v2.F
index da6a296..4699a06 100644
--- a/lib/qe_pseudo/read_upf_v2.F
+++ b/lib/qe_pseudo/read_upf_v2.F
@@ -82,14 +82,6 @@ SUBROUTINE read_upf_v2(u, upf, grid, ierr)             !
 
    ! Read radial grid mesh
    CALL read_upf_mesh(u, upf, grid)
-   ! Read non-linear core correction charge
-   ALLOCATE( upf%rho_atc(upf%mesh) )
-   IF(upf%nlcc) THEN
-      CALL iotk_scan_dat(u, 'PP_NLCC',  upf%rho_atc)
-   ELSE
-      ! A null core charge simplifies several functions, mostly in PAW
-      upf%rho_atc(1:upf%mesh) = 0._dp
-   ENDIF
 
    ! Read local potential
    IF(.not. upf%tcoulombp) THEN
@@ -113,6 +105,17 @@ SUBROUTINE read_upf_v2(u, upf, grid, ierr)             !
    ! Read data for gipaw reconstruction
 !   CALL read_upf_gipaw(u, upf)
    !
+   ! Read non-linear core correction charge
+   ALLOCATE( upf%rho_atc(upf%mesh) )
+   IF(upf%nlcc) THEN
+      rewind(u)
+      read(u,*)
+      CALL iotk_scan_dat(u, 'PP_NLCC',  upf%rho_atc)
+   ELSE
+      ! A null core charge simplifies several functions, mostly in PAW
+      upf%rho_atc(1:upf%mesh) = 0._dp
+   ENDIF
+   !
    ! Close the file (not the unit!)
    CALL iotk_close_read(u)
    !

[Longjun Xiang]

Thanks for your help.

I have download normal-conserving pseudopotential from this link: http://www.pseudo-dojo.org/.

One more question: Can we use PAW or US psedupotentials in Yambo 4.4.0? Or what's the normal-conserving pseduopential library you recommend?

[andrea.ferretti]

I have download normal-conserving pseudopotential from this link: http://www.pseudo-dojo.org/.

ok, I did the same, so prob I ended up using the same pseudos of your.

One more question: Can we use PAW or US psedupotentials in Yambo 4.4.0?

PAW are not supported at the moment. There is a tentative support for USPP that is still very limited and not production ready.

Or what's the normal-conserving pseduopential library you recommend?

pseudo-dojo is surely a very good one.
Libraries accessible from the Quantum ESPRESSO website are also good (though keep in mind that DFT tested pseudo potentials may not work out-of-the box for GW, meaning that GW dedicated tests on the PPs may be needed.)
One more option is to use the SSSP webpage https://www.materialscloud.org/discover ... efficiency
from Materials Cloud (that mixes both USPP,PAW,NCPP pseudos) .