From: Carlie Coats on

As many of the other posters have noted, this describes "automatic
arrays" supported under F90 and later versions of the standard; it
is also supported in particular by g77, which you'll find on older
Linux systems.

The one caveat is this: automatic arrays are usually implemented
by compiler writers using the stack, and one OS family in particular --
MS Windows -- hard-codes the stack size to a ridiculously small 512MB.
If you do serious modeling (weather, land surface, air quality, etc.),
this will be a serious problem there.

Some compilers implement an "allocate large automatic arrays off
the heap" strategy that has more call-overhead but gets around
problems of this sort, but impacts project portability. See your
vendor's documentation.

FWIW -- Carlie Coats

From: monir on
Thank you ALL for your precise and helpful replies.
The answer to my subject question is clearly: "YES, one can".

1) Shortly before retrieving your replies and being unsure what the
answer would be, I tried a Parameter statement in the example Sub Test
() ; specifying the maximum anticipated subscripts "m" and "n" for the
local arrays.
I got different results, which is very confusing, and I've been
working on the problem since then !!!

2) OP example:
Subroutine Test(w,m,n) !m=10, n=20
integer m,n
real w
real x(m)
real y(m,n)
real z(m,m,n)
!.....................................
w = whatever
!....................................
return
end subroutine Test


Modified:
Subroutine Test_2(w)
integer m,n, maxm, maxn
Parameter (maxm=30, maxn = 30)
real w
real x(maxm)
real y(maxm,maxn)
real z(maxm,maxm,maxn)
!.....................................
w = whatever
!....................................
return
end subroutine Test_2

3) In the real situation (actual code), the individual routines works
fine in isolation, but not in the following combination, which may
suggest that the variable arrays are not manipulated/passed correctly
(dimension-wise) and perhaps the problem is not a dynamic array issue
after all. Or is it ??
(F77 & g95)

3) Here're the troublesome DECLARATION sections of the code:

! ************************************************************
SUBROUTINE Splint3d(x1a, x2a, x3a,
1 ya, maxPln,maxR,maxTH,
2 k, m, n,
3 x1, x2, x3, Z)
! ************************************************************
! USES: Splie2d , Splin2d , Splined , Splintd

integer k,m,n
integer maxPln,maxR,maxTH
integer i,j,kk
integer kmax,mmax,nmax,nop

double precision x1,x2,x3, Z
double precision d1,dn
! ...the following 4 arrays are dim exactly as in the calling
! ...routine and are printed correctly in this routine
double precision x1a(maxPln),x2a(maxR),x3a(maxTH)
double precision ya(maxPln,maxR,maxTH)

double precision y(maxR,maxTH), y2a(maxR,maxTH)
double precision ytmp(maxPln), y2tmp(maxPln)

do 13 i=1, k
do 12 j=1, m
do 12 kk=1, n
y(j,kk) = ya(i,j,kk)
12 continue

call splie2d (x2a,x3a, y , maxR, maxTH, m, n, y2a)
call splin2d (x2a,x3a, y , y2a , maxR, maxTH, m,n, x2,x3,ytmp(i))
13 continue

call splined (x1a, ytmp , k, d1, dn, y2tmp)
call splintd (x1a, ytmp , y2tmp ,k,x1,z)

Return
End Subroutine Splint3d

!************************************************************
SUBROUTINE SPLIE2d(x1a, x2a, ya,maxM,maxN, m, n,y2a)
!************************************************************
! USES: Splined

integer maxM,maxN,m,n
integer nn,nop,j,k

parameter (nn=100)

double precision d1,dn
double precision x1a(maxM), x2a(maxN)
double precision ya(maxM,maxN), y2a(maxM,maxN)

double precision ytmp(nn),y2tmp(nn)

do 13 j=1, m
do 11 k=1,n
ytmp(k) = ya(j,k)
11 continue

call splined(x2a,ytmp,n, d1, dn,y2tmp)
do 12 k=1, n
y2a(j,k) = y2tmp(k)
12 continue
13 continue

return
End Subroutine SPLIE2d

!************************************************************
SUBROUTINE SPLIN2d(x1a,x2a, ya, y2a, maxM,maxN, m,n,x1,x2,y)
!************************************************************
! USES: Splintd , Splined

integer maxM,maxN,m,n
integer nn,nop,j,k

parameter (nn=100)

double precision d1,dn,x1,x2,y
double precision x1a(maxM), x2a(maxN)
double precision ya(maxM,maxN),y2a(maxM,maxN)

double precision ytmp(nn),y2tmp(nn)
double precision yytmp(nn)

do 12 j=1, m
do 11 k=1, n
ytmp(k) = ya(j,k)
y2tmp(k) = y2a(j,k)
11 continue
call splintd(x2a,ytmp,y2tmp,n,x2,yytmp(j))
12 continue

call splined(x1a,yytmp,m, d1, dn,y2tmp)
call splintd(x1a,yytmp,y2tmp,m,x1,y)
return
End Subroutine SPLIN2d

C ******************************************************************
SUBROUTINE SPLINEd(X, Y, N, YP1, YPN, Y2)
C ******************************************************************
implicit double precision (a-h,o-z)

dimension X(N),Y(N),Y2(N)
!..............code...............................
return
End

C ******************************************************************
SUBROUTINE SPLINTd(XA, YA, Y2A, N, X, Y)
C ******************************************************************
implicit double precision (a-h,o-z)

dimension XA(N), YA(N), Y2A(N)
!..............code...............................
return
end

I apologize for the lengthy posting.
Please ignore the question if it is an "obsolete F77" time-consuming
question!
Hopefully someone would be able to identify the problem with minimum
time/effort.
That would be greatly appreciated.

Thank you kindly.
Monir
From: Colin Watters on
"monir" <monirg(a)mondenet.com> wrote in message
news:ff0d1fdd-8c9f-4f88-a0bc-e586e2f11e50(a)r12g2000vbm.googlegroups.com...
> Thank you ALL for your precise and helpful replies.
> The answer to my subject question is clearly: "YES, one can".
>
> 1) Shortly before retrieving your replies and being unsure what the
> answer would be, I tried a Parameter statement in the example Sub Test
> () ; specifying the maximum anticipated subscripts "m" and "n" for the
> local arrays.
> I got different results, which is very confusing, and I've been
> working on the problem since then !!!
>

<snip>

>
> 3) In the real situation (actual code), the individual routines works
> fine in isolation, but not in the following combination, which may
> suggest that the variable arrays are not manipulated/passed correctly
> (dimension-wise) and perhaps the problem is not a dynamic array issue
> after all. Or is it ??
> (F77 & g95)
>
> 3) Here're the troublesome DECLARATION sections of the code:

<snip>

> I apologize for the lengthy posting.
> Please ignore the question if it is an "obsolete F77" time-consuming
> question!
> Hopefully someone would be able to identify the problem with minimum
> time/effort.
> That would be greatly appreciated.
>
> Thank you kindly.
> Monir

It is highly likley that the maximum return on time/effort will be obtained
by putting all the code shown (and that I have snipped) into a single
module (even if this is only for experimental purposes). This will ensure
every routine has an "explicit interface", and so allow the compiler to
diagnose most (or all) possible errors of the type you appear to be
describing.

--
Qolin

Email: my qname at domain dot com
Domain: qomputing


From: Richard Maine on
monir <monirg(a)mondenet.com> wrote:

> 3) In the real situation (actual code), the individual routines works
> fine in isolation, but not in the following combination, which may
> suggest that the variable arrays are not manipulated/passed correctly
> (dimension-wise) and perhaps the problem is not a dynamic array issue
> after all. Or is it ??

I didn't tak ethe time to trace everything through, but it didn't take
much time at all to find at least one example of an array that was not
declared consistently in the caller and the callee. That suggests there
are likely to be more. I'm not going to try to track them down for you.
I suggest just sitting down and looking at every one. The first example
I noticed was
....
> double precision ytmp(maxPln), y2tmp(maxPln)
....
> call splined (x1a, ytmp , k, d1, dn, y2tmp)
....
> SUBROUTINE SPLINEd(X, Y, N, YP1, YPN, Y2)
....
> dimension X(N),Y(N),Y2(N)

So y2tmp is dimensioned maxPln in the caller, but maxPln is not even
passed to splined. Instead, k is passed and used (as the dummy named n)
to dimension the y2 dummy argument.

This stuff isn't rocket science. Quite the opposite, it is nothing other
than taking the time to sit down and look. *AT EACH AND EVERY CASE*. The
actual and dummy should agree. I just showed how to look at one. I
suggest doing all the rest. Not worth my time. (Insert comment about
teaching people how to fish instead of giving them a fish; I feel my
time is better spent in my showing what to look for than in my finding
it for you. No, I didn't find it and refuse to say where - I just
stopped looking after seeing the above case.) Odds are that this one
isn't actually a problem, but I take it as symptomatic of a style that
probably will cause problems elsewhere.

Perhaps you might think that k and maxPln are supposed to have the same
value, but to me that doesn't matter. Making assumptions like that all
over the place is exactly how one gets into such troubles. Every
assumption like that is something that needs to be verified. Any such
assumptions should certainly be explicitly stated in comments in the
code - probably with exclamation marks. Better yet is not to make such
assumptions. If two things are supposed to be the same, then make them
the same or have the code test the values.

So look at every declaration, comparing the actual and dummy. Don't
count on any assumptions about what ought to be. Just look directly at
the exact declarations. If they don't match, then figure that's a likely
source of problem.

Along the same line, it has been mentioned here many times that implicit
typing is prone to error. Even more prone to error is randomly mixing
styles, using implicit typing some places and exlicit typing elsewhere.
That kind of thing makes consistency much harder to check. The more you
make the actual and dummy declarations done the same way, the more
obvious problems will be.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: e p chandler on
"monir" <monirg(a)mondenet.com> wrote

> 1) Shortly before retrieving your replies and being unsure what the
> answer would be, I tried a Parameter statement in the example Sub Test
> () ; specifying the maximum anticipated subscripts "m" and "n" for the
> local arrays.
> I got different results, which is very confusing, and I've been
> working on the problem since then !!!

[snip]

Immediately the chief suspect is that your acutal arguments are not the same
as your formal arguments.

[snip]

for example:

> SUBROUTINE SPLINTd(XA, YA, Y2A, N, X, Y)
> implicit double precision (a-h,o-z)
> dimension XA(N), YA(N), Y2A(N)

is called with the assumption that XA, YA and Y2A are the same size, yet in
several calling programs
the passed arrays are dimensioned with DIFFERENT variables, which I expect
are NOT constrained to be the same size.

--- e