msg-byu / kgridgen Goto Github PK
View Code? Open in Web Editor NEWGenerator for Generalized Regular k-point grids
Generator for Generalized Regular k-point grids
I encountered the following error when reducing k-points with generateIrredKpointList
:
ERROR: (symmetryReduceKpointList in generateKpoints.f90)
The length of an orbit did not divide the group size
Group size: 4 Orbit length: 3
Here are the parameters in generateIrredKpointList
before being passed to symmetryReduceKpointList
:
A
1.0000000000000000 1.0000000000000000 1.0000000000000000
1.2247448700000001 -1.2247448700000001 -1.0000000000000000
-0.16598509000000000 -1.6430829700000000 1.8090680600000000
Atom labels: 0
AtBas
0.0000000000000000 0.0000000000000000 0.0000000000000000
K
0.47497680660440167 0.25229592053480804 0.27272727286079029
0.21246520990660386 -0.12155611919778875 -9.0909090708815130E-002
-0.10629664241000890 6.0144154125115687E-002 4.6152488284893219E-002
R
0.47497680660440217 0.25229592053480782 0.27272727286079013
0.42493041981320634 -0.24311223839557669 -0.18181818141762968
-2.7664181297411120E-002 -0.27384716467239190 0.30151134596980300
We made changes to the routine that maps points into the first Brillouin zone and we wanted to have a place where we could record our thoughts for future reference and just in case our changes break something.
The following is taken from Gus's notes and describes how the routine originally was implemented.
For efficiency's sake, first do a Minkowski reduction on the reciprocal vectors (R) to get the most compact cell possible. This will limit the search over possible translations to the smallest set possible. For each k-point, check each equivalent translation and select the one that is closest to the origin. By definition, the closest point is the translationally equivalent "brother" that is in the first Brillioun zone.
We removed the search over translationally equivalent k-points by mapping the k-points into the first unit cell of the Minkowski basis. Instead of searching for translationally equivalent k-points within a sphere, the search is restricted to the eight unit cells that have a vertex at the origin. The Minkowski basis assures that we don't run into problems like the one shown in the picture below where there are points closer to the origin than those that lie within the eight unit cells that have a vertex at the origin (four unit cells in 2D).
The python wrapper is giving the following error:
f90wrap_kpointgeneration.f90:31:31:
31 | reps_=reps_, aeps_=aeps)
| 1
Error: Symbol ‘aeps’ at (1) has no IMPLICIT type; did you mean ‘aeps_’?
Changing line 31 in wrap/f90wrap_kpointgeneration.f90 from "aeps_=aeps" to "aeps_=aeps_" to match with src/kpointgeneration.f90 should fix it.
Would be nice to add some utilities:
...
This error happens for the POSCAR below. The structure was generated by MLIP (during a relaxation?). Something is amiss because the input lattice vectors are not linearly dependent---mathematica says that the triple product (volume) of these (i.e., the determinant) is ~140 cubic angstroms.
1
1.51776 1.51776 -1.51776
7.58878 1.51776 7.58878
1.51776 -4.55327 -1.51776
2 2 6
cart
0 0 0
3.03551 -0 0
4.55327 -1.51776 1.51776
1.51776 -1.51776 -1.51776
6.07102 -3.03551 3.03551
7.58878 1.51776 4.55327
3.03551 -3.03551 0
4.55327 1.51776 1.51776
6.07102 -0 3.03551
7.58878 -1.51776 4.55327
For HNF of [[1, 0, 0], [2, 3, 0], [4, 5, 6]], reciprocal lattice vectors of [[-1, 1, -1], [1, -1, -1], [-1, -1, 1]], and shift of [0, 0, 0], the code gives the incorrect weights for each orbit.
In generateKpoints.f90
the subroutine generateFullKpointList
uses the following to check that "The point generating vectors and the reciprocal lattice are incommensurate.":
if (any(matmul(Kinv,R) - nint(matmul(Kinv,R)) > eps)) then
in the subroutine symmetryReduceKpointList
The following check is run instead:
if (.not. equal(matmul(InvK,R), nint(matmul(InvK,R)), eps)) then
These two look equivalent on the surface but for some reason they aren't. I've just built a grid that passes the check in generateFullKpointList
but not the one in symmetryReduceKpointList
. The grid in question has a reciprocal lattice of:
1 0 0
0 0.5 -0.5
0 0.5 0.5
and the point generating vectors are:
1 0 0
0 0.5 -0.5
-0.5 -0.249953 0.250047
it was generated from an HNF of:
1 0 0
0 1 0
5324 5324 10648
I suggest that the first equality check be used since it's correctly recognizing that the grid and the cell are commensurate.
When the lattice vectors have a negative determinate the function generateFullKpointsList in generatekpoints.f90 gives an error that the unit cell has a larger volume than the reciprocal lattice.
If I give the code three different sets of k-grid generating vectors that all define the same k-point grid, or lattice, then at present the code returns 3 different numbers of irreducible k-points. This should not happen!
A driver with three different sets of vectors that demonstrates this phenomenon for a grid of 168 points follows:
PROGRAM kpoint_driver
use kpointGeneration
use num_types
use vector_matrix_utilities
use symmetry, only : get_lattice_pointGroup
use rational_mathematics, only: HermiteNormalForm
implicit none
real(dp) :: K(3,3), R(3,3), Hinv(3,3), eps, shift(3), H(3,3)
real(dp), pointer :: klist(:,:)
real(dp), pointer :: pgOps(:,:,:), rdKlist(:,:)
integer, pointer :: weights(:)
real(dp), pointer :: atbase(:,:)
integer :: at(8)
integer i
real(dp) :: lat(3,3), lat_inv(3,3)
logical :: err
allocate(atbase(3,8))
shift = (/ 0.0_dp, 0.0_dp, 0.0_dp /)
lat(:,1) = (/0.5_dp, 0.5_dp, 0.0_dp/)
lat(:,2) = (/0.5_dp, -0.5_dp, 2.0_dp/)
lat(:,3) = (/1.0_dp, -1.0_dp, 0.0_dp/)
at = (/0, 0, 0, 1, 1, 1, 1, 1/)
atbase(:,1) = (/0.0_dp,0.0_dp,0.0_dp/)
atbase(:,2) = (/0.5_dp, 0.25_dp, 0.125_dp/)
atbase(:,3) = (/0.5_dp, 0.75_dp, 0.375_dp/)
atbase(:,4) = (/0.0_dp, 0.5_dp, 0.25_dp/)
atbase(:,5) = (/0.0_dp, 0.0_dp, 0.5_dp/)
atbase(:,6) = (/0.5_dp, 0.25_dp, 0.625_dp/)
atbase(:,7) = (/0.0_dp, 0.5_dp, 0.75_dp/)
atbase(:,8) = (/0.5_dp, 0.75_dp, 0.875_dp/)
call matrix_inverse(lat, lat_inv, err)
R = transpose(lat_inv)
! All of the following grids define the same lattice but return a
! different number of k-points.
! !Mueller: returns 48 k-points
! K(:,1) = (/-0.0714285714_dp, -0.0714285714_dp, 0.125000000_dp/)
! K(:,2) = (/ 0.0119047619_dp, -0.154761905_dp, 0.0_dp/)
! K(:,3) = (/0.154761905_dp, -0.0119047619_dp, 0.0_dp/)
! ! US: returns 52 k-points
K(:,1) = (/0.14285714_dp, 0.14285714_dp, 0.0_dp/)
K(:,2) = (/-0.25_dp, 0.25_dp, 0.125_dp/)
K(:,3) = (/0.01190476_dp, -0.1547619_dp , 0.0_dp/)
! ! HNF version: returns 44 k-points (I believe this is the correct answer).
! K(:,1) = (/0.14285714_dp, 0.14285714_dp, 0.0_dp/)
! K(:,2) = (/-0.07142857_dp, -0.07142857_dp, 0.125_dp/)
! K(:,3) = (/0.08333333_dp, -0.08333333_dp, -0.125_dp/)
eps = 1e-3_dp
call generateFullKpointList(K, R, shift, klist, eps)
call generateIrredKpointList(lat, atbase, at, K, R, shift, rdKlist, weights, eps)
print *, "found this many k-points", size(klist,1)
print *, "found this many irreducible k-points", size(rdKlist,1)
END PROGRAM kpoint_driver
idx = findKptIndex(roKpt, InvK, L, D)
! Reshift the k-point before finding its index
roKpt = roKpt + shift
! write(*,'("shKpt: ",3(f6.3,1x),i3)') roKpt
! idx = findKptIndex(roKpt, InvK, L, D)
! write(*,'("Op#",1x,i2,5x,"rkpt: ",3(f6.3,1x),5x,"idx: ",i4)') iOp,roKpt,idx
! Is this a new addition to the orbit?
if (hashTable(idx)==0) then
! write(*,'(/,"Operator:",i3)') iOp
! write(*,'(3(1x,f7.3))') (SymOps(i,:,iOp),i=1,3)
! write(*,'("roKpt: ",3(f6.3,1x),i3)') roKpt
! write(*,'("Op#",1x,i2,5x,"rkpt: ",3(f6.3,1x),5x,"idx: ",i4)') iOp,roKpt,idx
! print *,"point added"
hashTable(idx) = cOrbit
! if so increase the number of members of this orbit by 1
iWt(cOrbit)=iWt(cOrbit)+1
endif
enddo
! write(*,'(/,"iWt: ",i4)') iWt(cOrbit)
enddo
In the current revision (0.5.4), the preceding lines (generateKpoints.f90) are confusing. The reshifted kpoint, roKpt
, is never used (so why is it reshifted?). And the comment above that says ! Reshift the k-point before finding its index
but the index is never calculated. Maybe this is just left over from the printout lines below that were used for checking/debugging?
The KpList
, pgOps
, and trans
variables are not deallocated in this function. After calling this function thousands of times my program ended up using over 5 gigs of memory.
This is fixed by simply adding deallocate(KpList,pgOps,trans)
to the end of this function. That is all that my pull request changes.
Hello,
compilation of the kgridGen tool fails with the message:
../../symlib/src/librational.a(rational_mathematics.o): In function __rational_mathematics_MOD_get_rationals_in_range': ~/UTILS/kGridGen/symlib/src/rational_mathematics.f90:628: undefined reference to
__utilities_MOD_ralloc_integer'
collect2: error: ld returned 1 exit status
Makefile:76: recipe for target 'kptgen.x' failed
make: *** [kptgen.x] Error 1
I tried gfortran as well as ifort with the same error message
Previous build of the symlib worked fine
Can anyone help me?
Thanks.
Wiley and I got different representative k-points for the orbits when running kgridGen with these parameters:
(all vectors are columns)
lattice vectors
[[ 2.986 0. 1.493]
[ 0. 0. -4.479]
[ 0. 2.986 1.493]]
reciprocal lattice vectors
[[ 0.3349 0. -0. ]
[ 0.1116 0.1116 -0.2233]
[ 0. 0.3349 -0. ]]
atom positions
[0.0, 0.0, 0.0]
[0.33333333, 0.33333333, 0.33333333]
[0.66666667, 0.66666667, 0.66666667]
atom labels
[0, 0, 1]
grid generating vectors
[[ 0.0558 -0.0558 0.0558]
[ 0.0558 0.0558 -0.0558]
[-0.0558 0.0558 0.0558]]
offset
[0.0, 0.0, 0.0]
When Wiley ran kgridGen he got (weight, k-point in Cartesian coordinates)
1.0 [0. 0. 0.]
8.0 [ 0.056 -0.056 0.056]
4.0 [ 0.112 -0.112 0.112]
2.0 [0.167 0.056 0.167]
4.0 [-0.112 0. -0.112]
1.0 [ 0. -0.112 0. ]
4.0 [ 0. -0. 0.112]
8.0 [ 0.056 0.056 -0.167]
4.0 [ 0. -0.112 0.112]
When I ran kgridGen I got (weight, k-point in Cartesian coordinates)
1.0 [0. 0. 0.]
8.0 [ 0.056 -0.056 0.056]
4.0 [ 0.112 -0.112 0.112]
2.0 [0.167 0.056 0.167]
4.0 [ 0.223 -0. 0.223]
1.0 [ 0. -0.112 0. ]
4.0 [0. 0. 0.112]
8.0 [ 0.056 -0.056 0.167]
4.0 [ 0. -0.112 0.112]
The weights of the orbits are the same.
I recently encountered the following error:
ERROR: (symmetryReduceKpointList in generateKpoints.f90)
At least one k-point in the unreduced list was not included in one of the orbits of the symmetry group.
The reciprocal lattice vectors used are:
r1 = (1,0,0)
r2 = (0,0,0.33333333333333331)
r3 = (1,-1,0)
The k-point grid vectors are:
k1 = (0.49999999999999994, 0.49999999999999994, 0)
k2 = (-0.24999999999999997, -0.24999999999999997, 8.3333333333333329E-002)
k3 = (7.5131480090157769E-004, -7.5131480090157769E-004, 0)
At present to run two k-point folds the user has to modify the file driver.f90
and recompile the code to produce executables for each case. Instead we should modify the driver to read in an input file that defines the lattice, the grid, and the floating point tolerance.
Would be nice, at least for debugging, to add a new routine the exports the full list of kpoints, but partitioned into orbits.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.