[Pw_forum] bug: cosAC does not work with (centered) monoclinic groups using unique b axis

[Paolo Giannozzi]

Please try this patch:
diff --git a/Modules/latgen.f90 b/Modules/latgen.f90
index 39a12f81a..6d00f060a 100644
--- a/Modules/latgen.f90
+++ b/Modules/latgen.f90
@@ -571,7 +571,7 @@ SUBROUTINE abc2celldm ( ibrav, a,b,c,cosab,cosac,cosbc,
celldm )
      celldm(5) = cosac
      celldm(6) = cosab
      !
-  ELSE IF ( ibrav ==-12 ) THEN
+  ELSE IF ( ibrav ==-12 .OR. ibrav ==-13 ) THEN
      !
      ! ... monoclinic P lattice, unique axis b
      !
P.

On Fri, Jan 26, 2018 at 6:51 PM, José C. Conesa <jcconesa at icp.csic.es>
wrote:

> Hi,
>
> Using qe-6.2.1 I was puzzled by some pw.x results obtained when using an
> input file containing these lines:
>
> ....
>
>  &system
>     ibrav=-13,uniqueb=.true.
>     space_group=12
>     A=14.3100,B=6.3383,C=10.1995
>     cosAC=-0.70644
> ...
>
> until I realized that the corresponding output contained these lines:
>
>      celldm(1)=  27.041981  celldm(2)=   0.442928  celldm(3)=   0.712753
>      celldm(4)=   0.000000  celldm(5)=   0.000000  celldm(6)=   0.000000
>
> That is, the monoclinic angle was not taken into account. Giving the angle
> parameter with cosAB or cos BC changed nothing. I only could obtain the
> correct resullts using an input file with these lines:
>
> .....
>  &system
>     ibrav=-13,uniqueb=.true.
>     space_group=12
>     A=14.3100,B=6.3383,C=10.1995
>     celldm(5)=-0.70644
>
> .....
>
> Then I get in output, as expected:
>
>      celldm(1)=  27.041981  celldm(2)=   0.442928  celldm(3)=   0.712753
>      celldm(4)=   0.000000  celldm(5)=  -0.706440  celldm(6)=   0.000000
>
> If I change the unit cell definition so that the unique axis is c, and use ibrav=13
> (with the default uniqueb=.false.) then cosAB is read correctly. Not
> reading cosAC when ibrav=-13 is obviously a bug that should be corrected.
> I did not verify (yet) if the same problem occurs with ibrav=-12, but I
> suspect it may occur also. If some problem occurs also for other negative
> ibrav values, I do not know.
>
> By the way, when explaining the different ibrav values the manual should
> include a mention (now absent) to the possibility of having ibrav=-13, and
> when explaining both ibrav=-12 and ibrav=-13 it should be said, at that
> same place, that one must add uniqueb=.true. (although actually specifying
> uniqueb should not be necessary, it might be adopted automatically by the
> program when these two negative ibrav values are detected).
>
> Regards,
>
> --
> José C. Conesa
> Instituto de Catálisis y Petroleoquímica, CSIC
> Marie Curie 2, Cantoblanco
> 28049 Madrid, Spain
> Tel. (+34)915854766 <+34%20915%2085%2047%2066>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Libre
> de virus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_-6946635839658223488_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>



-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20180126/102af171/attachment.html>