Fermi-GBM #239
Fermi-GBM #239
Conversation
|
Rather that "full" and "minimal" examples, it would be good to have versions for "alert", "flight position", "ground position", "final position" and "sub threshold" all using the same schema, given that's the intended use. |
| "description": "Triggered detectors" | ||
| }, | ||
| "duration_class": { | ||
| "enum": ["SHORT", "LONG", "UNCERTAIN"], |
There was a problem hiding this comment.
this doesn't need to be all caps
There was a problem hiding this comment.
same with all the other all caps enums
There was a problem hiding this comment.
I like all caps, especially for the "notice_type" enum. Do you mind leaving everything in all caps? Or only the "notice_type"?
Co-authored-by: Judy Racusin <[email protected]>
Co-authored-by: Judy Racusin <[email protected]>
| }, | ||
| "localization_algorithm": { | ||
| "type": "string", | ||
| "description": "Version number" |
There was a problem hiding this comment.
Is there a reference document for these version numbers?
There was a problem hiding this comment.
I doubt. It is the only production algorithm. I assume we can find very old notices computed with have earlier versions of the loc.
There was a problem hiding this comment.
There is no description of the versions. I need to find out if the subthreshold and the targeted use the same algorithm.
| }, | ||
| "duration_class": { | ||
| "enum": ["SHORT", "LONG", "UNCERTAIN"], | ||
| "description": "Long vs. short duration event" |
There was a problem hiding this comment.
Waiting to receive info about it together with soft/hard definition.
Co-authored-by: Judy Racusin <[email protected]>
Co-authored-by: Judy Racusin <[email protected]>
| }, | ||
| "hardness_class": { | ||
| "enum": ["SOFT", "HARD"], | ||
| "description": "Classification based on the hardness ratio." |
There was a problem hiding this comment.
Could you please add reference in the description?
There was a problem hiding this comment.
@Vidushi-GitHub: I am inquiring for a more precise definition, if this is what you mean by reference.
| }, | ||
| "high_energy_high_intensity": { | ||
| "enum": [false, true, "UNCERTAIN"], | ||
| "description": "High energy, high intensity event" |
There was a problem hiding this comment.
Is this for bright, extraordinary events?
Can you add threshold intensity criteria in the description?
There was a problem hiding this comment.
@Vidushi-GitHub : Not extraordinarily bright, just enough emission in the high energy range. Something like, more than ? counts with E>? from BGOs. So not your typical GRB. I'm trying to find out the exact numbers as above.
Your language is more precise but I don't want to leave room for ambiguity. I'm going to make another change to a middle ground. Co-authored-by: Vidushi Sharma <[email protected]>
Co-authored-by: Vidushi Sharma <[email protected]>
Co-authored-by: Vidushi Sharma <[email protected]>
Thanks for catching the typos! Co-authored-by: Vidushi Sharma <[email protected]>
|
@jracusin, @Vidushi-GitHub, @lpsinger, @dakota002: Shall we defer merging this PR until after PR #240 is merged? The "notice_type" field then will be part of the core. Now it is Fermi-specific. |
It would be reasonable for sub threshold to be a separate Kafka topic, if you'd prefer that, but keep the rest of the sequence in the same topic. |
|
@shb46 |
|
@Vidushi-GitHub: Thanks for keeping my PR in mind. (cc: @jracusin, @lpsinger, @dakota002) I am waiting to get quantitative info on the three fields, so I can offer better descriptions. I think, we've cleaned everything else. Until then I will not have anything new for review. Please let me know if you think of more comments in the meanwhile. |
Single schema for all GBM notices.