Dear (please sign your messages, including your affiliation), there is no problem in kmesh.pl for non-orthogonal monoclinic systems. It seems like you are not following correctly the recipe in the user guide. kmesh.pl should be used to create the list of k-points both for wannier90 and for QE, in order to be sure that they are consistent. Apparently you are using it only for wannier90, while for QE you are using the automatic 5 5 5 grid. The inconsistency that emerges is due to the fact that the fourth k-point created by kmesh.pl is outside the BZ but QE folds it back inside. If you use kmesh.pl to generate an explicit list of k-points to be added to your nscf input, everything should be ok.
Kind regards, Marco *** Marco Gibertini ********************************************************** Associate Professor of Condensed-Matter Physics UNIMORE University of Modena and Reggio Emilia, Italy ********************************************************** > Il giorno 2 giu 2026, alle ore 04:36, 一世长安繁华尽 <[email protected]> ha scritto: > > Dear Wannier90 Developers, > I am using Quantum ESPRESSO 7.1 + Wannier90 to calculate monoclinic m-HfO₂ > with a non-orthogonal unit cell (ibrav=0). I followed the official user guide > Appendix A.1 to generate k-points with kmesh.pl, but I get a k-point 4 is > wrong error in pw2wannier90. > 1. My QE nscf input (with nosym=.true., noinv=.true.) > &CONTROL calculation = 'nscf' restart_mode = 'from_scratch' outdir = './tmp' > pseudo_dir = './' prefix = 'hfo2_scf' wf_collect = .TRUE. / &SYSTEM ibrav = 0 > nat = 12 ntyp = 2 ecutwfc = 80.0 ecutrho = 400.0 occupations = 'smearing' > smearing = 'gauss' degauss = 1.0D-9 nosym = .TRUE. noinv=.true. nbnd = 80 / > &ELECTRONS conv_thr = 1.0D-8 mixing_beta = 0.3 / ATOMIC_SPECIES Hf 178.49 > Hf_ONCV_PBE-1.2.upf O 16.00 O_ONCV_PBE-1.2.upf CELL_PARAMETERS (angstrom) > 5.0941750100 0.0000000000 0.0000000000 0.0000000000 5.1506447000 0.0000000000 > -0.8761689831 0.0000000000 5.2029534928 ATOMIC_POSITIONS (crystal) O > 0.5407102482 0.2743536413 0.0117443256 O 0.9267679105 0.8329482139 > 0.1581029835 Hf 0.2964816700 0.0449068930 0.2196121225 Hf 0.7253781402 > 0.5380476866 0.2802104172 O 0.0656911493 0.3147648608 0.3460114403 O > 0.4500930639 0.7529668907 0.4845099501 O 0.5720354001 0.2449214857 > 0.5378973073 O 0.9373617380 0.6765659775 0.6446066286 Hf 0.2648245966 > 0.4657810453 0.7144970546 Hf 0.7129856771 0.9508095845 0.7838205843 O > 0.0668449565 0.1562139360 0.8414187512 O 0.4441759530 0.7523384683 > 0.9964560835 K_POINTS automatic 5 5 5 0 0 0 > 2. I generated k-points using kmesh.pl: > 3. Error from pw2wannier90 > Program PW2WANNIER v.7.1 starts on 1Jun2026 at 11:54:25 > Reading xml data from directory: ./tmp/hfo2_scf.save/ > - Real lattice is ok > - Reciprocal lattice is ok > Something wrong! > k-point 4 is wrong > 0.000000000000000E+000 0.000000000000000E+000 0.587455761468897 > 0.000000000000000E+000 0.000000000000000E+000 -0.391637174312598 > Error in routine pw2wannier90 (4): > problems with k-points > stopping ... > My key questions: > The official user guide Appendix A.1 says: > "We suggest to always use this utility (kmesh.pl) to generate the k grids". > But it does NOT mention that kmesh.pl is incompatible with non-orthogonal / > monoclinic lattices. > Why does this error happen? > If I MUST keep the begin kpoints block in my .win file (instead of only using > mp_grid), what is the correct, standard way to get the k-point list for a > non-orthogonal monoclinic system like m-HfO₂? > Should I extract k-points directly from QE output XML instead of using > kmesh.pl? > Thank you very much for your help! > _______________________________________________ > Wannier mailing list > [email protected] > https://www.google.com/url?q=https://lists.quantum-espresso.org/mailman/listinfo/wannier&source=gmail-imap&ust=1780972637000000&usg=AOvVaw212fdftAj9Wp-mUHQ6yiDj
_______________________________________________ Wannier mailing list [email protected] https://lists.quantum-espresso.org/mailman/listinfo/wannier
