Gridded relocations in all 3 dimensions

[LuDesmeuzes]

Hello Anthony,

First, I’d like to thank you for all the details and explanation already available on your github and website. For the past few months, I have been learning to use NonLinLoc and am now able to use the programs but there are still some grey areas I would like to ask you about if that is okay with you.

Second, I wanted to say that I know you have already addressed this issue several times (gridded locations), and that I am sorry to bother you again with it. I have tried to apply all the tips you gave in the other topics (especially number 17 and 52) and on your website, but have not still been able to fix it.

My config:

Both my layer.P.mod.hdr and layer.S.mod.hdr files are:
98 98 100 0.0 0.0 0.0 1.0 1.0 1.0 SLOW_LEN

And as for layer.P.mod.buf and layer.S.mod.buf I am using a 3D velocity model that I have configured and put into a binary file following the detailed information available on your website. (I hope I did not mess this part up) I could send you more info about that model if necessary, such as my code to transform it from a lat/lon/depth velocity model to an interpolated x,y,z regular step velocity model.

With these files and Grid2Time I was able to generate the grid files for every station in my station files that I filled up using the GTSRCE format.
GTSRCE CBB LATLON 44.597 6.855 0 0
GTSRCE CREF LATLON 44.549681 6.621956 0 0
GTSRCE ENAUX LATLON 44.1095 6.7775 0 0

I also set on purpose the elevation to 0 because I do not have a velocity model for above the altitude 0.
Is that the way to go? Or should I configure it differently, like keep the actual elevation (maybe in negative value because it is above 0?) ?

My study area is about 20*25 km squared centred about around lat = 44.51 and lon = 6.75.
Lat min is 44.40, max is 44.62 and lon min and max are respectively 6.59 and 6.91 degrees.

CONTROL 9 159753
TRANS SIMPLE 44.06 6.14 0
LOCSEARCH OCT 10 10 10 0.001 150000 1000 1 0
LOCGRID 98 98 100 0 0 0 1 1 1 PROB_DENSITY SAVE
LOCMETH EDT_OT_WT 9999.0 4 -1 -1 1.7 6 -1.0 1
LOCGAU 0.2 0.0
LOCGAU2 0.02 0.05 2.0
LOCPHASEID P P p Pn Pg
LOCPHASEID S S s Sn Sg
LOCQUAL2ERR 0.1 0.5 1.0 2.0 99999.9
LOCANGLES ANGLES_YES 5
LOCPHSTAT 9999.0 -1 9999.0 1.0 1.0 9999.9 -9999.9 9999.9

For the TRANS SIMPLE, I put the bottom left corner of the area I made the grid files for.
LOCSEARCH I configured to be proportional to LOCGRID (following what you suggested in topic 52).
To be honest I still do have issues understanding how to set LOCGRID. I have made a few other tries with a LOCGRID that is closer in size to the study area, but I tend to get more errors such as:
--> WARNING: WARNING: max prob location on grid boundary 11, rejecting location.
So that’s why I set it to the size of my travel time grid size (in the .hdr files)
I am also not so sure how to position the initial search grid properly.
Should I consider that xOrig yOrig and zOrig refer to the centre or the bottom left corner of the initial search grid?

For the remaining arguments, I’m just guessing and taking examples from other study cases I could find on your website/github, so I would also love if you could insight me on this.

Please find bellow a zoomed picture of my relocations. I am 100% available to give more information if that could help you help me :)

Thank you very much in advance,
Best regards,

Ludovic Desmeuzes

[alomax]

Hello Ludovic,

Thanks for your questions, no problem for me to comment.

I have configured and put into a binary file following the detailed information available on your website. (I hope I did not mess this part up)

To check the model is reasonable, you could use Vel2Grid LAYER statements to construct a 1D model with approximately the layer mean velocities from your 3D model, and run Grid2Time with 2D travel-times grids (as in the NLL sample), and/or in 3D using your 3D VGGRID with 3D travel-times. Then, if the locations look similar to your plot above (and also depths), the 3D model may be correctly converted to NLL binary grid format.

I also set on purpose the elevation to 0 because I do not have a velocity model for above the altitude 0.
Is that the way to go? Or should I configure it differently, like keep the actual elevation (maybe in negative value because it is above 0?) ?

As there is likely strong topography, it would be best to have the stations at their correct elevation. Perhaps you can extend the shallowest model velocities upwards, far enough to include all station elevations.

Some comments on your control statements:

TRANS SIMPLE 44.06 6.14 0

This is OK for small scale studies, but is the least accurate of NLL transforms. I would recommend AZIMUTHAL_EQUIDIST for a study where the target seismicity is centered within the stations network. Alternatively, LAMBERT or TRANS_MERC.
Given your lat/lon center at lat = 44.51 and lon = 6.75, I would put the TRANS and LOCGRID center at the same point, so something like:
TRANS AZIMUTHAL_EQUIDIST WGS-84 44.51 6.75 0
LOCGRID 98 98 100 -44.0 -44.0 0 1 1 1 PROB_DENSITY SAVE
where -44.0 -44.0 have to be adjusted to position the SW corner of your 3D model correctly with respect to 44.51 6.75

LOCSEARCH OCT 10 10 10 0.001 150000 1000 1 0

150000 samples is alot, I usually use 50000
10 10 10 could be greater, perhaps 25 25 25

LOCMETH EDT_OT_WT 9999.0 4 -1 -1 1.7 6 -1.0 1
Perhaps:
LOCMETH EDT_OT_WT 9999.0 4 -1 -1 1.7 -1 -1.0 1
so all 3D travel-time grids are loaded into memory (if you have enough memory)

(int) maximum_number_3D_grids to attempt to read into memory (-1 for no max)

I still do have issues understanding how to set LOCGRID ... So that’s why I set it to the size of my travel time grid size (in the .hdr files)
I am also not so sure how to position the initial search grid properly.

See my suggestion about for LOCGRID. With a 3D model and travel-times, it is best that the LOCGRID is identical to the 3D model grid. This requires the same size and xOrig yOrig and zOrig for both grids. And they must both use the same (or very similar) geographic projection.

Should I consider that xOrig yOrig and zOrig refer to the centre or the bottom left corner of the initial search grid?
They specify the offset in km to the bottom left corner from the TRANS lat/lon position.

gridded locations
I see the gridded locations in your plot, and the large and diffuse spread in epicenters. There could be many causes. If the model and travel-times are fine, I would wonder about your pick uncertainties - are they compatible with your small-scale study, e.g. ~0.02 s for P and perhaps twice as much for S? I think your travel-time uncertainties are reasonable (LOCGAU2 0.02 0.05 2.0). Otherwise, I would need more information...

I hope this helps, some, ...

Best regards,
Anthony

[LuDesmeuzes]

Hello Anthony,

Thank you very much for your reply. I have started applying the changes you recommend. To be sure I make no extra mistakes, here are a few other questions I have:

Is 20*25 km a small-scale study or do you already consider this to be too large for a TRANS SIMPLE transform?

Whatever the answer for this, I am going switch my transform to the AZIMUTHAL_EQUIDIST. On your website in the Control File -> Generic -> TRANS section, I could not find the formula NLL is using to perform the AZIMUTHAL_EQUIDIST transform.

Do you confirm that it is the following?
x = R*(pi/2 – lat)sin(lon)
y = - R(pi/2 – lat)*cos(lon)

I need to know this because I am using the 3D velocity model that was handed to me by Jean Virieux which is a 0.04 deg by 0.04 deg lat/lon grid layered by a 1km thick grid along the depthness (lon from 4.5 to 10.5 deg, and lat from 42.5 to 47.5, but I am only using a fraction of this as calculating travel time grid for this whole area takes way too much time, and the depth from 0 to 100 km).
As this is not adequate to what NLL needs to generate the travel time grid files using Grid2Time, I am first projecting these values using a transform (used to be SIMPLE with the formula on your website) and these interpolating the projection so the velocity model is now projected onto x, y, z with a regular step of 1 km in all three directions. I expect to do the same but this time projecting with the AZIMUTHAL_EQUIDIST formulae. (I know I could be using TRANS GLOBAL, but I saw that you have not used it on you FAQ so I figured I would stick to something that has already been proven to work properly)

Regarding the TRANS and LOCGRID suggestion you made, correct me if I am wrong:
For the TRANS AZIMUTHAL_EQUIDIST WGS-84 44.51 6.75 0, the coordinates of the western and southern part of the grid will be accessible through negative coordinate values, explaining why you suggested for LOCGRID -44 (to be adjusted) and -44 (to be adjusted) for xOrig and yOrig. The xOrig and yOrig, will place the SW corner of the LOCGRID so it matches the coordinates of the SW corner of the 3D velocity model (or travel time grid files), which I think happen to be the minimum value for both x and y axes of the velocity model?

This leads me to think about this next question: why is it better to have the x = 0 and y = 0 coordinates in the centre of the grid than in the SW corner? Is it because the transform will be better and more proportional for the values around the latOrig and lonOrig and diverg the further away you go from the origin? And because 80/90% of the earthquake I’d like to relocated are around the centre, it is sound to centre the origin?

About this pick uncertainties, I’ve mainly been relocating using NLL throught SeisComp, and I think that most of the picks are picked without uncertainties. I’ll check on how does SeisComp proceed when there is no pick uncertainties.

Adjusting to your tips is going to take me a few days, but I will keep you informed regarding the results I get with this new settings.

Thank you very much for you help and answer,
I hope to exchange more with you soon.

Ludovic

[alomax]

Hello Ludovic,

Is 20*25 km a small-scale study or do you already consider this to be too large for a TRANS SIMPLE transform?

This is indeed fairly small.

Do you confirm that it is the following?
x = R*(pi/2 – lat)sin(lon)
y = - R(pi/2 – lat)*cos(lon)

No, the projection is a more complicated algorithm from the GMT source code. See the functions after this point in the NLL source code:

NonLinLoc/src/map_project.c

Line 587 in 1508f19

/* Azimuthal Equidistant Projection (AE) */

.

I know I could be using TRANS GLOBAL

TRANS GLOBAL is spherical coordinates, usually this is not a good choice for local and regional studies. Also many 1D models and 3D models are from inversions in flat earth, not spherical coordinates, and it is best to remain with the same projection as used for the model development.

Regarding the TRANS and LOCGRID suggestion you made, correct me if I am wrong: ...

I think you have all that correct.

This leads me to think about this next question: why is it better to have the x = 0 and y = 0 coordinates in the centre of the grid than in the SW corner? Is it because the transform will be better and more proportional for the values around the latOrig and lonOrig and diverg the further away you go from the origin?

Yes, this is a main reason.

And because 80/90% of the earthquake I’d like to relocated are around the centre, it is sound to centre the origin?

Yes, and this is particularly important when using AZIMUTHAL_EQUIDIST.

Though, the differences in locations should be small, and probably smaller than large scale shifts in the locations due to velocity model error - best to interpret seismicity as relative locations on different scales up to the size of the study area.

About this pick uncertainties...

If there are no pick uncertainties, then I usually set P and S (~2 * P unc) uncertainties to values like 0.02 sec and 0.05 sec for high quality waveforms and picks, and higher values if there are indications of noise or generally large residuals (e.g. much larger than assigned pick uncertainties). If your picks are in NLL hypo-phase format, you can directly enter the pick uncertainty in sec for each pick. Otherwise, you can use LOCQUAL2ERR to map quality to uncertainty in sec, if the picks have 0, 1, ... pick quality assignments.

Best regards,
Anthony