|This page is obsolete.|
A public API for generating synthetic gathers, in early development. An Agile Geoscience project for 2012.
The tool is a bit like Google Chart Images but for synthetic seismic data. The idea is to save geophysicists time making simple synthetic models, building mobile apps, generating figures, etc.
- The user passes some data and parameters via a URL (see right)
- The two requirements are physical rock properties (velocity of P-waves and S-waves, and rock density), and some key parameters
- It computes some functions (mainly interface reflectivity as a function of angle)
- It convolves the result with another function (a seismic wavelet)
- It returns a seismic plot image and some XML data
These data are mandatory, but could assume Vp = 2 x Vs if Vs is not provided
- Upper layer Vp (in m/s), Vs (m/s), and rho (kg/m3)
- Lower layer Vp, Vs, rho
Everything is passed via a URL. Perhaps it looks something like this:
http://synthetic.agilegeoscience.com/gather? vpu=3240&vsu=1620&dnu=2340&vpl=2590&vsl=1060&dnl=2210& wav=Ricker&f1=25& eqn=Zoeppritz&rng=0,90& trc=40&tim=240&plt=wiggle
The AVO* app assumes that numbers under 10 are in km/s and g/cm3. This is a safe assumption.
It would be nice to support ft/s for velocity (even in Imperial systems, density is given in g/cm3).
Here's an example of some input data and the resulting reflectivity plots (note — the goal of this application is to make seismic plots instead, and/or as well):
In addition to the rock property data, we need some parameters. Italics indicates the default value.
- Wavelet type: Ricker, Ormsby, perhaps Klauder, Butterworth?
- Wavelet frequencies: 0–200 Hz, 25 Hz default for Ricker
- Equation to use: Zoeppritz, Aki-Richards, Shuey 3-term, Shuey approximation (2-term)
- Angle range to compute: 0–90 degrees
- Number of traces in the plot: 1 to 100, 20 default
- Amount of time in the plot: 1 to 500 ms, 200 ms default
- Type of plot: wiggle trace (vector) or variable density (raster)
Nice to have, can default at first
- Scaling factor: none or some scalar
- Display position of critical angle or not: yes or no
- Scaling beyond critical angle: none or clip (or scale?)
- Wavelet stretch with offset: none by default
- Sample interval in time: 1 ms, 2 ms, or 4 ms
- How much random noise to add to the result: 0% by default
- Type of colour map for variable density: black/white, blue/white/red
- Whether or not to fill the positive values for a wiggle trace: fill by default
- Plot dimensions in pixels: 400 x 400 by default
- A title for the plot image: free text, no title by default
- Whether to label the plot axes or not: yes or no, don't label
- Whether or not to return computed data (as XML?) as well: yes or no, don't label
- Image type: PNG, SVG
- Other plots, like the charts I put in the AVO* app (easy)
- Other model types, like a wedge model (easy)
- More rock interfaces (harder)
- Elastic wave equation finiste difference modelling, instead of convolution-based (hard, see below)
- Fluid substitution using Gassmann's equation (hard)
Google Chart Image example
The following URL generates a simple AVO plot:
The result is shown on the right.
The main bit is chfd=... which describes the functions y(x) where y is magnitude and x is angle (I am plotting Aki-Richards and 2-term Shuey here, plus a fluid subbed A-R). The coefficients are computed in the app and passed to a procedure that builds this URL.
These are not things to worry about for v0.1 or even 1.0, but might affect how the app is architected.
- Layer the application on top of Madagascar and offer more advanced modelling and processing capability.
- For example, it can do signal processing, data manipulation, scaling, display, etc.
- Perhaps this is the way to architect everything from the start.
- Layer the application on top of Madagascar and offer more advanced modelling capability, such as elastic wave equation finite difference models (elastic modeling), perhaps even with anisotropy. This would require a lot more input, however, such as acquisition and migration parameters. But it would allow us to deal with multiples, NMO, wavelet stretch, etc.
- We'd want to avoid having to push a lot of data around, though it might be nice for people to be able to upload data which they then work on via the API.
- Option to provide a reflectivity function instead of rock properties. Only the convolution and plotting steps need to be performed in this case. The function would give R in terms of θ. This is exactly what we provide Google Chart Images today — but it only plots a chart, not a seismic section.
- Option to provide a reflectivity series, for a zero-offset 1D synthetic model. Not sure how useful this would be, but you never know.
- Option to get a wedge model. This would require passing another set of rock properties: VP, VS, ρ for the wedge (although at first you could just use the lower properties as the wedge properties). You would also need to give the maximum thickness of the wedge in ms, and assume it starts at 0 ms. I suppose you could assume the wedge becomes half the total time of the section (already given as a parameter). Then x on the plot becomes wedge thickness and you don't model offset at all. Unless you do the next thing...
- Option to simultaneously vary another parameter, such as wavelet frequency. For a wedge model, you could also model offset on the other axis. This would add another dimension to the seismic model (e.g. making a 1D model into a line, such as a frequency gather, and a 2D model into a cube, varying offset and frequency). The idea would then be to slice the model to plot a horizon (for a 2D model) or a surface (for a 3D).
- Option to provide actual logs. This might be too hard: you need to get DT, RHOB and ideally DTS as well. Then you need to compute a time transformation because of course the logs are in depth. If we wanted to model a 100 m section of log, we would be asking for at least 700 samples per log: this is way too much. You would need to get blocked logs to simplify the problem — perhaps this is a whole other tool. Perhaps it's a silly thing to do online :)
- Matt Hall and Evan Bianco at Agile
- Enthought engineers