Seismic processing invariably involves the application of a sequence of algorithms to large quantities of digital seismic data. This sequence is often referred to as the “flow”. Although each project tends to follow a familiar flow we’re dealing with real world data here so modifications are required to deal with irregularities in the data (and metadata). For this reason seismic processing packages are more like high level programming languages where the flow is constructed by the user selecting appropriate modules and parameters to achieve the desired result.

Flows in most seismic packages consist of a single pathway (a sequence of modules specified one after the other) created by modifying a simple text file which states the order of modules and the parameters for each. digger on the other hand allows for more creative flows and these are only realistically modified withing the user interface. The following screen capture shows a simple linear flow being created.

The user places a sequence of modules, specifies some parameters, joins them all together with pipes and then runs the flow. Let’s say we wanted to something a little bit more creative. For example, just imagine we only wanted to perform the bandpass filtering on traces with offsets less than 500m. We can do this using multiple pathways and the modules fork and join.

Next, we decide that we don’t want to drop any traces for the time being so the drop module gets disabled. Then we want to change the parameters in the bandpass filter. And finally instead of outputing the result to disk we would like to view the data in our seismic viewing program.

Using this multi-path approach it is relatively easy to construct quite complex flows if the need arises. We find the flexibility offered by this core piece of software invaluable to our prototyping and problem solving workflows.

So there you have it, that’s digger. In future posts we will cover other interesting features and specific modules of this program.