velocity (model)

[FMassin]

Hello,

In the config file, there is :

# TIME WINDOW PARAMETERS --------
# P and S wave velocity (in km/s) for travel time calculation
# (if None, the global velocity model 'iasp91' is used)
vp_tt = None
vs_tt = None
# As an alternative, a directory containing NonLinLoc travel time grids
# can be specified and values defined above will be ignored.
# Note that reading NonLinLoc grids takes time. For simple 1D models, you
# can speed up considerably the process using a generic station
# named "DEFAULT". The coordinates of this default station are not important,
# since they will be superseded by each station's coordinates.
NLL_time_dir = None

which is great for windowing, but is it (modelled arrival time) used anyway even if picks are available?

Also, about:

# SPECTRAL MODEL PARAMETERS --------
# P and S wave velocity close to the source (km/s)
vp_source = 5.5
vs_source = 3.2
# P and S wave velocity close to the stations (km/s)
# If set to None, velocity values close to the source will be used
vp_stations = None
vs_stations = None
# As an alternative, a directory containing a NonLinLoc model can be specified
# In this case, the values provided above will be ignored
NLL_model_dir = None

Again using NLL model seems great but that means Vp and s are not taken from IASP91 by default as for windowing? Would that be more appropriate if a 3d NLL model is not available?

Thanks for your help...

Fred

[claudiodsf]

Hi Fred,
concerning the first question, I made it clearer in 62e2d6b:

Theoretical P or S arrival times are used when a manual P or S pick is not
available, or when the manual P or S pick is too different from the
theoretical arrival (see 'p_arrival_tolerance' and 's_arrival_tolerance'
below).

Concerning the second question, it is not currently possible to use the IASP91 model for Vp and Vs close to the stations and to the source, but it's something that can be added in the function get_vel() in ssp_util.py. Do you want to make a PR? 😉

[FMassin]

Hi Claudio

Thanks for your sound answer.

My 2nd question is whether it would make sense to cast velocity values from a 1d model. Of course, the option to do it based on an NLL 3d model looks more attractive... by the way would it work with an NLL 1d model?

I would need to test the feature before extending it (Edit: For the records, it might be done with obspy.taup.velocity_model.VelocityModel.evaluate_above). I'm far from having tested all features and there are a lot of them (which is great!). And PR might not be appropriate for minor contrib anyway...

Cheers

Fred

[claudiodsf]

I think it would make sense to get velocities from a 1D model, such as IASP91.

And, yes, you can provide a NLL grid containing a 1D model, but the grid must be 3D.

But, looking at the code, I have the feeling that this line is wrong, since the method grd.get_vel() needs cartesian coordinates in a projection... I'll look into it.

[claudiodsf]

And... a PR is always welcome!!!

[claudiodsf]

Reading velocities from NLL models is fixed in bd602e4

[claudiodsf]

Reading velocities from iasp91 is now possible via 075290f