fortran95 or c for a new stellar evolution program?

Piet Hut piet at ias.edu
Mon Nov 21 15:38:08 GMT 2005


Bill, and all:

First of all, thank you SO much for taking this initiative,
to start a dialogue of this kind.  For many years now, I have
tried to talk with experts in stellar evolution, trying to raise
issues concerning programming style, especially modularity and
documentation, but I'm afraid I haven't gotten very far, mostly
because my own work has been in stellar dynamics, not evolution.
But since you have a hardwon reputation of actually writing a
stellar evolution code, you are in the right position to start
this dialogue, which is really 20 years overdue (it reminds me
of the dialogue I had with Josh Barnes and others, in 1985, which
resulted in us writing the NEMO environment for stellar dynamics,
which spun off the Starlab environment, and most recently the
ACS and Atlas initiatives).

Secondly, whatever any of us may say in response to your question,
you have the prerogative to choose the language you are most happy
with, and which you think is most suitable for your goals.  You
are about to fill an enormous gap in the market: after fifty years
of research in stellar evolution, your EZ code has been the very
first simple code aimed primarily at readibility.  Whatever you do
now may well set the standards for at least the next 25 years, no
kidding!  Everyone will be grateful to you, for the effort you have
made and are making to document and modularize stellar evolution
codes, so the question of having to learn a new language is really
minor.  Right now, any student in stellar evolution can learn a new
computer language in a few days to weeks (depending on the level
of proficiency), but NO student currently has access to a clearly
documented stellar evolution code, and the only alternative is for
them to spend years learning the ropes, by trial and error and asking
around for oral knowledge.

Given that your effort will reduce the time to really learn good
stellar evolution practice from years to months, any penalty you
introduce for anyone of having to learn a new language is tiny
compared to the gain you are offering.  My advice: do NOT limit
yourself to a choice between F95 and C.  Speed is really not an
issue (people established stellar evolution as a mature field in
the sixties with computers being a hundred million times slower
than they are now).  As long as you are developing and extending
a well-structured and modular code, forget about speed!  At any
stage, you or someone else may want to freeze the code in whatever
state of development it is at any point, and rewrite some of the
time-critical parts in C or whatever.  The ONLY point of concern
is to choose a language that you think is flexible enough to carry
the design of stellar evolution codes forward for the next 25 years,
if not 50 years.

I'm bloody serious here.  Your new code is likely to dominate the
style of programming, and will become a type of legacy code in due
time.  Why stick to languages that are eighties-like in spirit?
(actually, C is from the very early seventies, and F95 is almost
catching up with C, but let me be generous, and gave you a decade).
I suggest that you think deeply about what you think will give the
highest chance that a new generation of stellar evolution students
will program in a modular and clear and logical way, NOTWITHSTANDING
the fact that their thesis advisors will have no idea at all about
these essential points.  If you think lisp would be best, choose
lisp!  If you think Java would be best, pick Java!  If you think
Ruby will educate people to think in a more clear way, pick Ruby!
If there is any other language that you think is best, by all means,
choose that language!

You see, already from the responses it is clear that you have no way
at all to satisfy everybody.  You posed the question of C vs F95, and
you got people divided already over C, F95, and even C++ (all for good
individual reasons!).  You pick a language, everybody will be grateful
for you that you provide the world's first really readable modern
stellar evolution code, and everybody will use that code simply because
they have no choice.  A few thesis advisors will shake their head, but
when they tell their students that your language X is no good, their
students will smile and ask their advisors what other modular readable
code there is in any other language.  At this point the advisors will
suddenly remember that there is a very important administrative meeting
they have to attend.  Exit advisors.

One more thing.  Traditionally, NO stellar evolution code that I know
of had any modern diagnostics tools.  Sure, you can visualize the H-R
track that a code makes, but how can you put your fingers on the pulse
of what is happening with, say, convective overshoot, partial mixing,
you name it?  If you solve a complex system of coupled non-linear
differential equations, in a modern computer environment, you REALLY
need to have good visual tools to show what is going on down in the
core of the code, inside the heart of the beast.  Why has nobody done
that?  Simple: Fortran doesn't let you even THINK about doing that,
since it would be so cumbersome and alien!  F95 and C won't help you.
In the eighties visualization as a debugging and diagnostics tool was
not yet a clear concept.  A typical astronomer was delighted to have
his/her own terminal on their desk, and they didn't even dream of
having their own graphics device.  But now we're twenty years later.
PLEASE, Bill, don't start off with a twenty year lag at the starting
line.  Express yourself in something truly flexible, and set the
standards for at least the first half of the twentyfirst century.

By the way, Jun Makino says hello!  He happens to be visiting me here
in Princeton for a week.  I showed your email exchange of the last 24
hours to him, and we discussed the points I mentioned above.  He also
is in full agreement with what I have written here.

Best,

Piet



More information about the stellar-discuss mailing list