Programming

This doesn't seem to be too bad, but I think the app should be in c++, or an interpreter language, and not Fortran. Unfortunately I am getting ready for a conference and a grant meeting, so I may not be able to work much on this until later in the month.

Please let me know if you need it right away and I will see what I can do.

LMHmedchem

Please take your owm time.

Hi.

I looked over the code that you posted. It contains ALLOCATE statements, so I think you can ignore LMHmedchem comments about array declarations, because that is the Fortran-77 way of doing things. Fortran-90 and later use modern techniques for dynamic storage.

My take is different from LMHmedchem's in that I think a bird in the hand is worth two in the bush -- so you have a Fortran code, you might as well use it, as opposed to writing something new in a different language.

I considered the possible problems from too many files being open, so I wrote two test codes. The first simply opens files associating with "unit=1", but never explicitly closing them. The second opens files concurrently, associating with unit=n, where n varies. Both read a value from the file and the second goes back to read the first data file to make sure that the first file is still open and accessible.

I tried these codes with 2000 data files. "data0011 - data2010". The data files have a unique integer number in them (basically the sequence), and then the negative of that (number+1). Both test programs worked as I expected, without error.

I do agree with LMHmedchem that "Most likely, you are exceeding the capacity of some data structure that stores the contents of the files ...".

I will demonstrate a technique for identifying such errors in a subsequent post ... cheers, drl

---------- Post updated at 11:09 ---------- Previous update was at 10:57 ----------

Hi.

I wrote the following code to demonstrate how ALLOCATE can obtain storage dynamically, but the array is still subject to being over-run:

Code:

     program f1

! @(#) f1	Demonstrate Fortran-95.

       real, allocatable :: x(:)

       write (*,*) " Hello, world from Fortran-95."
       allocate (x(1))

       x(1) = 1.0
       write(*,*) " x(1) is ",x(1)

! For the loop below:
! 1)
! both gfortran, g95 -- beyond 6 one gets:
! glibc detected *** ./a.out: free(): invalid next size (fast)
! ifort (compiling name.90 -- beyond 7 yields:
! glibc detected *** ./a.out: double free or corruption

! 2)
! gfortran -fbounds-check:
! At line 19 of file one.f95
! Fortran runtime error: Array reference out of bounds for array
! 'x', upper bound of dimension 1 exceeded (2 > 1)
!
! g95 -fbounds-check:
! At line 25 of file one.f95
! Traceback: not available, compile with -ftrace=frame or -ftrace=full
! Fortran runtime error: Array element out of bounds: 2 in (1:1), dim=1
!
! ifort -check bounds two.f90
! forrtl: severe (408): fort: (2): Subscript #1 of the array X
! has value 2 which is greater than the upper bound of 1

       do i = 2, 6
         x(i) = float(i)
       end do

     end

This was run in the following context:

Code:

Environment: LC_ALL = C, LANG = C
(Versions displayed with local utility "version")
OS, ker|rel, machine: Linux, 2.6.26-2-amd64, x86_64
Distribution        : Debian GNU/Linux 5.0.8 (lenny) 
GNU bash 3.2.39
gfortran GNU Fortran (Debian 4.3.2-1.1) 4.3.2
G95 (GCC 4.0.3 (g95 0.92!) Jun 24 2009)
ifort (IFORT) 11.1 20090827

The results are part of the comments above. The first section shows that errors occur when the array is over-run sufficiently. However, if one enables bounds-checking, the error is caught immediately.

Regrettably, the AIX box to which I have access does not have a Fortran compiler that I could find. However, I think IBM almost certainly will have provided a means to check for such errors, so you'll need to do a bit of reading for that.

Adding the bounds check may degrade performance, but it's such a easy change to make to see if that is the error, that your time will be well-spent.

Best wishes, and keep us updated ... cheers, drl