EPW Forum

Posted: **Wed Jun 22, 2016 7:55 pm**

Hi,

My epw.x program crashes during the run of one of the examples with the following massage:

forrtl: severe (36): attempt to access non-existent record, unit 24, file .../diam.igk3

At first it seemed there is a problem with the way diam.igk3 is being read but that was not the case. Further debugging I realized that in file readigk.f90 there is a variable, INT_DIRECT_IO_FACTOR which specify the block length byte and this variable is very much machine dependent. In our machine this variable should be INT_DIRECT_IO_FACTOR=1 instead of 4.

Here, I would like to suggest a different way of programming which is machine independent and we don't need to setup this variable from one machine to the other.

Here is the patch:

--- EPW/src/readigk.f90.orig 2016-06-17 13:30:26.983044229 -0700
+++ EPW/src/readigk.f90 2016-06-20 13:15:41.015868448 -0700
@@ -33,20 +33,13 @@
#endif
! node number for shuffle
!
- integer :: itmp, lrigk, unf_recl, itmp1
+ integer :: itmp, lrigk, unf_recl, itmp1, iotemp,iofactor
character (len=256) :: tempfile
!
! the following is for pgi on opteron, I should test the rigth numbers
! on other machines/compilers
!
-#if defined(__PGI)||defined(__AIX)
-# define INT_DIRECT_IO_FACTOR 4
-#else
-!this must be here to compile on a serial machine
-!however the value is not tested
-# define INT_DIRECT_IO_FACTOR 4
-!jn won't compile with this on civet: call errore('INT_DIRECT_IO_FACTOR is not a tested quantity',-1)
-#endif
+INQUIRE (IOLENGTH=iofactor)iotemp
+ ! iotemp is a output variable and it does not matter whether it is integer or any other type.
!
! filename
!
@@ -61,7 +54,7 @@
! first and last byte is rec len, second is npw, 3dh to npwx-rh is igk
!
lrigk = npwx + 3
- unf_recl = INT_DIRECT_IO_FACTOR * lrigk
+ unf_recl = iofactor * lrigk
!
! open, read, and close
!

I hope it helps.

Cheers,
Ata

Ata Roudgar
Research Computing
WestGrid Site
IT Services
Simon Fraser University
Burnaby, British Columbia
Canada V5A 1S6

phone: 778 782-8860
fax: 778 782-4242

Posted: **Thu Jun 23, 2016 6:09 pm**

Dear Ata Roudgar,

Thank you very much for the suggestion. I had a similar problem in the past with that.

Fortunately, this problem has already been alleviate in the current trunk of QE/EPW (next official release in September).

Indeed, we do not read/write igk file anymore. This is a decision taken at the QE level and apply to all QE related programs (including EPW).

The igk indices are now kept in memory. Indeed, the IO was inefficient, the igk small and there was even accuracy issue as the igk were recalculated and tiny deviation could lead to different order.

However, there are two routines that still uses this: readdvscf.f90 and readwfc.f90

I tried to make similar changes to readdvscf.f90:

Code: Select all

  integer :: iotemp,iofactor
  INQUIRE (IOLENGTH=iofactor)iotemp
  CALL set_ndnmbr ( 0, iq, 1, nqc, filelab)
  tempfile = trim(dvscf_dir) // trim(prefix) // '.dvscf_q' // filelab
  !unf_recl = DIRECT_IO_FACTOR * lrdrho
  unf_recl = iofactor * lrdrho
  print*,'iofactor ',iofactor

However, this does not work in my case:

Code: Select all

 iofactor            4
At line 99 of file readdvscf.f90 (unit = 80, file = './save/pb.dvscf_q1')
Fortran runtime error: I/O past end of record on unformatted file

I assume that it is because the dvscf files created by the PH code (that I cannot really modify) have been created with DIRECT_IO_FACTOR = 8.

PS: The test has been done on my workstation made of Intel i7-4770 and using GCC 4.8.4.

Best,

Samuel

EPW Forum

EPW-5.4.0, attempt to access non-existent record, unit 24

EPW-5.4.0, attempt to access non-existent record, unit 24

Re: EPW-5.4.0, attempt to access non-existent record, unit 2