fortran95 or c for a new stellar evolution program?

[Evert Glebbeek]

Dear Bill & others,

> I'm trying to get some input from knowledgeable younger players with  
> interests in stellar evolution simulation about what programming  
> language to use for a fresh start system.

Sounds good! 

> The only candidate languages I'm even willing to consider are  
> fortran95 and c.  The feature set of fortran77 is too limited for the  
> kind of system building I want to do, and c++ doesn't add critical  
> new functionality for this kind of application (plus all c++ users  
> know c, but not vice versa).  Availability of free, reliable,  
> efficient compilers favors c over fortran95 (at least at present).   

Here's my overly biased (I'm a big C fan) opinion on the choice of core 
programming language and some of the reasoning behind it.

The big thing that Fortran'95 has going for it (and really the only thing I 
can honsetly say I truely like about Fortran) are its array assignment 
operations that make it easy to write compact readable code that can be 
optimised and paralellised well by the compiler.

The big thing that C has going for it is that it is a very portable 
language: having a C programme on one computer compiled with compiler A 
almost certainly will work the same on a totally different computer with 
compiler B. This is not my experience with Fortran. I'd go with C for this 
reason (and because I'm personally more comfortable with C than Fortran, 
but that's not really a valid reason here).

All that said, let me nevertheless suggest C++ for a project like this. I 
have a few classes that implement parts of Peter Eggleton's code in C++ 
(mainly to prove to myself that I could rewrite them like that, though I 
may finish it someday) and I think it makes sense to use C++ for something 
like this. More to the point, I think it is good to have a class-based 
structure where you have general routines that operate on a `mesh' class 
and a derived `star' class that overrides some virtual functions. A 
`binary' could be another derived class. This forces a modular design that 
would make it easier to couple the code directly to an N-body code or a 
hydrodynamics code because it completely hides internal details of how the 
star is stored. I agree with Evghenii that Fortran'95 is simply not 
`object oriented' enough for a modern language.

There may be more object-oriented languages than C++ out there that take 
this one step further and that I'm not aware of. But as far as I know, 
these are either scripting languages or languages running on a virtual 
machine like Java.

> Availability of packages for various parts of the physics (such as  
> equation of state, nuclear reaction network, etc.) favors fortran95  
> over c (at least until Frank Timmes rewrites his stuff!).

Well, they could be rewritten. Or, as Frank Timmes says, a mixed-language 
approach could be used (but more on my thoughts on that line of approach 
below).

> application: the only major deficiency of fortran95 compared to c is  
> the unfortunate lack of pointers to procedures as valid components of  
> derived types.  I can imagine situations in which I'd like to have  
> them, but it probably is not a show-stopper for fortran95 in this  
> application.

In that case, I suspect proper design would really be C++ virtual 
functions! ;)

> My impression is that while many of the "older" generation are  
> uncomfortable with anything other than fortran77, there is a large  
> fraction of the "younger" generation who are more comfortable with c  
> (or even c++)!  Does using fortran95 just make both groups unhappy?
> Or is it a good compromise that lets a larger number of people use  
> the system -- the fortran folks lured in by the name; the c folks  
> lured in by the promise of c-like features.

I'm not sure. For me, the biggest problem Fortran'95 has is that it has 
inherited all of Fortran'77, with its evil common blocks, implicit typing 
and arcane flow control. I know these don't have to be used (shouldn't be 
used) anymore, but it still leaves me with the feeling that in Fortran one 
can do the same thing in ten different ways that compete for minimal 
readability. ;)
In many respects my own Fortran code looks disturbingly like C code, upto 
and including redundant semicolons at the end of each line.

Probably Fortran'95 code should neither be C-like nor Fortran'77-like, but 
Fortran'95-like (whatever that means): they're different languages. Just 
as writing Fortran'77-like code in C produces ugly (and probably 
inefficient) C code and vice versa, I don't think one should write in 
Fortran'95 with anything other than a Fortran'95 style.

> So perhaps the jump from fortran77 to fortran95 is about as bad as  
> the jump to c, and then the case for fortran95 seems much weaker.

Actually, I have a feeling that this may be a weak point for Fortran'95: it 
has C-like features, but people who prefered C already don't use them 
because they use C anyway and people who prefer Fortran'77 don't use them 
because they continue to use Fortran'77 constructs anyway. In other words, 
I don't think luring people from either side by using Fortran'95 will be 
very helpful.

With regards to using multiple programming languages in one project... it's 
an interesting possibility and it certainly feels right that one should 
use the right tool for the right job. Unfortunately I don't think current 
compilers and development tools are properly adapted for projects like 
this. It's sortof ok if one uses the GNU compiler because that's basically 
one compiler that does all languages but it's performance is mediocre 
compared to some other compilers out there. It also has the risk of 
alienating everyone except people who are proficient in both languages.

To wrap up my brainstorming post, I think the answer to the question is 
related to the intended future scope of the project. If it should be easy 
to couple to other codes (which I think is an important thing to do in teh 
future), then concepts like data-hiding and easy portability are important 
and I'd go with C (or actually C++) over Fortran'95.
If the idea is to create a new, open-sourced community-developed stellar 
evolution code that is not otherwise different from existing codes, then 
Fortran'95 or a mixed-language approach might be better.

Just my two cents for the discussion. I hope it's somewhat useful. :)

Cheers,

Evert
- -- 
Evert Glebbeek, PhD student
Physics and Astronomy Department, University of Utrecht
Buys Ballot Laboratory, room 762
e-mail: glebbeek at astro.uu.nl   tel. +31 (0)30 253 5235
www: http://www.phys.uu.nl/~glebbeek/