-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation update #92
base: development
Are you sure you want to change the base?
Documentation update #92
Conversation
First stages of generatign tutorials. Added the Archive one from a branh Conor hasd made and a new detect one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the comments:
There is already a PR submitted for the Archive tutorial. Delete the file from this PR.
There's a .swp file included - please remove this.
In order for this to be parsed into the documentation, you will need to add an entry to the tutorials.rst file (see existing example).
Other than that, this is a great addition! If you could ensure the read/display code works as expected for the Onset inspection, that would be great.
docs/tutorials/detect.rst
Outdated
|
||
You will need a semi-continuous waveform archive organised in a known way (see `Archive` tutorial), a travel time LUT (as generated in the previous tutorial) and a station file (as used to generate the LUT). You will also need to choose a location to store your results and a name for your run. QuakeMigrate will automatically generate an output structure to store all your results and place this in a folder in your chosen location named as the run name. You may well run QuakeMigrate many times before you reach the final set of parameter values which produce the best results. It is therefore important to choose a clear and documented run-naming-scheme. | ||
|
||
.. note:: Your run name and directory does not have to be the same for the three QuakeMigrate stages (`detect`, `trigger` and `locate`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not true - each stage will look for info from the previous stage with a consistent naming scheme. It is possible to run trigger with different subnames (and subsequently locate).
Decimation of the LUT | ||
=========================== | ||
|
||
To reduce computation time the decimation functionality of the LUT can be used. This reduces the number of nodes at which the coalescence is calculated resulting in a spatially low-pass filtered coalescence function. This is reasonable when we use the data for earthquake detection, but should be carefully considered if the locations output from a decimated grid are to be relied upon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would perhaps like to add some discussion here about the issues of over decimation - can lead to mis-migration of onset functions. Decimation (and choice of node spacing more generally) should be chosen carefully against the expected sharpness of the onset functions (related to data quality/dominant period of signals). We have a simple idea of how to mitigate the impact this has, using a boxcar filter, but this is yet to be implemented.
docs/tutorials/detect.rst
Outdated
QuakeMigrate transforms your waveform data using two preprocessing operations before migration and stacking. These are a bandpass filter and transformation into an onset function. | ||
|
||
|
||
The onset function should (if correctly specified) peak at the arrival time of a seismic phase. This function acts to simplify the seismic wavefield recorded by your instruments so the migration and stacking process work more reliably with noisy data or inaccurate velocity models. The correct choice of bandpass filters maximises the signal-to-noise ratio of your desired arrivals thereby maximising the coalescence value of any migrated earthquake. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, critically, extracts probabilistic 'information', which is one of the cornerstones of the method. When the Onset tutorial is written, can just refer the user there.
docs/tutorials/detect.rst
Outdated
from quakemigrate.signal.onset import STALTAOnset | ||
onset = STALTAOnset(position="classic") | ||
|
||
The STALTA function is the ratio between the average value in a short window to the average value in a longer window. In theory, if your window lengths are well-chosen, this function should peak at the arrival time of a seismic phase. The `STALTAOnset` function that ships with QuakeMigrate takes a single keyword argument which specifies the window position relative to the reference point (see image below). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to include here the exact words behind the initialism
docs/tutorials/detect.rst
Outdated
|
||
.. image:: img/waveform.png | ||
|
||
Using the `classic` argument will reproduce the `classic_sta_lta` from obspy (https://docs.obspy.org/packages/autogen/obspy.signal.trigger.classic_sta_lta.html) where both windows are behind the current timestamp. This is the more usual formulation as it is causal (i.e. doesn't rely on future data to generate the value at a particular time). In contrast, the `centred` argument will place the short window ahead of the current timestamp. This will maximise the signal-to-noise ratio. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It currently uses the ObsPy function - I've rewritten both of the functions into C, pending a PR to merge them in.
More to it than just maximising the snr - the windows are also then more statistically independent, at the cost of being less stable. In fact, good to mention here that the classic positioning is more stable in the presence of non-seismic noise - signal offsets due to recording issues etc.
docs/tutorials/detect.rst
Outdated
|
||
st[0].plot() | ||
|
||
By storing the data as miniSEED files, we not only make it easy to plot and manipulate the data using python libraries through obspy. We also can use miniSEEDs impressive compression routines to effciently store large volumes of data. To access this, we store values in the scanmseed object as integers. To return the values stored in the `scanmseed` object to the real values, divide the coalesence traces by 5 and the X, and Y traces by 6. The depth (Z trace) is stored to the nearest millimetre, the exact number to divide the output by will depend on your units. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On your choice of units for the lookup table.
OK - had thought it would be more helpful to have them in one PR. I'll do that hmm - thought I had not added that - will do OK |
Deleting swp file.
…d1101/QuakeMigrate into documentation_update
Development
Development
A new example which includes grabbing data from IRIS and magnitudes Small changes to the creation of plots. Reduces the physical size of each generated figure to make printing and viewing easier
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Co-authored-by: Conor Bacon <conor.bacon@gmail.com>
Some of this PR has been extracted and re-submitted as part of #119. The Ethiopia example remains - it is probably worth extracting this and submitting a standalone PR, but with the Iceland dyke intrusion example, which covers most aspects of the package (namely magnitudes), this is not critical. |
An update to the tutorial section of the documentation. Included is a new "detect" tutorial.