Run time error when opening SCRATCH file

[Terry_Wong]

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.

[Steve_Lionel]

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]

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]

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]

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]

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

[jimdempseyatthecove]

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]

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

[Terry_Wong]

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]

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]

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]

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.