Out of bounds array access in EPW

Post here questions linked with issue while running the EPW code

Moderator: stiwari

Post Reply
nantolin
Posts: 2
Joined: Mon Apr 18, 2022 10:51 pm
Affiliation: N/A

Out of bounds array access in EPW

Post by nantolin »

Hello all.

I have been working on and off with the Q-E testsuite for a few months now and was wondering if there are any plans to address the out-of-bounds array access that occurs in a few EPW tests. I don't have time or enough familiarity with the code to understand how these bugs crept in, but I was surprised to see that they were not addressed in the latest 5.4.1/Q-E 7.0 release.

Specifically, I note out-of-bounds access on ndegen_k in ephwann_shuffle as exercised by input files epw12.in and epw13.in in the epw_base test, which I believe is leading to additional out-of-bounds issues when the output is written for the same test. The incorrect array dimension seems to be arising when the previous EPW results are read in.

I also note some read access issue with epw2.in and epw3.in in the epw_mob_ibte_sym test, seemingly related to the symmetry-reduced number of k-points.

Both of these seem like they may be related to the deprecation of the kmaps keyword...

Regards,
Nik

hlee
Posts: 415
Joined: Thu Aug 03, 2017 12:24 pm
Affiliation: The University of Texas at Austin

Re: Out of bounds array access in EPW

Post by hlee »

Dear Nik:

Thank you for your post.
We are aware of some of these cases and we are preparing the new release with many number of changes in the code.

But, if you provide log files which show in detail the OOB errors and let me know your environments such as compilers, libraries, etc., it helps much.
In out tests with the debug mode enabled, they don't arise in the testsuite.

Sincerely,

H. Lee

nantolin
Posts: 2
Joined: Mon Apr 18, 2022 10:51 pm
Affiliation: N/A

Re: Out of bounds array access in EPW

Post by nantolin »

Dr. Lee,

I find these errors consistently on multiple Linux system architectures (generally RHEL based) building with gfortran (8/9/10) with the -fcheck=bounds option specified. It appears to me that the --enable-debug flag in the Q-E configure also enables this checking behavior, albeit with a syntax that is deprecated in more recent gfortran compilers; I know the bounds checking has improved since gfortran 4.8, so perhaps this behavior is only detected in newer compilers.

Note that all line numbers below may be slightly off due to my addition of debug output to the source code.

In the case of the epw_base test, input file epw9.in:
At line 507 of file q-e/EPW/src/cum_mod.f90
Fortran runtime error: Index '21' of dimension 1 of array 'sigmai' above upper bound of 20

In the case of the epw_base test, input file epw12.in:
(Added output to track array size):
Number of WS vectors for electrons 43
Value of nrr_k after epw_read 79
Size of ndegen_k 43 1 (printed immediately before loop at line ~680)
At line 684 of file q-e/EPW/src/ephwann_shuffle.f90
Fortran runtime error: Index '44' of dimension 1 of array 'ndegen_k' above upper bound of 43

"Fixing" that error by forcing the loop at line ~680 to respect the original array bounds causes OOB array access in lambda_all and gamma_all in the output writing routine around line 1660.

In the case of the epw_mob_ibte_sym test, input file epw2.in:
(Immediately after the q-points calculation output)
At line 1168 of file q-e/EPW/src/ephwann_shuffle.f90 (unit = 142, file = 'inv_tau_tmp')
Fortran runtime error: I/O past end of record on unformatted file
(This failure does not depend on inclusion of the -fcheck=bounds flag)

I freely admit in these cases that I have inferred the proper order in which the testsuite input files are to be run, and that order may be incorrect.

Regards,
Nik

Post Reply