From: Carlie Coats on 20 Dec 2009 11:16 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 20 Dec 2009 16:46 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 20 Dec 2009 17:46 "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 20 Dec 2009 18:02 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 20 Dec 2009 18:42
"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 |