Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26749 Discussions

Run time error when opening SCRATCH file

Terry_Wong
Beginner
555 Views

I am getting an error code return of 43 when I use an OPEN statement to to open a binary scratch file.

It seems to work the first time I call it, but then fails on the 2nd call.

Also, it only fails when I'm running in parallel using MPI. I only make the open call from the master processor.

 

0 Kudos
11 Replies
Steve_Lionel
Black Belt Retired Employee
554 Views

If you take off the IOSTAT so that the full message is displayed, what does it say? 

Try this - insert a SLEEPQQ(500) call just before the second open (or after a close). I have seen in the past that Windows sometimes takes a while to fully close a file after returning from the "close" call.

Terry_Wong
Beginner
554 Views

Steve:

When I leave off the iostat argument, the program will return with

forrtl: severe (43): file name specification error, unit 201, file "Unknown"

The open statement is as follows:

    open(unit, status="SCRATCH",form='UNFORMATTED',convert='BIG_ENDIAN')   

The program will run if I replace the status with REPLACE.

I tried inserting the SLEEPQQ but did not help.

When I remove the IOSTAT, the program keeps running in serial because I was testing on the value of iostat.

However, when I run it in parallel using MPI, the program will stop.

Terry

 

Steve_Lionel
Black Belt Retired Employee
554 Views

Interesting.  So there is only one thread per MPI rank?

The combination of SCRATCH and BIG_ENDIAN seems a bit odd to me. What are you doing with this?

jimdempseyatthecove
Black Belt
554 Views

Error 43 is Unit is already open. Have you somehow forgotten to close the unit prior to the second open?

>> I only make the open call from the master processor.

Is the close performed by the same thread? (in the event your "master" rank is multi-threaded)

Jim Dempsey

Steve_Lionel
Black Belt Retired Employee
554 Views

No, 43 is: "severe (43): File name specification error"

jimdempseyatthecove
Black Belt
554 Views

My mistake, when looking up, I transposed 43 to 34.

Can the user supply FILE="arbitrary"

And have the scratch file use the supplied name as opposed to a random name generated by the RTL?

Jim Dempsey

Steve_Lionel
Black Belt Retired Employee
554 Views

No - FILE= will be ignored if STATUS='SCRATCH'.

Terry_Wong
Beginner
554 Views

I modified the open statement as follows:

open(unit, status="SCRATCH",form='UNFORMATTED',iostat=ios, iomsg=iomsg)

Note I removed the BIG_ENDIAN specification in case that was an issue.

In multiple places in the code with different unit numbers, in serial mode, the call returned ios of 0 each time.

In parallel mode, using MPI with 2 processors, the open call always returned 43 as the error code, whether I opened that particular unit number for the first time or subsequent times.

Additionally, I only called the open statement from the master node.

I ensured that the file was closed before opening it with an inquire statement.

I removed my check on the condition of the ios value, and the code ran through to completion.

However, it is still disturbing to me that I'm getting different behavior between the serial and parallel codes.

Terry

Steve_Lionel
Black Belt Retired Employee
554 Views

Are you able to construct a simple test case that the Intel developers can try for themselves? Also, which exact compiler version are you using? Whose MPI?

Terry_Wong
Beginner
554 Views

Sorry I tried but I could not reproduce the problem with a simple case.

As a workaround, I was able to get the code to work by changing the status of the file to REPLACE from SCRATCH.  I also set the DISPOSE argument in the OPEN statement to DELETE so the file effectively acts like a SCRATCH file.

 

Terry

Steve_Lionel
Black Belt Retired Employee
554 Views

I wonder if some other part of your program is corrupting memory. This sort of thing can be very hard to find, though I have had some luck running a program under Intel Inspector XE. I am not sure how practical that is in an MPI application.

Reply