Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add example that pre-filters from Pub/Sub metadata #14

Open
2 tasks
wmwv opened this issue Jul 13, 2023 · 6 comments
Open
2 tasks

Add example that pre-filters from Pub/Sub metadata #14

wmwv opened this issue Jul 13, 2023 · 6 comments
Labels
documentation Improvements or additions to documentation

Comments

@wmwv
Copy link
Contributor

wmwv commented Jul 13, 2023

Show an example of a user classifiers that runs based on input

  1. Pre-filtering based on Pub/Sub metadata
  2. Pre-filtering based on a classification from some "standard" classifier that we're running.
@troyraen troyraen added the documentation Improvements or additions to documentation label Jul 13, 2023
@troyraen
Copy link
Contributor

Currently those two examples would actually look the same. Our broker pipeline does not filter, it publishes every alert. Classifications are added to the alert packet and the Pub/Sub metadata (the latter specifically to make filtering via metadata doable).

We should keep in mind that filtering based on Pub/Sub metadata (i.e., creating a Pub/Sub subscription with a filter natively attached) does not really save money*. The only filtering option that would save the user money is for our broker to filter internally and publish topic(s) with only a subset of alerts.

*All throughput charges still apply for every message sent to the topic, regardless of whether it passes through the subscription's filter. Egress charges to the subscription do not apply to any message that does not pass the filter.

@wmwv
Copy link
Contributor Author

wmwv commented Jul 13, 2023

  1. Pre-filtering based on RA, Dec. Don't care about classification.
  2. Pre-filtering based on SuperNNova result.

I appreciate that these look very similar. But they are different user stories.

And, in principle you could be looking at different steps in the pipeline.

@wmwv
Copy link
Contributor Author

wmwv commented Jul 13, 2023

The money savings is not in the topic but rather in only running your classifier on a subset of alerts.

@wmwv
Copy link
Contributor Author

wmwv commented Jul 13, 2023

The only filtering option that would save the user money is for our broker to filter internally and publish topic(s) with only a subset of alerts.

And yes, this is definitely something we should consider doing based on user demand and feedback.

@wmwv
Copy link
Contributor Author

wmwv commented Jul 13, 2023

E.g., bright transients is certainly a category people might want, and would be much lower volume. Think about, e.g., I have a 4-m telescope, what can I take spectra of? Probably you want < 20 mag.

@troyraen
Copy link
Contributor

E.g., bright transients is certainly a category people might want, and would be much lower volume. Think about, e.g., I have a 4-m telescope, what can I take spectra of? Probably you want < 20 mag.

That's a good example that brings up an issue we haven't quite tackled yet: Pub/Sub metadata is always strings -- thus you can do comparisons like "equal", "not equal", and "in list", but you cannot do ">" or "<". A solution we've discussed before is to bin the magnitudes before attaching as metadata. Does 0.5 mag bins seem reasonable? Then you could compare with a list like [18.0, 18.5, 19.0, 19.5] to get < 20 mag. Do you think much could be gained by going down to 0.25 mag bins? This would be a simple thing to add to the broker's "tag" module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants