Error in routine ktokpmq (1): k+q does not fall on k-grid

[eliephys78]

Dear All,

I am performing some elph calculations using EPW. However while running the epw1.in input file (to calculate the elph matrices), the code calculates everything but then stops with an error:

Use zone-centred Wigner-Seitz cells
Number of WS vectors for electrons 2353
Number of WS vectors for phonons 157
Number of WS vectors for electron-phonon 157
Maximum number of cores for efficient parallelization 1413
Results may improve by using use_ws == .TRUE.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Error in routine ktokpmq (1):
k+q does not fall on k-grid

However running another system with the same q, k qf and kf grids, proceeds normally without giving this error.

I also remember running the same systems on an old version of EPW (compatiblw with QE-6.3) without getting this error.
I cannot find why the code stops for this particular system.

Regards
Elie Moujaes
Federal university of Rondonia
Brazil

[hlee]

Dear eliephys78:

I assume that you are using the same number of cores as that of k pools.

Could you provide nscf and epw inputs which generated this error? Also it helps much to provide the full EPW output.
Lastly, I need to know which version of EPW you are using (the official version of EPW or the development version at gitlab).

Sincerely,

H. Lee

[eliephys78]

Dear H. Lee,

Thank you for your response. The version of EPW I am using is the one that comes with teh QE-6.5 package. I did not download it separately.
1- my PBS script file looks like:

#PBS -S /bin/bash
#PBS -l select=8:ncpus=16:mpiprocs=16:ompthreads=1:mem=50gb
#PBS -N system
##PBS -l place=free:exclhost
#PBS -q fat_1m
module load composer_xe/2017.2.174 impi/5.1.1.109
cd $PBS_O_WORKDIR

mpirun ~/qe-6.5/bin/pw.x -npools $(wc -l < $PBS_NODEFILE) < scfrel.in > scfrel.out
mpirun ~/qe-6.5/bin/pw.x -npools $(wc -l < $PBS_NODEFILE) < nscfrel.in > nscf.out
mpirun ~/qe-6.5/EPW/bin/epw.x -npools $(wc -l < $PBS_NODEFILE) < epw1.in > epw1.out

2- My nscf input is: using a 48x48x1 grid =2304 points with the option nosym switched on).

&control
prefix=''
calculation='nscf',
restart_mode='from_scratch',
tstress=.true.,
tprnfor=.true.,
pseudo_dir = '/fefs1/physics/eamoujaes.....',
wf_collect=.true.,
outdir='/fefs1/physics/eamoujaes/....',

etot_conv_thr=1.0D-5
forc_conv_thr=5.0D-4


/
&system
ibrav= 4,celldm(1)=7.05516,celldm(3)=6.3, nat=3, ntyp= 3, ecutwfc =70, vdw_corr='DFT-D',occupations='fixed',nbnd=40, nosym=.true.


/
&electrons
electron_maxstep=750
conv_thr=1.D-8,
mixing_beta=0.2D0,
mixing_mode='plain',
diago_david_ndim=2,

/
&ions
ion_dynamics ='bfgs'
/
&cell
cell_dynamics='bfgs'
press=0.0
/

ATOMIC_SPECIES
.
.
.

ATOMIC_POSITIONS (angstrom)
.
.

K_POINTS crystal
2304
0.00000000 0.00000000 0.00000000 4.340278e-04
0.00000000 0.02083333 0.00000000 4.340278e-04
0.00000000 0.04166667 0.00000000 4.340278e-04
0.00000000 0.06250000 0.00000000 4.340278e-04
0.00000000 0.08333333 0.00000000 4.340278e-04
0.00000000 0.10416667 0.00000000 4.340278e-04
0.00000000 0.12500000 0.00000000 4.340278e-04
0.00000000 0.14583333 0.00000000 4.340278e-04
0.00000000 0.16666667 0.00000000 4.340278e-04
0.00000000 0.18750000 0.00000000 4.340278e-04

3- Finally my epw input is: (with the 74 points at the end being the ones calculated for the phonon grid, with their 'dyn' filees found in the phonons folder.

--
&inputepw
prefix ='pdste',
amass(1) = ...
amass(2)= ...
amass(2)= ...
outdir ='/fefs1/physics/eamoujaes/EPW/epw/OUT/'
dvscf_dir ='/fefs1/physics/eamoujaes/EPW/phonons/save'

elph = .true.
kmaps = .false.
epbwrite = .true.
epbread = .false.
epwwrite = .true.
epwread = .false.

wannierize=.true.
nbndsub=14
num_iter=500
nbndskip=26
!dis_froz_min = -10.0d0
!dis_froz_max = 0.0d0
proj(1)='random'
proj(2)='..'
proj(3)='...'
proj(4)='...'
system_2d=.true.

lpolar=.true.


efermi_read=.true.
fermi_energy=-1.8502

etf_mem=2

wdata(1) ='search_shells=35'
wdata(2) ='bands_plot =.true.'
wdata(3)='exclude_bands:1,2,17-40'
wdata(4)='begin kpoint_path'
wdata(5)='G 0.000000 0.000000 0.000000 K 0.3333333 0.3333333 0.0000000'
wdata(6)='K 0.3333333 0.3333333 0.000000 M 0.5000000 0.0000000 0.0000000'
wdata(7)='M 0.5000000 0.0000000 0.000000 G 0.000000 0.000000 0.0000000'
wdata(8)='end kpoint_path'

elecselfen = .false.
phonselfen = .false.
a2f = .false.

!parallel_k = .true.
!parallel_q = .false.

fsthick = 7 ! eV
eptemp = 300 ! K
degaussw = 0.005 ! eV

iverbosity=0

nkf1 =48
nkf2 = 48
nkf3 = 1

nqf1 = 12
nqf2 = 12
nqf3 = 1

nk1 = 48
nk2 = 48
nk3 = 1

nq1 = 12
nq2 = 12
nq3 = 1

/

74 cartesian

0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00
0.000000000000000E+00 0.962250448649308E-01 0.000000000000000E+00
0.000000000000000E+00 0.192450089729862E+00 0.000000000000000E+00
0.000000000000000E+00 0.288675134594792E+00 0.000000000000000E+00
0.000000000000000E+00 0.384900179459723E+00 0.000000000000000E+00
0.000000000000000E+00 0.481125224324654E+00 0.000000000000000E+00
0.000000000000000E+00 -0.577350269189585E+00 0.000000000000000E+00
0.833333333333333E-01 0.481125224324654E-01 0.000000000000000E+00
.
.
.

As I said in my first email, I used the same PBS files for a different system (with same number of phonon points (74) with same coarse and fine grids
but with different atomic species), and the calculations ended normally without any error.

Regards

[hlee]

Dear eliephys78:

Given information you provided, it is difficult to reproduce your error.

Could you confirm that you are using the same number of pools as that of cpus?
Also did you try to remove "nosym=.true.' in nscf.in?
If you didn't add "nosym=.true.", is the total number of k points in nscf calculation different from 2304?

It seems that your k+q grid is not commensurate with k grid and this means that something weird happens in k+q grid. I am not sure, but it might be related to the 2D system (or system_2d flag).

As I said in my first email, I used the same PBS files for a different system (with same number of phonon points (74) with same coarse and fine grids
but with different atomic species), and the calculations ended normally without any error.

Do two systems have the same symmetry and q-point coordinates (not the number of q points)?

Added after my first post
The best way to know what's going on is to insert some codes which print out the relevant information in the subroutine of ktokpmq in kfold.f90 .
For example, the error occurs in the following part:

Code: Select all

    !
    ! now add the phonon wavevector and check that k+q falls again on the k grid
    !
    xxk = xxk + DBLE(sign) * xxq
    !
    xx = xxk(1) * nkc1
    yy = xxk(2) * nkc2
    zz = xxk(3) * nkc3
    in_the_list = ABS(xx - NINT(xx)) <= eps5 .AND. &
                  ABS(yy - NINT(yy)) <= eps5 .AND. &
                  ABS(zz - NINT(zz)) <= eps5
    IF (.NOT. in_the_list) CALL errore('ktokpmq', 'k+q does not fall on k-grid', 1)

Sincerely,

H. Lee

[hlee]

Dear eliephys78:

Another suggestion and question are:
1.
Could you try to include vme=.false. in your epw input?

2.
Did you download QE v6.5 at this site (https://gitlab.com/QEF/q-e/-/releases)? I am asking you whether you are using the office EPW v5.2 included in the official QE v6.5.

3. I want to look at the header of epw.out including the following informtion:

Code: Select all

     Parallel version (MPI), running on    24 processors

     MPI processes distributed on     1 nodes
     K-points division:     npool     =      24
     Fft bands division:     nmany     =       1

Additionally, if you didn't read my previous post, please read it carefully and answer to my question.

Sincerely,

H. Lee

[eliephys78]

Dear H. Lee,

Once again thank you very much for your effort to help me discover where the error is. Answering your questions:

1- the q-points are exactly the same in both systems.
2- nosym=.true. is set the same in both systems. I usually set it to true so that exactly 2304 points are produced.
3- the number of pools is equal to the number of processors: Here is the head of the epw1.out (for both systems).

Parallel version (MPI & OpenMP), running on 128 processor cores
Number of MPI processes: 128
Threads/MPI process: 1
MPI processes distributed on 8 nodes
K-points division: npool = 128

4- As far as I remember, I have donwloaded the new version from : https://github.com/QEF/q-e/releases
5- I have not tried to set vme=.false. I am running the same input again with this option.
6- the error could not be due to the system_2d=.true. since this flag is switched on in both systems. One of them has worked perfectly fine (It even started to calculate lambda).
7- The weird thing is that the code outputs decay.H but stops before outputting the decay.dynmat and the epwane files which is another clue that the error is indeed in the 'phonon' grid and this is why I think the error has nothing to do with the vme flag.
8- I have checked the inputs of both systems: they are exactly the same (same q points, same fine grids, same coarse grids, same other flags). I just can't see why one should work and the other does not.
9- In the input files I have sent in my previous email , the only thing I have omitted are the atomic species and names of the output directories.

I hope I have answered all the questions.

[hlee]

Dear eliephys78:

Thank you for your reply.
Personally, I am very interested in your issue since I realized that there are many issues in EPW related to 2D systems. Unfortunately, I don't have any real example so that I can reproduce errors.

7- The weird thing is that the code outputs decay.H but stops before outputting the decay.dynmat and the epwane files which is another clue that the error is indeed in the 'phonon' grid and this is why I think the error has nothing to do with the vme flag.

decay.H is calculated in the subroutine of hambloch2wan and decay.dynmat is calculated in the subroutine of dynbloch2wan.
These subroutines are called in the subroutine of ephwann_shuffle_mem.f90 (you use etf_mem=2) in the following order:

hambloch2wan -> vmebloch2wan (currently, vme=T in your case) -> dynbloch2wan

I guess that the problem occurs in the intermediate step between hambloch2wan and dynbloch2wan, that is, vmebloch2wan; this is proven by your error message since the subroutine of ktokpmq is called in the subroutine of vmebloch2wan .

2- nosym=.true. is set the same in both systems. I usually set it to true so that exactly 2304 points are produced.

I don't like the solution using nosym=T; it just complicates the situations in EPW.
Did you use nosym=T because without nosym=T pw.x increases the number of k points you specified in nscf.in?
If not so, you should remove nosym=T.
If so, you had better try to use calculations='bands' without nosym=T.

1- the q-points are exactly the same in both systems.

8- I have checked the inputs of both systems: they are exactly the same (same q points, same fine grids, same coarse grids, same other flags). I just can't see why one should work and the other does not.

Very strange if the q-point coordinates in the Cartesian (2pi/a) unit are exactly the same. This means that two systems have the exactly same symmetry. I suspected that this issue might be due to the symmetry of 2D system.

Sincerely,

H. Lee

[eliephys78]

Dear H. Lee,

Thanks for your suggestions. Meanwhile the calculations are running with vme=.false. I will check if the calculations survive beyond the 'decay.H' output. If not, I will see how I can resolve it and let you know.

Regards

[eliephys78]

Dear H.Lee,

Setting vme=.false. in the epw1.in and in subsequent input files solved the problem.

Thanks once again for your help.

Regards

[hlee]

Dear eliephys78:

I don't think that your issue is solved; vme=F just skips the part resulting in the error by calculating the dipole matrix elements instead of the velocity matrix elements.

Could you provide all contents of *.bvec file (this file was generated when you use vme=T)?

Sincerely,

H. Lee