-
Notifications
You must be signed in to change notification settings - Fork 22
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
Common neutrino telescope alert schema #236
Common neutrino telescope alert schema #236
Conversation
…Bronze track alerts
0 - initial 1 - update 1 2 - update 2...
Please advise on next steps to move this forward, thanks |
Hi @blaufuss, we decided to create a template folder alongside the core schema to host generic schema examples. |
thanks, Is this already in main? |
Soon will be, see PR: #243 |
I guess template means something. this is just a common unified schema. But I'm ok if that's where it should go. Please advise when this is merged to main and I will update my PR |
Sure, I will let you know. |
Hi @blaufuss , we discussed this in the GCN meeting. |
This is done |
"alert_type": "update", | ||
"alert_type": "initial", | ||
"alert_tense": "current", | ||
"analysis_pipeline": "IceCube Bronze Track alert", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @blaufuss , we were checking this schema with our upcoming base schema suggestion.
Everything looks consistent, kindly add:
(a) record_number, as, initial, update are already in use
(b) Instead of pipeline, you may add:
"notice_type": {
"enum": ["field_1", "field_2", "field_3"],
"description": "Defines the category or type of notice and serves as its title. It is recommended when a single schema is used to produce multiple notice types.
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The enum could be ["gold","bronze"]. This could be in addition to the pipeline, if it makes sense to have both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments
(b) "analysis pipeline" is intended to be a name of the analysis that generated the alert. And is coming
from the base schema. The gcn kafka labels should be the determinate?
And to migrate this to a enum means changing this enum for each new alert type in any experiment if I understand correctly?
(a) I don't understand the comment. What record number are you referring to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jracusin @Vidushi-GitHub I would advocate in favor of not using enum in "analysis _pipeline" since the pipelines are specific to each experiments (the purpose is similar to the Ligo-Virgo-Kagra "Pipeline" field).
About a "notice_type" field, it is interesting, but having it, with enum type, in a Neutrino.Alert base schema may not be relevant because here also each experiment can have their own notice_type. However I see an interest of having this field free in one of the core shema.
For the record_number, you mean the one of the core Reporter.schema.json? In what sense do you suggest to use it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
record_number - this is an integer that should be incremented if more than one record might be sent for a particular neutrino. For example, an initial alert, then an update or a retraction. The idea is that the user will know which is the most recent one, in case they end up ingested out of order. If there will never be an update, then it's not needed.
notice_type - we didn't put this in the core schema, but are adding it to the documentation (nasa-gcn/gcn.nasa.gov#2909), because it's custom to each observatory. This could go in the IceCube and KM3Net-specific schema, not in this base neutrino schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in response to this guidance, I've made several changes:
- added the "record_number" to shared neutrino alert class
- removed "analysis_pipeline" from shared neutrino alert class
- added "notice_type" to IceCube specific alert class with an enum including the Gold Track, Bronze Track and Cascade Alert as enum members (first set of alerts we'd re-implement in GCN Kafka).
** per guidance these would be in the same kafka topic I believe with different notice types. - Given the icecube alert class a more generic name (old one was Gold/Bronze specific: single_neutrino_alerts
Please let us know if there's anything else before this can be approved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that's all much improved. We just posted a few more minor comments. Once those are resolved, we'll get this merged, and tag a new minor update version of the schema.
Remove common "analysis_pipeline" Add notice_type to IceCube specific format Add record_number for ordered message tracking to Alert schema
…lert schema that can be used by all alert streams in IceCube
@@ -13,6 +20,6 @@ | |||
"healpix_url": "https://roc.icecube.wisc.edu/public/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you intend to have this link to an individual healpix map associated with this event, or just this general link? The actual map would be more useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating to include a full example that's available online
record_num starts at 1 and full path to good example FITS
@jracusin I think I've addressed the open issues, please let me know if I missed anything. |
}, | ||
"notice_type": { | ||
"enum": ["Gold Track Alert", "Bronze Track Alert", "Cascade Alert"], | ||
"description": "Type of IceCube Alert", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add more description or paper reference in the description?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My expectation was to add this to the GCN website documentation. The enum description doesn't seem
like the correct place to describe the selections behind each enumeration. Please let me know if I'm misreading what you're talking about...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A brief description of the basis of Gold, bronze, and Cascade alerts, "Type of IceCube Alerts," looks vague.
Sure, add the detailed information on the GCN website as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expanded the description of this. Each selection pipeline does have it's own unique backing publication, but do feel this is best in the details documentation rather than trying to fit them into the schema. Does this work for you?
Otherwise, maybe you have an example of what more you want? Each pipeline will have a unique reference and detailed selection
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #236 +/- ##
=====================================
Coverage ? 0
=====================================
Files ? 0
Lines ? 0
Branches ? 0
=====================================
Hits ? 0
Misses ? 0
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
"alert_topology": { | ||
"description": "Event topology of the alert", | ||
"enum": ["Track", "Shower", "Multiplet"] | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really called topology? It sounds like morphology.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is the standard terminology in the field. e.g.
https://gcn.gsfc.nasa.gov/doc/High_Energy_Neutrino_Cascade_Alerts.pdf
https://icecube.wisc.edu/news/research/2020/02/new-insights-into-astrophysical-neutrino-flux/
https://arxiv.org/abs/1903.04175
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird. Thanks for checking.
Description
This PR adds a common GCN alert schema for alerts from neutrino telescopes.
It also reimplements the IceCube Gold/Bronze track alerts using this common schema, with example.
KM3Net will also implement their alerts using this common base schema.
We are happy to move the location of the shared base schema as determined by GCN dev team.