- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, 43 is: "severe (43): File name specification error"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No - FILE= will be ignored if STATUS='SCRATCH'.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page