[Wien] Fwd: Likely source/s of stupid kgen error

[Peter Blaha]

There is no problem with kgen.

Your two structures are P  and B lattices.

You will never be able to make identical k-meshes for them, as the BZ is 
different and also the size of the unit cell and number of atoms/unit 
cell differ by a factor of 2 (although one specifies the same lattice 
parameters a,b,c).

It is like: bcc Fe and Fe in a simple cubic cell with 2 atoms/cube.

For a comparison of fine details one has either to converge both 
k-meshes, or double the cell (making the B cell --> P), then 
constraining symmetry by labelling some atoms). Then the k-meshes can be 
made identical.

Am 07.09.2016 um 16:11 schrieb Laurence Marks:
> One of my students noticed an inconsistency in basdiv.f which might be
> a source of a problem she has (or not), see below. For certain the
> code and comments appear to be inconsistent:
>
>         read(*,*) n
>         if((iarb(1).eq.1).and.(n(1).ne.n(2))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in x
> and y direction'
>               goto 123
>         endif
>         if((iarb(2).eq.1).and.(n(1).ne.n(3))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in x
> and z direction'
>               goto 123
>         endif
>         if((iarb(3).eq.1).and.(n(1).ne.n(3))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in y
> and z direction'
>               goto 123
>         endif
>       endif
>
> Suggestions?
>
>
> ---------- Forwarded message ----------
> From: Tassie Andersen <tasskanders at gmail.com>
> Date: Tue, Sep 6, 2016 at 12:21 PM
> Subject: Likely source/s of stupid kgen error
> To: Laurence Marks <l-marks at northwestern.edu>
>
>
> Hello Laurie,
>
> I think I may have found the source/s of the kgen error I described. I
> searched for the exact error message in $WIENROOT/SRC_kgen and found
> something helpful in basdiv.f . From what I can tell this file takes
> in some variables, one of which describes whether the unit cell has
> any equal length dimensions (x ,y , z), this is described in the
> heading info by 'IARB' .
>
> The problem is that later, when it checks the values of IARB (and can
> generate a subsequent error message) it uses the following routine
> with cases to check against :
>
>       if(NMSHP.le.0) then
>  123    write(*,*) " Specify 3 mesh-divisions (n1,n2,n3):"
>         read(*,*) n
>         if((iarb(1).eq.1).and.(n(1).ne.n(2))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in x
> and y direction'
>               goto 123
>         endif
>         if((iarb(2).eq.1).and.(n(1).ne.n(3))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in x
> and z direction'
>               goto 123
>         endif
>         if((iarb(3).eq.1).and.(n(1).ne.n(3))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in y
> and z direction'
>               goto 123
>         endif
>       endif
>       NMSHP=(N(1)+1)*(N(2)+1)*(N(3)+1)
>       RETURN
>       END
>
> Notice that case 'if((iarb(2).eq.1).and.(n(1).ne.n(3))) then' and
> 'if((iarb(3).eq.1).and.(n(1).ne.n(3))) then' have the same
> requirements for variable n. This should probably be the following
> instead (if I'm reading correctly):
>
>       if(NMSHP.le.0) then
>  123    write(*,*) " Specify 3 mesh-divisions (n1,n2,n3):"
>         read(*,*) n
>         if((iarb(1).eq.1).and.(n(1).ne.n(2))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in x
> and y direction'
>               goto 123
>         endif
>         if((iarb(2).eq.1).and.(n(2).ne.n(3))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in x
> and z direction'
>               goto 123
>         endif
>         if((iarb(3).eq.1).and.(n(1).ne.n(3))) then
>               write(*,*) 'Lattice symmetry requires equal mesh in y
> and z direction'
>               goto 123
>         endif
>       endif
>       NMSHP=(N(1)+1)*(N(2)+1)*(N(3)+1)
>       RETURN
>       END
>
> However, in the intro commented text there's a note saying '2 and 3
> are reversed?' so I'm not sure is IARB(2)=1 specifies if y = z or if x
> = z (vice versa with IARB(3) = 1). So either the fix I propose or the
> corresponding one for the iarb(3) condition needs to be altered.
> However, this doesn't solve the root of the problem (though it is
> annoying and keeps you from entering the proper values).
>
> The real issue is that my structure, where x=y=/=z should have
> iarb(1)=1 and iarb(2), iarb(3) =/= 1. Somehow iarb(2) is being set to
> 1 in this particular case (but not others with a different symmetry
> group). The only file I can find that sets IARB values is bravai.f (or
> birken.f or bravai_bla, but these two don't seem to be called ever). I
> can't figure out where it's messing it up though. It'd be good to
> print all three IARB values after bravai.f runs to check it but I'm
> not sure how to do that. Any suggestions are appreciated.
>
> So it seems there are at least 2 issues.
>
> Regards,
> Tassie
>
>

-- 
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300             FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at    WIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--------------------------------------------------------------------------