Open statement fails intermitently

[dajum]

I call this statement thousands of times in a run.

OPEN(UNIT=147,ACCESS='SEQUENTIAL',FORM='BINARY',STATUS='UNKNOWN',FILE=fnl(NUMOUT)%filename, ERR=20,IOSTAT=iERR)

Most runs it works just fine.  But very infrequently it fails with IERR=37.  Why would it think it was direct access? I'm not setting a RECL and the ACCESS and FORM should define it sufficiently to not be direct access. So the status is puzzling.  Because it mostly works, is this message just random and some other issue exists in the lower level file handling code? How make this so it doesn't randomly fail?

[dajum]

One additional point.  I just put it in a loop to try again, and it will run giving me the correct output.  It appears something in the file handling system has an issue I can't see.

[Steve_Lionel]

My initial guess is that you have a memory corrupter somewhere in your program. Try this as an experiment - move that OPEN to its own subroutine and call it from where you have the OPEN. Does the behavior change?

[dajum]

Thanks for your help Steve!

No it still fails.  I took out the IOSTAT and ERR and let it crash without catching it and it gives error 256 which seems to still be the same cause. 

There are factors here that might impact this.  This code runs in a thread.  Other output in other units (but not this unit) may be happening in the main thread.  But it is pretty random on when it occurs.  Have yet to see it exactly at the same file. The model I'm running writes about 30 files in 213 folders.  But it is run from another program and runs it 10 times, and it is random which of the 10 runs causes the crash.  But if I just loop back and do the open a second time it seems to succeed because I don't get any failures that way.

[Barbara_P_Intel]

What version of the compiler are you using?   Other developers reported random I/O issues when using OpenMP and doing I/O in different threads. Those reported problems are fixed in the current release.

[dajum]

Hi Barbara,

I'm using Version 19.1.1.216 Build 20200306.  I have a user getting the same error with an older version, but not sure which one at the moment. When you say current you mean 2021.3?

Thanks,

Dave

[Barbara_P_Intel · Accepted solution]

Yes, I do. The current release is ifort (IFORT) 2021.3.0 20210609.

[Steve_Lionel]

Ah, you didn't mention threading! (Nor did you mention the compiler version.) Barbara likely has the right idea here.

[dajum]

Thanks to both of you for the help. I was able to verify that using the 2021.3 version to build and run our executable no longer hits the error.  This still uses our libraries that are all built with 19.1.1.216, so this is very good. Thanks!

[Barbara_P_Intel]

That's GREAT news!  You're welcome!