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

Allowable unit numbers?

Izaak_Beekman
New Contributor II
1,792 Views
As far as I know the fortran standard does not say anything about the valid range of unit numbers or the pre-connected units (stdin,stdout,stderr). The pre-connected units I beleive are usually in the neighborhood of 4,5,6 and using the intrinsic module iso_fortran_env you can find them at run time.

Does anybody know:
1) if there is an upper bound on allowable unit numbers, and if so is this hardware dependant, compile dependant, OS dependant or some combination?
2) if there are any other unit numbers one must be carefull about, other than stdin,stdout,stderr and working within a valid range of numbers.
3) Is there a way to querry available unit numbers at runtime?
4) Is there a way to gracefully recover from openning bad unit numbers?

Many thanks in advance.
-Z
0 Kudos
10 Replies
TimP
Honored Contributor III
1,792 Views
If you read comp.lang.fortran for expert recommendations there, you'll see it is usual practice to assume no pre-opened unit numbers greater than 9 on current Fortran platforms. It wouldn't be a good quality implementation if there were a reliance on pre-connected units other than the 3 (at most) standard ones which you could find with iso_fortran_env.
When you OPEN a unit number which was pre-connected, you replace the pre-connected functionality and can't get it back. It should behave just as a unit number which was not previously connected, so that would not act as a "bad unit number."
0 Kudos
Izaak_Beekman
New Contributor II
1,792 Views
Quoting - tim18
If you read comp.lang.fortran for expert recommendations there, you'll see it is usual practice to assume no pre-opened unit numbers greater than 9 on current Fortran platforms. It wouldn't be a good quality implementation if there were a reliance on pre-connected units other than the 3 (at most) standard ones which you could find with iso_fortran_env.
When you OPEN a unit number which was pre-connected, you replace the pre-connected functionality and can't get it back. It should behave just as a unit number which was not previously connected, so that would not act as a "bad unit number."

It seems to me there is some upper bound on allowable unit numbers. For instance if I try to open a file connected to unit 124 the code just hangs. This is more what my question is about, allowable unit numbers, if there are certain units which don't exist, or should be avoided, what the maximum allowable unit number is and how to find all of this information.
0 Kudos
rreis
New Contributor I
1,792 Views
Quoting - zbeekman

It seems to me there is some upper bound on allowable unit numbers. For instance if I try to open a file connected to unit 124 the code just hangs. This is more what my question is about, allowable unit numbers, if there are certain units which don't exist, or should be avoided, what the maximum allowable unit number is and how to find all of this information.

I'm using unit numbers has high as 999 without problem...
0 Kudos
Izaak_Beekman
New Contributor II
1,792 Views
Quoting - rreis

I'm using unit numbers has high as 999 without problem...
Does 124 ever give you trouble? If I start at 110 and try to increment the unit number by 1 using a do loop to loop through the 106 files I am reading it hangs at 124. I haven't tried unit numbers greater than 124. I am on a RHEL derivative x86_64 machine.

03:28 PM (1) Codes $ uname -a
Linux XXXXXXXXX.XXXXXXXXX.EDU 2.6.18-128.1.1.el5 #1 SMP Tue Feb 10 18:09:15 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

0 Kudos
Ron_Green
Moderator
1,792 Views
Quoting - zbeekman
Does 124 ever give you trouble? If I start at 110 and try to increment the unit number by 1 using a do loop to loop through the 106 files I am reading it hangs at 124. I haven't tried unit numbers greater than 124. I am on a RHEL derivative x86_64 machine.

03:28 PM (1) Codes $ uname -a
Linux XXXXXXXXX.XXXXXXXXX.EDU 2.6.18-128.1.1.el5 #1 SMP Tue Feb 10 18:09:15 EST 2009 x86_64 x86_64 x86_64 GNU/Linux


Intel Fortran shouldn't have a problem with unit=124. However, your shell (process) will have a limit 'open files':

ulimit -a

to list it (look for 'open files' limit). However, this is typically 1024. Did you mean it hangs at 1024 and not 124? It would make sense that you'd have problems around this file limit.

ron
0 Kudos
Izaak_Beekman
New Contributor II
1,792 Views

Intel Fortran shouldn't have a problem with unit=124. However, your shell (process) will have a limit 'open files':

ulimit -a

to list it (look for 'open files' limit). However, this is typically 1024. Did you mean it hangs at 1024 and not 124? It would make sense that you'd have problems around this file limit.

ron

So, a while ago, I posted a possible compiler bug using asynchronous IO. I noticed that the asynchronous OPEN statements hung after the first 13 successful ones. For each file that was opened the unit number was incremented from 110 by 1. I tried changing this offset to 10 and now it appears that the code works, with the notable exception that the index variables in the implied do loops of asynchronous read statements do not appear to be "thread private" : I get segmentation faults, complaints about too much data required in read statements, and when compiled with the -check option i get array out-of-bounds errors. (I suspect that since multiple asynchronousIO files are open simultaneously with asynchronous reads they are incrementing the same index variable. Note, also, that I am using the fortran 03 language feature of asynchronous IO and NOT using openMP or any other explicit thread management.) Once I have nailed down whether there is a legitimate issue with my choice of unit numbers I plan to update the thread I started about the asynchronousIO issues. Also, ulimit -n is 1024 on all the machines I have been testing on, as Ron had mentioned.

Thanks for all the help,
-Z


0 Kudos
Ron_Green
Moderator
1,792 Views
Thanks for the details on what you are seeing. It does sound like there is something to investigate. Keep us updated on your progress and try to find a concise code reproducer so we can get a bug report going on this.

thanks

ron
0 Kudos
Steven_L_Intel1
Employee
1,792 Views
The range of unit numbers is implementation dependent. Intel Fortran allows any positive 32-bit integer as a unit number.

There was an issue related to the implementation of asynchronous I/O that caused "collision" between units with a certain spacing between them, but that has been fixed for a while now.
0 Kudos
Izaak_Beekman
New Contributor II
1,792 Views
The range of unit numbers is implementation dependent. Intel Fortran allows any positive 32-bit integer as a unit number.

There was an issue related to the implementation of asynchronous I/O that caused "collision" between units with a certain spacing between them, but that has been fixed for a while now.

Steve: Do you know which versions are affected by the bug? Thanks.
0 Kudos
Steven_L_Intel1
Employee
1,792 Views
Version 10.1 was affected. It was fixed in an update to 10.1 in July 2008. The issue affected two units whose numbers were separated by 521.
0 Kudos
Reply