Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Run time error when opening SCRATCH file

Terry_Wong
Beginner
1,383 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
Honored Contributor III
1,382 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.

0 Kudos
Terry_Wong
Beginner
1,382 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

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,382 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?

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,382 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

0 Kudos
Steve_Lionel
Honored Contributor III
1,382 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,382 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

0 Kudos
Steve_Lionel
Honored Contributor III
1,382 Views

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

0 Kudos
Terry_Wong
Beginner
1,382 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

0 Kudos
Steve_Lionel
Honored Contributor III
1,382 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?

0 Kudos
Terry_Wong
Beginner
1,382 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

0 Kudos
Steve_Lionel
Honored Contributor III
1,382 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.

0 Kudos
Reply