[Wien] Bug in join_vectorfiles (x joinvec): truncates case.energy* and case.vector* when case.klist has fewer k-points than case.klist_band_N

[Peter Blaha]

Hi,

Please note, that    x joinvec -h
shows that joinvec accepts a   -band   switch.
Using this switch, the error should (hopefully) not appear.

Anyway, your suggestion is probably useful and I'll take it to weaken a 
possible usage error.

However, this opens the door for another user error:
Suppose one changes case.klist (or klist_band), but for some reasons 
forgets to execute/ or mistypes   x lapw1 -p (-band), but runs 
immediately  x joinvec (-band)

For this, another check would be needed.

Best regards
Peter Blaha

Am 09.08.2026 um 19:56 schrieb Jaroslav Hamrle:
> Dear colleagues,
> 
> I'd like to report a bug in join_vectorfiles.f (SRC_trig, used by x 
> joinvec) and suggest a fix.
> 
> *Symptom*: When using case.klist_band which are run in parallel 
> calculations (-p), for example
> $ x lapw1 -up -band -p
> $ x lapw1 -dn -band -p
> the outgoing parallel energy and vector files are written to
> case.energyup_1, case.energyup_2, etc
> case.vectorup_1, case.vector_2, etc
> 
> When attempting to joinvec them
> $ x joinvec -up
> the resulting
> case.energyup
> case.vectorup
> can be silently partly truncated and not containing all k-points.
> This truncation happens when number of k-points in the individual 
> parallel case.klist_band_N is larger than in main case.klist
> 
> For example, in my calculation, the case.klist has 641 kpoints, and each 
> case.klist_band_N has 1024 k-points. But due to the bug in 
> join_vectorfiles.f, only k-points between 1-641 from each 
> case.klist_band_N  were added. Namely, the resulting case.energyup have 
> kpoints only in ranges  1-641, 1025-1665, 2049-2689, 3073-3713.
> *
> Suggested fix of join_vectorfile.f *: the "do" loop summing over k- 
> points already has a correct EOF handler (end=101, etc.) for detecting 
> the true end of each file. The read number of k-points, nkpoints, 
> included in the "do" loop is hence redundant and, in this particular 
> scenario, wrong. I changed the three "do jk=1,nkpoints" loops (energy, 
> energydum, and vector joining) to unbounded "do" loops. Now, those "do" 
> loops terminate solely via the existing "end=" labels.
> 
> Note, the variable containing number of k-points,
> nkpoints = count_kmesh_klist(unit_klist)
> is unused now, and can be deleted. But I left it in the program for a 
> minimal patch.
> 
> Finally, I attach the patch  (join_vectorfiles.patch, for $WIENROOT/ 
> SRC_trig, tested against WIEN2k 24.1), together with patch description 
> and suggested new version of join_vectorfiles.f.
> 
> Patch can be applied as:
> patch -b join_vectorfiles.f join_vectorfiles.patch
> then recompile via siteconfig (Select program --> trig).
> 
> With my best regards,
> Jaroslav Hamrle
> 
> 
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> https://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

-- 
-----------------------------------------------------------------------
Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
Email: peter.blaha at tuwien.ac.at
WWW:   http://www.imc.tuwien.ac.at      WIEN2k: http://www.wien2k.at
-------------------------------------------------------------------------