msg-byu / kgridgen Goto Github PK

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.

Would be nice, at least for debugging, to add a new routine the exports the full list of kpoints, but partitioned into orbits.

Would be nice to add some utilities:

• Unfold a reduced list
• compare two kpoints, see if equivalent
• Put all kpoints in the BZ (instead of first unit cell). (Is accuracy increased when the shortest k-vectors are used, after all the bands aren't really periodic for a finite basis set...)
• Find irreducible wedge of BZ

...

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.

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).

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.

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     

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)

          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?

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.

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.

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

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

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.

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.