Hey there, Anthony!
First of all, thank you for developing, maintaining, and continuously improving NonLinLoc — it is an essential tool for us. I also really appreciate how responsive you are on GitHub; your answers are extremely helpful for users like me when checking configurations and understanding how to properly use NLLoc.
I have been using NonLinLoc for some time to locate seismicity in the Canary Islands, with a configuration based on Metropolis for LOCSEARCH and GAU_ANALYTIC for LOCMETH. Until now, I had not explored alternative configurations, as this setup has provided sufficiently reliable results for our purposes (mainly volcano monitoring).
However, after reading the SSST-Coherence manuscript and as recently we have obtained a P-wave 3D velocity model for several islands, I've started reviewing relevantthe Issues in this Github (#17, #52) and your recommendations to see if I can improve our daily solutions. Then, I've found that, if I haven't missinterpreted it, you mainly use and recommend OCTREE instead of Metropolis (#34 and #45) for LOCSEARCH and EDT_OT_WT instead of GAU_ANALYTIC (#29).
Following this, I ran a series of tests using your recommended configuration (similar to the La Palma example in #31, but without SSST-Coherence) with the seismicity in the IGN catalog in Tenerife and sorroundings from 2025-11-01 to 2026-03-05. I don't attach the Metropolis + EDT / EDT_OT_WT reults because it doesn't converge at all.
Our network consists of ~25 seismic stations (mainly broadband), fairly evenly distributed. The median values of the dataset are:
- Min distance from earthquakes to stations 4.6 km
- Number of phases is 16
- Number of stations 10 stations.
Configuration
Velocity model (only for P Wave) .hdr:
440 240 128 -110.0 -60.0 -4.00 0.50 0.50 0.50 SLOW_LEN
Inputs
Common
CONTROL 1 54321
TRANS AZIMUTHAL_EQUIDIST WGS-84 28.20 -16.40 0.0
GTMODE GRID3D ANGLES_YES
LOCSIG Reprocessing Catalog Tenerife
LOCCOM tenerife_new_test
LOCHYPOUT SAVE_NLLOC_ALL NLL_FORMAT_VER_2 SAVE_NLLOC_OCTREE SAVE_FMAMP
LOCGRID 401 201 101 -100.0 -55.0 -3.0 0.5 0.5 0.5 PROB_DENSITY SAVE
LOCGAU 0.05 0.0
LOCGAU2 0.02 0.02 1.0
LOCSTAWT 0 1.0
LOCPHASEID P P p
LOCPHASEID S S s
LOCQUAL2ERR 0.03 0.03 0.03 99999.9 99999.9
LOCANGLES ANGLES_YES 5
LOCPHSTAT 0.35 6 175.0 1.0 1.0 5.0
OCT + EDT_OT_WT
LOCSEARCH OCT 40 20 10 0.0001 50000 1000 0 0
LOCMETH EDT_OT_WT 9999.0 2 -1 -1 1.75 -1 -1 0
OCT + EDT
LOCSEARCH OCT 40 20 10 0.0001 50000 1000 0 0
LOCMETH EDT 9999.0 2 -1 -1 1.75 -1 -1 0
OCT + GAU_ANALYTIC
LOCSEARCH OCT 40 20 10 0.0001 50000 1000 0 0
LOCMETH GAU_ANALYTIC 9999.0 2 -1 -1 1.75 -1 -1 0
MET + GAU_ANALYTIC
LOCSEARCH MET 10000 1000 4000 5000 5 -1 0.01 8.0 1.0e-10
LOCMETH GAU_ANALYTIC 9999.0 2 -1 -1 1.75 -1 -1 0
Results:
RMS distribution (blue cumulative, black gaussian fit)
Values
| Method |
N |
Empirical_Median |
Empirical_Std |
Gauss_Mu |
Gauss_Sigma |
| oct_gau |
519 |
0.269 |
0.159 |
0.3 |
0.159 |
| oct_edt |
519 |
0.265 |
0.142 |
0.288 |
0.142 |
| oct_edt_ot_wt |
519 |
0.265 |
0.142 |
0.288 |
0.142 |
| met_gau |
519 |
0.269 |
0.158 |
0.301 |
0.158 |
Uncertainties
Vertical uncertainty
Values
| Method |
N |
Empirical_Median |
Empirical_Std |
Gauss_Mu |
Gauss_Sigma |
Shapiro-Wilk (p) |
| oct_gau |
224 |
4.395 |
1.247 |
4.473 |
1.245 |
|
| oct_edt |
225 |
5.364 |
2.113 |
5.656 |
2.108 |
|
| oct_edt_ot_wt |
225 |
4.709 |
1.767 |
4.923 |
1.763 |
|
| met_gau |
225 |
4.372 |
1.262 |
4.422 |
1.259 |
|
Horizontal uncertainty
Values
| Method |
N |
Empirical_Median |
Empirical_Std |
Gauss_Mu |
Gauss_Sigma |
| oct_gau |
224 |
4.511 |
2.248 |
4.945 |
2.243 |
| oct_edt |
225 |
6.461 |
6.596 |
8.076 |
6.581 |
| oct_edt_ot_wt |
225 |
5.308 |
5.466 |
6.371 |
5.453 |
| met_gau |
225 |
4.525 |
2.206 |
4.889 |
2.201 |
The main difference that I've found is when zooming in the most active area in Tenerife (, we see grided locations with the octree solutions (as expected #85 #31), but as long as is mucho lower than the uncertainties, it's ok (?)
Zoom in Tenerife
Epicentral
Depth vs Longitude
Questions
So, my questions are:
-
In general, why do you not recommend Metropolis? For relatively small study areas (e.g., islands smaller than ~40 × 40 km) and similar seismic network distribution, which configuration would you recommend?
-
Given that we have a 3D P-wave velocity model with ~0.5 km resolution and a constant Vp/Vs ratio, would you expect SSST to significantly improve our locations? Or is it mainly beneficial when the 3D velocity model is not sufficiently accurate or is unavailable?
-
Is there anything important I might be overlooking or misinterpreting in this workflow that could be affecting the location results?
Thanks again for your time — I really appreciate your help with this.
Best regards,
Edu
Hey there, Anthony!
First of all, thank you for developing, maintaining, and continuously improving NonLinLoc — it is an essential tool for us. I also really appreciate how responsive you are on GitHub; your answers are extremely helpful for users like me when checking configurations and understanding how to properly use NLLoc.
I have been using NonLinLoc for some time to locate seismicity in the Canary Islands, with a configuration based on Metropolis for LOCSEARCH and GAU_ANALYTIC for LOCMETH. Until now, I had not explored alternative configurations, as this setup has provided sufficiently reliable results for our purposes (mainly volcano monitoring).
However, after reading the SSST-Coherence manuscript and as recently we have obtained a P-wave 3D velocity model for several islands, I've started reviewing relevantthe Issues in this Github (#17, #52) and your recommendations to see if I can improve our daily solutions. Then, I've found that, if I haven't missinterpreted it, you mainly use and recommend OCTREE instead of Metropolis (#34 and #45) for LOCSEARCH and EDT_OT_WT instead of GAU_ANALYTIC (#29).
Following this, I ran a series of tests using your recommended configuration (similar to the La Palma example in #31, but without SSST-Coherence) with the seismicity in the IGN catalog in Tenerife and sorroundings from 2025-11-01 to 2026-03-05. I don't attach the Metropolis + EDT / EDT_OT_WT reults because it doesn't converge at all.
Our network consists of ~25 seismic stations (mainly broadband), fairly evenly distributed. The median values of the dataset are:
Configuration
Velocity model (only for P Wave) .hdr:
Inputs
Common
OCT + EDT_OT_WT
OCT + EDT
OCT + GAU_ANALYTIC
MET + GAU_ANALYTIC
Results:
RMS distribution (blue cumulative, black gaussian fit)
Values
Uncertainties
Vertical uncertainty
Values
Horizontal uncertainty
Values
The main difference that I've found is when zooming in the most active area in Tenerife (, we see grided locations with the octree solutions (as expected #85 #31), but as long as is mucho lower than the uncertainties, it's ok (?)
Zoom in Tenerife
Epicentral
Depth vs Longitude
Questions
So, my questions are:
In general, why do you not recommend Metropolis? For relatively small study areas (e.g., islands smaller than ~40 × 40 km) and similar seismic network distribution, which configuration would you recommend?
Given that we have a 3D P-wave velocity model with ~0.5 km resolution and a constant Vp/Vs ratio, would you expect SSST to significantly improve our locations? Or is it mainly beneficial when the 3D velocity model is not sufficiently accurate or is unavailable?
Is there anything important I might be overlooking or misinterpreting in this workflow that could be affecting the location results?
Thanks again for your time — I really appreciate your help with this.
Best regards,
Edu