add first notices for svom/eclairs

[timroland]

Here are the first 2 notices example of the SVOM/ECLAIRs alerts, with the associated "alert" schema.

[lpsinger]

@timroland, something weird happened with this PR; you seem to have altered almost every file in the repository.

[dakota002]

He ran the steps for releasing a new version. We should probably clarify in the readme that this is not required for making PRs

[lpsinger]

@dakota002, would you please help @timroland fix this?

[timroland]

Ok that's done I deleted the commits that were problematic. Tell me if it is ok

[timroland]

I had a question about the topics that will be created with the new schema I defined. Will it be the same than the naming of the example files (i.e. begins with "gcn.notices.svom.alert.*" where * is the notice type) ?

[lpsinger]

I had a question about the topics that will be created with the new schema I defined. Will it be the same than the naming of the example files (i.e. begins with "gcn.notices.svom.alert.*" where * is the notice type) ?

No, it doesn't have to be exactly the same. You could create the Kafka topic gcn.notices.svom, or you could create multiple topics, one for each instrument: gcn.notices.svom.eclairs, gcn.notices.svom.grm. I would suggest not calling it .alert since that by itself doesn't add any information; all Kafka topics are for alerts of some kind.

[lpsinger]

@jracusin, @Vidushi-GitHub, would one of you please review this?

[Vidushi-GitHub]

In Core Schema, we have "id" field in Event Schema, that should serve for instrument id.

[timroland]

Actually this is not just a field specifying the instrument, but the type of notice produced. In the SVOM terminology N1 notices corresponds to the first notice (trigger notice) SVOM produces. N2 notices correspond to refined analysis and N3 notices to final parameters.

[Vidushi-GitHub]

Ah Ok! Both are N1 (first notices), what are 'e' and 'g'? Better description is required for users.
Record_number field from Reporter.schema.json might be useful if multiple triggers are expected.

[timroland]

Indeed "e" and "g" stand for the instrument... I will update the description

[Vidushi-GitHub]

@jracusin please help with #127

[jracusin]

This is specifying if it's a rate or image trigger (just like Swift-BAT), not the count rate itself. We have info in gcn.notices.core.statistics on rate and image SNR, duration, energy range. I'd rather we add an enum to core.statistics with which type of trigger it is ["rate","image"] since it would be applicable to both BAT and SVOM.

[timroland]

Yes you are right. It is specifying if its a rate or image trigger... I just thought it was clearer to specify "count_rate" instead of just "rate", but if it is a standard, I will modify.
However, even if the ECLAIRs trigger is a rate trigger, the SNR and other info are based on the image it produces on the sky, so we still have image_snr, etc.

[jracusin]

I just submitted PR #135 to add "trigger_type" to the core statistics schema. @Vidushi-GitHub, please review. Once that's merged in, it can be used from core here. We will also have to do a minor version release.

[jracusin]

@timroland please use core.statistics.trigger_type

[Vidushi-GitHub]

@timroland As a gentle reminder, please make the following changes:

• Description of "notice_level":
• Update the "trigger_type": using core statistics schema

Thanks

[timroland]

Hi, sorry for the late reply... I updated the schema. I remove the notice_level parameter as it is in fact just an alias of the schema in the SVOM nomenclature (N1 are "trigger" notices and the letter stands for the instrument, it will appear in the documentation).
I had a question concerning the "Pointing" schema as it has "ra" and "dec" parameters. How to distinguish from "ra" and "dec" paramaters from the Localization schema ?

[Vidushi-GitHub]

Hi, sorry for the late reply... I updated the schema. I remove the notice_level parameter as it is in fact just an alias of the schema in the SVOM nomenclature (N1 are "trigger" notices and the letter stands for the instrument, it will appear in the documentation). I had a question concerning the "Pointing" schema as it has "ra" and "dec" parameters. How to distinguish from "ra" and "dec" paramaters from the Localization schema ?

Hi, no worries. Thanks for the corrections.

Nice catch. While it may not be an issue for the archive in future, but consumers can easily get confused with localization (ra, dec), will come up with a better solution.

[Vidushi-GitHub]

Hi Tim (@timroland), thanks for the suggestion, we have recently updated the pointing schema to avoid the confusion of the same (ra, dec) pairs in localization as well. Please update the schema accordingly for renamed properties: (ra_pointing, dec_pointing), in the updated pointing schema.

[Vidushi-GitHub]

Hi @timroland, could you please tell us where you have used the Pointing Schema in examples? I was going through the examples, and all of them have (ra, dec, ra_dec_error), these parameters together should be used for the Localization schema. Is at any place are you using Pointing Schema?

[Vidushi-GitHub]

It seems this branch is complete and quite old. I double-checked it, and it validates.
SVOM has pointing core schema, but it is not in use in schema example, thus no conflict with renamed (ra, dec).
As per conversation with @jracusin, I am merging this PR.