DDS,ASeismicProcessingArchitecture.pptVIP

DDS, A Seismic Processing Architecture Reproducible research workshop UBC, Vancouver, 2006 Randall L. Selzler RSelzler @ Data-W Jerry Ehlers Jerry.Ehlers @ BP.com Joseph A. Dellinger* Joseph.Dellinger @ BP.com DDS ORIGINS: Amoco TRC, early 90’s DDS began at the Amoco Tulsa Research Center at a time of great organizational strain. The job of the TRC was to do research and crunch data, not to write software. Creating software is expensive! Amoco’s solution was an edict that “everyone will use DISCO, or else”. Else! But DISCO just wasn’t good enough! And so chaos ensued... We were “mired in seismic processing diversity”. DDS grew up surrounded by: USP (Amoco internal trace-header based) SEPlib (ASCII header pointing to data cubes) SU (SEGY trace-header based) DISCO (proprietary monitor-based system) .... and needed to be compatible with all of these! Although formally cast as a research group, in fact the TRC also functioned as an “internal contractor” processing shop. 1) So to catch on, not only would any software have to be usable for quick-turnaround research, but 2) the ability to process large datasets efficiently and in parallel was also of vital importance. [Terabytes of data, Connection Machines, MPI, OpenMP] 3) The group had accumulated a considerable number and variety of computers. [All “Unix”, but CM5, Cray, Sun, SGI, Linux, Linux clusters, 32 and 64 bit...] 4) Finally, there was an urgent need for software that could accomodate all the various mutant SEGY formats coming into the shop, as well as DISCO, SEPlib, SU, and USP! and out of the chaos came... John Etgen was using SEPlib for migration algorithm research on the CM200, a machine that required massively parallel data I/O. He showed SEPlib to Randy Selzler: “I want something that looks like THIS, but can handle the large industrial-strength jobs I need to do!” And thus DDS was born... How SEPlib did it DDS can