fortran95 or c for a new stellar evolution program?

[Bill Paxton]

On Nov 25, 2005, at 1:58 AM, Evert Glebbeek wrote:
> Perhaps someone could organise a mailinglist or discussion forum?  
> I'm having a
> little trouble keeping track of who's on the To: and Cc: list...

Thank you for volunteering!  ; - )    Please let us all know when you  
have it set up.

> It may be easy to get C compiler X and Fortran compiler Y to work  
> together, but what if someone
> has Fortran compiler Z?

I'm still in the dark about the current state of c & fortran  
interoperability, even at the level of simple procedure calls back  
and forth with simple arguments (integer and double, say).  Can this  
be done in a portable manner?  Where should I look for more info?   
Presumably there are examples of this in the multi-lingual codes like  
FLASH (and also the Garching stellar evolution code, I should mention).

If the c-fortran interface can be done in a manner that works for a  
sufficient set of platforms and compilers, then it would probably be  
possible to do something with both languages without too much of a  
"complexity penalty".  But I still need to see an example.

If making c  (or c++) and fortran work together in a nicely portable  
manner looks too hard, I think the fall back is still not a single  
language environment, but rather a single "low level"  (c or fortran  
probably) and a single "high level" (Ruby or Python probably).

BTW: I finally got curious about what was being proposed for fortran  
2003 and checked it out yesterday.  Turns out that two major items on  
the wish list are object orientation support (including pointers to  
procedures of course) and interoperability with c (even to the level  
of derived types).    Here's a link to a PDF description if anyone is  
curious

	http://www.kcl.ac.uk/kis/support/cit//fortran/john_reid_new_2003.pdf

So, maybe in 5 or 10 years, fortran will be supplying some of the  
things were wanting now!  But in the meantime, we'll make do with  
what is working now.

Oh, that reminds me of Madhu's question/comment about platforms.  My  
bias is take care of Mac and linux and forget the rest for now.  And  
once Mac makes the switch to Intel, things might even get simpler --  
will we all be using ifort?

> I always figured that it would be possible to change the Eggleton  
> adaptive
> mesh to a `normal' Lagrangian mesh simply by changing the mesh spacing
> function.

We may need a separate distribution list for any detailed discussion  
of the Eggleton code ("I survived the Eggleton code" might be the  
motto).

But I think the issue of Eulerian/Lagrangian/Eggletonian is worth a  
few words.  I like to think about it in terms of 2 operations:  
solving the stellar structure equations and adjusting the mesh to fit  
the current situation.  Eggleton's insight was the possibility of  
coupling these operations so that the mesh adjustment is done as part  
of the solution of the equations.  It works very well, but at a cost  
in performance (not a big deal) and in complexity of the equations (a  
much bigger deal to me at least).

The `normal' Eulerian/Lagrangian approaches don't couple these  
operations.  Instead, they alternate between solving the equations  
and revising the mesh, so the equations can be simpler and fewer in  
number.  But now you need to provide a separate algorithm for adding/ 
deleting/moving mesh points.  This is where the magic comes in of  
course, but at least it isn't spread throughout the equations.  And  
there is the possibility to experiment with different methods here in  
a more modular manner.  (Is my bias showing yet?)

> Bill, about the organisation of this project, I assume you will be  
> starting on
> this by your self at first and at some point convert it to an open  
> source
> project that everyone can easily contribute to?

Frank Timmes and I have been batting this idea around for awhile now,  
and I certainly hope he will continue to devote a chunk of his time  
to making it real.  Both Frank and I believe in putting things out  
there on the web for anyone to grab and play with (if you haven't  
visited his website, you should take a look -- http:// 
www.cococubed.com/code_pages/codes.shtml).

That said, let me make it clear that I'm not interested in (or  
particularly skilled at) organizing and managing a project.  I have  
enough trouble keeping my own desk straight, let alone a multi- 
person, open source project, even with all the modern tools like  
CVS.  Just to show what a troglodyte I am, I don't even know how to  
use CVS and don't want to learn!  (Which is not to say that I may not  
HAVE to learn at some point just to keep playing in this game.)

So I'm not planning to set up an open source project anytime soon,  
but that doesn't mean it won't be appropriate at some point in the  
future.

> most people will just talk and design indefinitely. Someone needs to
> take the initiative to start programming and then others will join in.

That's true.  I think it is important to accept that it will take  
several rounds to find a good design and that can only be done by  
putting something fairly complete together and finding out why it  
stinks.  The good news with this effort is that thanks to Frank we  
have a good set of physics modules available already (eos and nuclear  
burning in particular, plus OPAL for opacities of course).   So I  
think we can go from the talk and design stage to the "make mistakes  
quickly" stage where we'll actually learn something perhaps.

In that spirit, I'm in the process of making the first of many  
mistakes along the road to something useful.  My normal mode of  
operation would be to keep my many failures to myself and just share  
something that may be the 6th or 7th complete implementation.  But in  
this case, it seems appropriate (if painful) to share the failures  
along the way too.  Perhaps that's the level of "open source" sharing  
that's appropriate for now -- pre-alpha releases of flawed but  
complete implementations to kick around.

Finally, I was serious about volunteering you to set up mailing list  
for this.  You are right that it is needed -- especially so that the  
poor souls getting all these messages who have better things to do  
can get off the list!

Cheers,
Bill