Editing RSF School and Workshop, Vancouver 2006 (section)

==Abstracts==

=== Jon Claerbout: Reproducible computational research - A history of hurdles, mostly overcome ===

I discovered reproducibility in computational research when I learned about makefile syntax and how to use it to incorporate figures in documents. Here I summarize the reproducibility obstacles I faced writing textbooks, teaching reproducibility, how SEP has set up it's reproducibility rules, and how it uses them. An unanswered question is what we can do to enable reproducible research to spread more widely throughout the community. The next "killer application" will be "reproducible lectures."

=== Matthias Schwab: Reproducible Research - Opportunities in non-research communities ===

Reproducible research was created by academic scientists doing data processing. Unfortunately reproducible research has not spread widely among this research community, nor has a standard technology evolved. Why? And do other potential user communities exist that would benefit even more from a similar technology? What are their needs? And would they potentially be more capable in adopting such a technology? Is there a business case out there? 

=== Igor Morozov: Integrated open-source geophysical code framework ===

In the [http://seisweb.usask.ca/SIA SIA package], we propose an open-source code framework to meet the needs of both academic and commercial researchers in several areas of geophysics. SIA currently includes over 200 dynamically-linked plug-in tools which are tightly integrated with a content-agnostic processing monitor and serve a wide range of processing tasks. The package consists of three main components operating as parallel UNIX processes: 1) multiple and optionally distributed processing flows using dynamically-linked object libraries, 2) the user interface implemented using Qt, and 3) 3D/2D interactive visualization server based on OpenGL. These components communicate with each other by means of an object protocol currently based on the Parallel Virtual Machine (PVM). Object and class libraries, templates, and software development utilities were developed, including an automated, distributed, web-based code update service.

At present, the scope of SIA applications includes reflection, refraction, and some earthquake seismology, numerical modeling, 2- and 3-D potential field processing and inversion, graphics, and web services. Several key algorithms, (for example, 1-D and 3-D finite-difference seismic modeling and 2-D ray tracing) were ported into the system. 

After 10 years of its development, batch execution remains the main mode of SIA operation, and UNIX shells can be used to implement complex and fully reproducible data processing. Seismic Un*x sub-flows can be used in CMP processing applications, and GMT is extensively used for PostScript plotting. The new OpenGL visualization program allows building custom interactive user interfaces, such as for travel-time picking, ray tracing, and 2-D gravity modeling. Reproducibility of interactive processing may present some concern; however, with flexible parameterization and two-way interaction of the GUI with the calling processing flows, this goal is well within the capability of the framework and implementation presented here.

=== Joe Dellinger: DDS, A Seismic Processing Architecture ===

The Data Dictionary System (DDS1) is a seismic processing architecture. It has proved its value for both research and production in seismic imaging inside Amoco and BP for more than a decade. The software has been ported to more than a dozen hardware platforms and the data sets can be efficiently accessed across any combination of them. A key (and at this time, unique) feature of DDS is its ability to read and write almost any data format. This is primarily useful because it allows DDS to inter-operate with other processing systems, allowing DDS to serve as a bridge between different processing environments. However, in the spirit of reproducible research, it also allows DDS to document data so that it can be read and understood into the future. DDS was released by BP America in 2003 under an open-source license. The goal of this paper is to reveal useful innovations so that subsequent projects can benefit from DDS, as DDS has benefited from concepts from earlier processing systems.

=== Randy Selzler: PSEIS, A Processing Architecture Blueprint ===

The Parallel Seismic Earth Imaging System (PSEIS1) is a software package that is envisioned as a successor to DDS2. It will retain the high efficiency that made DDS suitable for production processing at a leading HPC facility. Its flexibility will continue to facilitate advanced research in seismic processing and imaging. It will also continue to inter-operate with other processing system in order to maximize total value. The new system provides an alternative to MPI for parallel processing on distributed-memory machines. By tailoring it specifically for seismic processing, applications will be easier to develop, maintain and execute, while remaining efficient and scalable. This scheme is described in a companion paper session “PSEIS, Blueprint for Parallel Processing.”
The system supports parallel I/O by slicing data set dimensions across independent file systems. I/O can split headers and samples into separate file for special processing. Two user interfaces are provided that complement each other. Power users can leverage existing skills with scripts and casual users can benefit from the GUI. Object-Oriented technology is used to improve robustness, functionality and long term cost.

=== Randy Selzler: PSEIS, A Blueprint for Parallel Processing ===

The Parallel Seismic Earth Imaging System (PSEIS1) is a software package that is envisioned as a successor to DDS2. It provides an alternative to MPI for parallel programming on distributed (and shared) memory machines. The objective is to make it easier to develop, maintain and execute parallel applications that are efficient and scalable. This is accomplished by integrating the technology into the I/O architecture and by tailoring it specifically to seismic processing. The new scheme provides a strategy for fault-tolerant processing, check-point restarts, persistent data storage, out-of-core solvers, data monitoring and parallel debugging.

=== Joe Dellinger: Vplot graphics language - past, present, and future ===

Vplot is the graphical language used by the Stanford Exploration Project's "SEPlib" seismic processing system. Application programs such as "Graph", "Wiggle", and "Grey" write out specifications for plots in "vplot format". The appropriate vplot "pen" filter then reads in the vplot file and
produces the desired plot on the corresponding graphical device.

Vplot was originally created to allow consistent plotting on any of a dozen or so different graphical devices, each of which could only be accessed
using its own unique and proprietary programming interface. With so many devices (and now ones arriving every few months!), writing a separate version
of each plotting program for each device would have been completely impractical. Today, however, that is exactly what we do: most graphical programs directly support "X", "postscript", and/or "bitmaps".

Vplot is still in use today at least partly because the challenge of supporting so many different incompatible devices imposed a discipline that
produced a flexible and powerful internal programming logic. Even with the universe of plotting devices now collapsed down to only 3, vplot has been
useful enough in making those 3 compatible to survive.

In my talk I will explain the "vplot virtual device" and show how it was meant to be used. I will show what I think are the "good ideas" vplot
contains that even today have not been replicated in other systems. Foremost among these is the "4th canonical graphical device", the "capture the changes I've made and turn that back into a new figure" device ("vppen"). I will also show useful features in vplot that should still be used, but have been forgotten.

Finally, I will discuss "where should we go from here". If we wish to use vplot with Madagascar, now is our chance to update it!

=== Jeff Thorson: TKSU – Experiences with a graphical front end to SU ===

Seismic Unix (SU) is a readily available seismic processing package
from the Center for Wave Phenomena, CSM, with a command-line-driven
interface. TKSU is a graphical user interface to SU that provides the
ability to interactively build a processing flow out of SU modules,
set values for module parameters from menus, and create a shell script
to execute the processing flow. Although developed specifically for
the SU package, TKSU is loosely coupled to SU and can manage any set
of programs that follows the command-line parameter conventions of SU.
TKSU is written entirely in Tcl/Tk. In this talk I discuss the
advantages and shortcomings I’ve experienced with a generic graphical
front end to processing flow scripts.

=== Roscoe Bartlett: An Overview of the Thyra Interoperability Effort for Abstract Numerical Algorithms within Trilinos ===

The Trilinos Project is an effort to develop and implement robust parallel algorithms using modern object-oriented software design, while still leveraging the value of established numerical libraries such as PETSc, Aztec, the BLAS and LAPACK. It emphasizes abstract interfaces for maximum flexibility of component interchanging, and provides a full-featured set of concrete classes that implement all abstract interfaces.  The number of Trilinos packages continues to grow along with the variety and sophistication of the numerical algorithms (and other numerical support software) contained in these packages. It is clear that the standalone use of these packages and algorithms is insufficient to solve tomorrows challenging multi-physics analysis and design problems. The Thyra effort seeks to develop a uniform set of Trilinos standard software interfaces and protocols by which any reasonable combination of Trilinos algorithms and other tools may be automatically supported; even configurations that the individual package and algorithm developers never even imagined. In this talk I will provide an overview of the Thyra effort discussing its context, requirements, history, current status, and future plans. Thyra is both a Trilinos package (named thyra) and a more general collaboration between Trilinos developers. The primary focus of Thyra is the support for abstract numerical algorithms (ANAs) such as iterative linear solvers (e.g. Belos), eigen solvers (e.g. Anasazi), nonlinear equation solvers (e.g. NOX), stability and bifurcation analysis (e.g. LOCA), ODE/DAE solvers (e.g. Rythmos), and constrained optimization (e.g. MOOCHO). The primary foundation for Thyra's ANA support is a minimal set of fundamental operator/vector interoperability interfaces expressed as abstract C++ classes. Using the foundation of these basic operator/vector interfaces, more sophisticated mathematical interfaces are being developed to address higher-level capabilities such as preconditioner factories, linear solver factories, nonlinear model evaluators, and nonlinear solvers.

=== Bill Spotz: PyTrilinos: A Python Interface to Trilinos ===

PyTrilinos is a python interface to selected Trilinos packages, discussed in the previous talk.  Such an interface provides all the power of a high-level scripting language combined with the computational efficiency of compiled solver code. This makes it a suitable environment for both rapid prototyping and application development.  Python is particularly well-suited for Trilinos, because the language was designed from the ground-up to be object-oriented, which allows for nearly one-to-one proxies of Trilinos C++ classes.  This talk will give an overview of the current status of PyTrilinos, with some emphasis on efforts made to make PyTrilinos compatible with other scientific python software such as NumPy and SciPy.  I will give a short interactive demonstration to convey the utility of the PyTrilinos interface, and will conclude with a proposal to provide a python interface to the Thyra package.

=== Bill Symes: A Software Framework for Inversion ===

This talk describes an experimental framework for algorithm organization and software development in support of research on geophysical inversion. The central assumptions of this project are that software components can be designed to closely mimic the mathematical concepts they implement, and that such mimicry eases algorithm construction and hypothesis-testing. I will report some applications of these ideas to modeling and inversion of reflection seismograms via finite difference modeling.

===Felix J. Herrmann: (P)SLIMpy: a object-oriented abstraction for (Parallel) numerical linear algebra ===

This talk gives an overview of current efforts at SLIM towards an out-of-core and parallel Python library. This library contains abstractions of pipe-based std-in/std-out programs wrapped into elementwise vector and matrix-vector operators. With this framework, we are able to develop matlab-like abstract numerical linear algorithms that are reusable and void of coordinate information. I will describe our progress towards parallelization of embarrassingly parallelizable algorithms and towards algorithms that require domain decompositions. I will also show how the abstraction allows us to use the same code for out-of-core serial as well as out-of-core parallel (MPI) abstract numerical algorithms. Our library is an example of how to interoperate different software packages that include PETSC (parallel vectors), Madagascar (vector and matrix-vector operations), CurveLab (Curvelet transform) and Python implementations of numerical arrays. This is joined work with Sean Ross Ross, Darren Thomson and Henryk Modzelewski.