fortran95 or c for a new stellar evolution program?

[Evert Glebbeek]

Hi Bill & al,

> Perhaps Piet has the right idea -- use a high level interpreted
> language as glue to put together packages that are written in various
> languages such as Frank mentioned.

Yes then this is probably a good approach if it really works well. In fact, it 
doesn't even have to be that way from the beginning: if the core design is 
solid, then plugins and addons written in different languages shouldn't be 
too hard to write...
What I think would be good is if the code is modular enough that apart from 
the main programme we would basically have a set of library functions that 
one can just pull together to do whatever one wants to do. The main programme 
then could look something like

STAR star;
initialise(star);
while (!evolution_done(star)) evolve (star);
destroy_star(star);

and within the while loop one could do all sorts of interesting things based 
on what we got out of the last evolutionary timestep. Just daydreaming 
here! :)

> Hmmm.... I haven't written a big 
> system in Lisp since back in the 70's -- how would you like lots of
> lambda's?  ; - )   Don't worry; I'm just kidding...  But I have had
> good luck recently using Ruby with c extensions.  I guess that's
> another thing for me to check -- can Ruby deal with fortran packages
> in a reasonable manner?  (And please do NOT start sending me messages
> about how I should be using Python instead!)

Personally, I like Python but I don't know much about Ruby (beyond having read 
some of Piet's tutorials). Anyway, I wouldn't recommend Python for this 
anyway because I've heard too many horror stories of editors deleting all 
indentation from a source file and the bother of reindenting the code on a 
copy&paste operation (those who know Python will understand).

> And if any of the rest of you have thoughts about
> your ideal stellar evolution testbed, please share!

I guess I don't have any recommendations right now for the testing phase of 
the project, but I do have a feature request if I can make one already: one 
of the strengths of Peter Eggleton's original code (apart from the adaptive 
mesh) is the ability to permute and change the equations (and number of 
equations) that are solved without having to touch the solver itself (or 
without changing the source of the programme, in many cases). This is pretty 
neat and I think it makes sense to have something like this in a new code.
Maybe we should have a discussion or inventory about what sort of features 
everyone thinks would be most useful in a new code like this?

Cheers,

Evert
- -- 
Evert Glebbeek, PhD student
Physics and Astronomy Department, Utrecht University
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/