Sure, this is like the array "shell" that is known by all subroutines in the module symme: it gets initiaized by sym_rho_init_shells. Then it is used by sym_rho_serial. But yes, a different name for the array "n" will be useful if it is made known to the entire module.
I'll go over this as part of the hacking project I am really interested in. Then you can take a look and decide to what extent all this may be useful for quantum espresso. Thanks again for your help! (I may have more questions about details of the code in the course of this project.) Roland On Sun, Mar 15 2026, Paolo Giannozzi wrote: > Re-using an integer array means that you have to carry it around in > a module; I would rather re-build a local integer array containing > Miller indices (and maybe with a less generic name) as it is done in > sym_rho_init_shells > > Paolo > > On 3/14/2026 11:30 PM, Roland Winkler wrote: >> Thank you Paolo. >> I thought that the code in sym_rho_serial could reuse the integer >> array >> "n" set up in sym_rho_init_shells so that then sym_rho_serial could >> compare integers as in sym_rho_init_shells, instead of comparing floats >> with "ABS ( ... ) < 1.0D-5" that sym_rho_serial is using now. >> I am asking this because for what I really want I need to extend >> the >> arithmetic used for the symmetrization of the charge density, and I'd >> like to avoid developing an approach that may fail in corner cases, even >> if these corner cases are more exotic. So I want to make sure I >> understand the relevant existing code as much as possible. >> Thanks again, >> Roland >> On Sat, Mar 14 2026, Paolo Giannozzi wrote: >>> I guess the reason is that the conversion from cartesian to crystal >>> axis for G-vectors is done in-place using a routine unsurprisingly >>> called "cryst_to_cart". The output is in the same real variable >>> "g0". It is not wise to compare real numbers with "if (a == b)", as >>> one would do with integers, even if in practice they are integers. >>> >>> Paolo >>> >>> On 3/14/2026 2:21 PM, Roland Winkler wrote: >>>> Dear Paolo, >>>> now that Stefano corrected my embarrassing mistake regarding the >>>> space >>>> group symmetry of wurtzite (that explains everything I am seeing), >>>> I kindly would like to ask one more technical question that you may be >>>> able to answer, as you said you wrote the code for the charge >>>> symmetrization. >>>> I want to understand the generic approach implemented in the code >>>> for >>>> charge symmetrization. It seems to me that the initialization performed >>>> by sym_rho_init_shells is conceptually very similar to the actual >>>> symmetrization performed by sym_rho_serial. Both routines map >>>> reciprocal lattice vectors onto their images under the crystallographic >>>> point group. (The phase factors associated with nonsymmorphic >>>> symmetries only affect the images of the charge density and >>>> magnetization.) >>>> Was there a reason why you implemented the rotations of the >>>> reciprocal >>>> lattice vectors in sym_rho_init_shells via integer arithmetic, but >>>> sym_rho_serial uses floating point arithmetic for this task? It would >>>> seem to me that integer arithmetic should work in both cases and it >>>> would be better suited for this task than floating point arithmetic. >>>> Thank you, >>>> Roland >>>> On Sat, Mar 14 2026, Paolo Giannozzi wrote: >>>>> I wrote many years ago the code that symmetrizes the charge density >>>>> in reciprocal space. Unfortunately I have no time right now to delve >>>>> into your question, but please note that the code is generic, uses >>>>> the available crystal symmetry and knows nothing about your specific >>>>> case. >>>>> >>>>> In the first versions of QE symmetry operations were stored as >>>>> matrices of integer numbers, acting on crystal axis. This is >>>>> practical to deal with transformation of real-space grid >>>>> indices. For all other cases, symmetry operations are transformed to >>>>> real matrices, acting on cartesian coordinates. >>>>> >>>>> PG >>>>> >>>>> >>>>> On 3/12/2026 7:20 PM, Roland Winkler wrote: >>>>>> Dear Users >>>>>> I am trying to understand how quantum espresso (pw) is >>>>>> symmetrizing >>>>>> the charge density rhog in reciprocal space. My understanding is >>>>>> that for a nonmagnetic symmorphic crystal structure all components >>>>>> of rhog in a star should be equal [Streitwolf, Group Theory in >>>>>> Physics, Eq. (6.8)]. >>>>>> For systems with zincblende structure this is, indeed, what I get. >>>>>> However, for systems with wurtzite structure half of the components >>>>>> in some stars have opposite signs. >>>>>> More specifically, I have checked that sym_rho_init_shells >>>>>> identifies the stars as expected. However, sym_rho_serial then >>>>>> gives opposite signs for half of the components in some stars. >>>>>> The code in sym_rho_init_shells is quite straightforward, using >>>>>> integer arithmetic for the transformations of the reciprocal lattice >>>>>> vectors. This code is doing what I expect, and it gives the results >>>>>> I expect. However, I have not yet got the same level of >>>>>> understanding for sym_rho_serial. The latter routine is doing >>>>>> something more complicated, implementing the transformations of the >>>>>> reciprocal lattice vectors via floating point arithmetic where I do >>>>>> not understand the reason for this different approach. I can merely >>>>>> say that I have instrumented sym_rho_serial to write out the density >>>>>> after symmetrization and I do not get what I expect as described >>>>>> above. [For example, for the job attached below, the components >>>>>> 12,14,16,18,20,22 and 13,15,17,19,21,23 of rhog form two stars >>>>>> (according to sym_rho_init_shells), but the corresponding values of >>>>>> rhog in each of these stars are not equal.] >>>>>> Am I missing something? Any help is appreciated. >>>>>> My input file for pw.x is attached. I am using version 7.5. >>>>>> Roland Winkler >>>>>> &CONTROL >>>>>> calculation='scf' >>>>>> verbosity='high' >>>>>> prefix='zns' ! Output files are named according to prefix >>>>>> / >>>>>> &SYSTEM >>>>>> space_group=186 ! Space group number >>>>>> a=3.811 ! Lattice parameter a in angstroms >>>>>> c=6.234 ! Lattice parameter c in angstroms >>>>>> nat=2 ! Number of atoms in the asymmetric unit >>>>>> ntyp=2 ! Number of different atom types. Here, Zn and S. >>>>>> ecutwfc=40 ! Kinetic energy cutoff for wavefunctions (Ry) >>>>>> ecutrho=200 ! Kinetic energy cutoff for charge density and >>>>>> potential (Ry) >>>>>> / >>>>>> &ELECTRONS >>>>>> / >>>>>> &IONS >>>>>> / >>>>>> &CELL >>>>>> / >>>>>> ATOMIC_SPECIES >>>>>> Zn 65.38 zn_pbe_v1.uspp.F.UPF >>>>>> S 32.065 s_pbe_v1.4.uspp.F.UPF >>>>>> ATOMIC_POSITIONS crystal_sg >>>>>> Zn 1/3 2/3 0.00000 >>>>>> S 1/3 2/3 0.38500 >>>>>> K_POINTS automatic >>>>>> 2 2 2 0 0 0 >>>>>> _______________________________________________________________________________ >>>>>> The Quantum ESPRESSO Foundation stands in solidarity with all >>>>>> civilians worldwide who are victims of terrorism, military >>>>>> aggression, and indiscriminate warfare. >>>>>> -------------------------------------------------------------------------------- >>>>>> Quantum ESPRESSO is supported by MaX (www.max-centre.eu) >>>>>> users mailing list [email protected] >>>>>> https://lists.quantum-espresso.org/mailman/listinfo/users _______________________________________________________________________________ The Quantum ESPRESSO Foundation stands in solidarity with all civilians worldwide who are victims of terrorism, military aggression, and indiscriminate warfare. -------------------------------------------------------------------------------- Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list [email protected] https://lists.quantum-espresso.org/mailman/listinfo/users
