Distance catalog default config: radius = 300" (and not 3 deg) #410
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current logic for crossmatching catalogs that use distance is:
redshift
(z) value:a. if z is too small (<0.01), subsample with a fixed 300 arcsec radius.
b. if z is large enough, subsample with a radius computed using the z.
But to me, the radius computed at large enough redshift values is always smaller than 300 arcsec (actually, always less than 150 and gets smaller as the distance grows), so we actually just never keep anything that is further than 300 arcsec away, so not sure why we use this large 3 degrees radius.
I'll re-do the math again, but if this is true, we can lower this from 3 deg (which is 10800 arcsec) to 300 arcsec, which will speed up processing alerts for new ZTF objects.