Prev: DRAIN-2DX compile
Next: Anybody use GPPTOOL to do programming before
From: laurel on 4 Nov 2005 14:43
Hi, I am more of an IDL coder, but I am using an external fortan code
that is having trouble compiling with g77 on a sun machine. I have
included what I think are the pertinent parts of the code and the error
message that comes up when I try to compile it.

****code snipet****
Subroutine KT_2003_sub1(ctime,R,theta,phi,Brm,Btm,Bpm)
..
..
..
Subroutine assign_coeffs(M)
IMPLICIT REAL*8(A-H,O-Z)
COMMON /coef/ a(8,64), b(8,64), c(8,64), d(8,64)

DATA a(1,1:64)/
~ 0.13217647646022754326D-20,
~ 0.50643011679165539362D-16,
~ -0.62311994734606299672D-13,
~ 0.73000393989897114366D-10, (and the rest of the 64 numbers)
..
..
..
RETURN
END
..
..
..
END

****end code****

to compile:
>g77 -c -m64 KT_2003_sub1.f

error messages that come up:

KT_2003_sub1.f: In subroutine `assign_coeffs':
KT_2003_sub1.f:500:
DATA a(1,1:64)/
1 2
Invalid token at (2) in expression or subexpression at (1)
KT_2003_sub1.f:502:
~ 0.50643011679165539362D-16,
^
Too many initial values in list of initializers starting at (^)


********
Does anyone know what I need to change to make this work?

Thanks so much!

-Laurel

From: David Flower on 4 Nov 2005 15:06

laurel wrote:
> Hi, I am more of an IDL coder, but I am using an external fortan code
> that is having trouble compiling with g77 on a sun machine. I have
> included what I think are the pertinent parts of the code and the error
> message that comes up when I try to compile it.
>
> ****code snipet****
> Subroutine KT_2003_sub1(ctime,R,theta,phi,Brm,Btm,Bpm)
> .
> .
> .
> Subroutine assign_coeffs(M)
> IMPLICIT REAL*8(A-H,O-Z)
> COMMON /coef/ a(8,64), b(8,64), c(8,64), d(8,64)
>
> DATA a(1,1:64)/
> ~ 0.13217647646022754326D-20,
> ~ 0.50643011679165539362D-16,
> ~ -0.62311994734606299672D-13,
> ~ 0.73000393989897114366D-10, (and the rest of the 64 numbers)
> .
> .
> .
> RETURN
> END
> .
> .
> .
> END
>
> ****end code****
>
> to compile:
> >g77 -c -m64 KT_2003_sub1.f
>
> error messages that come up:
>
> KT_2003_sub1.f: In subroutine `assign_coeffs':
> KT_2003_sub1.f:500:
> DATA a(1,1:64)/
> 1 2
> Invalid token at (2) in expression or subexpression at (1)
> KT_2003_sub1.f:502:
> ~ 0.50643011679165539362D-16,
> ^
> Too many initial values in list of initializers starting at (^)
>
>
> ********
> Does anyone know what I need to change to make this work?
>
> Thanks so much!
>
> -Laurel

You cannot use DATA statements for variables in COMMON, except in a
BLOCK DATA sub-program.

This makes sense, as what would you do if two routines initialised a
COMMON variable differently!

Dave Flower

From: Richard E Maine on 4 Nov 2005 15:07
laurel <laurelr(a)gmail.com> wrote:

> ... having trouble compiling with g77 ...
....
> DATA a(1,1:64)/

The problem is because this is not standard Fortran 77. The 1:64 bit is
a Fortran 90 construct, while g77 is a Fortran 77 compiler. It might be
that some Fortran 77 compilers accept this as an extension, but many
certainly won't... except, of course, for Fortran 90 compilers that also
count as f77 compilers because of f77 being a subset of f90.

The way to do this in standard f77 is with an implied DO loop as in

DATA (a(1,i), i=1,64)/

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
From: Richard E Maine on 4 Nov 2005 15:24
David Flower <DavJFlower(a)AOL.COM> wrote:

> You cannot use DATA statements for variables in COMMON, except in a
> BLOCK DATA sub-program.

Oh. I failed to even note that part, stopping as soon as I saw the
invalid syntax. Some compilers accept that as an extension, in fact it
is a fairly common extension (with a bunch of caveats about multiple
definitions).

I forget whether or not g77 is one of the compilers that accepts it
(since I don't do that), though I think it probably is.

Anyway, from the messages, it is clear that it is complaining about the
array slice syntax. It is possible that once that is fixed, the compiler
might then complain about the COMMON block issue. If that's the case,
you'll need to do both the fix I mentioned, plus move it into a block
data as David notes.

Block data can raise extra "issues", so it is arguable whether or not
you want to do that if the compiler accepts it without a block data. By
using block data, you get standard conformance and guaranteed acceptance
of that aspect on all compilers (though the real*8 shows that the code
has other nonstandard, but widely accepted, usages anyway), but you may
have some practical "issues" with things like object code libraries.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
From: laurel on 4 Nov 2005 15:34
Thank so much Richard, the 'implied DO loop' indeed fixed the errors I
was getting. I don't know about the problem with putting the values in
COMMON. The assign_coeffs subroutine is the first to be called and as
far as I know, none of the other subroutines change the COMMON values,
they only use them in other variables.

Again, thanks for your time, it is much appreciated!

-Laurel

 | 
Pages: 1
Prev: DRAIN-2DX compile
Next: Anybody use GPPTOOL to do programming before