## New user SLIM

March 19, 2006 Programs No comments

The Seismic Laboratory for Imaging and Modeling (SLIM) from the department of Earth and Ocean Sciences (EOS) at the University of British Columbia (UBC) is happy to announce the creation of its user folder in RSF. Current contributions are:
sfthr Threshold float/complex inputs given a constant/varying threshold level.
Methods available:
– soft
– hard
– non-negative Garrote (nng)

sfsort Sort in ascending/descending order absolute value entries of a float/complex vector.
More functions that come out of our industry-supported research will be released in the near future.

## RSF hypercubes acquire physical dimensions

March 17, 2006 Programs No comments

At the suggestion of Gilles Hennenfent, certain RSF programs now recognize unit1=, unit2=, etc keywords in addition to label1=, label2=, etc. This allows for more control on physical dimensionality.
Here is an example of having some fun with physical units:

1. Create some data.
bash$sfspike n1=100 n2=100 > spike.rsf bash$ sfin spike.rsf
spike.rsf:
in="/var/scratch/spike.rsf@"
esize=4 type=float form=native
n1=100         d1=0.004       o1=0          label1="Time" unit1="s"
n2=100         d2=0.1         o2=0          label2="Distance" unit2="km"
10000 elements 40000 bytes

2. Convert kilometers to feet:
bash$sfunits unit2=ft spike.rsf >> spike.rsf Converting "km" to "ft" on axis 2 bash$ sfin spike.rsf
spike.rsf:
in="/var/scratch/spike.rsf@"
esize=4 type=float form=native
n1=100         d1=0.004       o1=0          label1="Time" unit1="s"
n2=100         d2=328.084     o2=0          label2="Distance" unit2="ft"
10000 elements 40000 bytes


sfunits is a new script for unit conversion. It relies on the Unix units utility.

3. Apply 2-D FFT transform.
bash$< spike.rsf sffft1 | sffft3 axis=2 > fft.rsf sffft3: padded to 200 bash$ sfin fft.rsf
fft.rsf:
in="/var/scratch/fft.rsf@"
esize=8 type=complex form=native
n1=55          d1=2.31481     o1=0          label1="Frequency" unit1="1/s"
n2=200         d2=1.524e-05   o2=-0.001524  label2="Wavenumber" unit2="1/ft"
11000 elements 88000 bytes

4. Transform back.
bash$< fft.rsf sffft3 axis=2 inv=y | sffft1 inv=y > back.rsf bash$ sfin back.rsf
back.rsf:
in="/var/scratch/back.rsf@"
esize=4 type=float form=native
n1=100         d1=0.00400001  o1=0          label1="Time" unit1="s"
n2=100         d2=328.084     o2=0          label2="Distance" unit2="ft"
10000 elements 40000 bytes


Warning: this is a substantial change that affects many programs and examples. Please report any problems.

## Offset continuation practice

March 17, 2006 Documentation No comments

## How can I use information from sfattr or sfget in SConstruct Flows?

March 2, 2006 FAQ No comments

This may not be the most elegant solution but you can try using parameter files. Here is an example:

1. Create some data.
Flow('data',None,'spike n1=100 | bandpass fhi=40')
2. Generate a parameter file from it.
Flow('mag.par','data',"attr want=max | sed 's/value = /mag=/' ")
3. Use the parameter file in processing.
Flow('test','mag.par','spike n1=100 par=\$SOURCE',stdin=0)

## Nick Vlad on RSF and XML

March 2, 2006 Systems No comments

### Thoughts from Nick Vlad on RSF and XML

Provocative idea for the long term that you may post if it seems interesting: Making the history files XML
documents. Their “written by machine, sometimes read by a human” paradigm is exactely that of XML. This
will not impede reading with existing programs, but will instead open intriguing possibilities. The
machine would be able to construct a diagram of the processing history. One does not need to write C++
code to do graphical interfaces. Just transform XML into XHTML 1.0 Strict through a XSLT filter – or
through a basic python script (i.e. <sfwindow> into <div class=”sfwindow”> ). Format with CSS. The history of the file becomes all of a sudden a nice suite of boxes on a webpage. One can do Fahrner Image Replacements in the CSS stylesheet to use specific icons for various (classes of) programs. We’ve just got ourselves a neat little “Processing History Explorer”!
But this is not all. Assume that each RSF program, when appropriately queried, would return a range of valid values for its parameters and a list of the file tags it needs, with intent (in, out, inout). Then it would be possible to automatically transform the XML information about a program into SVG drawings (again, with a XSLT stylesheet), with arrows connecting the processes/files. It is possible to do hyperlinks from SVG elements, so the user can open a window with a XHTML form with menus, radio buttons, etc, with the settings of the program. Now, all of a sudden, we have more than a “Processing History Explorer”. Change the parameters, press submit, modify the flow, run it, the XML description of the processing flow gets transformed into a Scons file, and runs on the remote machine!
The great advantages of doing graphical interfaces this way would be that: (A) they would be entirely platform-independent; (B) They would run as well on remote user machines as on the local host; (C) The number of people who can do web development is much greater than that of the people who know how to do GUI development, so it will be easier to get people to contribute.

## Offset continuation theory

March 1, 2006 Documentation No comments

Another old paper has been added to the collection: