So there are two errors here: The first on refers to the Pardiso solver (I am not using the MKL Pardiso solver but the standalone version 6.0.0 for performace reasons.) It fails to find or open the license file, which it has already found, opened and read for millions of times during the program execution. Then there is a second error regarding the opening of another file, here is the code snippet where the error is triggered:
inquire(file=name2(1:TRIM_LENGTH2), exist=exist_flag) if (exist_flag) then OPEN(UNIT=12, FILE=name2(1:TRIM_LENGTH2), access="stream") READ(12) process_id_saved CLOSE(12) else ....
This file has also been opened, read and closed millions of times. The error code 1450 translates to ERROR_NO_SYSTEM_RESOURCES. The program is using only 60 MB of RAM, the file I am reading is only a few bytes, it contains the current process id. The file is written during the first loop:
OPEN(UNIT=13, FILE=name2(1:TRIM_LENGTH2), form="unformatted", ACTION="write", STATUS="replace", access="stream") WRITE(UNIT=13) process_id CLOSE(13)
I did some digging on the internet and found out that ERROR_NO_SYSTEM_RESOURCES could refer to a full IO Buffer, but i am closing every file I read or write with close(). Maybe the pardiso solver does not close the license file after reading it? Unfortunately i can not look into its source code. Is it possible to emtpy the bugger manually?
The ERROR_NO_SYSTEM_RESOURCES is a Windows error indicating it ran out of "something" necessary to open the file. The resource is not necessarily an I/O buffer, but it can also be another object identified by a Windows handle. What version of Windows are your running (and if it is Win32 or x64)?
You have to read more into the explanation than what is said. Discount the size limitation for a moment (your buffer size is likely under what is mentioned). There are two (of many) requirements for the open to succeed (in case where FILE_FLAG_NO_BUFFERING is used). a) A physical RAM buffer of sufficient size must be available, and b), a suitable virtual memory address must be available. The article implies only a). You did not state as to if you have a 32-bit application or 64-bit application. If 32-bit your heap may have been fragmented to have grown to the point where it is unable to obtain a suitable virtual address (aligned malloc to page size).
Indicates a named pipe issue, there are many others...
If your application is opening files millions of times, consider opening the file once, and then re-positioning the file pointer. Depending on your access mode this may be via REWIND or POS=1.
I had noticed in some past versions of IFort that file access operations had small memory leaks (a few bytes per file operation statement). Normally, with less than, say, a hundred such statements encountered in a run, that could cause the leak of less than a kilobyte, which is probably tolerable. With millions of file openings and closings, that would no longer be true.
Which version of IFort did you use?
This is the equivalent WinAPI code to what INQUIRE() is doing, note the call to FindClose to fix a memory leak:
RECURSIVE FUNCTION file_exists (fname) RESULT (size) IMPLICIT NONE TYPE(T_WIN32_FIND_DATA) :: fdata CHARACTER(LEN=*),INTENT(IN) :: fname ! full pathname to file INTEGER(HANDLE) :: ihandl INTEGER :: size, rval, nc size = -1 nc = chcnt(fname, LEN(fname)) IF (nc > 5) THEN ihandl = FindFirstFile (fname, fdata) IF (ihandl /= INVALID_HANDLE_VALUE) THEN size = fdata%nFileSizeLow ! added in v5.024; without this we had a memory leak rval = FindClose (ihandl) ENDIF END IF END FUNCTION file_exists
I strongly endorse the suggestion to open the file once and leave it open.