[Stellar-discuss] f95 + c + Ruby = okay on Mac. But what about linux?

[Bill Paxton]

Hi (is anybody out there?),

As my first post to the official stellar-discuss mailing list, here's  
a quick update on the feasibility of making a multilingual testbed  
for the stellar evolution code.  I've managed to hack together  
something on the Mac just to see if I could get past linker problems.

1) I've done this with Ruby rather than Python since I'm familiar  
with Ruby from previous projects (in particular, Tioga), and for  
writing low-level add-ons, I much prefer the trace-and-sweep garbage  
collector of Ruby over the reference-counting scheme in Python.

2) There are 2 ways to use "low-level" code (i.e., c, c++, f77, or  
f95) in Ruby (or in Python for that matter).  My preference (and what  
I did in Tioga) was to make an "extension" that is basically a  
dynamically loadable library.  The other alternative is to "embed"  
the Ruby interpreter in some other program.  I've had to go with this  
second approach in order to get the Fortran runtime set up properly.   
It is also probably simpler since it avoids getting into the issues  
of creating dynamic lib's on different systems.  I was able to create  
a dynamic lib with a Fortran routine in it, but when I tried to add  
file I/O, the Fortran runtime wasn't available and the link failed.   
Perhaps someone can eventually figure out how to make this work, but  
in the meantime, embedding Ruby will work okay and gets around the  
fortran runtime problem by using the fortran compiler to do the final  
load that builds the executable.

3) Ruby only has an interface to C (or C++), so I needed to put a C  
layer between Ruby and Fortran -- i.e., if I want to make a Fortran  
routine callable from a Ruby script, I need to provide a C wrapper,  
and then Ruby calls the C wrapper, which then calls Fortran.

4) Thanks to google, I'm using cfortran.h to do the C to Fortran  
interface (http://www-zeus.desy.de/~burow/cfortran/).  It seems to  
work nicely and allows quite general calls back and forth between C  
(or C++) and Fortran (f77 or f95), even allowing procedures as args  
as well as strings, vectors, and multidimensional arrays.

5) You need to tell cfortran.h which fortran compiler you are using  
so it can produce correct wrappers.  I've been able to make it work  
on the Mac with gcc and the Absoft ProFortran compiler, but not with  
the IBM xlf compiler (at least not yet).

6) I've been able to use lots of fancy f95 things (e.g., pointers and  
dynamic array allocation) as well as reading from files, putting data  
and routines in modules, etc.  However, the fortran routines to be  
called from C seem to need to be "bare" routines that are not inside  
a module (they can themselves "use" modules, they just can't  
themselves be inside one or else cfortran.h can't create a proper  
wrapper).  Again, there is undoubtedly a way around for this that I  
simply haven't found yet.  But even if there isn't, it just means yet  
another layer of calls.

7) So to get from Ruby to the desired Fortran routine, we go through  
both a C wrapper and a Fortran wrapper.  Creating these wrappers  
would be a real burden if they were needed for every routine in a  
large system, but that's not how I expect things to go.  Instead,  
there may only be 1 or 2 Ruby-level routines for each of the large  
physics packages such as the EOS or the nuclear network.  And if this  
includes a "high bandwidth" interface routine so that lots of  
requests can be "pipelined" to the package in a single call, the  
overhead can be made negligible.  (Frank has also shown that this  
pipelining can make a significant improvement in performance by  
better processor cache utilization).

Here's a tar file with the toy example I've been playing with.  If  
you're on a Mac and looking for a way to waste some time, you might  
try it.  If you're running linux, it would be nice to know if this  
arrangement can be made to work there for some combination of C and  
f95 compilers.  If you need Ruby, there are some hints to get you  
started on my website as part of the Tioga documentation (see http:// 
theory.kitp.ucsb.edu/~paxton/tioga.html).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cf.tar.gz
Type: application/x-gzip
Size: 29121 bytes
Desc: not available
Url : http://www.srcf.ucam.org/pipermail/stellar-discuss/attachments/20051128/4b2a1337/cf.tar-0011.bin
-------------- next part --------------

The folder you get from the tar file has a makefile that will need to  
be edited for your system.  In addition to the makefile and the  
cfortran.h header, there are 3 c files, 3 f95 files, 1 ruby file, and  
1 data file.

Finally, let me be clear that this is VERY raw stuff and is sure to  
change since there are sure to be problems I haven't tripped over  
yet.  I just wanted to follow up on my promise to share the  
incomplete stumblings along the way.  And I was pleased to see that  
there is at least one scheme that seems to be a plausible candidate  
(if only on the Mac so far).  I haven't talked to Frank yet, and he  
may have better alternatives to propose that work with a wider range  
of compilers (Frank, are you out there?).

Cheers,
Bill