Input conversion error

[anitac....@gmail.com]

HI,

I am trying to run a fortran code but keep getting input conversion error. I have tried and checked the formats and for other errors. But I couldn't find any issues. Hope you can help.

DO 166 L = 1,NINC
READ(3,1890,END=167) ELE,FRC(L),SMFRC,AREA
SUMAA = SUMAA + FRC(L)
SUMAEL = SUMAEL + (ELE*FRC(L))
C
SUMAR = SUMAR + AREA
AAR = 1. - SMFRC
C WRITE(*,1893) ELE,FRC(L),SMFRC,AREA,SUMAR
C PAUSE ' '

C
167 CONTINUE
1890 FORMAT (F9.2,3F9.4)
1892 FORMAT (F9.2,3F9.4,F9.2,I5)
1893 FORMAT (F9.2,3F9.4,F9.2)

File no 3 looks like this

ELE FRC SMFRC Area
4033 0.001 0.001 0.005
4043 0.002 0.003 0.009
4053 0.005 0.008 0.022
4063 0.005 0.013 0.023
4073 0.009 0.022 0.039
4083 0.012 0.034 0.053
4093 0.012 0.046 0.055
4103 0.011 0.057 0.047
4113 0.008 0.065 0.037
4123 0.016 0.081 0.070
4133 0.011 0.092 0.048
4143 0.010 0.101 0.042
4153 0.008 0.109 0.036
4163 0.005 0.115 0.024

ERROR

forrtl: severe (64): input conversion error, unit 3, file C:\Documents and Setti
ngs\Administrator\My Documents\PTAA14Oct\PTAA7B\HAMAA1
Image PC Routine Line Source
PTAA7B.exe 00446D09 Unknown Unknown Unknown
PTAA7B.exe 00446B67 Unknown Unknown Unknown
PTAA7B.exe 00445D44 Unknown Unknown Unknown
PTAA7B.exe 00446179 Unknown Unknown Unknown
PTAA7B.exe 0043E122 Unknown Unknown Unknown
PTAA7B.exe 00403E56 Unknown Unknown Unknown
PTAA7B.exe 00481289 Unknown Unknown Unknown
PTAA7B.exe 004666C9 Unknown Unknown Unknown
KERNEL32.dll 7C4E87F5 Unknown Unknown Unknown

Incrementally linked image--PC correlation disabled.
Press any key to continue

[anitac....@gmail.com]

a point to note it, outside the DO loop the titles of the columns in file 3 gets read properly

[Richard Maine]

<anitac....@gmail.com> wrote:

> I am trying to run a fortran code but keep getting input conversion error.
> I have tried and checked the formats and for other errors. But I
> couldn't find any issues. Hope you can help.
>
> DO 166 L = 1,NINC
> READ(3,1890,END=167) ELE,FRC(L),SMFRC,AREA
> SUMAA = SUMAA + FRC(L)
> SUMAEL = SUMAEL + (ELE*FRC(L))
> C
> SUMAR = SUMAR + AREA
> AAR = 1. - SMFRC
> C WRITE(*,1893) ELE,FRC(L),SMFRC,AREA,SUMAR
> C PAUSE ' '
>
> C
> 167 CONTINUE
> 1890 FORMAT (F9.2,3F9.4)
> 1892 FORMAT (F9.2,3F9.4,F9.2,I5)
> 1893 FORMAT (F9.2,3F9.4,F9.2)
>
> File no 3 looks like this
>
> ELE FRC SMFRC Area
> 4033 0.001 0.001 0.005
> 4043 0.002 0.003 0.009

And does that look like the format you are reading it with?
I'm guessing you are unfamiliar with Fortran fomats because it doesn't
look even close. The f9.2 at the beginning of your format says to look
for a field of 9 characters, with an implied decimal point before the
last 2. Ignoring the implied decimal point bit (and it is generally a
bad idea to count on it), it doesn't look to me like your first field
has 9 characters at all. I count only 4 numeric characters.... followed
by a tab.

And those tabs are likely to be part of your problem. The tab character
is not in the Fortran character set at all, so there's really no
guarantee what will happen with it. But odds are it will be read as a
single character. Perhaps you are assuming it will be expended to some
number of blanks. Perhaps some compiler might do that. Since it isn't
standard, pretty much anything could possibly happen, but I wouldn't
expect that.

Also, that first field sure looks like an integer to me. I'm not sure
why you are trying to read it with an F format. Speking of which, very
high on the list of frequently asked questions in the newsgroup is
asking posters to provide more information than isolated lines of code
wher ethey think the problem lies. In particular, declarations matter -
a lot.

Speaking of isolated lines of code, you don't show anything that reads
the first line of the file - the one with the column labels. From your
description, I'm guessing that you have other code that reads that line,
but I don't see it. If you don't skip over that line somehow, the code
you have shown certainly won't be able to read it (and would likely give
an input conversion error from attempting to do so).

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[herrman...@gmail.com]

On Monday, November 7, 2016 at 11:51:06 PM UTC-8, Richard Maine wrote:

> <anitac.warr...@gmail.com> wrote:

> > I am trying to run a fortran code but keep getting input conversion error.

(snip)

> > ELE FRC SMFRC Area
> > 4033 0.001 0.001 0.005
> > 4043 0.002 0.003 0.009

> And does that look like the format you are reading it with?
> I'm guessing you are unfamiliar with Fortran fomats because it doesn't
> look even close. The f9.2 at the beginning of your format says to look
> for a field of 9 characters, with an implied decimal point before the
> last 2. Ignoring the implied decimal point bit (and it is generally a
> bad idea to count on it), it doesn't look to me like your first field
> has 9 characters at all. I count only 4 numeric characters.... followed
> by a tab.

Interesting. I did a cut and paste off the original post, and got blanks.
(But not the right number for F9.2 and F9.4 format.)

But then I did a reply, and cut/paste off the reply text, and the
tabs were there.

> And those tabs are likely to be part of your problem. The tab character
> is not in the Fortran character set at all, so there's really no
> guarantee what will happen with it. But odds are it will be read as a
> single character. Perhaps you are assuming it will be expended to some
> number of blanks. Perhaps some compiler might do that. Since it isn't
> standard, pretty much anything could possibly happen, but I wouldn't
> expect that.

Yes, the DEC compilers, at least in the days before list directed
input, process tabs in an unusual way. As I remember, and without
looking it up, tab goes to the beginning of the next format
descriptor with a list item. (I am not sure now what it does with X.)

Fixed columns work well with cards, not so bad for disk file
input, but not so well at all with terminals. (Especially as most
don't tell you what column you are in.)

But list-directed is a better system.

> Also, that first field sure looks like an integer to me. I'm not sure
> why you are trying to read it with an F format. Speking of which, very
> high on the list of frequently asked questions in the newsgroup is
> asking posters to provide more information than isolated lines of code
> wher ethey think the problem lies. In particular, declarations matter -
> a lot.

Well, reading integers with F format isn't so bad.

Without the declarations, we don't know if ELE is real or integer.

> Speaking of isolated lines of code, you don't show anything that reads
> the first line of the file - the one with the column labels. From your
> description, I'm guessing that you have other code that reads that line,
> but I don't see it. If you don't skip over that line somehow, the code
> you have shown certainly won't be able to read it (and would likely give
> an input conversion error from attempting to do so).

He said it was read in successfully, but didn't show it.

Also, there is no statement 166, the end of the DO loop.

[Arjen Markus]

On Tuesday, November 8, 2016 at 10:11:13 AM UTC+1, herrman...@gmail.com wrote:

>
> Fixed columns work well with cards, not so bad for disk file
> input, but not so well at all with terminals. (Especially as most
> don't tell you what column you are in.)
>
> But list-directed is a better system.

But note that you have much less control over how things are read.

>
> Well, reading integers with F format isn't so bad.
>

I'd say: reading integer values into real variables using an F format isn't so bad. You should not try to read integer values into integer variables that way ;).

Also: a format like F9.0 is likely to cause less surprises - there will be no implicit decimal that way.

Regards,

Arjen

[Richard Maine]

Arjen Markus <arjen.m...@gmail.com> wrote:

> I'd say: reading integer values into real variables using an F format
> isn't so bad. You should not try to read integer values into integer
> variables that way ;).
>
> Also: a format like F9.0 is likely to cause less surprises - there will be
> no implicit decimal that way.

I'll buy less (well.... "fewer") surprises, but it isn't none. And there
is still an implicit decimal; it is just at the right end of the field.
Things are better these days with BN being the default (enough so that
many people won't know what I am talking about because barely anyone
actually uses the BN/BZ specifiers). But back in the f66 days, and in
some cases with some compilers in f77, try your F9.0 with an integer
value that isn't right justified in the field. Feel free to come back
here and ask what the heck just happened. :-(

[Richard Maine]

<herrman...@gmail.com> wrote:

> On Monday, November 7, 2016 at 11:51:06 PM UTC-8, Richard Maine wrote:

> > And those tabs are likely to be part of your problem....

> Interesting. I did a cut and paste off the original post, and got blanks.
> (But not the right number for F9.2 and F9.4 format.)

> But then I did a reply, and cut/paste off the reply text, and the
> tabs were there.

Hmm. I didn't notice that. In fact I didn't notice the tabs at all until
I was trying to use a cursor to count characters and noticed it jump
over what I originally thought were blanks. So I suppose it is vaguely
possible that the tabs were a posting artifact instead of in the
original file. I'm guessing not, but I can't be sure. In any case, as
you note, the number of blanks isn't right even if they are blanks, that
being why I had been trying to count them.

> Yes, the DEC compilers, at least in the days before list directed
> input, process tabs in an unusual way.

That this might be from old DEC code (or at least from someone using
practices from those days) occurred to me after I did my prior post. I
think the Intel compiler today might still do that funny thing with tabs
for compatibility with ancient code (and coders who still use the
practice), though I'm not sure and haven't bothered to test.

> But list-directed is a better system.

Of course list-directed isn't guaranteed to do what would be needed with
the tabs here either. It would be a reasonable extension, and I'd expect
most compilers to handle it, but it isn't actually specified in the
standard. Still, I'd agree that it is probably the easiest way to deal
with this input and is *PROBABLY* reasonably portable.

Another way is to use 1x to skip over the tabs. That does assume that
the tabs are always in exactly the same column (and that something has
not "helpfully" converted them to mltiple blanks for you).

The most robust way is, alas, slightly messy. It's probably what I'd do,
but then I already have library routines that take care of all the
messiness. Read each line into a string and then parse out the fields
yourself, accepting both tabs and blanks as field separators. That way
you are not sensitive to exact positioning and can handle the tabs
regardless of whether or not something has converted them to blanks
behind your back.

[herrman...@gmail.com]

On Tuesday, November 8, 2016 at 7:45:09 AM UTC-8, Richard Maine wrote:

(snip, I wrote)

> > Yes, the DEC compilers, at least in the days before list directed
> > input, process tabs in an unusual way.

> That this might be from old DEC code (or at least from someone using
> practices from those days) occurred to me after I did my prior post. I
> think the Intel compiler today might still do that funny thing with tabs
> for compatibility with ancient code (and coders who still use the
> practice), though I'm not sure and haven't bothered to test.

OK, I had to look this up, as I didn't remember how it
actually worked. I tended not to use it, as other compilers
I knew didn't do it.

Seems that I forgot, and that it is comma, and not tab.
(That was about 40 years ago, when I was using Fortran
on a PDP-10.)

If you put a comma into a numerical field, the effect of that
descriptor ends, and the following descriptor starts at the
next column. If you make w big enough, and there might even
be a default, then you can use comma separated input.

> > But list-directed is a better system.

> Of course list-directed isn't guaranteed to do what would be needed with
> the tabs here either. It would be a reasonable extension, and I'd expect
> most compilers to handle it, but it isn't actually specified in the
> standard. Still, I'd agree that it is probably the easiest way to deal
> with this input and is *PROBABLY* reasonably portable.

What I mean was that this (comma field terminator, I am not sure
now what it does with tabs) input method is similar to a non-standard
list directed input.

I don't know now when DEC got actual list directed (with the *) input
into their compilers.

> Another way is to use 1x to skip over the tabs. That does assume that
> the tabs are always in exactly the same column (and that something has
> not "helpfully" converted them to mltiple blanks for you).

Yes, that sounds like the hard way.

[Arjen Markus]

On Tuesday, November 8, 2016 at 4:45:09 PM UTC+1, Richard Maine wrote:

I have seen the deliberate use of implicit decimals, but that is a long time ago. And I know of the BN and BZ specifiers, but I do not recall any occasion to actually use them.

Regards,

Arjen

[herrman...@gmail.com]

On Wednesday, November 9, 2016 at 12:03:54 AM UTC-8, Arjen Markus wrote:

(snip)

> I have seen the deliberate use of implicit decimals, but that is a
> long time ago. And I know of the BN and BZ specifiers, but I do not
> recall any occasion to actually use them.

The likely use of BZ is for programs from the Fortran 66 days.

In Fortran 66, blanks in input fields read the same as zeros.
For E, F, and G where the input has a decimal point, this isn't
much of a problem. For I (also O and Z), it can easily give a
much larger value than expected. Also, for E, F, and G with
implied decimal.

Implied decimal point works pretty well on cards, where fields
go in specific columns, sometimes with the columns printed
on the card. Not so well on terminals.

[Arjen Markus]

Yes, it was used to read in a large matrix/table of data that were not all that accurate, so without the decimal point more data fitted on a line.

Regards,

Arjen

[herrman...@gmail.com]

On Wednesday, November 9, 2016 at 4:35:02 AM UTC-8, Arjen Markus wrote:
>
(snip, I wrote)

> > The likely use of BZ is for programs from the Fortran 66 days.

> > In Fortran 66, blanks in input fields read the same as zeros.
> > For E, F, and G where the input has a decimal point, this isn't
> > much of a problem. For I (also O and Z), it can easily give a
> > much larger value than expected. Also, for E, F, and G with
> > implied decimal.

> > Implied decimal point works pretty well on cards, where fields
> > go in specific columns, sometimes with the columns printed
> > on the card. Not so well on terminals.

> Yes, it was used to read in a large matrix/table of data that
> were not all that accurate, so without the decimal point more
> data fitted on a line.

Yes, but you can still use implied decimal point, and BN,
and fill in all the zeros. BZ saves typing some zeros.