yambo-code / yambo Goto Github PK

This might be due to the following call inside src/interface/INT.F

   call W_reset(Xw(1),damping=0.001_SP)                                 
   call W_reset(Xw(2),damping=0.001_SP)                                 

User reports yambo stopping with this error:
"[ERROR] STOP signal received while in :[04] Dynamical Dielectric Matrix [ERROR] clock_find: too many clocks"

when more than 64 cpu are used. Input provided, report asked.
http://www.yambo-code.org/forum/viewtopic.php?f=15&t=1569&p=7508#p7508

A user reported this problem:
Incompatibility between values read in database and input file when reading a previous ndb.em1d file in lifetime calculation. Actually, we would need to reproduce the problem as it is also possible the user made some mistake.
http://www.yambo-code.org/forum/viewtopic.php?f=14&t=1511&p=7308#p7308

the function ypp -k h : path generations of high symmetry points, in the GPL version it is documented in the legend (ypp -H), but not yet implemented.

Preprocessor error since YAMBO_FREE is used here with 2 arguments while include/memory.h defines it with a single argument. I guess this should be two separate calls to YAMBO_FREE.

Which would then result in the same problem as the matching YAMBO_ALLOC calls higher up the subroutine which lack a specific implementation for the generic mem_dri routine.

Dear developers,

I was trying to redo the exciton-phonon coupling effect on Si to calculate the temperature-dependent absorption spectrum; However it seems that this is not part of the official release of Yambo as of now.
Will the exciton-phonon coupling part be released any time soon?

Best,
LUCA

Hi guys, I was wondering whether there is interest in creating a conda package for yambo.

While a conda yambo won't get you optimal performance for your machine, the pre-built binaries make it much easier and faster for new prospective users to give it a try (most other MaX codes already have one).

I've started compiling a conda recipe here but I'm running into issues at the configure stage - yambo doesn't seem to like the C preprocessor

checking how to run the C++ preprocessor... $BUILD_PREFIX/bin/x86_64-conda-linux-gnu-cpp
configure: error: in `/home/conda/staged-recipes/build_artifacts/yambo_1619355155817/work/lib/hdf5/hdf5-1.12.0':
configure: error: C++ preprocessor "/home/conda/staged-recipes/build_artifacts/yambo_1619355155817/_build_env/bin/x86_64-conda-linux-gnu-cpp" fails sanity check
See `config.log' for more details

Also, it tries to compile hdf5 although I've already added it as a dependency.

Could you perhaps help me tweak the compilation?

In the PR conda-forge/staged-recipes#14727 there is the meta.yaml that describes the dependencies, and the build.sh that contains the commands to build.

E.g. I'm wondering whether I need to add, on top of hdf5, the netcdf and netcdf-fortran dependencies and whether I need to explicitly link against them using the configure options or whether the configure should autodiscover them.

Initial version for all libraries

yaml-0.2.2.tar.gz
fftqe.tar.gz
fftw-3.3.6-pl1.tar.gz
hdf5-1.8.18.tar.gz
iotk-y1.2.1.tar.gz
netcdf-y4.1.3_v2.tar.gz
etsf_io-1.0.4.tar.gz
lapack-3.6.1.tar.gz
blacs.tar.gz
slatec.tar.gz
scalapack-2.0.2.tar.gz
petsc-3.7.4.tar.gz
slepc-3.7.3.tar.gz
iotk-y1.2.2.tar.gz
libxc-y2.0.3.tar.gz
futile-yambo.tar.gz

checking if FC precompiler works on FC source... cpp: warning: argument unused during compilation: '-E' [-Wunused-command-line-argument]
cpp: error: unable to execute command: Executable "gcc" doesn't exist!
yes
checking whether we are using the GNU Fortran 77 compiler... yes

It should use $(CC), and not fail when gcc doesn't exist.

FreeBSD 11.2, clang-6

See this post from user in the forum

https://www.yambo-code.eu/forum/viewtopic.php?t=2568&sid=39567e6a5b38958e08a268ad2c73bdfe

The source might be this procedure:

   group_size=max(1,int(n_total_states/500))                            
   do i1=1,n_total_states,group_size                                    
     call ef2nel(Tel,E_sorted(i1),n_of_el_from_zero(1),'both ')         
     if (n_of_el_from_zero(1)<-nel_diff_zero) i_Ef(1)=i1                
     if (n_of_el_from_zero(1)> nel_diff_zero) then                      
       i_Ef(2)=i1                                                       
       exit                                                             
     endif                                                              
   enddo                                                                

since changing the total number of bands from 600 to 1000 group size changes from 1 to 2

Following discussions with @sangallidavide, @daniele-varsano, @andrea-ferretti and Savio Laricchia, I am posting this table with the issues and caveats that I have compiled while trying different Lkind, BSEmod, BSSmod, and architecture (GPU/CPU) options.

The last column of the table is written from the perspective of a user who is not familiar with everything behind the scenes (such as how an iterative solver works).

Some of the issues (such as the scalapack bug or being able to use BSEmod="coupling" on GPU) already have a solution/patch/workaround which however is not generally available.

Other issues may be tackled by changing the logic of the code (such as: if I have Lfull I get EELS directly as 1+vX with no inversions/KKR, if I have Lbar I get ABS directly as 1-vX with no inversions/KKR).

Finally, some issues are solved by simply telling the user what the code is doing via Warning/Error messages. Particular attention should be given to the cases where the code prints wrong spectra without warning.

In building yambo with ext-libs, I get an error
This is on a Centos7 server for our supercomputer.

[Making qe_pseudo]<<<
cp: ‘/opt/ohpc/admin/UAbuild/yambo/yambo-5.0.3/lib/qe_pseudo/.objects’ and ‘lib/qe_pseudo/.objects’ are the same file
: warning: ISO C99 requires whitespace after the macro name
make[2]: Entering directory /opt/ohpc/admin/UAbuild/yambo/yambo-5.0.3/lib/qe_pseudo' Makefile:104: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. make[2]: Leaving directory /opt/ohpc/admin/UAbuild/yambo/yambo-5.0.3/lib/qe_pseudo'
make[1]: *** [yambo] Error 2

Despite these being supplied build still downloads tarballs:

./configure CPP="gcc10 -E -P" FPP="gfortran10 -E -P -cpp" --with-netcdf-includedir="pkg-config --cflags netcdf netcdf-fortran" --with-netcdf-libs="pkg-config --libs netcdf netcdf-fortran" --with-hdf5-includedir=/usr/local/include --with-hdf5-libs="-lhdf5" --with-libxc-includedir="pkg-config --cflags libxc libxcf90" --with-libxc-libs="pkg-config --libs libxc libxcf90" --prefix=/usr/local

Additionally, it can't use external pnetcdf package and just downloads the tarball.

FYI: downloads aren't allowed by package builders. All dependencies should be either pre-installed as packages, or pre-downloaded.

Such difficulties likely cause porting systems to not have ports for Yambo.

I am trying to create a FreeBSD port but I just can't build Yambo.

Also after tarballs are downloaded build just fails ungracefully:

===>  Building for yambo-5.1.0
gmake[1]: Entering directory '/disk-samsung/freebsd-ports/science/yambo/work/yambo-5.1.0'
gmake[2]: Entering directory '/disk-samsung/freebsd-ports/science/yambo/work/yambo-5.1.0'
gmake[2]: warning: -j6 forced in submake: resetting jobserver mode.
gmake[2]: *** No rule to make target 'w'.  Stop.
gmake[2]: Leaving directory '/disk-samsung/freebsd-ports/science/yambo/work/yambo-5.1.0'
yambo build failed
gmake[1]: Leaving directory '/disk-samsung/freebsd-ports/science/yambo/work/yambo-5.1.0'
===>  Staging for yambo-5.1.0
===>   yambo-5.1.0 depends on executable: gfortran10 - found
===>   yambo-5.1.0 depends on executable: gcc10 - found
===>   Generating temporary packing list
gmake[1]: Entering directory '/disk-samsung/freebsd-ports/science/yambo/work/yambo-5.1.0'
gmake[1]: *** No rule to make target 'install'.  Stop.
gmake[1]: Leaving directory '/disk-samsung/freebsd-ports/science/yambo/work/yambo-5.1.0'
*** Error code 2

My Fortran compiler (i used two different versions from gfortran, 4.8.5 and 6.4.0) complains that it can't compile the code that results from the expansion of these macros as it cannot fine a specific subroutine for the generic 'mem_dri' routine (which should be defined in src/modules/mod_memory.F). I am not a Fortran expert - I was only trying to install this code for one of the users of the cluster I manage - but the compiler does seem to be right in this case.

The loading of kb and kbd form factors is buggy

Yambo defines the form factors with dimenion n_sp_pol, but fills only the element i_sp_pol=1

The bug can be easely reproduced using the following input for C6H3Cl3 and comparing with 02_ALDA_diago_ws

N.B.: you need to use the "SAVE_converted" folder with recent versions of yambo

mv SAVE SAVE_old
mv SAVE_converted SAVE
yambo
yambo -F bse.in

with the following bse.in

optics                       # [R OPT] Optics
bse                          # [R BSE] Bethe Salpeter Equation.
tddft                        # [R   K] Use TDDFT kernel
bsk                          # [R BSK] Bethe Salpeter Equation kernel
bss                          # [R BSS] Bethe Salpeter Equation solver
NonPDirs= "XYZ"              # [X/BSS] Non periodic chartesian directions (X,Y,Z,XY...)
BSEmod= "resonant"           # [BSE] resonant/causal/coupling
BSKmod= "ALDA"               # [BSE] IP/Hartree/HF/ALDA/SEX/BSfxc
BSSmod= "s"                  # [BSS] (h)aydock/(d)iagonalization/(i)nversion/(t)ddft`
BSENGexx= 1535         mHa   # [BSK] Exchange components

BSSNEig= 30                     # [SLEPC] Number of eigenvalues to compute
BSSEnTarget= 0.000000      eV    # [SLEPC] Target energy to find eigenvalues
BSSSlepcApproach= "Krylov-Schur" # [SLEPC] Approach ("Krylov-Schur","Generalized-Davidson","Jacob-Davidson")
BSSSlepcPrecondition= "preonly+jacobi" # [SLEPC] Precondition technique (none|preonly+jacobi|bcgs+jacobi)
BSSSlepcExtraction= "ritz"       # [SLEPC] Extraction technique (ritz|harmonic)
BSSSlepcMaxIt=0                  # [SLEPC] Maximum number of iterations
BSSSlepcNCV=0                    # [SLEPC] Dimension of the subspace
BSSSlepcTol= 0.100000E-5         # [SLEPC] Tolerance for the iterative solver
BSSSlepcMatrix                # [SLEPC] Store slepc matrix, faster but more memory consuming

rim_cut
CUTGeo= "ws xyz"             # [CUT] Coulomb Cutoff geometry: box/cylinder/sphere
CUTwsGvec= 0.700000            # [CUT] WS cutoff: number of G to be modified

% BEnRange
  3.00000 | 11.00000 | eV    # [BSS] Energy range
%
% BDmRange
  0.10000 |  0.10000 | eV    # [BSS] Damping range
%
BEnSteps=  800               # [BSS] Energy steps
% BLongDir
 1.000000 | 1.000000 | 1.000000 |        # [BSS] [cc] Electric Field
%
% BSEBands
  14 |  34 |                 # [BSK] Bands range
%

Also in the code I tried to play with different options. Relevant info in file src/linear_algebra/MATRIX_slepc.F

 !
 ! * Krylov subspaces: EPSKRYLOVSCHUR, STPPRECOND not accepted,
 !                        STSINVERT + KSPPREONLY+ PCJACOBI gives wrong eigenvalues. Too strong (?)
 !                                  +  KSPBCGS  + PCJACOBI works fine
 !
 ! * Generalized-Davidson: EPSGD, RIGHT VECTORS ONLY
 !                       STPPRECOND + KSPPREONLY + PCJACOBY very fast for few eigenvectors
 !
 ! * Jacob-Davidson: EPSJD, NOT WORKING WITH KSP PREONLY
 !                    STPPRECOND + KSPCG SUPER-SLOW + PCJACOBY super slow
 !

But I was not sure which was the correct set of combinations to use

A user reports a degeneracy break in the calculation of when using PBE. He is using 4.2.4
In the post, there is a pw input file to reproduce the problem.

My device's system is 2vCPUs | 8GiB | c7.large.4 Ubuntu 20.04 server 64 bit.And i referenced this course:
[https://www.yambo-code.eu/wiki/index.php/Install_Yambo_on_Ubuntu/LinuxMint]
I only changed yambo-5.0.1 to yambo-5.1.0 when i executed these orders, and it always made a mistake at this step:

compile the code (where -j4 means that the code is compiled in parallel on 4 cores):
make -j4 yambo

The mistakes is:

make[2]: *** [config/mk/global/actions/compile_external_libraries.mk:36: petsc] Error 2
if test -d slepc-3.14.2 ; then \
  unset PETSC_DIR; \
  unset PETSC_ARCH; \
  cd slepc-3.14.2; \
  PETSC_DIR=/root/yambo-5.1.0/lib/external/gfortran/gfortran/single \
  SLEPC_DIR=/root/yambo-5.1.0/lib/slepc/slepc-3.14.2 \
  python3 ./configure --prefix="/root/yambo-5.1.0/lib/external/gfortran/gfortran/single" ; \
fi
Checking environment...
ERROR: File error while reading PETSc version
ERROR during configure (log file not open yet)
make[3]: *** [Makefile:34: configure-stamp] Error 1
make[2]: *** [config/mk/global/actions/compile_external_libraries.mk:38: slepc] Error 2
make[3]: Nothing to be done for 'all'.
        [lib/qe_pseudo] qe_pseudo (checking work to be done)
        [lib/slatec] slatec (checking work to be done)
        [lib/math77] math77 (checking work to be done)
        [lib/local] local (checking work to be done)
        [lib/yambo/driver/src/interface] interface (checking work to be done)
        [lib/yambo/driver/src/main] main (checking work to be done)
        [lib/yambo/driver/src/options] options (checking work to be done)
make[1]: *** No rule to make target 'lib'.  Stop.
make: *** [config/mk/global/actions/compile_yambo.mk:38: yambo] Error [2_](url)

Maybe i shoule change some configuration?

 --with-blas-libs="-L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -lgomp -lpthread -lm -ldl" \
 --with-lapack-libs="-L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -lgomp -lpthread -lm -ldl" 

Any help would be appreciated!

At present there is a barrier here: https://github.com/yambo-code/yambo/blob/master/config/m4/acx_misc.m4

Connected discussion on yambo forum: https://www.yambo-code.eu/forum/viewtopic.php?p=13043#p13043

Reported by @muralidhar-nalabothula :
https://www.yambo-code.eu/forum/viewtopic.php?p=12955#p12955

The sigma_y matrix defined in "yambo/src/modules/mod_D_lattice.F" is not correct.
As Fortran in column major, reshaping [1,2,3,4] will give ([[1 3],[2 4]])

So the matrix is currently defined as -sigma_y(actual). I can see that in one of the Tait-Bryan angles (beta) defined in "yambo/src/setup/build_spin_sop.F" lacks minus sign. I guess the minus was removed to compensate this. When rotating spinors wave functions with time reversal symmetry, it picks up an additional phase of -1 (which does not effect the results due to gauge arbitrary ness). I also see some other instances where sigma_y is used.

Hello,

I am trying to compile Yambo 4.5.3 for a user but I am running into some issues when doing make all.

As far as I can tell, there are some issues with the "internal" dependencies handling in the makefile.

For example, ypp is compiled before ypp_ph. Both depends on ypp/modules/ but ypp_ph adds a YPP_ELPH define when compiling the files in this folder. Unfortunately it seems that it doesn't trigger a new recompilation when the folder ypp/modules/ has already been visited when building ypp.

Any ideas on how to fix that issue or at least work it around?

Best regards,
Rémi

Dear All,

While running the executable "p2y" for generating input files for Yambo using output files of Quantum Espresso, I encountered this error:

p2y

____ ____ ___ .___ . .___ ______
\ \ / / / \ | / | | _ \ / __
\ / / / ^ \ | \ / | | |) | | | | |
_ / / /\ \ | |/| | | _ < | | | |
| | / _____ \ | | | | | |) | | `--" |
|| // _\ || || |/ _/

<---> DBs path set to .
<---> detected QE data format: qexsd
<---> == PWscf v.6.x generated data (QEXSD fmt) ==
<---> Header/K-points/Energies...

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine qexsd_read_symmetry (2):
fmt problem

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ...
Abort(2) on node 0 (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 2) - process 0

Below are some details of our installation :
QE 6.7 Intel MPI 2019 + intel mkl + fftw 3.3.8 + hdf5 1.10.4 (yambo 4.5.2 rev.171 - MPI+SLK)

@daniele-varsano @andrea-ferretti @andreamarini @sangallidavide

Dear all,

I am tyring to compile yambo_4.2.0, however I get the following compilation error concerning p2y executable.

make[2]: Leaving directory /home/LUCA/yambo_4.2.0/yambo/interfaces/p2y' make[2]: Entering directory /home/LUCA/yambo_4.2.0/yambo/interfaces/p2y'
numrec_kinds.F mod_pw_data.F qeh5_module.F pw_errore.F pw_struct_module.F qexml.f90(706): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "LATTICE_PARAMETER", alat, ATTR = attr )
-----------^
qexml.f90(708): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "CELL_DIMENSIONS", celldm(1:6) )
-----------^
qexml.f90(714): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "a1", a1(:) * alat, COLUMNS=3 )
-----------^
qexml.f90(715): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "a2", a2(:) * alat, COLUMNS=3 )
-----------^
qexml.f90(716): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "a3", a3(:) * alat, COLUMNS=3 )
-----------^
qexml.f90(723): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "b1", b1(:), COLUMNS=3 )
-----------^
qexml.f90(724): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "b2", b2(:), COLUMNS=3 )
-----------^
qexml.f90(725): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "b3", b3(:), COLUMNS=3 )
-----------^
qexml.f90(791): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "MASS", amass(i) )
--------------^
qexml.f90(810): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_ATTR]
CALL iotk_write_attr( attr, "tau", tau(:,i) )
--------------^
qexml.f90(863): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "FRACTIONAL_TRANSLATION", tmp(1:3), COLUMNS=3 )
--------------^
qexml.f90(896): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "MAXIMUM_POSITION", emaxpos )
-----------^
qexml.f90(898): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "INVERSE_REGION", eopreg )
-----------^
qexml.f90(900): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "FIELD_AMPLITUDE", eamp )
-----------^
qexml.f90(926): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "WFC_CUTOFF", ecutwfc )
-----------^
qexml.f90(928): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "RHO_CUTOFF", ecutrho )
-----------^
qexml.f90(995): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( iunaux, "K-POINT_COORDS", xk, ATTR = attr )
-----------^
qexml.f90(1066): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "HUBBARD_U", Hubbard_U(1:nsp) )
--------------^
qexml.f90(1068): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "HUBBARD_ALPHA", Hubbard_alpha(1:nsp) )
--------------^
qexml.f90(1093): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
call iotk_write_dat(ounit, "yukawa", yukawa)
-----------^
qexml.f90(1094): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
call iotk_write_dat(ounit, "ecutvcut", ecutvcut)
-----------^
qexml.f90(1095): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
call iotk_write_dat(ounit, "exx_fraction", exx_fraction)
-----------^
qexml.f90(1096): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
call iotk_write_dat(ounit, "screening_parameter", screening_parameter)
-----------^
qexml.f90(1125): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "SMEARING_PARAMETER", degauss , ATTR = attr )
--------------^
qexml.f90(1154): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "INPUT_OCC_UP", input_occ(1:nstates_up,1) )
--------------^
qexml.f90(1157): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "INPUT_OCC_DOWN", input_occ(1:nstates_dw,2) )
-----------------^
qexml.f90(1196): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_ATTR]
CALL iotk_write_attr( attr, "XYZ", xk(:,ik), FIRST = .TRUE. )
--------------^
qexml.f90(1198): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_ATTR]
CALL iotk_write_attr( attr, "WEIGHT", wk(ik) )
--------------^
qexml.f90(1226): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat( ounit, "Q-POINT", xqq(:), COLUMNS=3 )
-----------^
qexml.f90(1256): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_WRITE_DAT]
CALL iotk_write_dat ( ounit, "NUMBER_OF_ELECTRONS", nelec )
-----------^
qexml.f90(3424): catastrophic error: Too many errors, exiting
compilation aborted for qexml.f90 (code 1)
make[2]: *** [qexml.o] Error 1
make[2]: *** Waiting for unfinished jobs....
numrec_module.F numrec_locate.F qexsd_p2y.f90(602): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_ATTR]
CALL iotk_scan_attr( attr, "alat", alat, IERR=ierr )
--------------^
qexsd_p2y.f90(613): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat(iunit, "a1", a1(:), IERR=ierr )
--------------^
qexsd_p2y.f90(618): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat(iunit, "a2", a2(:), IERR=ierr )
--------------^
qexsd_p2y.f90(623): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat(iunit, "a3", a3(:), IERR=ierr )
--------------^
qexsd_p2y.f90(679): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat(iunit,"mass",amass_(is),IERR=ierr)
--------------^
qexsd_p2y.f90(710): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat(iunit,"atom",tau_(:,i),ATTR=attr, IERR=ierr)
--------------^
qexsd_p2y.f90(833): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat( iunit, "rotation", s_(1:3,1:3,i), IERR=ierr )
------------------^
qexsd_p2y.f90(836): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
CALL iotk_scan_dat( iunit, "fractional_translation", trasl_(1:3,i), IERR=ierr )
------------------^
qexsd_p2y.f90(916): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "ecutwfc", ecutwfc, IERR=ierr )
--------------^
qexsd_p2y.f90(920): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "ecutrho", ecutrho, IERR=ierr )
--------------^
qexsd_p2y.f90(1245): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat(iunit, "ecutfock", ecutfock, IERR=ierr )
--------------^
qexsd_p2y.f90(1250): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat(iunit, "exx_fraction", exx_fraction, IERR=ierr )
--------------^
qexsd_p2y.f90(1255): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat(iunit, "screening_parameter", screening_parameter, IERR=ierr )
--------------^
qexsd_p2y.f90(1270): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat(iunit, "ecutvcut", ecutvcut, IERR=ierr )
--------------^
qexsd_p2y.f90(1320): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "degauss", degauss, IERR=ierr)
-----------------^
qexsd_p2y.f90(1334): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "tot_charge", tot_charge, IERR=ierr)
--------------^
qexsd_p2y.f90(1339): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "tot_magnetization", tot_mag, FOUND=lfound, IERR=ierr)
--------------^
qexsd_p2y.f90(1427): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "nelec", nelec, IERR=ierr)
--------------^
qexsd_p2y.f90(1437): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "fermi_energy", fermi_energy, FOUND=lfound, IERR=ierr)
--------------^
qexsd_p2y.f90(1443): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "highestOccupiedLevel", homo_energy, FOUND=lfound, IERR=ierr)
--------------^
qexsd_p2y.f90(1449): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "two_fermi_energies", fermi_energy_updw, FOUND=lfound, IERR=ierr)
--------------^
qexsd_p2y.f90(1514): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_ATTR]
call iotk_scan_attr( attr, "degauss", degauss, IERR=ierr)
-----------------^
qexsd_p2y.f90(1533): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "k_point", rvec, ATTR=attr, IERR=ierr)
--------------------^
qexsd_p2y.f90(1538): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_ATTR]
call iotk_scan_attr( attr, "weight", wk(ik), IERR=ierr)
--------------------^
qexsd_p2y.f90(1548): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "eigenvalues", eig_, IERR=ierr)
--------------------^
qexsd_p2y.f90(1559): error #6285: There is no matching specific subroutine for this generic subroutine call. [IOTK_SCAN_DAT]
call iotk_scan_dat( iunit, "occupations", occ_, IERR=ierr)
--------------------^
compilation aborted for qexsd_p2y.f90 (code 1)
make[2]: *** [qexsd_p2y.o] Error 1
numrec_ddpoly.F numrec_polint.F mod_numerical.F pw_basis_module.F make[2]: Leaving directory /home/vziaei/yambo_revs/yambo_4.2.0/yambo/interfaces/p2y' make[1]: *** [p2y] Error 2 make[1]: Leaving directory /home/vziaei/yambo_revs/yambo_4.2.0/yambo'
p2y build failed

Best wishes,
LUCA

The build process fails to download the etsf-io package. TThe cause is a download failure, leaving an empty file.

The download is done by the Makefile in lib/archive. On our system, this executes
the command

wget --no-check-certificate -O etsf_io-1.0.4.tar.gz https://github.com/yambo-code/yambo/files/845218/

This is not what is intended, and the cause is a typo in package.list. Line 56 (line number for Yambo 4.5.3) should
read

url_etsf_io=https://github.com/yambo-code/yambo/files/845218/$(tarball_etsf_io)

(the _io at the end is missing).

The mistake in package.list is still present in the version that I found in the repo on 3 February 2020, but is now on line 70.

Hi guys, I guess you are aware of this but my link checkers on https://atomistic.software/#/ alerted me to the fact that the yambo web site at https://yambo-code.org/ has been unreachable since at least December 15th.

Worth fixing?

For example applying a stretching to bulk iron of test-suite when doing a BSE calculation with bands from 5 to 10 leads to the following energies and occupations.

 [QP_apply] Action to be applied: USER defined scissor

  [04.01]  QP corrections report
  ==============================

  [K+QP] === General ===
  [K+QP] Electronic Temperature                     :  0.258693E-1   300.200    [eV K]
  [K+QP] Bosonic    Temperature                     :  0.258606E-1   300.100    [eV K]
  [K+QP] Finite Temperature mode                    : yes
  [K+QP] El. density                                :  0.67814E+24 [cm-3]
  [K+QP] Fermi Level                                : -3.170129 [eV]

  [K+QP] === Gaps and Widths ===
  [K+QP] Conduction Band Min                        : -3.170129 [eV]
  [K+QP] Valence Band Max                           : -3.170129 [eV]
  [K+QP] Filled Bands                               :  10
  [K+QP] Empty Bands                                :   5  20
   
  [K+QP] === Metallic Characters ===
  [K+QP] N of el / N of met el                      :  8.000000  0.000000
  [K+QP] Average metallic occ.                      :  0.000000

  [WARNING] [K+QP] Metallic system
   
  Eqp @ K [ 1]
   -4.18075  -4.05053   0.92893   0.98412 -22.08835 -21.47579 -19.64319 -17.36086
  -17.23808 -16.29019   4.43012   5.39058  25.54383  25.61119  27.15088  27.25378
  Eqp @ K [ 2]
   -1.44541  -0.45291   0.36015   0.58579 -20.55967 -19.19084 -19.08801 -17.88579
  -16.45774 -14.01948   5.45836   5.95674  14.05958  15.07340  21.47403  22.11517
  Eqp @ K [ 3]
   -2.15004  -1.88616   0.15134   0.15255 -20.22450 -20.11913 -19.70416 -19.67519
  -17.50186 -12.55490   5.11368   5.40319  20.05680  20.10777  20.50891  20.56504

With some machines (openSUSE Leap 15 and Tumbleweed) I get the following error while linking (using yambo 4.2.4):

/bin/sh: echo$: command not found
make[1]: *** [Makefile:85: yambo] Error 127
make[1]: Leaving directory '/home/rbw/programs/installs/yambo-4.2.4/driver'
make: *** [Makefile:192: yambo] Error 2

Older openSUSE links just fine. I don't know what difference in software make the difference (like gcc 4.85 to 7/8), but after much trying removing the \$ after the variable names in sbin/make_makefiles.sh did the trick for me:

\$(target): \$(dep_file) \$(objs)
\$(driver)
\$(link)
\$(modmove)
\$(dircheck)
@mv \$@ \$(exec_prefix)
before:
\$(target): \$(dep_file) \$(objs)
\$(driver)\$
\$(link)\$
\$(modmove)\$
\$(dircheck)\$
@mv \$@ \$(exec_prefix)

I don't know much about makefiles, so I don't know, whether that's a good solution.

Compiling with intel oneapi 2023 gives the errors:
1.
.../yambo-5.1.2/src/tools/io.c:56:15: error: call to undeclared function 'system'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
*ierr=system(name);
^
How to fix:
add
#include <stdlib.h>
in the head of src/tools/io.c

.../yambo-5.1.2/src/parser/PARSER_symbols.c:44:14: error: call to undeclared library function 'strdup' with type 'char *(const char *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ptr->name = strdup(sym_name);
^
.../yambo-5.1.2/src/parser/PARSER_symbols.c:44:14: note: include the header <string.h> or explicitly provide a declaration for 'strdup'
How to fix:
add
#include <string.h>
#include <strings.h>
in the head of src/parser/PARSER_symbols.c

Dear developers,

I am trying to compile YAMBO with NVIDIA HPC SDK 21.3 in order to benefit from GPUs in our cluster. The Fortran compiler bundled there identifies itself as nvfortran, however acts almost identical to PGI compiler.

PGI compiler has some different ideas on how to interpret sources. I see workarounds for them are already implemented, i.e. in src/modules/mod_stderr.F with a preprocessor option _PGI

Since configure does not recognize nvfortran as a PGI compiler, these workarounds are ignored.

I suggest adding nvfortran to config/m4/acx_get_fc_kind.m4 as a PGI compiler derivative

    *nvfortran*)
      FCKIND="pgi"
      FCVERSION=`$FC --version`
      ;;

Edit:
It seems acx_fortran_flags.m4 acts independently from acx_get_fc_kind.m4. nvfortran needs to be added there as well.

Hello,

Apologies for posting this here, but I am unable to register on the forum to ask questions. In the confirm registration section, the code question seems to have no code given to replace letters? And I'm unsure if an email is supposed to be sent that gives you the code, I simply get the error 'You have provided an invalid answer to the question.'

I'm trying to compile yambo 5.1.0 with intel and I get this error
yambo ypp linking failed. Check logs/compile_ypp.log

and in the compile_ypp.log at the bottom there is:
/wsu/el7/intel/2020/yambo-5.1.0/lib/libypp_Ydriver_main.a(launcher.o): In function launcher': launcher.c:(.text+0xe1): undefined reference to yambo_'

Any help would be appreciated!

This is using yambo 4.3.2

I'm trying to use the --prefix flag of the configure script to configure installation in a different folder than where the object files are built but I'm running into issues:

./configure --prefix=/usr/local
$ make yambo
cp: '/home/max/codes/yambo-4.3.2/lib/archive/Makefile' and 'lib/archive/Makefile' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/archive/Makefile.loc' and 'lib/archive/Makefile.loc' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/archive/fftw-3.3.6-pl1.tar.gz' and 'lib/archive/fftw-3.3.6-pl1.tar.gz' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/archive/iotk-y1.2.2.tar.gz' and 'lib/archive/iotk-y1.2.2.tar.gz' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/archive/keep-extlibs-stamp' and 'lib/archive/keep-extlibs-stamp' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/archive/libxc-2.2.3.tar.gz' and 'lib/archive/libxc-2.2.3.tar.gz' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/archive/package.list' and 'lib/archive/package.list' are the same file
cp: '/home/max/codes/yambo-4.3.2/config/missing' and 'config/missing' are the same file
cp: '/home/max/codes/yambo-4.3.2/lib/iotk/Makefile.loc' and 'lib/iotk/Makefile.loc' are the same file
/bin/sh: 2: test: /home/max/codes/yambo-4.3.2/lib/iotk/make_iotk.inc: unexpected operator
 
>>>[Making iotk]<<<
make[1]: Entering directory '/home/max/codes/yambo-4.3.2/lib/iotk'
if test -d iotk ; then ( cd iotk;  \
	if test -e /usr/local/lib/iotk/make.sys ; then rm /usr/local/lib/iotk/make.sys ; fi ; \
        if test -e /usr/local/lib/iotk/make_iotk.inc ; then \
           cp /usr/local/lib/iotk/make_iotk.inc /usr/local/lib/iotk/make.sys ; \
        fi ; \
        if test -e /home/max/codes/yambo-4.3.2/lib/iotk/iotk_specials.h ; then \
           cp /home/max/codes/yambo-4.3.2/lib/iotk/iotk_specials.h /usr/local/lib/iotk/iotk/include ; \
        fi ) ; \
fi
cp: cannot create regular file '/usr/local/lib/iotk/iotk/include': No such file or directory
Makefile:34: recipe for target 'configure-stamp' failed
make[1]: *** [configure-stamp] Error 1
make[1]: Leaving directory '/home/max/codes/yambo-4.3.2/lib/iotk'
Makefile:151: recipe for target 'ext-libs' failed
make: *** [ext-libs] Error 2

There are actually two issues I encountered:

• for some reason, make already tries to access /usr/local (contrary to the usual convention that make will build the executables in the folder where it is situated)
• there is no make install command despite ./configure --help actually promises one:

./configure --help
`configure' configures Yambo 4.3.2 r.134 (based on r.15658 h.afdb12c8c) to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

[...]

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/home/max/codes/yambo-4.3.2]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

By default, `make install' will install all the files in
`/home/max/codes/yambo-4.3.2/bin', `/home/max/codes/yambo-4.3.2/lib' etc.  You can specify
an installation prefix other than `/home/max/codes/yambo-4.3.2' using `--prefix',
for instance `--prefix=$HOME'.

[...]
$ make install
make: *** No rule to make target 'install'.  Stop.

So, my questions would be:

• for the time being, which files/folders would I need to copy by hand?
• could the Makefile be modified in such a way that make does not touch any folder in the prefix?
• could you add a make install command that copies the relevant files?

A user observed yambo failing when performing a test proposed in the tutorial (yambo parallel) hBN-2D (http://www.yambo-code.org/wiki/index.php?title=GW_parallel_strategies)
when using X_all_q_nCPU_LinAlg_INV=8.
The input file is reported here:
http://www.yambo-code.org/forum/viewtopic.php?f=10&t=1452&p=7022#p7018
and I have reproduced it using the input provided by the user. This is true also for the bug-fixes

From TianxiangQian:

I have finished the GW calculation. The log and report are attached in this email.
But I meet the NaN problem again on my HPC.
I find where NaN from.
It is in the ns.kb_pp_pwscf_fragment_1 like this.

I have renamed ns.kb_pp_pwscf_fragment* (do not use them).

Hello I am struggling with compilation and ending up at the missing separator error.

gcc -traditional -E -P -M -DU77 -DIFC -DGNU       -Isrc/fhp/finc  src/fhp/fsrc/blcomout.F | sed -e 's%blcomout.F.o%blcomout.o %g' | sed -e 's%blcomout.o%sys/ifort/objfst/blcomout.o sys/ifort/objprf/blcomout.o sys/ifort/objdbg/blcomout.o sys/ifort/cpp/blcomout.f sys/ifort/dep/blcomout.d%g' > sys/ifort/dep/blcomout.d
sys/ifort/dep/blcomout.d:3: *** missing separator.  Stop.

The make file can be downloaded from link

sbin/compilation/stamp_remove.sh is buggy

The following line
if [ $1 == "lib" ] && [ ! -z $llib ] && [[ "$file_src" == *"${ypp/\./}" ]] ; then stamp=$compdir/config/stamps_and_lists/lib_ypp_${llib}.a.stamp; fi

Returns
stamp=$compdir/config/stamps_and_lists/lib_ypp_${llib}.a.stamp
even if $file_src does not contain the string ypp

I realized that, I don't know why, there is a cleaning of the coefficient of the W interpolation
before they are used. This is clear from the following lines of code in QP_interpolate_W.F:

 call rim('c')
 !
  YAMBO_FREE(f_coeff)

followed by the following lines:

   do ig2=1,RIM_W_ng
     do ig1=1,RIM_W_ng
       !
       if(ig1==1.and.ig2==1.and.(.not. RIM_W_for_graph)) then
         dummy(:) = f_coeff(1,1,1,1,:)

As f_coeff is used after cleaning, yambo gives an error.

Hi,

Do you plan to make possible using the new API of Libxc?

mod_cusolverdn_y.F mod_pars.F mod_openmp.F mod_units.F mod_drivers.F mod_lexical_sort.F mod_com_interfcs.F mod_descriptors.F mod_wrapper.F mod_FFT.F mod_matrix_operate.F mod_atom_proj.F mod_cutoff_ws.F mod_ACFDT.F mod_stderr.F mod_OUTPUT_simple.F mod_wrapper_omp.F mod_com.F mod_logo  mod_debug.F mod_memory.F mod_linear_algebra.F mod_frequency.F mod_PHEL.F mod_parallel.F mod_RT_occupations.F mod_cuda.F mod_SLK.F mod_matrix.F mod_R_lattice.F mod_electrons.F mod_X.F mod_xc_functionals.f90:32:6:

   32 |  use xc_f90_types_m
      |      1
Fatal Error: Cannot open module file ‘xc_f90_types_m.mod’ for reading at (1): No such file or directory
compilation terminated.

A.K.

the configuration script seems to really hate accepting some of the options given to it. Currently, it keeps selecting to compile its own internal BLACS/ScaLAPACK even though I am specifying to it that I want it to use the MKL versions. config.log doesn't even show it testing for the existence of ScaLAPACK or BLACS.

A dot "." is missing in lib/archive/package.list

tarball_iotk=iotk-y1.2.2tar.gz -> ... 2.tar.gz

there seem to be issues building the external libraries during make all. iotk first seems to not create its destination include directory before copying a file into it. manually creating the directory and running it again gets past that, but then it fails to find make.sys when its makefile is run.

[jschnaitter@ec59 yambo-4.4.0]$ make all
for target in yambo ypp a2y p2y  yambo_ph ypp_ph yambo_rt ypp_rt yambo_nl ypp_nl yambo_kerr      ; do rm -f "/groups/arcc/temp/yambo-4.4.0/bin/$target" ; make $target; if test ! -f "/groups/arcc/temp/yambo-4.4.0/bin/$target" ; then echo "$target build failed"; break;fi ; done
make[1]: Entering directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0'
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/iotk-y1.2.2.tar.gz’ and ‘lib/archive/iotk-y1.2.2.tar.gz’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/keep-extlibs-stamp’ and ‘lib/archive/keep-extlibs-stamp’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/libxc-2.2.3.tar.gz’ and ‘lib/archive/libxc-2.2.3.tar.gz’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/Makefile’ and ‘lib/archive/Makefile’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/Makefile.loc’ and ‘lib/archive/Makefile.loc’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/package.list’ and ‘lib/archive/package.list’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/config/missing’ and ‘config/missing’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/libxc/Makefile.loc’ and ‘lib/libxc/Makefile.loc’ are the same file

>>>[Making libxc]<<<
make[2]: Entering directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/libxc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/libxc'
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/iotk-y1.2.2.tar.gz’ and ‘lib/archive/iotk-y1.2.2.tar.gz’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/keep-extlibs-stamp’ and ‘lib/archive/keep-extlibs-stamp’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/libxc-2.2.3.tar.gz’ and ‘lib/archive/libxc-2.2.3.tar.gz’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/Makefile’ and ‘lib/archive/Makefile’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/Makefile.loc’ and ‘lib/archive/Makefile.loc’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/archive/package.list’ and ‘lib/archive/package.list’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/config/missing’ and ‘config/missing’ are the same file
cp: ‘/groups/arcc/temp/yambo-4.4.0/lib/iotk/Makefile.loc’ and ‘lib/iotk/Makefile.loc’ are the same file
/bin/sh: line 1: test: /groups/arcc/temp/yambo-4.4.0/lib/iotk/make_iotk.inc: binary operator expected

>>>[Making iotk]<<<
make[2]: Entering directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/iotk'
if test -d iotk ; then \
( cd iotk;  make loclib_only ; make iotk.x ) ; fi
make[3]: Entering directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/iotk/iotk'
Makefile:2: ../make.sys: No such file or directory
make[3]: *** No rule to make target `../make.sys'.  Stop.
make[3]: Leaving directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/iotk/iotk'
make[3]: Entering directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/iotk/iotk'
Makefile:2: ../make.sys: No such file or directory
make[3]: *** No rule to make target `../make.sys'.  Stop.
make[3]: Leaving directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/iotk/iotk'
make[2]: *** [package-ready-stamp] Error 2
make[2]: Leaving directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0/lib/iotk'
make[1]: *** [ext-libs] Error 2
make[1]: Leaving directory `/lustre/fs0/groups/arcc/temp/yambo-4.4.0'
yambo build failed

I think it might be an issue with the test statements. at one point /bin/sh was complaining that test was expecting a binary operator, but now it isn't.

it also seems that this makefile breaks when run in parallel. If I try to run make with -j, libxc fails to build, claiming it cannot find xc.h.

As noticed by a user:
http://www.yambo-code.org/forum/viewtopic.php?f=30&t=1725

ypp exciton sorting in 4.5 requires the q vector label even if the finite-q BSE has not been released. This is just a small inconsistency that may cause confusion.

for MoS2 with SOC (large 4x4 cell)

doing dos calculation using Version 4.4.0 Revision 16643 Hash c3f6efe
it crashes saying "segmentation fault" inside the loop
do i_E=1,DOS_E_steps
call el_density_of_states(k,E,dos_E(i_E),DOS_broadening,bands,el_dos(i_E,:), & ! standard
& USE_the_DbGd=USE_the_DbGd,USE_occupations=USE_occ,& ! optionals
& WF_fac=WF_fac,PDOS_fac=PDOS_fac) ! optional pointers

doing the same calculation with devel_excitonlifetimes
Version 4.4.0 Revision 16059 Hash 6e74a14, it does not crash

After version 5.2 the subroutine was changed introducing Xw as optional variable.

However such a change would require to define an interface in a module

!

-subroutine rim(mode)
+subroutine rim(mode,Xw)
  !
  use pars,          ONLY:SP,pi,DP
  use com,           ONLY:msg
@@ -20,6 +20,7 @@ subroutine rim(mode)
 &                        RIM_id_epsm1_reference,RIM_anisotropy,RIM_W,&
 &                        cut_is_slab,idir
  use timing_m,      ONLY:timing
+ use frequency,     ONLY:w_samp
  !
 #include<memory.h>
  !
@@ -27,9 +28,10 @@ subroutine rim(mode)
  !
  ! Work Space
  !
- type(PP_indexes)::px
- integer   :: iq
- real(SP)  :: em1_anis(3),G_radii,G_circ
+ type(PP_indexes)      ::px
+ type(w_samp),optional :: Xw
+ integer               :: iq

Dear all,

I know that the maintainers are already aware of this from the yambo forum but I recently also found another format issue that only shows up in spin-polarized calculations

`p2y

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Error in routine qexsd_read_band_structure (1):
fmt problem (dims I)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
`

I think this is also related to a change in xml format between recent versions of pwscf.

A user reported in the forum NaN appearing in Sigma_c in a GW calculations:
http://www.yambo-code.org/forum/viewtopic.php?f=14&t=1565&p=7501#p7501
The error needs to be reproduced, input files attached in the post.

When disabling IOTK, compilation fails in lib/qe_pseudo/read_upf_v2.f90 as it still tries to call IOTK functions.

The G vectors are sorted by doing a loop on the miller indexes, e.g.
(0,0,0), (1,0,0), (0,1,0), (0,0,1), (1,1,0), ...

If the super-cell is non uniform, e.g. suppose z >> (x,y) this implies that this ordering is very different from the ordering as a function of the energy cutoff associated. For example given g1=(100,0,0) and g2=(0,0,100) we will have E[g1] >> E[g2].

In order to perform an integral up to a given cut-off, say 10 Ry (over a maximum of 40 Ry), one needs to find the G vectors which lay inside the corresponding sphere. yambo correctly computes the total number of G-vectors inside such sphere. To this end it temporary sorts the G-vectors.
(see sort call here: https://github.com/yambo-code/yambo/blob/master/src/setup/G_shells_finder.F )
Suppose that, as a result, there are 10.000 G (over a total of 200.000) vectors with E< 10 Ry.

Due to the way G-vectors are sorted, this will imply that these G-vectors are not the first 10.000. The sphere:

• would contain some G-vectors with very high index, e.g. vectors g_i=(0,0,N) with very large N
• would not contain some G-vectors with quite low index, e.g. vectors g_j=(m,0,0) with quite small m
  This happens because the z direction is much larger in real space, e.g. much smaller in reciprocal space.

Here comes the issue. When doing integrals, the code does not loop over the vectors inside the sphere, but over the vectors from 1 to 10.000. In practice it takes vectors with very high energy in the plane (corresponding cutoff much bigger than 10 Ry) and vectors with very low energy out of plane (corresponding cutoff much smaller than 10 Ry). This implies that, to converge up to a nominal cutoff 10 Ry along z, one would need to set in input a much higher cutoff. Indeed in 2D materials W converges very slowly against the energy cutoff.

There are 2 possible solutions:
a) Create a table which gives the index of the sorted G-vector, say E_sort_g_index, and perform all the integrals in G-space as

A=0
do i_g=1,ng_max
  i_g_p=E_sort_g_index(i_g)
  A=A+f(i_g_p)
enddo 

b) sort the g-vectors, to avoid changing all G-integrals, and also store the inverse E_sort_g_index for the cases in which the previous sorting is needed.

According to the help information of configure, --enable-dp=no should be equivalent to --disable-dp, or, given that the default is to configure for single precision, not specifying this option. This however does not work and is a bug in the option handling for --enable-dp, where only action is taken if nothing is specified or if the value is yes, leaving the variable build_precision uninitialized (and causing the build of PETSc to fail). The actual bug is in config/yambo_specific.m4 (Yambo 4.5.3) or config/m4/yambo_specific.m4 (GitHub sources found on 3 February 2021). The problem is on lines 66-68 which currently reads:

def_dp=""
if test x"$enable_dp" = "x";    then enable_dp="no";     build_precision="single"; fi
if test x"$enable_dp" = "xyes"; then def_dp="-D_DOUBLE"; build_precision="double"; fi

which should become, e.g.,

if test x"$enable_dp" = "x";    then enable_dp="no"; fi
def_dp=""
build_precision="single"
if test x"$enable_dp" = "xyes"; then def_dp="-D_DOUBLE"; build_precision="double"; fi

(and the first line is only needed if you want to ensure that enable_dp is not empty which may help avoiding trouble further down the configure script.)

The workaround is of course simply, never use --disable-dp or --enable-dp=no, but it is confusing and one needs to be an expert software installer to realise that the bug during the build process is due to specifying a single precision build in this way (which is perfectly valid according to ./configure --help).

It fails to build on FreeBSD 11.2:

>>>[Making slatec]<<<
cp: lib/slatec/.objects and /usr/ports/science/yambo/work/yambo-4.2.3/lib/slatec/.objects are identical (not copied).
<command-line>:0:11: warning: ISO C99 requires whitespace after the macro name
gmake[3]: Entering directory '/usr/ports/science/yambo/work/yambo-4.2.3/lib/slatec'
Makefile:89: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
gmake[3]: Leaving directory '/usr/ports/science/yambo/work/yambo-4.2.3/lib/slatec'
gmake[2]: *** [Makefile:171: int-libs] Error 2