search

SeisComP3 / seiscomp3

SeisComP is a seismological software for data acquisition, processing, distribution and interactive analysis.
Other
111 stars 87 forks source link

Theoretical arrivals in scolv are computed using a different modeler localization #96

Open pgouedard opened 7 years ago

pgouedard commented 7 years ago

Theoretical arrivals in scolv/picker seems to be always computed using the same modeler (libtau) and profile (iasp91), whatever the actual plugin used for localization.

This is an issue for visual assessment of picking quality and residuals.

gempa-jabe commented 7 years ago

You are right but what is your suggestion to improve the situation? I can comment more detailed then.

pgouedard commented 7 years ago

Thanks for the quick answer!

I would suggest at least to be able to select the time table used by libtau in the scolv configuration, similarly to what is done for LocSAT. That might be available now, as I found two profiles (iasp91 and ak135), but did not found the corresponding entry...

A more flexible option would be add plugin capabilities for theoretical computation, as it is the case for localization. By using the same plugin for both, one would be able to have a visual feedback on the actual localization quality.

gempa-jabe commented 7 years ago

I would suggest at least to be able to select the time table used by libtau in the scolv configuration, similarly to what is done for LocSAT. That might be available now, as I found two profiles (iasp91 and ak135), but did not found the corresponding entry...

This can be done but it still does not fully solve the problem. If you have a locator with custom tables then neither iaspei91 nor ak135 will help. Furthermore you need to know what tables have been used to locate the origin to select the proper libtau entry. I agree that more flexibility is desirable but to the cost of more confusion/complexity maybe. Anyway, we will add it.

A more flexible option would be add plugin capabilities for theoretical computation, as it is the case for localization. By using the same plugin for both, one would be able to have a visual feedback on the actual localization quality.

Yep, this would be helpful but not all locators expose an interface to their travel time computation functions. LocSAT does and I have implemented it so at least a selection between LocSAT and libtau would be possible. Unfortunately there is no standard library for travel time tables that is also used by available locators. Each locator implementation brings its own table format and setup and is more or less an isolated environment. Beside LocSAT I don't see options for NonLinLoc or Hypo71.

What we could do is to visualize the residuals as returned from the locator. That would only work for associated phases though.

pgouedard commented 7 years ago

I agree that the ability to select the libtau time table does not fully solve the problem. It would however add quite some flexibility as I guess (even if I have not investigated in details) creating custom time tables using any modeler and saving then in libtau-compatible format is possible. The user/administrator would then be in charge of making sure what is used for theoretical computation is meaningful regarding what is used to locate the origin. I don't know the development cost associated to adding the libtau profile selection as a drop-down menu in the scolv interface, similarly to what is done for the locator, but this would have the advantage of explicitly indicating both the theoretical time table and the locator next to each other.

As for using plugins for theoretical time computation, I had in mind defining specific plugins and not re-using the locator ones, as I agree with you that this is not practical for all locators.

I don't know what to make of your last comment... Is it not what is done in the table and the residual-vs-distance plot? It seems to me that the residuals there are not consistent with the theoretical arrival times displayed in the picker window, which is what first brought my attention to the matter.

gempa-jabe commented 7 years ago

As for using plugins for theoretical time computation, I had in mind defining specific plugins and not re-using the locator ones, as I agree with you that this is not practical for all locators.

That has been done already. You can already add new plugins that implement a travel time table interface. The only thing that is missing in this regard is the ability to select in from scolv. Once the drop-down menu is ready, you could write a plugin to use your custom travel times.

I don't know what to make of your last comment... Is it not what is done in the table and the residual-vs-distance plot?

Yes, but I meant for theoretical arrivals in the picker. Instead of plotting a blue P marker from libtau, we could plot the onset - residual as theoretical arrival that is then consistent with the locator being used.

pgouedard commented 7 years ago

Got it! Thanks for the clarification. This would indeed be an elegant way for associated phases.