composition of the excited state

[Andy]

Hello,
I want to know the contribution of each single particle level to an absorption peak after a TDDFT calculation. I know this feature for molecules (where I used NWChem - there it was possible to read the contribution of each niveau (to the excited state) in the output file). Is there something similar in Yambo?
Thank you very much for an answer and kind regards,
Andreas Luecke

[Daniele Varsano]

Dear Andreas,
first let me ask you to fill your signature with your affiliation, this is a rule of the forum.

yes, it is possible if you solve the TDDFT (or BSE) in transition space (yambo -o b -k ...), while if you solve the equation on reciprocal space this information it is not accessible.
In order to look to the contribution you need to use the ypp postprocessing executable.
http://www.yambo-code.org/input_file/ypp/index.php

by typing:

Code: Select all

ypp -e s

you will have your excitation energies ordered by energy or intenisty, with the relative index.

Code: Select all

ypp -e a

will generate an ypp.in input file, where you can edit with the indezes of the excitations you are interested in. Next you will have the information in output running ypp.

Please remember that in order to have access to this information you need a full diagonalization of the matrix (yambo -y d), so no recursive methods, and activate the flag "WRbsWF".
Have a look here:
http://www.yambo-code.org/input_file/ya ... -diago.php

Best,

Daniele

[Andy]

Hi Daniele,
thank you very much for your fast reply. Unfortunately I cannot test your suggestions because our cluster is defect at the moment. Hence I tried to compile yambo on my Mac Pro (OS X 10.8.3) but I was not able to resolve the compiler errors. I show you here the error messages - maybe you know this kind of problem. If you want I can also create a new topic in the "Compilation"-forum as it doesn't belong to ypp.

I use the latest svn version and the following configure script:

Code: Select all

./configure FC=mpif90 CC=mpicc CXX=mpicc FCFLAGS="-nofor-main -arch x86_64"  --enable-msgs-comps --with-netcdf-lib='/Users/anlu/Documents/Doktorarbeit/yambo_Files/lib/' --with-netcdf-include='/Users/anlu/Documents/Doktorarbeit/yambo_Files/include' --with-iotk='/Users/anlu/Documents/Doktorarbeit/espresso-5.0.2_myMPI_neu/S3DE/iotk' --with-p2y=5.0 FCCPP=mpif90 CFLAGS="-arch x86_64"

For the compilers I get the following infos:
-----------------
boskoop:libxc anlu$ mpicc --version
icc (ICC) 13.0.1 20121010
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

boskoop:libxc anlu$ mpif90 --version
ifort (IFORT) 13.0.1 20121010
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
-------------------

Unfortunately the compilation aborts while compiling the libxc library:

• .....
  libtool: compile: mpicc -DHAVE_CONFIG_H -I. -I.. -arch x86_64 -D_C_US -D_FORTRAN_US -MT libxc_la-mgga_x_2d_prhg07.lo -MD -MP -MF .deps/libxc_la-mgga_x_2d_prhg07.Tpo -c mgga_x_2d_prhg07.c -o libxc_la-mgga_x_2d_prhg07.o
  mv -f .deps/libxc_la-mgga_x_2d_prhg07.Tpo .deps/libxc_la-mgga_x_2d_prhg07.Plo
  /bin/sh ../libtool --tag=CC --tag=F77 --mode=compile mpicc -DHAVE_CONFIG_H -I. -I.. -arch x86_64 -D_C_US -D_FORTRAN_US -MT libxc_la-xc_f.lo -MD -MP -MF .deps/libxc_la-xc_f.Tpo -c -o libxc_la-xc_f.lo `test -f 'xc_f.c' || echo './'`xc_f.c
  libtool: ignoring unknown tag F77
  libtool: compile: mpicc -DHAVE_CONFIG_H -I. -I.. -arch x86_64 -D_C_US -D_FORTRAN_US -MT libxc_la-xc_f.lo -MD -MP -MF .deps/libxc_la-xc_f.Tpo -c xc_f.c -o libxc_la-xc_f.o
  mv -f .deps/libxc_la-xc_f.Tpo .deps/libxc_la-xc_f.Plo
  /bin/sh ../libtool --tag=FC --tag=F77 --mode=compile mpif90 -nofor-main -arch x86_64 -c -o libxc_la-libxc_funcs.lo `test -f 'libxc_funcs.f90' || echo './'`libxc_funcs.f90
  libtool: ignoring unknown tag F77
  libtool: compile: mpif90 -nofor-main -arch x86_64 -c libxc_funcs.f90 -o libxc_la-libxc_funcs.o
  mpif90 -nofor-main -arch x86_64 -c -o libxc_funcs.o libxc_funcs.f90
  mpif90 ./libxc_master.F90 > ../src/libxc.f90
  Undefined symbols for architecture x86_64:
  "_MAIN__", referenced from:
  _main in for_main.o
  ld: symbol(s) not found for architecture x86_64
  make[3]: *** [libxc.f90] Error 1
  make[3]: Leaving directory `/Users/anlu/Documents/Doktorarbeit/yambo_Files/yambo_download_nochmal/yambo/stable/lib/libxc/src'
  make[2]: *** [all] Error 2
  make[2]: Leaving directory `/Users/anlu/Documents/Doktorarbeit/yambo_Files/yambo_download_nochmal/yambo/stable/lib/libxc/src'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/Users/anlu/Documents/Doktorarbeit/yambo_Files/yambo_download_nochmal/yambo/stable/lib/libxc'
  make: *** [all] Error 2

Do you have any ideas? Thank you very much for an answer and kind regards,

Andreas

[Daniele Varsano]

Dear Andreas,
it looks a pre-processor problem.
I compiled yambo on a mac, by using gfortran explicitly setting the pre-processor compiler, using these options:

Code: Select all

./configure  --with-iotk=/Users/daniele/codes/espresso-5.0.1/iotk --with-p2y=5.0 CPP=/usr/local/bin/cpp-4.6  FCCPP=/usr/local/bin/cpp-4.6 --with-fftw=/usr/local/lib   --with-fftw-lib=-lfftw3 --with-netcdf-lib=/usr/local/Cellar/netcdf/4.2.1.1/lib  --with-netcdf-include=/usr/local/Cellar/netcdf/4.2.1.1/include --with-netcdf-link='-lnetcdff -lnetcdf -lhdf5hl_fortran -lhdf5_hl -lhdf5_fortran -lhdf5 -lz -L/usr/local/Cellar/curl/7.32.0/lib -lcurl'

Please note the definition of CPP and FCCPP, you can have a try.
My gfortran version is GNU Fortran (GCC) 4.8.2.
You can have a try, of course, discard all the option you are not interested in and remember to do a make clean_all before configuring and compiling.


Hope it helps,
Best,
Daniele

[Andy]

Hello Daniele,

thanks again for your fast reply. Your hint with the pre-processor was correct - when I changed the FCCPP to "FCCPP=/usr/bin/fpp" the compilation went on. Unfortunately I get linker errors when yambo gets linked:

• ....
  (eval mpif90 -nofor-main -arch x86_64 -I /Users/anlu/Documents/Doktorarbeit/yambo_Files/nochmal5/yambo/stable/include -o yambo driver.o getopt.o yambo_driver.o -L/Users/anlu/Documents/Doktorarbeit/yambo_Files/nochmal5/yambo/stable/lib -lbse -lqp -lpol_function -ltddft -linterface -lsetup -lqp_ctl -lbz_ops -lcoulomb -lwf_and_fft -lio -lcommon -lcommunicate -lparser -lxc_functionals -lmodules -lexternal_c -llapack -lblas -L/Users/anlu/Documents/Doktorarbeit/yambo_Files/lib -lnetcdff -L/Users/anlu/Documents/Doktorarbeit/yambo_Files/lib -lnetcdf -lcurl -lz -lxc -lslatec -lm ) > /dev/null
  Undefined symbols for architecture x86_64:
  "_acfdt_mp_acfdt_e_range_", referenced from:
  _std_presets_ in libmodules.a(std_presets.o)
  "_acfdt_mp_acfdt_n_freqs_", referenced from:
  _std_presets_ in libmodules.a(std_presets.o)
  "_acfdt_mp_acfdt_n_lambda_", referenced from:
  _std_presets_ in libmodules.a(std_presets.o)
  "_drivers_mp_finite_tel_", referenced from:
  _qp_driver_ in libqp.a(QP_driver.o)
  _occupations_fermi_ in libcommon.a(OCCUPATIONS_Fermi.o)
  _x_pre_setup_ in libpol_function.a(X_pre_setup.o)
  _functions_mp_bose_f_ in libmodules.a(mod_functions.o)
  _functions_mp_bose_decay_ in libmodules.a(mod_functions.o)
  _functions_mp_e2et_ in libmodules.a(mod_functions.o)
  _functions_mp_h2ht_ in libmodules.a(mod_functions.o)
  .....

I googled e.g. the names "_acfdt_mp_acfdt_e_range_" but was not able to find anything about it. Do you know which library is missing?

Fortunately the cluster's admin was able to repair the cluster so I was able to test your suggestions. I tested it with silicon bulk (2 atoms in unit cell) but I've some understanding questions:

I created the input-File:

Code: Select all

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
BSEmod= "causal"             # [BSE] resonant/causal/coupling
BSKmod= "ALDA"               # [BSE] IP/Hartree/HF/ALDA/SEX
BSSmod= "d"                  # [BSS] (h)aydock/(d)iagonalization/(i)nversion/(t)ddft`
BSENGexx=  5961        RL    # [BSK] Exchange components
% BEnRange
  0.00000 | 10.00000 | eV    # [BSS] Energy range
%
% BDmRange
  0.10000 |  0.10000 | eV    # [BSS] Damping range
%
BEnSteps= 100                # [BSS] Energy steps
% BLongDir
 1.000000 | 0.000000 | 0.000000 |        # [BSS] [cc] Electric Field
%
% BSEBands
   1 | 128 |                 # [BSK] Bands range
%
WRbsWF                      # [BSS] Write to disk excitonic the FWs

My questions:

1) Concerning the option WRbsWF - has the explanation just a spelling mistake and "FWs" means "WFs = WaveFunctions" ?
2) I did a "yambo -o b" calculation some weeks ago but it took very long - very much time is spend in the folder "SAVE" where the code creates files named "ndb.BS_Q1_fragments_1_1", "ndb.BS_Q1_fragments_1_2", "ndb.BS_Q1_fragments_2_2", ... till the number of fragments (=number of k-Points?!) is reached. For the g-space calculations I always reduced

Code: Select all

% QpntsRXd
  1 | 29 |                   # [Xd] Transferred momenta

to

Code: Select all

% QpntsRXd
  1 | 1 |                   # [Xd] Transferred momenta

as I'm only interested in the q->0 limit - the optical absorption. I thought that one can reduce the effort for the BSE calculation by adding

Code: Select all

BSEQptR
1|1|                        # (BSK)

to the input-file but the program is still creating so many fragment files in the SAVE folder. Maybe I'm a little bit fastidious because of the speed of the gspace calculations (which lasted only some seconds) - whereas the "yambo -o b -k alda" calculations take several days - or did I something wrong in the configurations? I have some approaches how to overcome this problem - can you comment on the chance of success:
-The number of reciprocal lattice vectors (5961) is very high - I would reduce it to around 1000 + some convergence tests. Is this comparable to the case where I reduce the energy cutoff in the PWscf calculation?
-I would have a look on the bandstructure and would take only 10 bands below and 10 bands above the fermi level in "BSEBands" into account.
-I reduce the number of k-point sampling in the brillouin zone in the PWscf input file which should reduce the number of fragments.

Are there more ways to reduce the computational effort from several days to some hours?

Thank you very much for an answer and kind regards,

Andreas Luecke

[Andy]

Hello Daniele,

some additional question, because I'm very confused at the moment.

If I use "yambo -o g -k alda", I calculate a TDDFT spectrum with the "Adiabatic Local Density Approximation" for the kernel. If I understand you correctly I cannot identify the contribution of each state here as I work in reciprocal space.

You mentioned that I have to work in the transition space which is activated with the option "yambo -o b" - but is this a TDDFT calculation any longer? I have the impression that I do a BSE calculation here.
Is there a possibility to get the contribution of each state after a TDDFT calculation and not a BSE calculation? If yes - with which options?

On the cluster I've only the version "GPL Version 3.4.1 Revision 3187" but if I write "yambo -o b -k lrc", the lrc option seems to be ignored and replaced by hartree:

• optics # [R OPT] Optics
  bse # [R BSE] Bethe Salpeter Equation.
  tddft # [R K] Use TDDFT kernel
  bsk # [R BSK] Bethe Salpeter Equation kernel
  BSEmod= "causal" # [BSE] resonant/causal/coupling
  BSKmod= "Hartree" # [BSE] IP/Hartree/HF/ALDA/SEX
  BSENGexx= 5961 RL # [BSK] Exchange components
  % BEnRange
  0.00000 | 10.00000 | eV # [BSS] Energy range
  %
  % BDmRange
  0.10000 | 0.10000 | eV # [BSS] Damping range
  %
  BEnSteps= 100 # [BSS] Energy steps
  % BLongDir
  1.000000 | 0.000000 | 0.000000 | # [BSS] [cc] Electric Field
  %
  % BSEBands
  1 | 128 | # [BSK] Bands range

Is this a bug in my older version?

Thanks again very much and kind regards,

Andreas

[Daniele Varsano]

Dear Andreas,

Fortunately the cluster's admin was able to repair the cluster

OK, that's' better, in mac it is not rare to encounter problems.

1) Concerning the option WRbsWF - has the explanation just a spelling mistake and "FWs" means "WFs = WaveFunctions" ?

Yes it is a spelling mistake.

2) IN g-space you can calculate the response for finite q, so you can control the QpntsRXd variable. In transition space only the q-->0 limit is implemented. The Hamiltonian is divided in blocks, this is because you have many fragments.

the speed of the gspace calculations (which lasted only some seconds) - whereas the "yambo -o b -k alda" calculations take several days

Well it depends on what you ask. To have an equivalent calculation in g-space you should consider to set NGsBlkXd= 5961, this would mean to invert a matrix six thousand by six thousand for each energy step (by default 100 times), I doubt that it will be a few seconds calculation. In transition space you diagonalize the excitonic matrix (that could be bigger) just once.

The number of reciprocal lattice vectors (5961) is very high - I would reduce it to around 1000 + some convergence tests. Is this comparable to the case where I reduce the energy cutoff in the PWscf calculation?

Well it is not so high, anyway sure, you can try to reduce it by doing some convergence tests. Usually you need less vectors than the energy cutoff you used for the wfs in the ground state calculations. Please note, that this number (5961) are the G-vectors entering in the coulomb part. For the ALDA kernel you have automatically all the Gvecotrs included as in transition space this part is calculated in real space (while in G-space calculation, this is not true anymore).

I would have a look on the bandstructure and would take only 10 bands below and 10 bands above the fermi level in "BSEBands" into account.

Yes you have a huge number of bands, which means yout can have a very large excitonic matrix (it is called excitonic matrix in BSE, and not in ALDA, but ok, the matrix which the eigenvalues gives you the excitation energies). The dimension of the matrix is Nv x Nc x Nk x Nsym. The number of bands entering in the calculations, as usual is another variable where the convergence has to be checked, it is not a bad idea to start with few bands and adding them progressively until convergence.

I reduce the number of k-point sampling in the brillouin zone in the PWscf input file which should reduce the number of fragments.

K-point is another variable, the convergence has to be tested. As said before, a very large sampling will imply a larger matrix, so large number of elements to be built and time to diagonalize it.

Best,

Daniele

[Daniele Varsano]

Dear Andreas,

some additional question, because I'm very confused at the moment.

Take it easy, to familiarize it takes some time, and we try to help. Having a look to the tutorials may also help.

If I use "yambo -o g -k alda", I calculate a TDDFT spectrum with the "Adiabatic Local Density Approximation" for the kernel. If I understand you correctly I cannot identify the contribution of each state here as I work in reciprocal space.

Correct

You mentioned that I have to work in the transition space which is activated with the option "yambo -o b" - but is this a TDDFT calculation any longer? I have the impression that I do a BSE calculation here.
Is there a possibility to get the contribution of each state after a TDDFT calculation and not a BSE calculation? If yes - with which options?

Careful, yambo -o b means you work in transition space, next you need to define the kernel.
yambo -o b -k alda ---> TDDFT
yambo -o b -k sex ---> Bethe Salpeter

In your input file you have BSKmod= "ALDA" , so it means you are doing TDDFT (ALDA).
Next, once you have diagonalized the matrix you can see the transition by using the ypp utility.

On the cluster I've only the version "GPL Version 3.4.1 Revision 3187" but if I write "yambo -o b -k lrc", the lrc option seems to be ignored and replaced by hartree:

This is because the lrc kernel can be used in G-space only (yambo -o c -k lrc).
By typing yambo -H you can see the warning about the use of the kernels.

Anyway, about your calculations running for one day, if you want, you can post your input/report/standard output, we can have a look if there is something uncommon.

Best,

Daniele

[Andy]

Hi Daniele,
thank you again for clearing my misunderstandings.
I did some tests today and I was also able to reduce the computational effort for a "yambo -o b" calculation to 30 minutes
- by reducing the energy cutoff to 18 Ry in the PWscf calculation
- by reducing the number of RL components from 2733 to 1733 in the yambo.in file
- reducing the number of BSE bands from 50 to 8.
But why is a TDDFT calculation (yambo -o b -k alda) as much time consuming as a BSE calculation (yambo -o b -k sex)?

With this I tried to reproduce some curves I found in the literature. I added you the image in the attachment. On the left handside you see the image I want to reproduce. I didn't focus on the position of the peaks on the energy axis as I didn't wanted to make an extra GW calculation yet.
If I compare my results with the curves on the left handside the general shape is ok but it disturbs me that in the BSE calculation the first peak is only clear visible if I reduce the broadening parameter (compare pink and turquoise curve; all curves except the turquoise one have the same broadening value). But with this reduced broadening I would also get a well visbible peak in the Alda and Hartree calculations which is not the case on the left handside.
Is this a convergence problem or do you suspect other reasons?

Finally there is another behavior which was not expected by me:
If I do a Hartree and a Alda calculation in g-space I get exactly the same results (even for the last digit, I added you the files in the attachment). Is this correct?
My professor said there must be a mistake in my results. I also tried to to set NGsBlkXd to 113 in order to include local field effects but this does not introduce any differences between the Hartree and the Alda result.

Just to be sure - is "Hartree" equivalent to a RPA calculation which means that I set the kernel fxc to zero?

Thanks again for your patience and kind regards,

Andreas

[Daniele Varsano]

Dear Andreas,
I had a look to your outputs:

But why is a TDDFT calculation (yambo -o b -k alda) as much time consuming as a BSE calculation (yambo -o b -k sex)?

Here you are not doing two equivalen calculations, in your output I can see that you set:

Code: Select all

# | FxcGRLc= 1             RL    # [TDDFT] XC-kernel RL size
# | NGsBlkXd= 1 

Essentially you are using independent particle approximation, and this explain why your "Hartree" and "ALDA" are the same. You can
also compare with the 4th and 5th column which gives the IP approximations, and they are the same.
In transition space you are including local filelds (via exchange g vectors) and all the G's for the building of the ALDA kernel.
If you set the NGsBlkXd to the same values you set the EXXGvec in the transition space you will realize than in G space is even more time consuming.

Just to be sure - is "Hartree" equivalent to a RPA calculation which means that I set the kernel fxc to zero?

Yes, Hartree is equivalent to RPA, even if in literature you can find RPA for a calculation including or neglecting local filed effects.
In the picture on the left (that should come from the review of Onida, Rening and Rubio) I'm almost sure that LF are included.
I would not expect much differences for ALDA and RPA, but they should not be the same (you can compare the 2nd and 4th column in your calculation in transition space). They could be the same if you rise NGsBlkXd but leave FxcGRLc=1, in this case you are considering local filed effects (both in Hartree and ALDA Run), but you are not including the ALDA kernel essentially. In any case, for the ALDA I always suggest to calculate it in transition space for several reasons: it is faster, you include all the Gvec of the density, and as it is calculated in real space you eliminate noise that could come from the region of low density that are present when calcualted in G-space.

Best,
Daniele