SEG-Y/FAST Pick Importer

Also note that the autorouter got a little crazy in some places trying to make this work with only 2 layers. There are some places that need cleaning up (e.g. the 3V3 line near the right-hand side).

One noteworthy point I have discovered is this: when developing software for multiple platforms, it is extremely handy to make use of the svn:ignore property. I have modified a makefile to use the -include statement, and an ifndef block to override certain settings if a file is present (and it defines a variable called CUSTOMBUILD).

This seems to be working very well; on systems which are supported by the standard makefile (typically gcc toolchain based on architecture), I just don’t have anything present. On a system where I don’t wish to deviate from the standard makefile, but I wish to use the Intel Compiler Suite, I just fill in the details in custombuild.mk, which is ignored by Subversion.

When one is working in a fluid like air or water, and mapping reflections from solid objects, some of the complexity is removed from the governing wave equation. The acoustic velocity in air is dependent on pressure, density and temperature, all of which vary relatively little in a small open-air volume. However, as I’m discovering, it is quite possible to run into non-linearities in the acoustic parameters near to a transducer.
As a seismologist interested in designing an in-air rangefinder array, I need to throw away some of the assumptions we typically would make in earth materials.

So, in no particular order, some issues to overcome:

• Finding a transducer that is small, cheap, somewhat omnidirectional, and can act as both a transmitter and a receiver.
• Finding the right balance between simplicity and performance in the analog front end.
• Designing with parts that do not require expensive assembly and are not themselves expensive.
• Buffering the data in the digital pipeline.
• Writing fixed point DSP implementations of the required filtering (e.g. Weiner deconvolution).

Ongoing discussion on the XCore forums

Regardless, TI seems to have put together a really interesting platform. I’d be even more excited if it ran via bluetooth, but I understand that the power consumption and cost of the bluetooth transceiver are likely prohibitive. I will say, it’s a tempting product.

etc.

Interestingly, I’d already tried this – it’s just that the particular view of the image I was using had a big anomaly in about the same region as the taper that I hadn’t seen using my default colour scales. I thought there were problems with it: I was wrong.

Very quick and dirty example:

< model1.su suwind key=tracl min=1 max=400 > model1.start.su
< model1.su suwind key=tracl min=401 max=500 > model1.end.su
< model2.su suwind key=tracl min=401 max=500 > model2.start.su
< model2.su suwind key=tracl min=501 max=901 > model2.end.su

< model1.end.su suflip flip=2 | sutxtaper taper=2 tbeg=0 tend=0 tr1=101 tr2=0 | suflip flip=2 | suop op=ssqr > model1.end.taper.su
< model2.start.su sutxtaper taper=2 tbeg=0 tend=0 tr1=101 tr2=0 | suop op=ssqr > model2.start.taper.su

suop2 model2.start.taper.su model2.start.su op=quo > inter1.su
suop2 model1.end.taper.su model1.end.su op=quo > inter2.su
susum inter1.su inter2.su > intermediate.su

cat model1.start.su intermediate.su model2.end.su | suximage


I have velocity models that take the form of SEG-Y traces (i.e. the time delay corresponds to the z-coordinate, and the inline to the x-coordinate). I’d like to take the right-hand side of one model and the left-hand side of the other, and blend them smoothly in the middle (dimensions are the same).

The correct way to do this is with a linear taper if you don’t care about the rate of change, or with sine-squared and cosine-squared tapers if you do. This synchronizes the first derivative at the edges of the taper, as well as the magnitude.

Unfortunately, nobody seems to have written one for Seismic Unix, and I’ve discovered some artifact issues with my Python SEG-Y library. All of this makes for a slightly annoying situation.