Questions about the results of TDRPA + truncated coulomb potential

[Daniele Varsano]

Dear Niranji,

can you please provide a "light" input file running in few minutes that reproduce the problem? E.g. small cutoff energy, k points grid etc...
Please note, I'm not able to run your input as "DFT+Hubbard input syntax has changed since v7.1". I also suggest you use a more recent version of QE.

Best,
Daniele

[nthiliniek]

can you please provide a "light" input file running in few minutes that reproduce the problem? E.g. small cutoff energy, k points grid etc...
Please note, I'm not able to run your input as "DFT+Hubbard input syntax has changed since v7.1". I also suggest you use a more recent version of QE.

Hi Daniele,
Here I attached a light input file for the calculation and it is compatible with the new version of QE.

Thanks in advance!

input.rar

Niranji

[Daniele Varsano]

Dear Niranji,
I was not able to reproduce your problem. I ran your inputs on 16 cpus (with slightly reduced parameters: 45 Ry in ecut, and response function just for 10 frequencies) and I did not get anything strange.

There are slight differences between mine and your calculations in the rim section, as in the report you sent days before it seems that the coulomb integrals are done on the bare potential and not on the slab potential. Anyway, the coulomb integrals are not used in the RPA calculation, so this is not the source of your problem.

Actually, I would say that there could be a problem of miscompilation and I suggest you the following:
1) Try to repeat the calculation from scratch (actually you can reduce the number of frequencies just to see if the problem persists), compile the 5.2 yambo release from scratch, so after a make distclean, (probably you will need to edit the p2y subroutine to avoid the stop on DFT+U). When repeating the calculation
use a parallelization on bands only, something like (this is for 16 cpu):

Code: Select all

DIP_CPU= "1 2 8"                      # [PARALLEL] CPUs for each role
DIP_ROLEs= "k c v"                    # [PARALLEL] CPUs roles (k,c,v)
X_CPU= "1 1 1 2 8"                        # [PARALLEL] CPUs for each role
X_ROLEs= "q g k c v"                      # [PARALLEL] CPUs roles (q,g,k,c,v)

2) If the problem persists, recompile the code (after a make clean) by reconfiguring yambo using the --enable-int-linalg option.
3) If the problem still persists, send here your config.log file and we will check if there is something odd in the compilation.

Best,
Daniele

[nthiliniek]

Hi Daniele,
Thanks for the reply,
What do you mean by the number of frequencies in the response function?

1) Try to repeat the calculation from scratch (actually you can reduce the number of frequencies just to see if the problem persists),

Thanks
Niranji

[Daniele Varsano]

Dear Niranji,

I mean the number of frequency step "ETStpsXd", as you have zero in all the range, if the problem persists it is independent on the number of frequencies: if you reduce that value you save computational time, as the calculation scales linearly wrt that variable.

Best,
Daniele

[nthiliniek]

Hi Daniele,

3) If the problem still persists, send here your config.log file and we will check if there is something odd in the compilation.

I asked the admin to install the 5.2.0 version. But When I tried to run RPA calculation, it give me an error like this:
[ERROR] STOP signal received while in[06] Dipoles

[ERROR] Writing File ./src//ndb.dipoles; Variable NOT DEFINED; NetCDF: Parallel operation on file opened for non-parallel access

Here, I also attached the config.log file and the RPA input file

r-src_rim_cut_optics_dipoles_kernel_chi.txt

config.log

.

Thanks
Niranji

[Daniele Varsano]

Dear Niranji,

it seems that there are some problems in the compilation. You can try to not indicate netcdf/hdf5 path in the configure and let Yambo compile them and see if this solves the problem.

Best,
Daniele