[GRASS5] 'unsubscribe grass5'

[Tinus Joubert]

----- Original Message -----
From: "Roger Bivand" <rsb at reclus.nhh.no>
To: "Roger S. Miller" <rgrmill at Rt66.com>
Cc: <grass5 at geog.uni-hannover.de>
Sent: Wednesday, April 04, 2001 10:15 AM
Subject: Re: [GRASS5] Problems compiling r.fill.dir


> On Tue, 3 Apr 2001, Roger S. Miller wrote:
>
> > Malcolm Blue wrote:
> > >
> > > Fortran programmers,
> > >
> > > It's been a long time since I've done any fortran programming.  The
> > > compile for r.fill.dir exits with the following error messages:
> >
> > Malcom,
> >
> > These look like some ugly problems.  I think the version of r.fill.dir
> > now in the CVS tree is the one that I hacked to use floating point
> > elevations.  It compiled without problems on i586-pc-linux and ran fine
> > for me, but not well for Markus.  Markus since asked Huidae Cho to look
> > into the problems, because I pretty much ran out of time.
> >
> > The cygwin port of g77 must be more exacting than my linux port when it
> > comes to COMMON blocks.  The problem appears to be with the LEVEL
> > array.  In the original source code I think it was declared as REAL *2
> > LEVEL(4002,3).  I changed that to DOUBLE PRECISION LEVEL(4002,3) in all
> > of the subroutine where LEVEL was used, but apparently didn't change it
> > in those subroutine where it wasn't referenced.  One of the blank COMMON
> > statements excludes LEVEL entirely, which may be a feature of the
> > original code.
> >
> > > There are a number of messages of the same type.  Is it possible to
> > > reorder the variables on the common blocks defined in r.fill.dir, or
is
> > > there a switch to g77 that will tell it to align members of a common
> > > block to the same byte length?
> >
> > I don't know if g77 has a switch that relaxes it's restrictions on blank
> > COMMON.  Unfortunately my server at work seems to be off line and I
> > can't reach my sources or the documentation.  I got the ppupdate.f
> > source in the CVS tree and it looks like it may be sufficient to just
> > make a few changes.
> >
> > LEVEL is declared as INTEGER *2 in subroutines PATH, FIXALOOP, UPDATE,
> > and DOMAPTO.  In each case the source may need to declare LEVEL as
> > DOUBLE PRECISION.  Additionally, subroutine FILL doesn't declare LEVEL
> > at all and it may be necessary to add it's declaration (as DOUBLE
> > PRECISION) to that subroutine.
> >
> > If your g77 insists on having the large variable declared first, then
> > you can probably change their order.  The change needs to be made in all
> > of the "COMMON MASK,LEVEL" statements.  Change them to "COMMON
> > LEVEL,MASK".  In addition, the DO3BY3 subroutine declares the block as
> > "COMMON MASK,ELEV" and this needs to be changed to "COMMON ELEV,MASK".
> > In fact, it might be necessary to rename ELEV to LEVEL in that
> > subroutine.
> >
> > >
> > > Any other suggestions?
> >
> > If you don't need r.fill.dir right away, then hold off on trying to fix
> > it.  I'm converting the source to C and that should be ready in a few
> > weeks, depending on how much time I have available to work on it.
> > Huidae Cho may also be working on the source.  If you do need it right
> > away then I can probably send you a copy with the changes I described
> > above.
> >
> >
> Two suggestions: avoid unnamed commons - because they may actually be
> different in different subroutines(!), and secondly put commons with their
> declarations in a separate file, such as tbl.cmn, and include them in the
> [fg]77 source:
>       include 'tbl.cmn'
>
> Then all the subroutines get the same declarations, and you reduce the
> risk of typos. Think of them as structures declared in C header files,
> just that they can't be addressed as structures.
>
> Finally, I like implicit logical(a-z), because it flags most bugs in
> declarations so neatly, but can be tedious in legacy code.
>
> The g77 info suggests that one doesn't try to suppress these kinds of
> warnings, alignment in commons does matter, and sometimes it is even worth
> declaring unused variables in the common to get the alignment right.
>
> Roger
>
> --
> Roger Bivand
> Economic Geography Section, Department of Economics, Norwegian School of
> Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
> Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
> e-mail: Roger.Bivand at nhh.no
> and: Department of Geography and Regional Development, University of
> Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.
>
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write
to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'
>


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'