Bug report in subroutine iter_open

hezr · Post by **hezr** » Wed Feb 19, 2025 12:33 pm

Dear developers,

I am currently using EPW v5.7and have encountered what appears to be a bug, which I suspect might also affect the latest version (v5.9).

Specifically, when I restarted an interrupted transport calculation with "iterative_bte = .true.", the code crashed, with an error message like:

At line 1859 of file io_transport.f90 (unit = 133, file = './Fsparsecb/sparsecb_9')
Fortran runtime error: POS=specifier must be positive

I checked the source code and found the following lines in the file "io_transport.f90" (subroutine iter_open):
L1811-1812:

Code: Select all

            position_byte = (lrepmatw2_restart(my_pool_id + 1) - 1) * 8 + 1
            READ(iunepmat, POS=position_byte) dummy_real

L1825-1826:

Code: Select all

            position_byte = (5 * lrepmatw2_restart(my_pool_id + 1) - 1) * 4 + 1
            READ(iunsparseq, POS = position_byte) dummy_int

L1844-1845:

Code: Select all

            position_byte = (lrepmatw5_restart(my_pool_id + 1) - 1) * 8 + 1
            READ(iunepmatcb, POS = position_byte) dummy_real

L1858-1859:

Code: Select all

            position_byte = (5 * lrepmatw5_restart(my_pool_id + 1) - 1) * 4 + 1
            READ(iunsparseqcb, POS = position_byte) dummy_int

Although "position_byte" is declared as a 64-bit integer (line 1763):

Code: Select all

    INTEGER(KIND = 8) :: position_byte

both "lrepmatw2_restart" and "lrepmatw5_restart" are 32-bit integer arrays, as declared at lines 242-245 in the file "ephwann_shuffle.f90":

Code: Select all

  INTEGER :: lrepmatw2_restart(npool)
  !! To restart opening files
  INTEGER :: lrepmatw5_restart(npool)
  !! To restart opening files

Therefore, numerical overflow may occur during the computation. I tried modifying the source code (for example, L1858):

Code: Select all

position_byte = (5 * int(lrepmatw5_restart(my_pool_id + 1), kind=8) - 1) * 4 + 1

Then I re-complied the code and restarted the same interrupted task, and the code worked normally.

I've not started to use the latest version yet, so I'm not sure if there's the same problem. So I read the source code of v5.9, and found that the variable "position_byte" seems to be calculated in a way same as version 5.7 (L1773, 1787, 1806, 1820 in "io_transport.f90"). And the arrays "lrepmatw2_restart" and "lrepmatw5_restart" are also declared as 32-bit integers at L207-210 in the file "use_wannier.f90". Therefore, I think this issue might persist in version 5.9.

Thank you for the efforts in developing the code. I appreciate the opportunity to contribute by reporting this bug, and I hope this feedback can help improve the project.

Best regards,
Zirui He