relocated arrivals often flagged as Unused in seiscomp
Closed this issue · 3 comments
Hi there,
We've been using scrtdd with great success lately so thanks again for all the recent work.
I notice that after relocation many arrivals are flagged as unused. I suspect that as far as scrtdd is concerned, including them does not affect the solution but this does affect our subsequent QC process because an event with "only 4" phases is then flagged for review or outright removal from the catalog. The azimuthal gap is also usually increased. This also often makes subsequent relocations impossible without manually turning all the picks back on. See attached image where 6/10 phases are marked as unused.
Is there any harm is leaving them turned on / marked "Used"?
edit: some clarification- this is via processing multiple events, writing new picks/events out to XML, and then importing this XML file using scdispatch.
The arrivals are flagged as unused when their final weight becomes zero during the DD inversion. The parameter that controls the final weight is solver.downWeightingByResidual
. By default the finalValue
is 3, which means all arrivals whose dd equations have residuals (the mean of all the equation residuals in which an arrival is used) above 3 standard deviations are dropped, i.e. their weight becomes 0. You can try being less strict and increase the value to see if the arrivals are kept. There is no theoretical reason why the default value should be 3, it was just out of my experience, so it is safe to play around with that value.
Here is the explanation from Waldhauser & Ellsworth 's paper. Note that I didn't include the downweighting by inter-event distance, because I believe that is not a good idea, although there is an old repository branch with that feature around. If you find that option useful I would be happy to discuss it, but that's another topic.
Thanks, that makes sense. I think I was confused because the de-weighted picks were set to zero residual but I suppose it makes more sense to do that rather than leave their original residuals in the new origin.
Now that you mention it, it would make more sense to set the residuals even for unused arrivals. Unfortunately, I checked the code and I saw that the reason why they are set to zero is because I don't have the value for unused arrivals. This could in theory be fixed but it would be quite annoying to do, from the code perspective. I think I will keep it like it is now unless it becomes really annoying for the users to not see the residuals.