Make TauP (Arrival) API more modular (and efficient?)

Development
1

This is a follow up on my previous post, but it’s now in the proper category and a broader question.

I find the TauP API a little awkward in that we can’t mutate Arrival objects very easily. Consider the documented ways to access TauP calculation results. There are different methods for travel times, ray paths, pierce points, etc. and they all return their own Arrivals interface. But IMHO it is not uncommon to start with just travel times and later realise that ray paths/pierce points/etc. are also needed. Instead of:

from obspy.taup import TauPyModel
model = TauPyModel()
arrivals = model.get_travel_times(source_depth_in_km=55, distance_in_degree=67)
# Some other stuff
# Aw crap I need ray paths...
arrivals = model.get_ray_paths(source_depth_in_km=55, distance_in_degree=67)

I propose to move these members (or their wrappers) to Arrivals, incrementally adding missing information as it is requested:

from obspy.taup import TauPyModel()
model = TauPyModel()
arrivals = model.get_arrivals(...)
# Get ray paths
paths = arrivals.get_ray_paths(...)  # Returns cached paths or calculates new ones.
# Get travel times
times = arrivals.get_travel_times(...)  # Returns cached times or calculates new ones.
# Etc.

This way the method names are also more intuitive (IMHO, compare get_ray_paths(...) -> paths with get_ray_paths(...) -> arrivals).

Notice that I wrote “cached”, this is something I have been patching in for my project built on Obspy: new arrival information is only calculated when different parameters are requested (“memoization”). After thinking about it, I don’t see why this couldn’t be implemented in ObsPy itself, subject to backwards compatibility issues. It could be achieved relatively easily with the above proposed API, by using either cached_property (python>=3.8) or regular old properties with setters. I have been doing it the second way.

Thanks for all your hard work on ObsPy. This got rather long, let me know if I should open an issue instead.

2

If I recall correctly the taup module was auto converted from the Java code base and then remaining kinks and adaptions needed were fixed manually. It is hard to say for me what will happen in the future. I don’t think we have somebody currently willing to dedicate time to maintenance of our taup module, but in general questions to ask ourselves would be…

  • how to bring in eventual updates from Java TauP upstream?
  • would the former be complicated by making more custom changes in obspy taup port (as you suggest)?

But anyway, like I said, I don’t see that we have any person right now willing to dedicate time to obspy taup, so this is all rhetorical questions.

3

Thanks for the response. That makes sense, I can understand the difficulty with the taup module now. I will not rush any PR’s in that case. If I get time to have a look at the original taup I might start by working on a few things in my own projects and if I am satisfied that it could work with upstream changes without too much problem I would be happy to contribute, but as you say this becomes a more delicate situation.

I’ll mark as solved for now. Thanks