Phil,

Thanks for the suggestion.  I'll delve into the pointers that you
provided, but after a cursory examination I think that this will not
work. 

1) The ypfortran page admits that it cannot handle "explicit"
   interfaces for fairly fundamental reasons.  In fact, it is exactly
   these interfaces that C++ cannot handle either.

2) The following is not a deal-breaker, but it raises my skepticism
   up a few notches.  From the Numerical Python page:

   "If x and y are Numerical Python arrays, then the speed of the
    operation x + y is close to the speed of doing it in C if the
    arrays are big enough."

   This indicates rather extreme naivete with regards to optimization.
   If all that one is doing is adding two arrays, the best the
   compiler can do is keep memory bandwidth saturated.   


OTOH, the fact that there are apparently significant numbers of
climate/weather modellers that are familiar with numerical
python does speak in its favor.   I'll add this to my list of
"options" that I'll feed to people at NASA.

Cheers,

- Tom

>>>>> "Phil" == Phil Austin <[log in to unmask]> writes:

    Phil> Tom Clune writes:
    >>  My purpose in posting this message is to locate others in the
    >> community that may have implemented or be interested in
    >> implementing certain OO capabilities using some preprocessor
    >> (PERL?) and an F95 compiler.
    >> 

    Phil> Here's another possibility: write the framework in Numerical
    Phil> Python (http://numpy.sourceforge.net/)

    Phil> with bindings to the F90 and C++ code using Paul Dubois'
    Phil> wrapper packages Pyfortran and CXX:

    Phil> http://pyfortran.sourceforge.net/

    Phil> http://CXX.sourceforge.net/

    Phil> Advantages:

    Phil> 1) F77 programming scientists can pick up enough Python to
    Phil> be productive in about 3 hours.  Some tutorials for
    Phil> computational chemists give an idea of this:

    Phil> http://www.wag.caltech.edu/home/rpm/python_course/

    Phil> http://starship.python.net/crew/hinsen/

    Phil> 2) The language is currently "hot", and attracts very
    Phil> talented professional C++/Java coders (viz. the discussions
    Phil> on comp.lang.python).  It can handle projects at least as
    Phil> large as anything NASA/Goddard will come up with
    Phil> (e.g. http://www.zope.org)

    Phil> 3) There is an big community of Python-using scientists.
    Phil> Two examples in areas pertinent to gsfc are the

    Phil> a) the LLNL climate analysis data center

    Phil> http://www-pcmdi.llnl.gov/software/cdat/index.html
    Phil> http://www.python.org/workshops/2000-01/proceedings/papers/dubois/PCMDI-Python.html

    Phil> b) up the B-W parkway from you, at the Space Telescope
    Phil> Institute

    Phil> http://scisoft.stsci.edu/languages/Python.html


    Phil> also pertinent is Los Alamos' ACL commitment as evidenced
    Phil> by:


    Phil> http://software-carpentry.codesourcery.com/


    Phil> I can't speak for everyone at Goddard, but I know many of my
    Phil> former colleagues in Code 913 would jump at the chance to
    Phil> migrate to Python.

    Phil> If you'd like to see some short examples of wrapping Fortran
    Phil> radiation/thermodynamic codes (some from the GSFC climate
    Phil> and radiation branch), drop me a line.


    Phil> Regards, Phil

    Phil> Phil Austin INTERNET: [log in to unmask] (604) 822-2175 FAX:
    Phil> (604) 822-6150

    Phil> http://www.geog.ubc.ca/~phil Associate Professor Atmospheric
    Phil> Sciences Programme Geography #217 University of British
    Phil> Columbia 1984 W Mall Vancouver, BC V6T 1Z2 CANADA


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%