possible bug with icutcoul=2
Moderators: maryam.azizi, bruneval
possible bug with icutcoul=2
Hello-
When using icutcoul=2, the screening calculation fails with the error message:
"
Found q-points with non-zero component along non-periodic direction
This is not allowed, see Notes in cutoff_surface.F90
ACTION : Modify the q-point sampling "
The q-ponits chosen are fine. However, the error is originating when doing the optical limit with
q=(1e-5,2e-5,3e-5).
The "SMALL" parameter in cuoff_surface.F90 was set to tol6. Perhaps it should be set to a larger value as in cutoff_cylinder.F90 where it is set to GW_TOLQ0.
Thanks.
Wissam
Univ. of Pitt.
When using icutcoul=2, the screening calculation fails with the error message:
"
Found q-points with non-zero component along non-periodic direction
This is not allowed, see Notes in cutoff_surface.F90
ACTION : Modify the q-point sampling "
The q-ponits chosen are fine. However, the error is originating when doing the optical limit with
q=(1e-5,2e-5,3e-5).
The "SMALL" parameter in cuoff_surface.F90 was set to tol6. Perhaps it should be set to a larger value as in cutoff_cylinder.F90 where it is set to GW_TOLQ0.
Thanks.
Wissam
Univ. of Pitt.
Re: possible bug with icutcoul=2
Hello again,
I wonder if the icutcoul=2 option is working. Testing it gave a NaN while the standard method (without the cutoff) seemed okay. I tested the icutcoul=1 option on a 1D system and this seemed to work fine and agree with the standard method without the cutoff. I am using abinit 6.0.3.
Thanks.
Wissam
I wonder if the icutcoul=2 option is working. Testing it gave a NaN while the standard method (without the cutoff) seemed okay. I tested the icutcoul=1 option on a 1D system and this seemed to work fine and agree with the standard method without the cutoff. I am using abinit 6.0.3.
Thanks.
Wissam
Re: possible bug with icutcoul=2
The q-ponits chosen are fine. However, the error is originating when doing the optical limit with
q=(1e-5,2e-5,3e-5).
The "SMALL" parameter in cuoff_surface.F90 was set to tol6. Perhaps it should be set to a larger value as in cutoff_cylinder.F90 where it is set to GW_TOLQ0.
A better solution would be redefining GW_Q0_DEFAULT in 49_gw_toolbox_oop/m_gw_defs
such that the component along the non-periodic dimension is zero.
M
Re: possible bug with icutcoul=2
alsaidi wrote:Hello again,
I wonder if the icutcoul=2 option is working. Testing it gave a NaN while the standard method (without the cutoff) seemed okay. I tested the icutcoul=1 option on a 1D system and this seemed to work fine and agree with the standard method without the cutoff. I am using abinit 6.0.3.
Thanks.
Wissam
Could you provide an input file that can be run to reproduce the error?
M
Re: possible bug with icutcoul=2
Hello -
The reason I was getting the NaN is that I did not define rcut in the input file.
The cutoff for icutcoul=2 should be half the lattice constant in the z-direction by default but it is not set in this case and the user has to set it up.
But looking at the code (m_coulombian.F90 file) I saw that the small q-->0 limit of the Couloumb potential is not defined for the surface cutoff and thought that the code is still under development for surface calculations. I wonder if this is not the case? Is the code functional in this case?
Thanks.
Wissam
The reason I was getting the NaN is that I did not define rcut in the input file.
The cutoff for icutcoul=2 should be half the lattice constant in the z-direction by default but it is not set in this case and the user has to set it up.
But looking at the code (m_coulombian.F90 file) I saw that the small q-->0 limit of the Couloumb potential is not defined for the surface cutoff and thought that the code is still under development for surface calculations. I wonder if this is not the case? Is the code functional in this case?
Thanks.
Wissam
-
- Posts: 75
- Joined: Thu Dec 02, 2010 10:36 pm
Re: possible bug with icutcoul=2
I'v got the same Error in Sigma calculation when treating hexagonal graphene surface:
The q-point mesh is as follows:
the input file provides
icutcoul4 2
vcutgeo4 1 1 0
Could you please point me out what is wrong?
My full input file:
Many-many thx in any kind of help.
Code: Select all
--- !ERROR
message: |
Found q-points with non-zero component along non-periodic direction
This is not allowed, see Notes in cutoff_surface.F90
ACTION : Modify the q-point sampling
src_file: m_vcoul.F90
The q-point mesh is as follows:
Code: Select all
==== Q-mesh for screening function ====
Number of points in the irreducible wedge : 10
Reduced coordinates and weights :
1) 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.01563
2) 1.25000000E-01 0.00000000E+00 0.00000000E+00 0.09375
3) 2.50000000E-01 0.00000000E+00 0.00000000E+00 0.09375
4) 3.75000000E-01 0.00000000E+00 0.00000000E+00 0.09375
5) 5.00000000E-01 0.00000000E+00 0.00000000E+00 0.04688
6) 1.25000000E-01 1.25000000E-01 0.00000000E+00 0.09375
7) 2.50000000E-01 1.25000000E-01 0.00000000E+00 0.18750
8) 3.75000000E-01 1.25000000E-01 0.00000000E+00 0.18750
9) 2.50000000E-01 2.50000000E-01 0.00000000E+00 0.09375
10) 3.75000000E-01 2.50000000E-01 0.00000000E+00 0.09375
the input file provides
icutcoul4 2
vcutgeo4 1 1 0
Could you please point me out what is wrong?
My full input file:
Code: Select all
occopt 7 tsmear 0.005
ndtset 4
# DATASET 1 : GS calculation
tolwfr1 1d-14
nband1 8 # Adding 4 empty states to avoid problems in the SCF cycle.
# DATASET 2 : KSS generation
iscf2 -2
getden2 -1
tolwfr2 1d-8
kssform2 3
nband2 84
nbdbuf2 10
nbandkss2 72
# DATASET3 Computing the screening
optdriver3 3 # Screening run
getkss3 2
symchi3 1
ecutwfn3 10
ecuteps3 5
nband3 72
inclvkb3 0
gwcalctyp3 2
spmeth3 1
nomegasf3 100
gwpara3 2
awtr3 1
freqremax3 40 eV
nfreqre3 20
nfreqim3 5
# DATASET 4 : Sigma calculation
#
optdriver4 4 # Sigma run.
irdkss4 2
irdscr4 3
gwcalctyp4 2
gwpara4 2
symsigma4 1
ecutwfn4 10
ecuteps4 5
ecutsigx4 10
nband4 72
icutcoul4 2
vcutgeo4 1 1 0
nkptgw 10
kptgw
0.00000000E+00 0.00000000E+00 0.00000000E+00
1.25000000E-01 0.00000000E+00 0.00000000E+00
2.50000000E-01 0.00000000E+00 0.00000000E+00
3.75000000E-01 0.00000000E+00 0.00000000E+00
5.00000000E-01 0.00000000E+00 0.00000000E+00
1.25000000E-01 1.25000000E-01 0.00000000E+00
2.50000000E-01 1.25000000E-01 0.00000000E+00
3.75000000E-01 1.25000000E-01 0.00000000E+00
2.50000000E-01 2.50000000E-01 0.00000000E+00
3.75000000E-01 2.50000000E-01 0.00000000E+00
bdgw
1 9
1 9
1 9
1 9
1 9
1 9
1 9
1 9
1 9
1 9
# Definition of the k-point grid
kptopt 1
nshiftk 1
shiftk 0. 0. 0.
ngkpt 8 8 1
istwfk *1
# Structural parameters
acell 4.6273865954E+00 4.6273865954E+00 4.5117809063E+01 Bohr
rprim 1.0000000000E+00 0.0000000000E+00 0.0000000000E+00
-5.0000000000E-01 8.6602540378E-01 0.0000000000E+00
0.0000000000E+00 0.0000000000E+00 1.0000000000E+00
natom 2
ntypat 1
typat 1 1
znucl 6
xred 0.3333333333333333 0.6666666666666665 0.0000000000000000
0.6666666666666667 0.3333333333333333 0.0000000000000000
Many-many thx in any kind of help.
Re: possible bug with icutcoul=2
Dear roginovicci,
The Coulomb cutoff for surfaces is still under development.
The treatment of the q->0 limit will be available in the forthcoming release version.
Anyway, if you want to use it (no garantee about the results) in the present version, you will need to set qpoints for the long wavelength limit in the graphene plane, that is set "gw_qlwl" to a value inside the plane.
see http://www.abinit.org/doc/helpfiles/for ... ml#gw_qlwl for more information.
Yannick
The Coulomb cutoff for surfaces is still under development.
The treatment of the q->0 limit will be available in the forthcoming release version.
Anyway, if you want to use it (no garantee about the results) in the present version, you will need to set qpoints for the long wavelength limit in the graphene plane, that is set "gw_qlwl" to a value inside the plane.
see http://www.abinit.org/doc/helpfiles/for ... ml#gw_qlwl for more information.
Yannick
-
- Posts: 75
- Joined: Thu Dec 02, 2010 10:36 pm
Re: possible bug with icutcoul=2
Dear Yannick!
Thank you for the info, I'll check it out in a while. But, we still have a possibility to use a spheric Coulomb cut-off icutcoul=0 and rcut=a/2 (a is a lattice constant) in rhombohedral lattices. Why it is not possible to use icutcoul=0 with hex lattice? Sorry for (probably) stupid question.
The error with icutcoul=0 with hex-lattice:
Thank you for the info, I'll check it out in a while. But, we still have a possibility to use a spheric Coulomb cut-off icutcoul=0 and rcut=a/2 (a is a lattice constant) in rhombohedral lattices. Why it is not possible to use icutcoul=0 with hex lattice? Sorry for (probably) stupid question.
The error with icutcoul=0 with hex-lattice:
--- !ERROR
message: |
The G-vector with ig: 18 falls outside the FFT box.
Re: possible bug with icutcoul=2
The error with icutcoul=0 is not due to an impossibility to do it.
It is related to an error with the setup of the mesh and the FFT box.
Could you try to play a bit with ecuteps/ecutsigx parameters depending whether you are in the screening or sigma part ?
Yannick
It is related to an error with the setup of the mesh and the FFT box.
Could you try to play a bit with ecuteps/ecutsigx parameters depending whether you are in the screening or sigma part ?
Yannick
-
- Posts: 75
- Joined: Thu Dec 02, 2010 10:36 pm
Re: possible bug with icutcoul=2
All my hugs for your suggestion Yannick!
But while changing ecuteps/ecutsigx parameters do influence on contour deformation method (gwcalctyp = 2) it fails with Hartree-Fock calculation (gwcalctyp = 5).
I've found doubled FFT grid (fftgw =31) do cover all g-points, and that is probably the solution for Hartree-Fock calculations.
Thank you.
But while changing ecuteps/ecutsigx parameters do influence on contour deformation method (gwcalctyp = 2) it fails with Hartree-Fock calculation (gwcalctyp = 5).
I've found doubled FFT grid (fftgw =31) do cover all g-points, and that is probably the solution for Hartree-Fock calculations.
Thank you.