Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
22 Views

Run time error when opening SCRATCH file

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
Highlighted
Retired Employee
22 Views

If you take off the IOSTAT so

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.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
22 Views

Steve:

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
Highlighted
Retired Employee
22 Views

Interesting.  So there is

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?

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
22 Views

Error 43 is Unit is already

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
Highlighted
Retired Employee
22 Views

No, 43 is: "severe (43): File

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

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
22 Views

My mistake, when looking up,

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
Highlighted
Retired Employee
22 Views

No - FILE= will be ignored if

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

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
22 Views

I modified the open statement

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
Highlighted
Retired Employee
22 Views

Are you able to construct a

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?

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
22 Views

Sorry I tried but I could not

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
Highlighted
Retired Employee
22 Views

I wonder if some other part

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.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos