On Wednesday, 7 September 2016, Laurence Marks <l-ma...@northwestern.edu>
wrote:

> 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 <tasskand...@gmail.com <javascript:;>>
> Date: Tue, Sep 6, 2016 at 12:21 PM
> Subject: Likely source/s of stupid kgen error
> To: Laurence Marks <l-ma...@northwestern.edu <javascript:;>>
>
>
> 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
>
>
> --
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what
> nobody else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu ; Corrosion in 4D:
> MURI4D.numis.northwestern.edu
> Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
> Co-Editor, Acta Cryst A
> _______________________________________________
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at <javascript:;>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/index.html
>
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Reply via email to