Elastic wave-mode separation

August 29, 2010 Documentation No comments

Two new papers from the Center for Wave Phenomena, Colorado School of Mines, are added to the collection of reproducible documents:
Elastic wave-mode separation for VTI media
Elastic wave-mode separation for TTI media

Predictive painting

August 26, 2010 Documentation No comments

A new paper is added to the collection of reproducible documents:
Predictive painting of 3-D seismic volumes

Madagascar for users of Seismic Unix

August 17, 2010 Systems No comments

Seismic Unix (SU) is a famous open-source seismic processing package maintained by John Stockwell at the Center for Wave Phenomena, Colorado School of Mines.

SU has been around for 25 years and has attracted many devoted users. If you are one of them, please consider the following:

  • Using Seismic Unix is not an excuse for non-reproducible computational experiments. To facilitate reproducibility, you can use Python and SCons with the rsf.suproj module supplied by Madagascar. The book/rsf/su directory contains many examples of seismic data processing flows using SU and their loose translation to Madagascar analogs. Here is an example SConstruct script from rsf/su/sulab1
from rsf.suproj import *

Flow('plane',None,'suplane')
Result('plane','suxwigb label1="Time (s)" label2=Trace')

Flow('specfx','plane','suspecfx')
Result('specfx','suxwigb label1="Frequency (Hz)" label2=Trace')

End()

Its loose Madagascar translation is in rsf/su/rsflab1

from rsf.proj import *

Flow('plane',None,
     '''
     spike n1=64 n2=32 d2=1 o2=1 label2=Trace unit2=
     nsp=3 k1=8,20,32 k2=4 l2=28 p2=2,1,0 
     ''')
Flow('specfx','plane','spectra | scale axis=2')

for plot in ('plane','specfx'):
    Plot(plot,
         '''
         wiggle clip=1 transp=y yreverse=y poly=y
         wanttitle=n wheretitle=b wherexlabel=t
         ''')

Result('specfx','plane specfx','SideBySideAniso')

End()

If you want only rsf.suproj but not the rest of Madagascar, download madagascar-framework package from SourceForge.

  • It is also possible to convert between SU and RSF file formats with sfsuread and sfsuwrite and to combine SU and Madagascar programs in common processing flows.

  • If you decide to switch to Madagascar but are missing certain functionality from Seismic Unix, it is possible and legal to borrow code from SU and to add it to Madagascar. The opposite is not true, because the Madagascar license (GPL) is more restrictive than the SU license (BSD-like). The su directory contains some of the codes Madagascar has borrowed from SU by requests of the users. Naturally, we try to limit such borrowing to avoid unnecessary forks.

  • In a recent message to the Seismic Unix mailing list, John Stockwell described a proposal for S3, the third generation SU. The main requirements for S3 are:

    1. a new project managed on SourceForge
    2. GPL license
    3. flexible trace headers
    4. integration with scientific libraries
    5. integration with the current SU as well as other GPL- or BSD-licensed packages

One cannot help thinking that the project that John describes is Madagascar!

A recent case for reproducibility in climate science

August 4, 2010 Uncategorized 1 comment

Eureka Daily, a science blog at The Times newspaper, published a two-part article by Hannah Devlin about freedom of information in science (“FOI: should scientists be exempt?” and “Freedom of information and climate science” – both require a subscription). Part two discusses issues of openness in the context of a recent investigation of research practices of CRU – a climate research group at The University of East Anglia.
Here is an interesting excerpt from the second part:


As Myles Allen, a climate scientist at the University of Oxford points out, in most cases that which is in the public interest will be good for science too. Validation and replication are central to the scientific method. However, points of contention remain about the optimum degree of information sharing. Allen, for instance, suggests that while open access to data is generally desirable, making the computer code used to analyse data available online could have unintended negative consequences. If everyone’s using the same code, who’s going to challenge whether it’s working correctly?
This view is countered by programmer John Graham-Cumming, who found coding errors after trying to reproduce the CRU/Met Office’s CRUTEM and HadCRUT global warming datasets. Working from the raw data released by the Met Office and the description of their process for generating the datasets in a scientific paper he decided to validate their work – a considerable effort that required writing code to implement the algorithm described in the paper. In doing so, he found a problem with the way the error ranges were calculated (amongst other errors), stemming from a bug in their code.
He says: “You could say that by not releasing their buggy code they forced me to find the bug in it by writing my own validation. But actually, if they’d released their code I would have been able to quickly compare the code and the paper and find the bug without the massive effort to write new code. And no one else had actually done this validation (including the Muir Russell review) and as a result the Met Office has been releasing incorrect data for a long time. Perhaps that’s because the validation was so hard in the first place, whereas having code to check would have been easy.”

John Graham-Cumming demonstrated why reproducibility is crucial for computational sciences: it exposes scientific algorithms and workflows to a greater audience, thus preventing critical bugs from going unnoticed.
Reproducibility is an approach to openness in computational sciences. It assumes that not only data but source code (and eveything else needed to reproduce published results) should be released. At the end of the day, it might save one’s scientific credibility from a rather unpleasant public exposé.

Event of the year

August 3, 2010 Celebration No comments

The July 2010 School and Workshop in Houston went well and attracted more than 50 people, about half of them being graduate students. About 10 companies and 12 universities were represented. The event was sponsored by the Petroleum Technology Transfer Council. All presentation materials from the workshop are now available on the website.

For reproducible research, go to Madagascar

July 30, 2010 Celebration No comments

A story about Madagascar is featured today on the SourceForge blog.
Among more than 230,000 software projects hosted by SourceForge, Madagascar is currently the 210th in activity (or top 0.1%) thanks to the recent release of 1.0 and to our active Subversion repository.

madagascar-1.0

July 22, 2010 Celebration No comments

A big event in the Madagascar history: the first non-beta stable version (madagascar-1.0) is released! The event is celebrated at the School and Workshop in Houston.
This release features new reproducible papers, major structural improvements (thanks to Nick Vlad) and an automatic testing system (thanks to booklist, figlist, and testlist from Jim Jennings and vplotdiff from Joe Dellinger).
The cumulative number of all previous stable release downloads has exceeded 10,000.

The madagascar reference manual

July 20, 2010 Documentation No comments

SWAG (Seismic Wave Analysis Group) at KAUST is glad to introduce the Madagascar reference manual that includes description and usage information for all functions in rsf.h. These include Data types, preparing for input, operations with RSF files, error handling, linear operators, data analysis, filtering, solvers, interpolation, Smoothing, Ray tracing, General tools, Geometry, and System. The purpose behind this manual is to ease the task of searching for subroutines and understand their function. You can access the manual at book/rsf/manual.

Is there a Graphical User Interface to Madagascar?

July 19, 2010 FAQ No comments

A hardcore Madagascar user does not need anything more than a friendly editor (to edit SConstruct files) and the good old command line (to run scons commands). However, sometimes it is necessary to provide simplified GUIs (Graphical User Interfaces) for inexperienced users. Creating GUIs in Python is quite simple. An example is provided in rsf/rsf/gui. In this example, we obtain a compressed approximation of a piecewise-regular signal with by a wavelet transform. The figure using default parameters is shown below:

There are two main parameters in this experiment: the type of the wavelet transform (type= parameter in sfdwt) and the thresholding percentile (pclip= parameter in sfthreshold). The first step is to expose these parameters to CLI (Command Line Interface) by using ARGUMENTS.get construct in SConstruct:

# Wavelet transform type 
type = ARGUMENTS.get('type','b') 
# Thresholding percentile 
pclip = int(ARGUMENTS.get('pclip',50))

Now one can select parameters on the command line by launching something like

scons type=b pclip=50 view

Next, we build the GUI by using one of the Python interfaces. The gui.py script provides an interface using Tkinter, the most standard Python GUI package. It allows the user to select the parameter values graphically. Clicking the Run button would then launch scons with the selected parameters in the background.

An alternative, both simple and powerful GUI package is Traits from Enthought Inc. An example Traits-based interface interface is provided by gui-traits.py.

For full-featured GUIs exposing all program parameters, one can use the Madagascar interface to TKSU or OpendTect.

Dip-constrained transversely-isotropic medium

July 12, 2010 Documentation No comments

A new paper is added to the collection of reproducible documents:
A transversely isotropic medium with a tilted symmetry axis normal to the reflector

This paper is the first reproducible paper contributed by Seismic Wave Analysis Group from KAUST.