Seeking for advice about min_node_size for irregular staiton distribution

[zhong-yy]

In my study region, stations are highly concentrated in a small area. For this area with high station density, we require higher association accuracy, i.e. more events and less false detections. In the larger region outside this area, we can tolerate lower association accuracy.

According to the document, in small areas, high min_node_size values may lead to missed events

Rarely: Decrease min_node_size or min_node_size_location. If these values are too high, PyOcto might fail to locate events or associate picks to them. This will usually only be relevant if your study area is very small or you increased the values substantially above the default values.

However, if I use a too small min_node_size for the whole region, it would take a long time to run pyocto.

Should I first run pyocto with a large min_node_size and min_node_size_location for the whole region, and then run it again using the remaining picks for only the small region? Can I do this by using the second_pass_overwrites parameter? The second_pass_overwrites seems not fully documented, so I am not sure how to use it and what parameters I can overwrite? In addition, if the region in OctoAssociator is smaller than the range of station coverage, will the stations outside the region be used?

Regarding to the running time, the document does not suggest using a higher number of n_threads than available cores. However, pyocto often uses all the cores at the beginning, but soon use only one thread for a very long time until the program ends. In this case, maybe setting a n_threads to be much higher than the physical core numbers would mitigate this problem if there is enough memory? I suspect that it may be queue_memory_protection_dfs_size that makes a few threads run longer. Can I increase queue_memory_protection_dfs_size to reduce runtimes without introducing side effects to the result?

I would appreciate it if you could provide some suggestions

[yetinam]

Hi @zhong-yy ,

indeed, very inhomogeneous station distributions can cause trouble. A dense cluster of stations can make the runtime explode: if there is a coherent set of picks at a bunch of essentially colocated stations, it is impossible to constrain the location, i.e., they will fit a large number of cells. I would suspect that this is what happens in your case.

As a solution in similar scenarios, I've run two separate associations. First, I run a large-scale association. Here, I deduplicate stations that are too close to each other and make sure that in each short time window, only a single station in the dense cluster has a pick. Afterwards, you can map back which picks at all stations fit the associated events. Second, I would remove all picks that have already been associated and run a second round of association just for the dense cluster with a much smaller search area and excluding all stations not in the area. If necessary, you can still manually match the picks from the far field stations later. The second_pass_overwrites won't work for this case, because they can't change the stations or picks.

Regarding n_threads, I think it's safe to increase it past the number of available CPUs. Indeed, this might lead to a better distribution of the load. However, in my experience, you usually get stuck on a few cells in the end, so I wouldn't expect to much. In addition, it will increase the memory usage and CPU overheads from context switching. The parameter queue_memory_protection_dfs_size can be increased, as long as enough memory is available. It should improve runtime, because it will rely on a priority queue for longer before degrading into depth-first search. This might change the results, but usually for the better.

[zhong-yy]

Hi @yetinam , thank you very for your suggestions and sharing! That sounds like a lot of details to deal with.

For the moment, if I just want to make a minimum change to my current workflow, maybe using small min_node_size, min_node_size_location and pick_match_tolerance with a smaller search region will help? I can set a larger region and larger min_node_size in the second_pass_overwrite. I suppose most events can be captured in the first pass and the second pass won't take a long time.

[yetinam]

I think this might work as well. Best is probably just to try it. I'd be curious for the result, so if you don't mind, it would be great if you could comment here how it went.

[zhong-yy]

If I first run pyocto for a small region, events would concentrate on the region boundary and form clear stripes. This becomes more obvious if the boundary of the small region goes through a cluster of events (but you don't know beforehand where a cluster is). In addition, since some events near the boundary and outside the region are "absorbed" to the boundary, the space near the small region would be more empty. I don't see significant improvement in runtime. Besides, more parameters need to be tune.

I think your suggestion is a better option. At least, picks from close stations should be duplicated.