Earth to Mars Trajectory

From: "Jonathan Thornburg [remove -animal to reply]"
Subject: Earth to Mars Trajectory
Newsgroups: sci.astro.research
References:


Kent Paul Dolan wrote:
[[about an orbital mechanics simulation]]
unless you are tied to BLAS or
something similar in the way of a numerical software
library, why not a more modern programming language
that would make your software accessible to a larger
audience?

Fortran is dragging a _lot_ of baggage these days.

This does depend rather strongly on where in the scientific-computing
ecosystem you look. For example, in the Cactus toolkit for the parallel
solution of hyperbolic PDEs (http://www.cactuscode.org), newly-written
physics code is something like
50% Fortran 90
30% C
15% C++
5% Fortran 77
[I emphasize that this is "physics" code; the "infrastructure" code for
MPI, parallel I/O, memory management, etc, is mainly C/C++.]

Partly this is historical inertia, but partly it's that Fortran (still)
has much better support than C/C++/Java for certain kinds of numerical
computation. For example, consider the following trivial Fortran 77
subroutine to multiply two n*n matrices:

subroutine matrix_multiply(n, A, B, AB)
integer n
double precision A(n,n), B(n,n), AB(n,n)
integer i,j,k
double precision sum
do 300 j = 1, n
do 200 i = 1, n
sum = 0.0d0
do 100 k = 1, n
sum = sum + A(i,k)*B(k,j)
100 continue
AB(i,j) = sum
200 continue
300 continue
return
end

Until the C99 standard (which isn't yet widely used), you couldn't
write equivalent code in C without significant uglyness (measured in
programmer (in)convenience, (in)efficiency, or both).
[N.b. "equivalent" means n isn't known at compile time,
and the matrices are stored contiguously in memory. We
can ignore row- versus column-major storage.]
C99 has features ("variable length arrays") which let you write this
subroutine in a natural & efficient manner, but alas these are not
described in most C textbooks.

And as for C++, well, it's considerably *worse*: if you want a useful
matrix class, you have to roll your own. And C99 variable length arrays
aren't in the current ANSI/ISO C++ standard.

For these and othe reasons, the vast majority of high-quality numerical
software libraries (eg., the repository at http://www.netlib.org) are
still written in Fortran, most commonly Fortran 77. A classic example
is ODE integration. IMHO the three best general-purpose ODE integration
codes around are
* Shampine & Gordon's ODE/STEP (written in Fortran 66)
* Hindmarsh's ODEPACK/LSODE (written in Fortran 77)
* Brankin, Gladwell, & Shampine's RKSUITE (written in Fortran 77)

Some newer packages now provide C or C++ wrappers or translations
(eg RKSUITE now includes a 3rd-party translation to C++), but the
primary documentation is still usually written using Fortran
terminology, and "advanced features" are often only available through
the Fortran API.

I conclude that at least a reading knowledge of Fortran remains very
useful for doing scientific computation.

Fortunately, interlanguage calling is fairly easy. In particular, it's
easy (albeit usually slightly operating-system--dependent) to call
Fortran subroutines from a {C,C++,Java,Ada,Pascal,Modula-n,PL/1,...}
program. This is what I do in my own research codes (which are almost
entirely C++ or Perl.)

--
-- From: "Jonathan Thornburg [remove -animal to reply]"
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam