Many of the data processing operations are data-parallel: different traces, shot gathers, frequency slices, etc. can be processed independently. Madagascar provides several mechanisms for handling this type of embarrassingly parallel applications on computers with multiple processors.

1. OpenMP

OpenMP is a standard framework for parallel applications on shared-memory systems. It is supported by the latest versions of GCC and by some other compilers.
To run a data-parallel processing task like

sfradon np=100 p0=0 dp=0.01 < inp.rsf > out.rsf

on a shared-memory computer with multiple processors (such as a multi-core PC), try sfomp, as follows:.

sfomp sfradon np=100 p0=0 dp=0.01 < inp.rsf > out.rsf

sfomp splits the input along the slowest axis (presumed to be data-parallel) and runs it through parallel threads. The number of threads is set by the OMP_NUM_THREADS environmental variable or (by default) by the number of available CPUs.

2. MPI

MPI (Message-Passing Interface) is a standard framework for parallel processing on different computer architectures including distributed-memory systems. Several MPI implementations (such as MPICH) are available.
To parallelize a task using MPI, try sfmpi, as follows:

mpirun -np 8 sfmpi sfradon np=100 p0=0 dp=0.01 input=inp.rsf output=out.rsf

where the argument after -np specifies the number of processors involved. sfmpi will use this number to split the input along the slowest axis (presumed to be data-parallel) and to run it through parallel threads.
Note: Some MPI implementations do not support system calls implemented in sfmpi and therefore will not support this option.

3. MPI + OpenMP

It is possible to combine the advantages of shared-memory and distributed-memory architectures by using OpenMP and MPI together.

mpirun -np 32 sfmpi sfomp sfradon np=100 p0=0 dp=0.01 input=inp.rsf output=out.rsf

will distribute the job on 32 nodes and split it again on each node using shared-memory threads.

4. SCons

If you process data using SCons, another option is available. Change

Flow('out','inp','radon np=100 p0=0 dp=0.01')

in your SConstruct file to

Flow('out','inp','radon np=100 p0=0 dp=0.01',split=[3,256])

where the optional split= parameter contains the axis that needs to be split and the size of this axis. Then run something like

scons -j 8 CLUSTER='localhost 4 node1.utexas.edu 2' out.rsf

The -j options instructs SCons to run in parallel creating 8 threads, while the CLUSTER= option supplies it with the list of nodes to use and the number of processes to involve for each node. The output may look like

< inp.rsf /RSFROOT/bin/sfwindow n3=42 f3=0 squeeze=n > inp__0.rsf
< inp.rsf /RSFROOT/bin/sfwindow n3=42 f3=42 squeeze=n > inp__1.rsf
/usr/bin/ssh node1.utexas.edu "cd /home/test ; /bin/env < inp.rsf /RSFROOT/bin/sfwindow n3=42 f3=84 squeeze=n > inp__2.rsf "
< inp.rsf /RSFROOT/bin/sfwindow n3=42 f3=126 squeeze=n > inp__3.rsf
< inp.rsf /RSFROOT/bin/sfwindow n3=42 f3=168 squeeze=n > inp__4.rsf
/usr/bin/ssh node1.utexas.edu "cd /home/test ; /bin/env < inp.rsf /RSFROOT/bin/sfwindow f3=210 squeeze=n > inp__5.rsf "
< inp__0.rsf /RSFROOT/bin/sfradon p0=0 np=100 dp=0.01 > out__0.rsf
/usr/bin/ssh node1.utexas.edu "cd /home/test ; /bin/env < inp__1.rsf /RSFROOT/bin/sfradon p0=0 np=100 dp=0.01 > out__1.rsf "
< inp__3.rsf /RSFROOT/bin/sfradon p0=0 np=100 dp=0.01 > out__3.rsf
/usr/bin/ssh node1.utexas.edu "cd /home/test ; < spike__4.rsf /RSFROOT/bin/sfradon p0=0 np=100 dp=0.01 > out__4.rsf "
< inp__2.rsf /RSFROOT/bin/sfradon p0=0 np=100 dp=0.01 > out__2.rsf
< inp__5.rsf /RSFROOT/bin/sfradon p0=0 np=100 dp=0.01 > out__5.rsf
< out__0.rsf /RSFROOT/bin/sfcat axis=3 out__1.rsf out__2.rsf out__3.rsf out__4.rsf out__5.rsf > out.rsf

Splitting the input with sfwindow and putting the output back together with sfcat are immediately apparent. The advantage of the SCons-based approach (in addition to documentation and reproducible experiments) is fault tollerance: If one of the nodes dies during the process, one should be able to restart the computation without recreating parts that are already computed.

All these options will continue to evolve and improve with further testing. Please report your experiences and suggestions.

Just for fun… sfmandelbrot computes the famous Mandelbrot set. See examples in rsf/rsf/fractal.

Zooming in, one can explore different fractal patterns inside the set.

Just for fun… sffern computes “fractal ferns”. See an example in rsf/rsf/fractal and an animated gif.

It its now possible to check parameters for Madagascar programs in SCons flows using CHECKPAR option like this: scons CHECKPAR=y <target> Here is what happened when I first ran an example from rsftour:

bash$ scons CHECKPAR=y 
scons: Reading SConscript files ... 
No parameter "n2" in sfwindow 
Failed on "window n2=10 min1=0.4 max1=0.8"

After fixing self-documentation for sfwindow:

bash$ scons CHECKPAR=y 
scons: Reading SConscript files ... 
No parameter "nc" in sfwiggle 
Failed on "wiggle transp=y poly=y yreverse=y pclip=100 nc=100 allpos=n "

Fixing that one requires changing the SConstruct file.

CHECKPAR is an experimental option and will be enhanced in the future to include parameter ranges and other safety checks. Another useful option is TIMER.

You can now time the execution of processing flows in Scons using a TIMER option. Use it like this:
scons TIMER=y <target>
An example from rsftour:

bash$ scons -Q TIMER=y windowed.rsf

/usr/bin/time < Txx.HH /path/to/RSF/bin/sfwindow n2=10 n1=200 f1=200 > windowed.rsf

0.00user 0.01system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k

0inputs+0outputs (170major+25minor)pagefaults 0swaps