Dave Nichols et al 1993 implemented an object-oriented, geophysical inversion library, known as CLOP. CLOP never overcame its experimental character, however: it dealt almost exclusively with the inversion of linear operators, and it stored its data in a proprietary and inefficient C++ package (M++). In summary, CLOP's lack of speed, its programming errors, and some confusing defaults made the package unattractive for routine processing. However, CLOP enabled Dave Nichols Lumley et al. (1994) to prototype a new multiple inversion scheme rapidly, a work that might not have been attempted in a more traditional environment. Simultaneously, Dave Nichols and Lester Dye (Petroleum Engineering at Stanford) designed an improved class hierarchy that directly expressed the abstraction inherent in vector algebra.
Mark Gockenbach and Bill Symes independently developed a strikingly similar C++ library. In 1994, the efforts at Rice and Stanford merged into the HCL library Schwab (1994). Mark Gockenbach is HCL's primary author Gockenbach and Symes (1996) and maintains a detailed web-page 1996.
Currently, the HCL user community is small but nevertheless difficult to list precisely. At the present, Bill Symes's Rice Inversion Program and SEP experiment with geophysical problems. Martin Karrenbach has promised to continue HCL and related GOON work at Karlsruhe University. Dave Nichols shows continued interest, although his direct participation may be limited by his professional obligations. Finally, Mark Gockenbach continues to develop and maintain HCL. He also applies HCL to non-geophysical problems, such as molecular energy minimization.
Lydia Deng 1996 of the Colorado School of Mines chose a very different approach, called COOOL, when developing a C++ system for geophysical inversion. Rather than casting the inversion in terms of fundamental algebraic expressions, such as vectors, she concentrated directly on more complex classes, such as objective functions and solvers. A solver hands a set of model parameters to an application's objective function for evaluation . The objective function returns a single cost value to the solver . While this simple data transfer succeeds in the separation of the solver and application code, it does not support solvers that take advantage of additional application specific information, such as the derivative of the objective function.