Bug report in subroutine iter_open
Posted: 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:
L1811-1812:
L1825-1826:
L1844-1845:
L1858-1859:
Although "position_byte" is declared as a 64-bit integer (line 1763):
both "lrepmatw2_restart" and "lrepmatw5_restart" are 32-bit integer arrays, as declared at lines 242-245 in the file "ephwann_shuffle.f90":
Therefore, numerical overflow may occur during the computation. I tried modifying the source code (for example, L1858):
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
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:
I checked the source code and found the following lines in the file "io_transport.f90" (subroutine iter_open):At line 1859 of file io_transport.f90 (unit = 133, file = './Fsparsecb/sparsecb_9')
Fortran runtime error: POS=specifier must be positive
L1811-1812:
Code: Select all
position_byte = (lrepmatw2_restart(my_pool_id + 1) - 1) * 8 + 1
READ(iunepmat, POS=position_byte) dummy_real
Code: Select all
position_byte = (5 * lrepmatw2_restart(my_pool_id + 1) - 1) * 4 + 1
READ(iunsparseq, POS = position_byte) dummy_int
Code: Select all
position_byte = (lrepmatw5_restart(my_pool_id + 1) - 1) * 8 + 1
READ(iunepmatcb, POS = position_byte) dummy_real
Code: Select all
position_byte = (5 * lrepmatw5_restart(my_pool_id + 1) - 1) * 4 + 1
READ(iunsparseqcb, POS = position_byte) dummy_int
Code: Select all
INTEGER(KIND = 8) :: position_byte
Code: Select all
INTEGER :: lrepmatw2_restart(npool)
!! To restart opening files
INTEGER :: lrepmatw5_restart(npool)
!! To restart opening files
Code: Select all
position_byte = (5 * int(lrepmatw5_restart(my_pool_id + 1), kind=8) - 1) * 4 + 1
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