From berriz #at# chasma.harvard.edu  Thu Nov 21 14:39:11 1996
Received: from chasma.harvard.edu  for berriz {*at*} chasma.harvard.edu
	by www.ccl.net (8.8.2/950822.1) id OAA17888; Thu, 21 Nov 1996 14:22:40 -0500 (EST)
Received: by chasma.harvard.edu (AIX 3.2/UCB 5.64/4.03)
          id AA20812; Thu, 21 Nov 1996 14:20:43 -0500
Date: Thu, 21 Nov 1996 14:20:43 -0500
From: berriz-: at :-chasma.harvard.edu (Gabriel Berriz)
Message-Id: <9611211920.AA20812&$at$&chasma.harvard.edu>
To: chemistry-: at :-www.ccl.net
Subject: Q: Scientific Fortran for C programmers






Dear netters:

What follows is a hodge-podge of questions surrounding scientific
programming in general, and Fortran90, in particular.  I apologize
beforehand for their occasional vagueness.  I'm hoping that despite
it, they'll be "recognizable" to some CCL readers.  More than detailed
answers (which would be rather time-consuming to the brave responder),
I'm interested in pointers to pertinent readings.

I am experienced C programmer who's now taking his first steps in
Fortran (Fortran90, to be precise).  After a brief study of Fortran,
I'm surprised at how much my idea of what a program is is shaped by
the structure of C programs.  This is so much so that I am having some
difficulty grasping the overall structure of Fortran90 programs.  For
example, the whole business with "data blocks" seems bizarrely archaic
to me.  But this is a minor issue.  More important is that I'm unclear
on the usefulness of "modules."  How is a module different from a file
with a whole bunch of subroutines in it?  How is modularization achie-
ved with FORTRAN77?  What was deficient about this approach that
prompted the introduction of "modules" in Fortran90?  Is there more to
the rationale for modules than providing a finer control over variable
scoping (which, I imagine, could be achieved with not much effort by a
careful naming of variables)?  I am interested in reading discussions
on the structure of (medium to large) Fortran programs, particularly
ones geared to C programmers.

Two areas that I am particularly concerned about are (1) managing the
proliferation of versions of my source code; (2) high performance, in-
cluding parallelization.  (Of course, neither of these topics is spe-
cific to Fortran, though there may be features of Fortran90 that ger-
mane to them.)  Everything I've found on source code management seems
to be geared to the writers of commercial software.  I have found,
however, that their concerns are different from those encountered in
simulations-based research.  (Perhaps this is why I have yet to find
one writer/user of simulation programs who has managed to stick to RCS
for more than a couple of weeks.)  I.e., I am not worried about jug-
gling a few, significantly different versions, some released, some
geared for release, of my code.  My situation is that I am constantly
making small changes to my not-for-release code, as part of my simula-
tion "experiments," which means that I'm dealing with, effectively, a
large number of versions, many of which differ very slightly from each
other.  I keep notes on these changes (as comments on the code, or on
my makefiles), but they don't seem adequate documentation.  I suppose
a sounder approach would be to save *all* versions of code ever used
to generate data (which, incidentally, includes a non-trivial fraction
of "dead-end" data), as well as notes on all the various source ver-
sions that go into a given executable.  Obviously, this strategy leads
to a huge number of source files, and a wild efflorescence of file
name extensions.  Be that as it may, are there any resources (soft-
ware, books, articles, &c.) helpful towards this sort of bookkeeping?

As far as high-performance, I would like to learn about the effects of
program structure on execution speed.  For example, how expensive, re-
lative to their alternatives, are subroutine calls and modules in For-
tran90?  Do COMMON variables slow down execution?  Does one get faster
code if one avoids COMMON variables, and instead defines subroutines
with a long list of arguments?

Again, I apologize for the chaotic appearance (and the length!) of the
above query.  I hope that a "core" set of concerns is detectable.  I
greatly appreciate your comments and suggestions.  I'll summarize
the responses.



Gabriel Berriz
berriz -A_T- chasma.harvard.edu
Dept. of Chemistry and Chemical Biology
Harvard University