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..

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

> 
> 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++.

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

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

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

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

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

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

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

Further more,

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

    A good example would be the MPI library for Fortran, where none of
    advanced C struct is seen by a Fortran user.  It might be considered
    easy to do so for a system developed in C, practical solutions for
    wrappers do exist in Fortran 90 for specific module patterns.
    
    (I also suspect there are only specific solutions for specific
    module patterns, if one wants to do them right.  I could not even
    find a generic solution between Fortran (90) and FORTRAN (77).)

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

Both constraints are based on the earlier encapsulation consideration.
More specifically, if a data object is defined in a "space" in Fortran,
_all_ its operations should be defined in its own "space" in Fortran,
except some "handles" to the objects and some procedure names to the
operations, and certain well defined "fluxes" of the selected intrinsic
data-types going in and coming out its 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 Guo, [log in to unmask], (301)614-6172(o), (301)614-6297(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771


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