[Pw_forum] Conserving the same Wyckoff multiplicity in the input and in the output
hqtst42
hqtst42 at netc.pl
Wed Apr 19 11:47:25 CEST 2017
Dear Paolo,
Many thanks for you reply. It seems like "use_all_frac=.true. " solved
my problem.
I have one final question: assuming you use one of the options
that would prevent you from using (hybrid functionals / phonon
calculations), how could I change the input parameters (especially
ecutwfc) so all of the symmetry elements are present ?
Many thanks indeed,
Henri Colaux
Le 2017/04/19 à 18:46, Henri Colaux a écrit :
>
> Le 2017/04/12 à 19:36, Paolo Giannozzi a écrit :
>> The symmetry the code finds may differ from the actual symmetry of the
>> system. If so, only a reduced symmetry will be enforced. Note the last
>> point in this excerpt from the user manual. It holds also for Wyckoff
>> positions and space groups.
>>
>> Paolo
>>
>> ===========================================
>> 5.0.0.19 pw.x does not find all the symmetries you expected
>>
>> pw.x determines first the symmetry operations (rotations) of the
>> Bravais lattice; then checks which of these are symmetry operations of
>> the system (including if needed fractional translations). This is done
>> by rotating (and translating if needed) the atoms in the unit cell and
>> verifying if the rotated unit cell coincides with the original one.
>>
>> Assuming that your coordinates are correct (please carefully check!),
>> you may not find all the symmetries you expect because:
>>
>> the number of significant figures in the atomic positions is not large
>> enough. In file PW/eqvect.f90, the variable accep is used to decide
>> whether a rotation is a symmetry operation. Its current value (10-5 )
>> is quite strict: a rotated atom must coincide with another atom to 5
>> significant digits. You may change the value of accep and recompile.
>> they are not acceptable symmetry operations of the Bravais lattice.
>> This is the case for C60 , for instance: the Ih icosahedral group of
>> C60 contains 5-fold rotations that are incompatible with translation
>> symmetry.
>> the system is rotated with respect to symmetry axis. For instance: a
>> C60 molecule in the fcc lattice will have 24 symmetry operations (Th
>> group) only if the double bond is aligned along one of the crystal
>> axis; if C60 is rotated in some arbitrary way, pw.x may not find any
>> symmetry, apart from inversion.
>> they contain a fractional translation that is incompatible with the
>> FFT grid (see next paragraph). Note that if you change cutoff or unit
>> cell volume, the automatically computed FFT grid changes, and this may
>> explain changes in symmetry (and in the number of k-points as a
>> consequence) for no apparent good reason (only if you have fractional
>> translations in the system, though).
>> a fractional translation, without rotation, is a symmetry operation of
>> the system. This means that the cell is actually a supercell. In this
>> case, all symmetry operations containing fractional translations are
>> disabled. The reason is that in this rather exotic case there is no
>> simple way to select those symmetry operations forming a true group,
>> in the mathematical sense of the term.
>>
>> 5.0.0.20 Warning: symmetry operation # N not allowed
>>
>> This is not an error. If a symmetry operation contains a fractional
>> translation that is incompatible with the FFT grid, it is discarded in
>> order to prevent problems with symmetrization. Typical fractional
>> translations are 1/2 or 1/3 of a lattice vector. If the FFT grid
>> dimension along that direction is not divisible respectively by 2 or
>> by 3, the symmetry operation will not transform the FFT grid into
>> itself. Solution: you can either force your FFT grid to be
>> commensurate with fractional translation (set variables nr1, nr2, nr3
>> to suitable values), or set variable use_all_frac to .true., in
>> namelist &SYSTEM. Note however that the latter is incompatible with
>> hybrid functionals and with phonon calculations.
>> ===========================================
>>
>>
>> On Wed, Apr 12, 2017 at 12:03 PM, hqtst42 <hqtst42 at netc.pl> wrote:
>>> Hi Paolo,
>>>
>>> Many thanks for your reply ; maybe the problem may be something
>>> different ; I see a symmetry break from the gipaw simulation. Because of
>>> the symmetry, I expect, for example, 4 carbons with identical chemical
>>> shifts, yet I have 2 pairs of 2 equivalent carbon instead. For example:
>>>
>>> -------------------------------------------------------------------------------------------
>>>
>>> Total NMR chemical shifts in ppm:
>>> ---------------------------------------
>>> (adopting the Simpson convention for anisotropy and
>>> asymmetry)-----------
>>>
>>> Atom 1 C pos: ( 0.702166 0.334168 0.055776) Total
>>> sigma: 154.68
>>> 95.6267 39.1235 -16.2688
>>> 45.6199 165.6715 -100.3341
>>> -21.3569 -108.3456 202.7526
>>>
>>> C 1 anisotropy: 216.17 eta: -0.2840
>>> C 1 sigma_11= 103.0939 axis=( 0.761900 0.370231 0.531448)
>>> C 1 sigma_22= 62.1589 axis=( 0.615219 -0.670233 -0.415082)
>>> C 1 sigma_33= 298.7979 axis=( -0.202517 -0.643208 0.738424)
>>>
>>> Atom 2 C pos: ( 0.297834 0.203502 0.675798) Total
>>> sigma: 154.68
>>> 95.6267 39.1235 -16.2688
>>> 45.6199 165.6715 -100.3341
>>> -21.3569 -108.3456 202.7526
>>>
>>> C 2 anisotropy: 216.17 eta: -0.2840
>>> C 2 sigma_11= 103.0939 axis=( 0.761900 0.370231 0.531448)
>>> C 2 sigma_22= 62.1589 axis=( 0.615219 -0.670233 -0.415082)
>>> C 2 sigma_33= 298.7979 axis=( -0.202517 -0.643208 0.738424)
>>>
>>> Atom 3 C pos: ( 0.297163 0.472864 0.419799) Total
>>> sigma: 155.11
>>> 95.2156 39.0348 15.4560
>>> 45.5222 166.0586 99.6009
>>> 19.2085 107.7438 204.0451
>>>
>>> C 3 anisotropy: 215.17 eta: -0.2971
>>> C 3 sigma_11= 104.6936 axis=( -0.750294 -0.387720 0.535474)
>>> C 3 sigma_22= 62.0730 axis=( -0.631164 0.661092 -0.405696)
>>> C 3 sigma_33= 298.5528 axis=( 0.196701 0.642363 0.740729)
>>>
>>> Atom 4 C pos: ( 0.702837 0.064806 0.311775) Total
>>> sigma: 155.11
>>> 95.2156 39.0348 15.4560
>>> 45.5222 166.0586 99.6009
>>> 19.2085 107.7438 204.0451
>>>
>>> C 4 anisotropy: 215.17 eta: -0.2971
>>> C 4 sigma_11= 104.6936 axis=( -0.750294 -0.387720 0.535474)
>>> C 4 sigma_22= 62.0730 axis=( -0.631164 0.661092 -0.405696)
>>> C 4 sigma_33= 298.5528 axis=( 0.196701 0.642363 0.740729)
>>>
>>> -------------------------------------------------------------------------------------------
>>>
>>> There is apparently no version number for
>>> GIPAW:
>>>
>>> -------------------------------------------------------------------------------------------
>>> Program QE v.6.0 (svn rev. 13079) starts on 16Mar2017 at 19:27:28
>>> ***** This is GIPAW svn revision unknown *****
>>> -------------------------------------------------------------------------------------------
>>>
>>> Many thanks again for your time.
>>>
>>> Henri Colaux
>>>
>>>
>>> Le 2017/04/05 à 15:31, Paolo Giannozzi a écrit :
>>>> This is what you get:
>>>> 2 Sym. Ops., with inversion, found
>>>> (note: 2 additional sym.ops. were found but ignored
>>>> their fractional translations are incommensurate with FFT grid)
>>>> and this is what you get if you specify "use_all_frac=.true.":
>>>> 4 Sym. Ops., with inversion, found ( 2 have fractional translation)
>>>> These are symmetry operations (visible with verbosity='high')
>>>> s frac. trans.
>>>>
>>>> isym = 1 identity
>>>>
>>>> cryst. s( 1) = ( 1 0 0 )
>>>> ( 0 1 0 )
>>>> ( 0 0 1 )
>>>>
>>>> cart. s( 1) = ( 1.0000000 0.0000000 0.0000000 )
>>>> ( 0.0000000 1.0000000 0.0000000 )
>>>> ( 0.0000000 0.0000000 1.0000000 )
>>>>
>>>>
>>>> isym = 2 180 deg rotation - cart. axis [0,0,1]
>>>>
>>>> cryst. s( 2) = ( -1 0 0 ) f =( 0.0000000 )
>>>> ( 0 -1 0 ) ( 0.5000000 )
>>>> ( 0 0 1 ) ( 0.5000000 )
>>>>
>>>> cart. s( 2) = ( -1.0000000 0.0000000 0.0000000 ) f =( 0.0000000 )
>>>> ( 0.0000000 -1.0000000 0.0000000 ) ( 0.2688348 )
>>>> ( 0.0000000 0.0000000 1.0000000 ) ( 0.3657871 )
>>>>
>>>>
>>>> isym = 3 inversion
>>>>
>>>> cryst. s( 3) = ( -1 0 0 )
>>>> ( 0 -1 0 )
>>>> ( 0 0 -1 )
>>>>
>>>> cart. s( 3) = ( -1.0000000 0.0000000 0.0000000 )
>>>> ( 0.0000000 -1.0000000 0.0000000 )
>>>> ( 0.0000000 0.0000000 -1.0000000 )
>>>>
>>>>
>>>> isym = 4 inv. 180 deg rotation - cart. axis [0,0,1]
>>>>
>>>> cryst. s( 4) = ( 1 0 0 ) f =( 0.0000000 )
>>>> ( 0 1 0 ) ( 0.5000000 )
>>>> ( 0 0 -1 ) ( 0.5000000 )
>>>>
>>>> cart. s( 4) = ( 1.0000000 0.0000000 0.0000000 ) f =( 0.0000000 )
>>>> ( 0.0000000 1.0000000 0.0000000 ) ( 0.2688348 )
>>>> ( 0.0000000 0.0000000 -1.0000000 ) ( 0.3657871 )
>>>>
>>>>
>>>> point group C_2h (2/m)
>>>> there are 4 classes
>>>> the character table:
>>>>
>>>> E C2 i s_h
>>>> A_g 1.00 1.00 1.00 1.00
>>>> B_g 1.00 -1.00 1.00 -1.00
>>>> A_u 1.00 1.00 -1.00 -1.00
>>>> B_u 1.00 -1.00 -1.00 1.00
>>>>
>>>> the symmetry operations in each class and the name of the first element:
>>>>
>>>> E 1
>>>> identity
>>>> C2 2
>>>> 180 deg rotation - cart. axis [0,0,1]
>>>> i 3
>>>> inversion
>>>> s_h 4
>>>> inv. 180 deg rotation - cart. axis [0,0,1]
>>>>
>>>> On Wed, Apr 5, 2017 at 7:51 AM, Paolo Giannozzi <p.giannozzi at gmail.com> wrote:
>>>>> Structural optimization doesn't break the symmetry. The final symmetry
>>>>> - the one found by the code, I mean - should be the same as the
>>>>> initial one.
>>>>>
>>>>> On Wed, Apr 5, 2017 at 2:46 AM, hqtst42 <hqtst42 at netc.pl> wrote:
>>>>>> In the input file, there are the atomic coordinates for only one
>>>>>> molecule, and with the symmetry operation, I expect 4 equivalent
>>>>>> molecules per unit cell. Yet, the structure optimisation results in 2
>>>>>> pairs of 2 equivalent molecules per unit cell. I would like to explain
>>>>>> to the program not to break the symmetry.
>>>>>>
>>>>>> Le 2017/04/04 à 21:45, Paolo Giannozzi a écrit :
>>>>>>> What do you mean by "results with multiplicity 1" and "Wyckoff multiplicity?
>>>>>>>
>>>>>>> On Tue, Apr 4, 2017 at 12:08 PM, hqtst42 <hqtst42 at netc.pl> wrote:
>>>>>>>> Dear everyone,
>>>>>>>>
>>>>>>>> In the enclosed input file, I set atomic coordinates of all equivalent atoms
>>>>>>>> with crystal_sg and the space group.
>>>>>>>>
>>>>>>>> This should give results with a multiplicity of 1, but I have instead a
>>>>>>>> multiplicity of 2 in the output file.
>>>>>>>> How can I force the program to conserve the Wyckoff multiplicity taken as an
>>>>>>>> input ?
>>>>>>>> All in QE v 6.0
>>>>>>>>
>>>>>>>> Many thanks in advance,
>>>>>>>>
>>>>>>>> Henri Colaux
>>>>>>>> Research associate
>>>>>>>> RIKEN Yokohama
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pw_forum mailing list
>>>>>>>> Pw_forum at pwscf.org
>>>>>>>> http://pwscf.org/mailman/listinfo/pw_forum
>>>>>> _______________________________________________
>>>>>> 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
>>> _______________________________________________
>>> 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
>>
More information about the users
mailing list