Error!

Folks
hi,
I have a fortran code that i am running in the Windows smoothly, but in Ubuntu i am having this error:
/RinexSNR low30790.11o low30790.11snr auto0790.11n 88
low30790.11o
XYZ coordinates -1283634.1274999999 -4726427.8943999996 4074798.0304999999
1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
At line 172 of file RinexSNR.f
Fortran runtime error: Bad value during integer read
Can some one please help me? what i need to install?
Cheers,
Dave

Op maandag 7 mei 2012 14:24:27 UTC+2 schreef d.p...@gmail.com het volgende:
> Folks
> hi,
> I have a fortran code that i am running in the Windows smoothly, but in Ubuntu i am having this error:
> /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
> low30790.11o
> XYZ coordinates -1283634.1274999999 -4726427.8943999996 4074798.0304999999
> 1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
> At line 172 of file RinexSNR.f
> Fortran runtime error: Bad value during integer read
> Can some one please help me? what i need to install?
> Cheers,
> Dave

What is the value your program is complaining about? I guess
it is not recognised as a valid string representation of a
numerical value.

The message should give you enough information about where
it happens in the program. You have to check what is happening
at that point. Possibilities:
- Tabs in an input file that your Windows compiler accepts,
but the Linux compiler does not
- Line-ending problems perhaps?

As you give us very little information about the actual program,
we can only guess. But the program itself is fairly explicit
about where it is going wrong.

Regards,

Arjen

On 2012-05-07 09:24:27 -0300, d.poreh@gmail.com said:

> Folks
> hi,
> I have a fortran code that i am running in the Windows smoothly, but in
> Ubuntu i am having this error:
> /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
> low30790.11o
> XYZ coordinates -1283634.1274999999 -4726427.8943999996
> 4074798.0304999999
> 1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
> At line 172 of file RinexSNR.f
> Fortran runtime error: Bad value during integer read
> Can some one please help me? what i need to install?
> Cheers,
> Dave

The usual drill includes identifying the compiler (vendor, version,
options, etc)
beyond just the operating system (which usually has a version etc). Then one
shows the offending code and the corresponding data. Lacking that you get the
instructions just given when folks are feeling kindly and various less kindly
comments otherwise. (When you asked what you needed to install my first thought
was a thinking cap!)

At least you copied the actually error diagnostic rather than
translating it into
you guess of what it might mean.

Your guess of the trouble is almost certainly wrong as if it were right
you would
not have to ask for any further advice. That is why the actual code and
data are
insisted upon.

The immediate question is whether you you have completely and correctly
converted
all the data files fron Windows CR/LF line endings to the Linux LF line
endings.
The extra CRs would match the given error message. If the data is at
the very end
there can also be issues with a missing LF to officially end the line. Vendors
vary on how strict they are on such technical issues. Some do not believe that
convenience extensions are helpful in the long run.

On Monday, May 7, 2012 5:52:34 AM UTC-7, Arjen Markus wrote:
> Op maandag 7 mei 2012 14:24:27 UTC+2 schreef d.p...@gmail.com het volgende:
> > Folks
> > hi,
> > I have a fortran code that i am running in the Windows smoothly, but in Ubuntu i am having this error:
> > /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
> > low30790.11o
> > XYZ coordinates -1283634.1274999999 -4726427.8943999996 4074798.0304999999
> > 1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
> > At line 172 of file RinexSNR.f
> > Fortran runtime error: Bad value during integer read
> > Can some one please help me? what i need to install?
> > Cheers,
> > Dave
>
> What is the value your program is complaining about? I guess
> it is not recognised as a valid string representation of a
> numerical value.
>
> The message should give you enough information about where
> it happens in the program. You have to check what is happening
> at that point. Possibilities:
> - Tabs in an input file that your Windows compiler accepts,
> but the Linux compiler does not
> - Line-ending problems perhaps?
>
> As you give us very little information about the actual program,
> we can only guess. But the program itself is fairly explicit
> about where it is going wrong.
>
> Regards,
>
> Arjen
Code iw writtin in the CODe77, but it is compiling F95 and Gfortran it is going on smootly. what do you think would be the problem?
Cheer,
Dave

this is the error with F77:
f77 duh.f librariesSNR.f RinexSNR.f -o RinexSNR
pickup_blockiirm:
/usr/bin/f77: aborting compilation

On May 7, 10:24*pm, d.po...@gmail.com wrote:

> I have a fortran code that i am running in the Windows smoothly, but in Ubuntu i am having this error:
> /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
> *low30790.11o
> *XYZ coordinates * -1283634.1274999999 * * * -4726427.8943999996 * * * *4074798.0304999999
> *1 -0.20147787555933047 * * *-0.74185519903768027 * * * 0.63957605436794052
> At line 172 of file RinexSNR.f
> Fortran runtime error: Bad value during integer read
> Can some one please help me? what i need to install?
> Cheers,
> Dave

You need to show the lines of data being read (maybe the entire file);
and the READ and FORMAT statements being executed when the error
occurred.
(the READ statement is at line 172)

The program is telling you that it attempted to read an integer,
and that the data was not integer.

On May 7, 11:17*pm, d.po...@gmail.com wrote:

> Code iw writtin in the CODe77, but it is compiling F95 and Gfortran it isgoing on smootly. what do you think would be the problem?

The problem is lack of information.
You need to supply program and data.

> Cheer,
> Dave
>
> this is the error with F77:
> f77 duh.f librariesSNR.f RinexSNR.f -o RinexSNR
> *pickup_blockiirm:
> /usr/bin/f77: aborting compilation

On 8/05/2012 12:24 a.m., d.poreh@gmail.com wrote:
> Folks
> hi,
> I have a fortran code that i am running in the Windows smoothly, but in Ubuntu i am having this error:
> /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
> low30790.11o
> XYZ coordinates -1283634.1274999999 -4726427.8943999996 4074798.0304999999
> 1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
> At line 172 of file RinexSNR.f
> Fortran runtime error: Bad value during integer read
> Can some one please help me? what i need to install?
> Cheers,
> Dave

Wait! I'll just go and get my crystal ball.

On 2012-05-07 16:48:15 -0300, Gib Bogle said:

> On 8/05/2012 12:24 a.m., d.poreh@gmail.com wrote:
>> Folks
>> hi,
>> I have a fortran code that i am running in the Windows smoothly, but in
>> Ubuntu i am having this error:
>> /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
>> low30790.11o
>> XYZ coordinates -1283634.1274999999 -4726427.8943999996
>> 4074798.0304999999
>> 1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
>> At line 172 of file RinexSNR.f
>> Fortran runtime error: Bad value during integer read
>> Can some one please help me? what i need to install?
>> Cheers,
>> Dave
>
> Wait! I'll just go and get my crystal ball.

Google is more useful! And much less ambiguous.

If you Google RinexSNR you will get a number of hits for a research group at
the Univ. of Colorado which looks at GPS issues. You will even find a couple
hundred line fortran program which seems to be the one the OP is using.

Line 172 is even a read statement of a string. Since the author is listed
and seems to still be active I think that contacting the author might be the
easiest and most productive thing to do. If there is in fact a problem in
the code it would be sensible if the code on the web were fixed. And the
author might even to able to offer advice to others who have similar problems.

The author would not need either a crystal ball or Goggle!

Gordon Sande <Gordon.Sande@gmail.com> wrote:
>> On 8/05/2012 12:24 a.m., d.poreh@gmail.com wrote:

(snip)
>>> Ubuntu i am having this error:
>>> /RinexSNR low30790.11o low30790.11snr auto0790.11n 88
>>> low30790.11o
>>> XYZ coordinates -1283634.1274999999 -4726427.8943999996
>>> 4074798.0304999999
>>> 1 -0.20147787555933047 -0.74185519903768027 0.63957605436794052
>>> At line 172 of file RinexSNR.f
>>> Fortran runtime error: Bad value during integer read

(snip)
> Google is more useful! And much less ambiguous.

> If you Google RinexSNR you will get a number of hits for a
> research group at the Univ. of Colorado which looks at GPS
> issues. You will even find a couple hundred line fortran
> program which seems to be the one the OP is using.

> Line 172 is even a read statement of a string.

read(inline(1:32),'(5I3,X,I2,X,I3,4X,2I3)')
+ (itime(i), i=1,5), sec, msec, flag, numsat

The usual reason for these problems is that something else is
wrong, so it is using this on a line that doesn't have that format.

One thing to try is to print out inline(1:32) just before the read.
You might have many lines of the right data before it gets to the
wrong one, though, but you will have a better idea what the program
is doing, and when.

As someone mentioned, you can get this kind of error when mixing
files between windows and unix-like systems. A previous read might
have been processed wrong, so the wrong line is being processed here.

> Since the author is listed
> and seems to still be active I think that contacting the author might be the
> easiest and most productive thing to do. If there is in fact a problem in
> the code it would be sensible if the code on the web were fixed. And the
> author might even to able to offer advice to others who have similar problems.

-- glen

Is everyone telling me, (by inference) that modern compilers produce
run-time code that actually cares, in a formatted read, about the difference
between (traditional) cr-lf double symbol and single symbol cr or lf
line-ending codes? (ie among these three tokens for line-end?).

That would be a crazy system design criteria to not include and accept all
three variants.
I know my trusty 1985 compiler producses code that handles all three; and I
haven't noticed any problem with my DVF 6.6c compiler either. Why don't the
new run-time codes?

When I parse text (from unformatted reads) I look for all three variants
too. It isn'r exactly rocket science.

Terence <tbwright@bigpond.net.au> wrote:

> Is everyone telling me, (by inference) that modern compilers produce
> run-time code that actually cares, in a formatted read, about the difference
> between (traditional) cr-lf double symbol and single symbol cr or lf
> line-ending codes? (ie among these three tokens for line-end?).

Yes.

> That would be a crazy system design criteria to not include and accept all
> three variants.
> I know my trusty 1985 compiler producses code that handles all three; and I
> haven't noticed any problem with my DVF 6.6c compiler either. Why don't the
> new run-time codes?
>
> When I parse text (from unformatted reads) I look for all three variants
> too. It isn'r exactly rocket science.

So you handle only those 3 possibilities, then? You don't handle, say,
record headers with explicit record size, as I have seen in several
systems. Or binary zeros in the bottom 12 bits of the word (ala CDC)? Or
RS (record separator), which I've heard of being used, but haven't
personally experienced? Or fixed-length formatted records? Not to even
get much into formats that aren't ASCII at all (though I edged a little
into that territory by mentioning CDC).

Yes, there exist compilers that handle only the native forms used on the
systems that they run on. Trying to handle all forms that have ever been
used is indeed not rocket science. It is worse. I've worked with rocket
scientists. I could even stretch a point a little and call myself one
(to the extent that the term is even meaningful, as rocketry has much
more to do with engineering than science; most of the science part of
rocketry is pretty easy. Of course, science that happens to be done
using rockets is another matter, but that's not properly called "rocket
science" either). But I've never met anyone who seriously tried to
automatically handle every text file form ever designed.

In any case, yes such cases do exist, regardless of what you might think
about how poor that is. I've used them. I don't have names because I
don't keep track of which compilers handle which unsafe practices. I
avoid the practices so that I don't have to keep track of such things.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Terence <tbwright@bigpond.net.au> wrote:

> Is everyone telling me, (by inference) that modern compilers produce
> run-time code that actually cares, in a formatted read, about the difference
> between (traditional) cr-lf double symbol and single symbol cr or lf
> line-ending codes? (ie among these three tokens for line-end?).

It is a little hard to say which could and couldn't cause problems.

If you read a whole line in with A80 format, do you expect the CR to
be read as one of the characters?

It does seem that many compilers might accpet CR as white space in
list-directed read, and maybe even as white space in numeric fields,
but it should be just another character in A format input.

In that case, it could change the way the program reads later lines.

-- glen

No way Glen!
And I wouldn't use A80 anyway. I would read blocks of symbols with a
subroutine that replenished input until EOF, which subroutine supplied
symbols one-by one on demand as the text parsing logic proceeded (a la
Backus notation or sometimes Polish notation).
I recently added Greek to my systems (I already had Romaji and Slavic; never
did Cyrilic, even though Russian was on my Physics syllabus). Note, now when
parsing you have to know if to process one-byte or two byte characters to be
more general.

Terence <tbwright@bigpond.net.au> wrote:

> No way Glen!
> And I wouldn't use A80 anyway. I would read blocks of symbols with a
> subroutine that replenished input until EOF, which subroutine supplied
> symbols one-by one on demand as the text parsing logic proceeded (a la
> Backus notation or sometimes Polish notation).
> I recently added Greek to my systems (I already had Romaji and Slavic; never
> did Cyrilic, even though Russian was on my Physics syllabus). Note, now when
> parsing you have to know if to process one-byte or two byte characters to be
> more general.

The program in question does read a line in A80 format, and then
do things with that line.

read (12,'(a80)') line
c write(6,'(a80)') line
if (line(61:80).eq.'# / TYPES OF OBSERV') then

Also:

write(dynfmt, fmt='(A, I3.3, A)')
+ "(6X,", nobs, "(4X,A2))"
read(line, fmt=dynfmt) (key(i), i=1,nobs)

That is a lot of work, when it could just read with a nice large
number instead. (nobs isn't supposed to be more than nine.)

-- glen

Er, The equator radius or diameter or perimeter do not incease, but
decrease, as poles rise with run-off form melting ice. But the radius of
curvature at the equator increases, and the gravity gradient at the equator
then increases as the radius reduces. One word used ambiguously..