(j3.2006) Interesting F2003-ism

[Aleksandar Donev]

Bill Long wrote:

> At the beginning, only Fortran 
> callees have arguments like these, so initially in the actual real 
> world, all the focus will be on C calling Fortran.  None of the "lots of 
> libraries" you mention are set up to deal with this. 
And we don't have an interop TR so how this point makes any sense is 
beyond me. We are trying to help them set up to deal with this!

> Most of the rank-independent arguments I see in C libraries 
> are typeless buffers in routines used to just move data from one place 
> to another. Given that Fortran has intrinsic assignment for arrays, 
> libraries like these seem irrelevant to a Fortran programmer.
That is where you are wrong! I am at a SIAM conference now where I heard 
at least five Fortran jokes in random contexts in public talks, mostly 
by people developing FRAMEWORKS for solving scientific problems. Things 
like coupling different PDE solvers together, meshing by a centralized 
agent that than calls other specialized solvers, adaptive mesh 
refinement libraries, automatic computation and communication 
reordering, and all kinds of other stuff. I can try to write examples if 
I had the time, but I suggest looking at the program for the SIAM 
Conference on Computational Science and Engineering program on line. 
There is tons of talks about software infrastructures.

At present, all of those people are mostly concerned about calling 
Fortran-77 codes to do some compute-intensive jobs. They are trying to 
do Fortran-90 and are running into major headaches...this is what gave 
Craig headaches too...People get payed by DOE to do this but it is not 
easy. For example, AMR codes allocate memory for the refined meshes 
themselves. They use *sophisticaed* data structures---they don't just 
copy around buffers (and there are some that do, notably MPI and 
variants thereof). PETSc, which is now considered legacy code, uses 
array pointers to give Fortran 90 access to internal data-structures. 
But it needs the interop TR to do this portably. With the allocatable TR 
they may sometimes be able to do better by allowing non-alised access to 
the Fortran codes.

I am not even an expert on these C++ infrastructure codes developed 
mostly at DOE labs, since I program very specific particle-based codes 
and they are focused on PDEs mostly. But I have been to enough talks and 
have enouigh colleagues that do to know they are very important. You 
don't see them because as I said they avoid anything above Fortran 77 
like the plague...

Aleks