KPOINTS files for band-structure calculations

[FPrith]

When the command "vise vs -t band" is entered, to my knowlege, the following message will be displayed:
INFO: Numbers of kpoints are incremented to be even numbers.

1. What is the effect/reason of this treatment?

2. Would it be a problem to rewrite non-zero-weighted k points created in a vise command with those written in a IBZKPT file in a previous SCF calculation?
   In my calculations, band-structure caluculations are performed self-consistently;
   a WAVECAR file converged in a previous run is read, and an ICHARG tag is NOT set.

[yuuukuma]

1. This is mainly because it is often better to use an even number of k-points (e.g. NKRED=2). However, for band structure calculations, this is not necessary.
2. To perform hybrid functional calculations, we need to use the KPOINTS file that the software generates. However, when using GGA(+U), we can utilize fixed charge density and run non-selfconsistent calculations using ICHARG=11. In that case, as you mentioned, you should modify the parameters accordingly.

[FPrith]

Thank you for your reply.

1. I have understood the content. I had an interest on why the even-number k points are imposed in the case of band structure calculations (vise vs -t band).

2. I have an additional question to evaluate band structures.

I have done band structure calculations on collinear antiferromagnetic systems with the GGA-PBEsol functional.
All calculations have been done self consistently; so, ICHARG tags are NOT set to be 11.

In the case of MF2 (M = Mn, Co, etc.), the experimental XRD-derived space group is P4_2/mnm (tP lattice); meanwhile, antiferromagnetic primitive cells belong to Cmmm (oS lattice).
When KPOINTS files are created by the command "vise vs -t band" (by the SeeK-path rule), which Bravais lattice should be applied?
For example, the following warning is displayed when Cmmm is applied:
warnings.warn("oC lattice, but a almost equal to b", EdgeCaseWarning)

As a side note, to impose antiferromagnetic Cmmm, other "false" elements were intentionally included in POSCAR files only in the commands "vise vs" and "vise vs -t band"; for example, a Co2F4 POSCAR file was modified into a CoFeF4 where Fe played a role in "false" down-spin Co, and after entering the above commands, Fe was manually written into Co to get a "true" Co2F4 POSCAR file.