>>>>> "Jing" == Jing Guo <guo@dao> writes:

    Jing> Tom Clune wrote:
    >> If none of the scientists had ever ventured beyond F77, then
    >> the solution would be to write the framework in C++ and call
    >> F77 routines as needed.  However, many scientists have started
    >> using various F90 extensions which introduce _nontrivial_
    >> inter-language issues.  (E.g.  how to pass the dope vector for
    >> F90 arrays.)
    >> 
    >> I see 4 solutions.
    >> 
    >> 1) Rewrite any necessary F90 code in C++.  Some scientists will
    >> probably resist this to the point that the project will fail.
    >> On the plus side, we could hire some new software engineers
    >> that would otherwise be unwilling to work in Fortran.  (Begging
    >> the question of whether NASA can afford to hire C++ software
    >> engineers ...)
    >> 
    >> 2) Wait for F2k compilers to be released (and stable).  F2k
    >> provides almost everything that is needed to develop a
    >> framework.  However, we cannot wait that long, and it is very
    >> difficult to find software engineers that will work in any
    >> variant of Fortran..

    Jing> Although these two solutions are often mentioned, I wonder
    Jing> if anyone would consider them practical.

Certainly some people must consider waiting for F2k to be practical,
or else why is anyone bothering to work toward creating such a
standard?


    >>  3) Provide "handles" for any complex F90 derived type
    >> variables, and use the handles as an ugly interface to the C++
    >> framework layer.  This is functional, but relatively inelegant.
    >> (Special thanks to Jing Guo for this suggestion.)
    >> 
    >> 4) Use some sort of preprocessor that allows us to bootstrap
    >> fortran towards something like F2k/C++.

    Jing> Comparing the two solutions, solution (4) would certainly be
    Jing> a very powerful solution with wide applications, even if it
    Jing> means we have to limit our styles of Fortran 90 programming.
    Jing> However, I am also highly skeptical for any good chance of
    Jing> success.  It just seems to be a too complicate issue to be
    Jing> generally handled for now, plus that a general solution of
    Jing> mapping F90 types to C/C++ structures seems beyond
    Jing> necessary.

Yes, I was only arguing for doing a critical subset that would allow
(minimal) abstract base classes with automatic inheritance properties.
I think that this would be relatively easy for someone with the
correct skills. (I.e. not me.)

    Jing> Even for solution (3), I don't think it should be considered
    Jing> as a general solution, but case-by-case "hacks" if you like.

Certainly.

    Jing> First, I strongly believe that a robust mixed language
    Jing> environment is ensential for the developments of today's or
    Jing> tomorrow's complicate scientific computing systems.  This is
    Jing> really not by choice but by reality.

    Jing> Having said that, I don't think this mixed language
    Jing> environment must be general (or even possible to be so).
    Jing> This environment may be implementable only if some
    Jing> constraints are enforced.  For example, I believe following
    Jing> constraints would be helpful:

    Jing> o A software "module" (not a Fortran MODULE) should be
    Jing> developed in the same language, with interfaces to other
    Jing> "modules" that may be written in other languages.  This
    Jing> often naturally happens.

    Jing> o A software "module" should have very strong encapsulation.
    Jing> This also often naturally happens if the "module" is
    Jing> identified properly.

    Jing> Two constraints above will allow the interface of this
    Jing> "module" with the outside world (e.g. C or C++ or Fortran)
    Jing> to be minimized.  I think this is a very important initial
    Jing> condition.  If one can not define a small set of practical,
    Jing> stable, yet extendible, Fortran 90 interfaces for a given
    Jing> "module" (or make it a "class"), there is little reason to
    Jing> go any further.

But you do not get inheritance this way.  The "powers-that-be" have
essentially dictated that the nature of frameworks contains
inheritance of abstract base classes.   Thus, the handle would
in principle allow you to participate in the framework, but you'd
probably lose most of the value.

    Jing> Further more,

    Jing> o Only a selected subset of intrinsic data types-kinds-ranks
    Jing> (e.g.  INTEGER, REAL, and DOUBLE PRECISION) should be
    Jing> allowed to define the interfaces between two languages.
    Jing> This may sound less desirable, but could still be very
    Jing> powerful.

Sure, people got by with C/F77 for a couple of decades.

    Jing> A good example would be the MPI library for Fortran, where
    Jing> none of advanced C struct is seen by a Fortran user.  It
    Jing> might be considered easy to do so for a system developed in
    Jing> C, practical solutions for wrappers do exist in Fortran 90
    Jing> for specific module patterns.

    Jing> (I also suspect there are only specific solutions for
    Jing> specific module patterns, if one wants to do them right.  I
    Jing> could not even find a generic solution between Fortran (90)
    Jing> and FORTRAN (77).)

    Jing> o Give an open mind to copy-in/copy-out.  If it is
    Jing> reasonable to do copy-in/copy-out between Fortran routines,
    Jing> why can't we do that for the interfaces between two modules,
    Jing> which are often defined at a much higher level?

    Jing> Both constraints are based on the earlier encapsulation
    Jing> consideration.  More specifically, if a data object is
    Jing> defined in a "space" in Fortran, _all_ its operations should
    Jing> be defined in its own "space" in Fortran, except some
    Jing> "handles" to the objects and some procedure names to the
    Jing> operations, and certain well defined "fluxes" of the
    Jing> selected intrinsic data-types going in and coming out its
    Jing> own "space".

    >>  I look forward to seeing your responses.
    >> 
    >> Cheers,
    >> 
    >> - Tom
    >> 
    >> -- 
    >> Thomas Clune, Ph.D. Parallel Applications Consultant SGI
    >> [log in to unmask] Code 931 NASA GSFC 301-286-4635 (work) Greenbelt,
    >> MD 20771 301-286-1634 (fax)
    >> 

    Jing> Jing -- ________________________________ _-__-_-_ _-___---
    Jing> Jing Guo, [log in to unmask], (301)614-6172(o),
    Jing> (301)614-6297(fx) Data Assimilation Office, Code 910.3,
    Jing> NASA/GSFC, Greenbelt, MD 20771

--

-- 
Thomas Clune, Ph.D.	Parallel Applications Consultant
SGI			[log in to unmask]          
Code 931 NASA GSFC      301-286-4635 (work)
Greenbelt, MD 20771	301-286-1634 (fax)



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