Skip to content
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

Syngine tags consistency #266

Open
SeismoFelix opened this issue May 29, 2024 · 0 comments
Open

Syngine tags consistency #266

SeismoFelix opened this issue May 29, 2024 · 0 comments

Comments

@SeismoFelix
Copy link
Contributor

When fetching GFs from syngine database for the PREM velocity model, the same model parameter passed to taup_model during the creation of the the object process_sw :

model = 'prem' 
process_sw = ProcessData(filter_type='Bandpass',
freq_min=1/float(freqs_sw[1]),
freq_max=1/float(freqs_sw[0]),
pick_type='taup',
taup_model=model,
window_type='surface_wave',
window_length=wl_sw,
capuaf_file=path_weights,
 )

,
does not work when fetching the syngine-derived Green Functions. Here, Instead of defining model as prem, it has to be specified what kind of prem are we interested:

model = 'prem_i' 
greens = download_greens_tensors(stations, origins, model)

So, in this case the same tag used for process_sw does not apply for download_greens_tensors (unlike 'ak135').

This is because the Taup travel times library in Obspy names the PREM model generically, just 'prem'.

On the other hand, syngine database requires the specific type of prem model to fetch the green functions, either the isotropy (prem_i) or anisotropy one (prem_a).

In the same line, when in MTUQ is used the ak135 model, it is assumed the ak135f_2s. Is there a reason behind such an assumption and not being necessary to specify the model resolution (ak135f_1s, ak135f_2s, or ak135f_2s)?

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant