DEBACLE AVERTED

After one week, it seemed that our workshop was failing to foster cooperation. Two distinct camps were emerging: one favoring a pure C++ solution and the other an F90 solution. At SEP we were experiencing the same cultural divide that exists in the programming world at large. Fortran and C have had an uneasy marriage for 20 years. Now their offspring, F90 and C++ are estranged. F90 is the community of those who value high performance computing, continuity with past numeric codes, easy of learning, and unambiguous code. C++ is the community of popular modern computer science, namely, powerful abstractions.

Most SEP students were opposed to the adoption of a pure C++ system. The reasons for such resistance are rooted in recent SEP history, and go beyond the actual shortcomings of C++ as a tool to implement numerical algorithms. First, several previous attempts to build a critical mass of C++ programmers at SEP have not been successful, inducing skepticism about the chances of a new effort. Second, our new Power Challenge has compilers generating efficient parallel multi-threaded executables from F90 code, but not from C++ code. The iterative nature of the inversion algorithms that we use, combined with the desire of working on 3-D problems, makes the efficient use of the available computing resources even more important for inversion than for our usual research. A related reason is that much of the utility software layered on the top of Seplib90 Biondi et al. (1996), our new library for 3-D irregularly sampled data sets, had been already developed in F90 Clapp and Crawley (1996). Porting these libraries to C++ would be feasible, but an unwelcome chore.

On the other hand, despite the valiant efforts of several students, no simple and robust solution was found to implement in F90 several attractive capabilities that HCL easily supports in C++. Building a complex geophysical operator by combining simple ones can tremendously increase the speed of development and testing of sophisticated inversion methods. Complex operators can be built by assembling operators into an operator array, such as the ${\rm C=[A, I]^{'}}$,or into an operator chain, such as C=AB. F90 does not support a general method for assembling operators. Even if specialized routines can be written for implementing particular assembly patterns, recursive combination, such as building chains of operator matrices, are impossible. Further, multiple instances of the same type of operator cannot be initialized with different set of parameters. Therefore, operator chains, such as ${\rm C=A_1BA_2}$, cannot easily be constructed in F90. These difficulties are mostly consequences of the the restrictions on the use of subroutines and functions in F90. Function names can be passed around as arguments, but functions themselves cannot be components of derived types (F90 equivalent of C structures). Unfortunately, it seems that also Fortran 95 will inherit this severe handicap affecting the Fortran bloodline.

The logical solution of our mid-workshop impasse was combining C++ with F90; to take advantage of the attractive characteristics of both while bypassing their respective limitations. However, the binding of the F90 with C++ is difficult and non-standard. Because the two languages cater to different communities, compiler writers have not set a standard for linking object code generated from the two languages. Further, there are no defined interfaces specifying how to pass structures across language boundaries. Fortunately, our dynamic duo, Dave Nichols and Martin Karrenbach, overcame the conflict between Fortran 90 and C++ communities by finding a way to link them, at least on our SGI computer, and allowing crude cooperation until about 2001 when JAVA might subsume both. GOON was born.