<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Dear colleagues,<br>
      <br>
      I'd like to report a bug in join_vectorfiles.f (SRC_trig, used by
      x joinvec) and suggest a fix.<br>
      <br>
      <b>Symptom</b>: When using case.klist_band which are run in
      parallel calculations (-p), for example<br>
      $ x lapw1 -up -band -p<br>
      $ x lapw1 -dn -band -p<br>
      the outgoing parallel energy and vector files are written to<br>
      case.energyup_1, case.energyup_2, etc<br>
      case.vectorup_1, case.vector_2, etc<br>
      <br>
      When attempting to joinvec them<br>
      $ x joinvec -up<br>
      the resulting <br>
      case.energyup<br>
      case.vectorup<br>
      can be silently partly truncated and not containing all k-points. <br>
      This truncation happens when number of k-points in the individual
      parallel case.klist_band_N is larger than in main case.klist</p>
    <p>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.<br>
      <b><br>
        Suggested fix of join_vectorfile.f </b>: 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. <br>
      <br>
    </p>
    <p>Note, the variable containing number of k-points,  <br>
      nkpoints = count_kmesh_klist(unit_klist)<br>
      is unused now, and can be deleted. But I left it in the program
      for a minimal patch.<br>
      <br>
      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. <br>
      <br>
    </p>
    <p>Patch can be applied as:<br>
      patch -b join_vectorfiles.f join_vectorfiles.patch<br>
      then recompile via siteconfig (Select program --> trig).<br>
      <br>
      With my best regards,<br>
      Jaroslav Hamrle<br>
      <br>
    </p>
  </body>
</html>