INTRODUCTION

In the last ten years SEP has seen a progression in the way it does inversion. Earlier version of Claerbout (1999) coded the conjugate gradient loop within a FORTRAN 77 main program. Later, with the adoption of FORTRAN 90, the solver became a subroutine, operators were in modules, and vectors were 1-D arrays of floats (and later complex). This solution proved effective for a large range of problems. It was an ineffective for other problems and resulted in several additional FORTRAN 90 packages. To handle non-linear problems Clapp and Brown (1999) and Guitton (2000) introduced non-linear solvers. To handle problems that could not fit within core memory, Sava (2001) introduced a out of core solver. All of these packages have been used extensively at SEP over the years, but they all suffer some weaknesses that are related to coding in Fortran 90.

During the same period we have seen people in the geophysical community take a more object-oriented approach to the problem than FORTRAN 90 allows. Deng et al. (1996), Gockenbach and Symes (1999), and Harlan (2004b) used C++ as their controlling inversion framework. Schwab and Schroeder (1997); Schwab (1998) and Harlan (2004b) designed inversion systems within Java. For at least Deng et al. (1996) and Gockenbach and Symes (1999), memory limits was one of the reasons for the object-oriented language choice.

The size and complexity of the inversion problems at SEP has dramatically increased. These problems now involve operators that can take days to weeks to run Clapp (2003b); Sava and Biondi (2003) and can involve multiple instances of complex operations Clapp (2003a). Running these problems on Beowulf clusters poses a problem. The odds of a multi-week job running without a node failing is low. In addition, multiple instances of the same, or similar operator, is problematic (increasing with the complexity of the problem) in FORTRAN 90.

In this paper I discuss a new solution to the instability and complex problem description. I describe a Python inversion library which uses abstract vector and operator descriptions. From these abstract classes I derive specific classes to handle out-of-core problems. Operators become wrappers around SEPlib programs and vectors wrappers around SEPlib files. Deng et al. (1996) is a similar solution using C++ and SU. The difference is my Python library is built upon the framework described in Clapp (2004), which handles fault tolerance within parallel programs, and provides the building blocks for easy restarting of inversions.

I will begin by discussing the abstract vector and object design. I will then discuss the specific cases of out-of-core vectors and operators. I will conclude with a simple example of using the library.