GNU f90 read() run time error
lumbot
Fortran runtime error: I/O past end of record on unformatted file
The codes are:
character(100)fin
real(4)a
fin='xx.bin'
open(unit=2,file=fin,status='old',ACCESS='SEQUENTIAL',FORM='UNFORMATTED')
read(2)a
write(*,*)a
close(2)
The file exists
>l xx.bin
-rw-r--r-- 1 -- staff 19353628 May 5 14:01 ./xx.bin
Any clue
Arjen Markus
The first record in the file (assuming the file is properly
structured
as an unformatted file) could be shorter than the number of bytes that
make up a single real.
While unformatted files can have any structure, depending on the
compiler
used for the program that created the file, most nowadays use the
following scheme:
- Each record starts with 4 bytes indicating the number of bytes of
data
- The same 4 bytes appear after the data bytes
Could the file possible be a _binary_ file? For instance it is written
by a C program, so it is not structured with records and record
markers?
In that case, try ACCESS='STREAM' (a sufficiently modern version of
gfortran supports that F2003 feature)
Regards,
Arjen
Tobias Burnus
> I am getting the following error:
> Fortran runtime error: I/O past end of record on unformatted file
You haven't told us the version of the compiler you are using - nor how
you have created the file you are reading (if you used a different
compiler/compiler version to create it, tell us which).
Tobias
glen herrmannsfeldt
> I am getting the following error:
> Fortran runtime error: I/O past end of record on unformatted file
> The file exists
>>l xx.bin
> -rw-r--r-- 1 -- staff 19353628 May 5 14:01 ./xx.bin
Try:
od -x xx.bin | head
-- glen
feenberg
Unless the file was written by a Fortran program from the same
compiler, "unformatted" will not be able to read the file.
Fortran "unformatted" is not a way to read generic binary
data, but only reads record oriented files with a specific
non-portable structure. To read files from another source
a direct access file with a record length of 1 is possible.
Daniel Feenberg
Tobias Burnus
> Unless the file was written by a Fortran program from the same
> compiler, "unformatted" will not be able to read the file.
Well, the situation is not that bad; often a file written with one
Fortran compiler can also be opened using a different compiler - but,
granted, it does not always work. One also need to watch out for endian
differences, if one transfers files from a different platform, but with
compiler options/environment variables, one can usually handle those.
Tobias
Richard Maine
> To read files from another source
> a direct access file with a record length of 1 is possible.
Sometimes. There really isn't any completely bullet-proof and portable
method before the access='stream' of f2003. There are multiple
situations in which a record length of 1 won't work.
There are compilers for which the 1 means 1 word instead of 1 byte
(although there tend to be options to change that, at least with recent
compilers).
There are systems where the record length can't be arbitrary (for
example, it might need to be a multiple of the word length) or where
some record lengths imply record padding.
There are compilers where direct access files also have file or record
headers instead of being pure data.
There is also the mess of having to put together the 1-byte pieces after
you have read them. Don't assume that you can, for example, just read a
4-byte real with a record length of 1 byte, causing the compiler to read
4 records. That trick is non-standard and non-portable.
All that being said, things will often, perhaps even usually, work
(assuming you really do read 1 byte at a time and do asembly
separately). But there are enough caveats that I consider it misleading
to imply that it works without qualification.
Stream acess is *MUCH* more straightforward and has far fewer caveats;
that's why it was added.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
lumbot
The file was created by IDL into a binary in Mac Snow Leopard; I am
reading the file on linux. Endian is the same.
I don't think there is any first record indicating the number of
bytes. There are 7*691201 records of 4 bytes --> 19353628 that is the
file size.
----
Somehow 'sequential' does not work. Maybe I am using F90 (not F2003)
open(unit=2,file=fin,status='old',ACCESS='stream',FORM='UNFORMATTED',iostat=open_status)
if(open_status>0)stop"unit2 open error"
> ./mk_07orb_1sec
STOP unit2 open error
----
od -x xx.bin | head
0000000 0000 0000 4cee 45db d8c8 c3ee bcd3 441f
0000020 b7c8 3f1b 14b6 bf8e 0638 c0ed 0001 0000
0000040 51c3 45db 66d4 c3ef e2c1 441d aec5 3f19
0000060 02f3 bf8e 0c22 c0ed 0002 0000 5689 45db
0000100 f4ce c3ef 08a3 441c a5b1 3f17 f128 bf8d
0000120 11f9 c0ed 0003 0000 5b3e 45db 82b6 c3f0
0000140 2e79 441a 9c9d 3f15 df55 bf8d 17c0 c0ed
0000160 0004 0000 5fe2 45db 108d c3f1 5444 4418
0000200 9379 3f13 cd79 bf8d 1d73 c0ed 0005 0000
0000220 6477 45db 9e51 c3f1 7a03 4416 8a55 3f11
----
I tried to read in direct access mode
integer(4)isec
real(4)scpos15(3),scvel15(3)
open(unit=2,file=fin,status='old',ACCESS='direct',FORM='UNFORMATTED',iostat=open_status,recl=4)
if(open_status>0)stop"unit2 open error"
read(2,rec=1)isec
read(2,rec=2)scpos15 (this is line 27)
read(2,rec=5)scvel15
the first record, isec, is now read correctly, but not the rest
> ./mk_07orb_1sec
At line 27 of file mk_07orb_1sec.f90
Fortran runtime error: Short record on unformatted read
Louis Krupp
> Thanks everyone,
> The file was created by IDL into a binary in Mac Snow Leopard; I am
> reading the file on linux. Endian is the same.
> I don't think there is any first record indicating the number of
> bytes. There are 7*691201 records of 4 bytes --> 19353628 that is the
> file size.
> ----
> Somehow 'sequential' does not work. Maybe I am using F90 (not F2003)
>
> open(unit=2,file=fin,status='old',ACCESS='stream',FORM='UNFORMATTED',iostat=open_status)
> if(open_status>0)stop"unit2 open error"
>> ./mk_07orb_1sec
> STOP unit2 open error
Try it without the iostat clause. You'll get a more informative message.
Louis
Gordon Sande
Standard issues with very poorly asked question:
1. What system? GNU Fortran supports many. Which GNU Fortran? G95 and Gfortran
are both "GNU Fortran"s and both claim to be fortran 95.
2. Where did the unformatted file come from? What program wrote it? Do you
really know what "unformatted" means as a Fortran technical adjective? It
is what others call "binary" (but all files are binary on a binary computer so
common descriptions are pretty flakey at best).
3. Have you octal/hex dumped the "unformatted" file to verify that it
follows the
Fortran rule for being an unformatted file. The fortran rules are very strict
to support long records, backspacing, partial reading etc.
4. Did you think you were getting a byte sequential read which is Fortran 2003
and has various names as an extension to earlier versions.
Richard Maine
> The file was created by IDL into a binary in Mac Snow Leopard; I am
> reading the file on linux. Endian is the same.
> I don't think there is any first record indicating the number of
> bytes. There are 7*691201 records of 4 bytes --> 19353628 that is the
> file size.
> ----
> Somehow 'sequential' does not work.
That's because what you have is not a Fortran unformatted sequential
file. As others have noted, that is a particular form, which isn't what
you have.
> Maybe I am using F90 (not F2003)
Not pertinent to sequential or direct access. The only relevance to
f2003 is that f2003's stream access is really what you want. Many/most
f90/f95 compilers today do support the f2003 stream facility. I
recommend you pursue that. I don't recall exactly what compiler you are
using (GNU f90 isn't adequately descriptive, as Gordon mentioned). But I
believe that recent versions of both g95 and gFortran do support stream.
>
open(unit=2,file=fin,status='old',ACCESS='stream',FORM='UNFORMATTED',ios
tat=open_status)
> if(open_status>0)stop"unit2 open error"
> > ./mk_07orb_1sec
> STOP unit2 open error
Hmm. As Louis mentioned, taking the iostat out should give a better
message explaining what was wrong with the open. Assuming that the file
does exist and is readable (those assumptions are important; it is easy
to get lead astray on things like that) it might be that you are using
an old enough version of the compiler that it doesn't support stream.
The error message should make that evident, though.
> I tried to read in direct access mode
> integer(4)isec
> real(4)scpos15(3),scvel15(3)
>
>
open(unit=2,file=fin,status='old',ACCESS='direct',FORM='UNFORMATTED',ios
tat=open_status,recl=4)
> if(open_status>0)stop"unit2 open error"
> read(2,rec=1)isec
> read(2,rec=2)scpos15 (this is line 27)
> read(2,rec=5)scvel15
> the first record, isec, is now read correctly, but not the rest
> > ./mk_07orb_1sec
> At line 27 of file mk_07orb_1sec.f90
> Fortran runtime error: Short record on unformatted read
That's because you are trying to read 3 values (12 bytes) from the
second record. The rec=2 doesn't mean to start at the second record and
read as far as needed. It means to read just the second record. Some
compilers have non-portable hacks in this area, in particular, I think
some compilers special-case recl=1 to imply such behavior, but that's
not standard. That's one of the thinks that makes direct access a bit of
a pain for this purpose; doable, but sometimes painful.
lumbot
below and it works (as follows). There is 16B at the beginning. IDL
(interactive data language) does not create the head unless I use a
special flag. I think the case is closed.
character(100) fio
real(4) a(10),b(10)
integer(4) i
do i=1,10
a(i)=i
enddo
fio='./x.bin'
open(4,file=fio,status='replace',form='unformatted')
write(4)a
close(4)
open(2,file=fio,status='old',form='unformatted',access='sequential')
read(2)b
close(2)
write(*,*)b
robert....@oracle.com
The usual reason that error is given is that size of the data
being read exceeds the size of the record in the file. As
Arjen said, for most Fortran implementations on UNIX or Unix-like
operating systems, the length is in a four-byte header that
precedes the record. If the variable a is larger than the first
record in the file, then that is your problem.
Bob Corbett
Dave Allured
Others suggested reading this file with stream access. However I think
it was written by IDL specifically for direct access. It appears to be
direct access, little endian, record length 28 bytes, with the first
"word" of each record being a default 4-byte integer. I suppose the
other six "words" are default 4-byte reals, but I can't make out the
complete pattern for sure. Your sample code below reinforces this
guess.
You could also read the file as individual 4 byte "words", which is what
I think you are trying to do below. That is more confusing. That way,
you are doing more work keeping track of explicit word offsets for the
integer and six reals within each logical record. The errors you
encountered are a consequence of this. Better I think to make fortran
do that housekeeping for you, just read the file as 691201 logical
records of seven "words" each; one integer and six reals.
One caveat is that the units of "recl=" is not standardized. It may be
in bytes or 4-byte "words". IIRC it is bytes for gfortran on linux, but
I don't remember for sure. There may be a compiler line option to
change that.
> I tried to read in direct access mode
> integer(4)isec
> real(4)scpos15(3),scvel15(3)
>
> open(unit=2,file=fin,status='old',ACCESS='direct',FORM='UNFORMATTED',iostat=open_status,recl=4)
> if(open_status>0)stop"unit2 open error"
> read(2,rec=1)isec
> read(2,rec=2)scpos15 (this is line 27)
> read(2,rec=5)scvel15
> the first record, isec, is now read correctly, but not the rest
> > ./mk_07orb_1sec
> At line 27 of file mk_07orb_1sec.f90
> Fortran runtime error: Short record on unformatted read
Try the following, change recl from 28 to 7 if necessary (probably
not). Note that I made your variables to be default integers and
reals. This assumes the most likely scenario that your compiler uses
default 4-byte integers and reals. Explicit kind numbers e.g.
integer(4) are another can of worms for a different conversation.
integer isec
real scpos15(3), scvel15(3)
open(unit=2,file=fin,status='old',ACCESS='direct', &
iostat=open_status,recl=28)
if(open_status>0)stop"unit2 open error"
read (2,rec=1) isec, scpos15, scvel15
Subsequent record numbers go from 2 to 691201, incrementing by 1.
Stream access will also get the job done. Call it style, but I prefer
direct access for files that were constructed for that purpose in the
first place.
--Dave
maji...@gmail.com
I've faced to a run time fortran error: At line 28 of file output2data.f90 (unit = 1, file = 'OUTPUT.combined') Fortran runtime error: Bad real number in item 1 of list input
could you please help me to flee from that. Thanks in advance
The following is the part of my code.
PROGRAM output2data
IMPLICIT none
CHARACTER*42 :: syscom
CHARACTER*16 :: arubbish
CHARACTER*7 :: outputline
REAL :: data(99999,6,10)
INTEGER :: iii, jjj, startlinenumber, endlinenumber, nnn
print *,"Reading data..."
CALL SYSTEM ("cat OUTPUT > OUTPUT.combined 2> OUTPUT.combined.err")
data=0.
jjj=0
nnn=0
OPEN(1,FILE="OUTPUT.combined")
DO WHILE (.TRUE.)
READ(1,*,end=9991) outputline
IF (outputline .eq. "rolling") THEN ! We've found a data entry
! Rewind to the beginning of the data entry
BACKSPACE(1)
BACKSPACE(1)
BACKSPACE(1)
BACKSPACE(1)
BACKSPACE(1)
! Read in the numbers
jjj=jjj+1
READ(1,*,end=9991) data(jjj,1,1:10)
READ(1,*,end=9991) data(jjj,2,1:10)
READ(1,*,end=9991) data(jjj,3,1:10)
READ(1,*,end=9991) arubbish, data(jjj,4,2:10)
READ(1,*,end=9991) arubbish, data(jjj,5,2:10)
READ(1,*,end=9991) data(jjj,6,2:10)
END IF
END DO
9991 CONTINUE
CLOSE(1)
glen herrmannsfeldt
> I've faced to a run time fortran error: At line 28 of file
> output2data.f90 (unit = 1, file = 'OUTPUT.combined')
> Fortran runtime error: Bad real number in item 1 of list input
> could you please help me to flee from that. Thanks in advance
important, at least through, and maybe a few lines past, line 28.
> The following is the part of my code.
> PROGRAM output2data
> IMPLICIT none
> CHARACTER*42 :: syscom
> CHARACTER*16 :: arubbish
> CHARACTER*7 :: outputline
> REAL :: data(99999,6,10)
> INTEGER :: iii, jjj, startlinenumber, endlinenumber, nnn
> OPEN(1,FILE="OUTPUT.combined")
> DO WHILE (.TRUE.)
> READ(1,*,end=9991) outputline
> IF (outputline .eq. "rolling") THEN ! We've found a data entry
> ! Rewind to the beginning of the data entry
> BACKSPACE(1)
> BACKSPACE(1)
> BACKSPACE(1)
> BACKSPACE(1)
> BACKSPACE(1)
list-directed (* format) input or output.
List directed I/O can go to the next record at arbitrary points,
which the program won't know about. That can easily result in
the program reading from a different record than you believe
that it is reading.
-- glen
m.shah...@gmail.com
Thanks for your response. Once I used ifort instead of gfortran the following error has been cleared. Of course, I followed your comment about BACKSPACE but this error is happened too. Do you have any idea
forrtl: severe (59): list-directed I/O syntax error, unit 1, file /home/majid/Aquaporin/OUTPUT.combined
Image PC Routine Line Source
output2data.ex 000000000041B13A Unknown Unknown Unknown
output2data.ex 0000000000418D37 Unknown Unknown Unknown
output2data.ex 0000000000402F44 Unknown Unknown Unknown
output2data.ex 0000000000402BD6 Unknown Unknown Unknown
libc.so.6 00007F882011F76D Unknown Unknown Unknown
output2data.ex 0000000000402AC9 Unknown Unknown Unknown
Gordon Sande
> Hi All,
>
> I've faced to a run time fortran error: At line 28 of file
> output2data.f90 (unit = 1, file = 'OUTPUT.combined') Fortran runtime
> error: Bad real number in item 1 of list input
>
> could you please help me to flee from that. Thanks in advance
Here, you want advice on an input data file so show the data file. And for
extra credit show a hex/octal/whatever dump of the file to show nonprinting
characters. File formats are system dependent with line termination a
bother, particularly if the data file comes from a system with a different
convention.
At some point you will be asked to use a real format rather than relying on
a list directed format.
robin....@gmail.com
2 is not a good number to use.
e p chandler
> Hi All,
> I've faced to a run time fortran error: At line 28 of file output2data.f90 (unit = 1, file = 'OUTPUT.combined') Fortran runtime error: Bad real number in item 1 of list input
> could you please help me to flee from that. Thanks in advance
2. Also, it is a good idea to use unit numbers higher than what you are using.
On some systems low unit numbers such as 1, 2, 5 or 6 are pre-connected with keyboard input, display output and so on.
3. Lastly, DO WHILE (.TRUE.) ... END DO *is* a valid "loop forever" construct. However, DO ... END DO accomplishes the same thing. IMO it is a more regularly used language idiom. I think that if you want to emphasize the nature of the loop, why not just use comments:
DO ! until end of file
END DO ! why not break out via an IF statement?
--- e
maji...@gmail.com
I followed your comments but the error is happened too. the part of My input file is as follows;
1 3.8605E+06 5.9562E+02 3.7621E+06 3.7604E+06 1.6482E+03 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00
0.200f 1.9889E+07 0.0000E+00 -4.7888E+07 -4.7039E+07 -1.7072E+03 0.0000E+00 0.0000E+00 -8.4757E+05 0.0000E+00
7.075s 1.2500E+05 0.0000E+00 0.0000E+00 0.0000E+00 9.0000E+01 9.0000E+01 9.0000E+01 0.0000E+00 2.1014E+03
rolling 3.8605E+06 5.9562E+02 3.7621E+06 3.7604E+06 1.6482E+03 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00
averages 1.9889E+07 0.0000E+00 -4.7888E+07 -4.7039E+07 -1.7072E+03 0.0000E+00 0.0000E+00 -8.4757E+05 0.0000E+00
1.2500E+05 0.0000E+00 0.0000E+00 0.0000E+00 9.0000E+01 9.0000E+01 9.0000E+01 0.0000E+00 2.1014E+03
------------------------------------------------------------------------------------------------------------------------
500 3.8464E+06 1.1871E+04 5.4782E+05 6.5969E+05 -1.1187E+05 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00
100.000f 6.3010E+06 0.0000E+00 -7.4522E+06 -9.3373E+06 1.1181E+05 0.0000E+00 0.0000E+00 1.7732E+06 0.0000E+00
39.083m 1.2500E+05 0.0000E+00 0.0000E+00 0.0000E+00 9.0000E+01 9.0000E+01 9.0000E+01 0.0000E+00 4.9712E+02
rolling 3.8463E+06 1.5734E+04 7.5357E+05 8.7704E+05 -1.2347E+05 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00
averages 8.4862E+06 0.0000E+00 -1.0199E+07 -1.2025E+07 1.2342E+05 0.0000E+00 0.0000E+00 1.7029E+06 0.0000E+00
1.2500E+05 0.0000E+00 0.0000E+00 0.0000E+00 9.0000E+01 9.0000E+01 9.0000E+01 0.0000E+00 6.7294E+02
my code
READ(1,*,end=9991) arubbish, data(jjj,5,2:10)
READ(1,*,end=9991) data(jjj,6,2:10)
END IF
END DO
9991 CONTINUE
CLOSE(1)
glen herrmannsfeldt
> On Tuesday, July 22, 2014 12:02:10 AM UTC+9, e p chandler wrote:
>> On Monday, July 21, 2014 12:29:07 AM UTC-4, maji...@gmail.com wrote:
>> > I've faced to a run time fortran error: At line 28 of file
>> > output2data.f90 (unit = 1, file = 'OUTPUT.combined') Fortran
>> > runtime error: Bad real number in item 1 of list input
>> 1. I suggest you add some WRITE statements interspersed with your
>> READ statements to display the data you have just read.
>> Does it match with what you *think* you are reading?
>> Does it match with what is in the input file?
identifier for which statement it is, and the first value read.
READ(1,*,end=9991) data(jjj,1,1:10)
WRITE(*,*) "one",data(jjj,1,1)
>> 2. Also, it is a good idea to use unit numbers higher than what
>> you are using.
numbers have caused problems.
>> On some systems low unit numbers such as 1, 2, 5 or 6 are
>> pre-connected with keyboard input, display output and so on.
> I followed your comments but the error is happened too. the part of My input file is as follows;
> 1 3.8605E+06 5.9562E+02 3.7621E+06 3.7604E+06 1.6482E+03 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00
> 0.200f 1.9889E+07 0.0000E+00 -4.7888E+07 -4.7039E+07 -1.7072E+03 0.0000E+00 0.0000E+00 -8.4757E+05 0.0000E+00
What is the f for?
> 7.075s 1.2500E+05 0.0000E+00 0.0000E+00 0.0000E+00 9.0000E+01 9.0000E+01 9.0000E+01 0.0000E+00 2.1014E+03
> rolling 3.8605E+06 5.9562E+02 3.7621E+06 3.7604E+06 1.6482E+03 0.0000E+00 0.0000E+00 0.0000E+00 0.0000E+00
> averages 1.9889E+07 0.0000E+00 -4.7888E+07 -4.7039E+07 -1.7072E+03 0.0000E+00 0.0000E+00 -8.4757E+05 0.0000E+00
> 1.2500E+05 0.0000E+00 0.0000E+00 0.0000E+00 9.0000E+01 9.0000E+01 9.0000E+01 0.0000E+00 2.1014E+03
> ------------------------------------------------------------------------------------------------------------------------
easily cause problems. It is not easy to be sure where in the file you
are, and so where the BACKSPACE goes to.
-- glen
e p chandler
> input file is as follows;
Suppose that the mis-alignment of the first line is an artifact of posting.
Then you have records of data in strict column format.
The first column is descriptive data or spaces. This is followed by *NINE*
columns of data.
> PROGRAM output2data
> IMPLICIT none
> CHARACTER*42 :: syscom
> CHARACTER*16 :: arubbish
> CHARACTER*7 :: outputline
> REAL :: data(99999,6,10)
> INTEGER :: iii, jjj, startlinenumber, endlinenumber, nnn
> print *,"Reading data..."
> CALL SYSTEM ("cat OUTPUT > OUTPUT.combined 2> OUTPUT.combined.err")
> data=0.
> jjj=0
> nnn=0
> OPEN(1,FILE="OUTPUT.combined")
> DO WHILE (.TRUE.)
> READ(1,*,end=9991) outputline
> IF (outputline .eq. "rolling") THEN ! We've found a data entry
> ! Rewind to the beginning of the data entry
> BACKSPACE(1)
> BACKSPACE(1)
> BACKSPACE(1)
> BACKSPACE(1)
> BACKSPACE(1)
> ! Read in the numbers
> jjj=jjj+1
> READ(1,*,end=9991) data(jjj,1,1:10)
It reads *TEN* data items, the first of which is the sequence number 1.
> READ(1,*,end=9991) data(jjj,2,1:10)
On to the next record. It attempts to read *TEN* data items, the first,
"0.200f" as a REAL number. It fails.
The trailing "f" is a problem.
> READ(1,*,end=9991) data(jjj,3,1:10)
> ! READ(1,*,end=9991) arubbish ! Blank line - APPARENTLY NOT NEEDED - DON'T
> KNOW WHY
> READ(1,*,end=9991) arubbish, data(jjj,4,2:10)
> READ(1,*,end=9991) arubbish, data(jjj,5,2:10)
> READ(1,*,end=9991) data(jjj,6,2:10)
> END IF
> END DO
> 9991 CONTINUE
> CLOSE(1)
of data in it.
List directed read would then advance to the next record. Now you are out of
sequence.
--- e
Gordon Sande
read that has a 1:10.
Sometimes there is no leading text with 2:10 which would make trouble
for the initial read
of 1:10. Every look at this "solution" finds another level of confusion.
It would have been better to have read every data item with a known
fixed format
and only kept the one set of values that were wanted. Sometimes a gross
waste of
machine time is the efficient way to do things! At least there would
have be a quick
answer with less wasted time and earlier recognition of the defects in
either the data
or its description.
>
> --- e
robin....@gmail.com
> On Tuesday, July 22, 2014 12:02:10 AM UTC+9, e p chandler wrote:
>
> > On Monday, July 21, 2014 12:29:07 AM UTC-4, maji...@gmail.com wrote:
> > > Hi All,
> > > I've faced to a run time fortran error: At line 28 of file
> output2data.f90 (unit = 1, file = 'OUTPUT.combined') Fortran runtime error: >Bad real number in item 1 of list input
The last few numbers will will you what the program was processing
when the error occurred.
It could also help to echo (i.e., print each data as it is read in).
As well, I note that in the first data column 1, some values are followed by
a letter. Could this be the cause of your problem?
> > > READ(1,*,end=9991) data(jjj,2,1:10)
> > > READ(1,*,end=9991) data(jjj,3,1:10)
>
> >
>
> > > READ(1,*,end=9991) arubbish, data(jjj,4,2:10)
>
> >
>
> > > READ(1,*,end=9991) arubbish, data(jjj,5,2:10)
>
> >
>
> > > READ(1,*,end=9991) data(jjj,6,2:10)
>
> >
>
> > > END IF
>
> >
>
> > > END DO
>
> >
>
> > > 9991 CONTINUE
>
> >
>
> > > CLOSE(1)
>
> >
>
> >
>
> >
>
> > 1. I suggest you add some WRITE statements interspersed with your READ statements to display the data you have just read. Does it match with what you *think* you are reading? Does it match with what is in the input file?
>
> >
>
> >
>
> >
>
> > 2. Also, it is a good idea to use unit numbers higher than what you are using.
>
> >
>
> > On some systems low unit numbers such as 1, 2, 5 or 6 are pre-connected with keyboard input, display output and so on.
>
> >
>
> >
>
> >
>
> > 3. Lastly, DO WHILE (.TRUE.) ... END DO *is* a valid "loop forever" construct. However, DO ... END DO accomplishes the same thing. IMO it is a more regularly used language idiom. I think that if you want to emphasize the nature of the loop, why not just use comments:
>
> >
>
> >
>
> >
>
> > DO ! until end of file
>
> >
>
> >
>
> >
>
> > END DO ! why not break out via an IF statement?
>
> >
>
> >
>
> >
>
> > --- e
>
>
>
> Hi all,
>
>
>
> I followed your comments but the error is happened too. the part of My input file is as follows;
to use for files.
Use a number 10 or greater.
e p chandler
>> are trying to read 10 columns of data from a record with only 9
>> columns of data in it.
> read that has a 1:10.
> Sometimes there is no leading text with 2:10 which would make trouble
> for the initial read
> of 1:10. Every look at this "solution" finds another level of confusion.
> It would have been better to have read every data item with a known
> fixed format and only kept the one set of values that were wanted.
> Sometimes a gross waste of machine time is the efficient way to do things!
> At least there would have be a quick answer with less wasted time and earlier
> recognition of the defects in either the data or its description.
--- e
e p chandler
>> It would have been better to have read every data item with a known
>> fixed format and only kept the one set of values that were wanted.
>> Sometimes a gross waste of machine time is the efficient way to do things!
>> At least there would have be a quick answer with less wasted time and >
> I think the OP expected a Fortran READ to follow the example of some other
> programming language, where a trailing non-numeric character terminates
> evaluating a numeric value without throwing a fatal error. So he read in 10
> columns of data into an array, expecting that the trailing unit specifiers
> on the data in column one would be ignored.
"C"s scanf does behave this way.
glen herrmannsfeldt
> On Tuesday, July 22, 2014 1:22:58 PM UTC-4, e p chandler wrote:
>> I think the OP expected a Fortran READ to follow the example of some other
>> programming language, where a trailing non-numeric character terminates
>> evaluating a numeric value without throwing a fatal error. So he read in 10
>> columns of data into an array, expecting that the trailing unit specifiers
>> on the data in column one would be ignored.
> [please excuse reply to self]
> "C"s scanf does behave this way.
won't skip the unreadable character, but leave it for the next one.
Only if you read individual items as characters, and then pass them
to sscanf() will it ignore strange characters at the end of data items.
-- glen
e p chandler
glen herrmannsfeldt wrote:
>> "C"s scanf does behave this way.
> Well, not really. For one, if you read 10 items with one scanf(), it
> won't skip the unreadable character, but leave it for the next one.
> Only if you read individual items as characters, and then pass them
> to sscanf() will it ignore strange characters at the end of data items.
I was just trying to figure out where the OP's erroneous ideas came from.
--- The bogon flux has bitten me several times today.
Terence
Historically, and depemding on the compiler vendor, at least 4 of these
numbers are assigned to defaault human interface units of Screen, Keyboard,
Punch and Printer (the obsolete punch device became a second error reporting
printer in the '80s)..
As suggested by Robin, start with any integers of 10 and upward.
Zero is still a valid number to designate the screen, and '*' to mean
keyboard, in all compilers I have met.
But I haven't tried all of them.
maji...@gmail.com
Thank you so much for your comprehensive comments. Your comments really helped me to fix the problem. Thanks again
John Harper
> Definitely do not try to use file numbers 0,1,2,3,4,5,6.
>
> Historically, and depemding on the compiler vendor, at least 4 of these
> numbers are assigned to defaault human interface units of Screen,
> Keyboard, Punch and Printer (the obsolete punch device became a second
> error reporting printer in the '80s)..
>
> As suggested by Robin, start with any integers of 10 and upward.
used 5,6,19,21,23,44 for its own purposes and my Fortran programs did weird
things if I tried to use 19,21,23 or 44 myself. (I never tried unit 0 then.)
One current graphics package uses 0,5,6,99. The subroutine opennow below
checks unit numbers between 0 and 100 and is worth calling at various stages
in your program if you suspect unit-number trouble.
subroutine opennow(string)
! Reveals which units are open. Use string to say where program is at, e.g.
! call opennow('Just before graphics')
character,intent(in):: string*(*)
logical opnd
integer i
do i = 0,100
inquire(i,opened=opnd)
if(opnd)print*,'At "',string,'" unit ',i,' is open.'
end do
end subroutine opennow
--
John Harper
Gordon Sande
> Terence wrote:
>
>> Definitely do not try to use file numbers 0,1,2,3,4,5,6.
>>
>> Historically, and depemding on the compiler vendor, at least 4 of these
>> numbers are assigned to defaault human interface units of Screen,
>> Keyboard, Punch and Printer (the obsolete punch device became a second
>> error reporting printer in the '80s)..
>>
>> As suggested by Robin, start with any integers of 10 and upward.
>
> Even that can cause trouble. Many years ago we had a graphics package that
> used 5,6,19,21,23,44 for its own purposes and my Fortran programs did weird
> things if I tried to use 19,21,23 or 44 myself. (I never tried unit 0 then.)
> One current graphics package uses 0,5,6,99. The subroutine opennow below
> checks unit numbers between 0 and 100 and is worth calling at various stages
> in your program if you suspect unit-number trouble.
commonly used as
an internal file because of some serious hacking of the Fotran runtime on some
systems. As we know old habits die very slowly.