SNEWS2 / hop-SNalert-app

Client application for the SuperNova Early Warning System 2.0 network
BSD 3-Clause "New" or "Revised" License
1 stars 6 forks source link

Discussion about dataformat #24

Open gvannoye opened 3 years ago

gvannoye commented 3 years ago

Here are the dataformats I suggested during one of the Virtual Offices:

proposed formats:

AlertObservation:
detector_name: str that must be in a list of detector names
sent_time: str in the format of "YYYY-MM-DD hh:mm:ss ns" (precision to the ns not needed?)
event_time: str in the format of "YYYY-MM-DD hh:mm:ss ns"
detector_status: str that must be in a list of possible status (to be determined with the experiments)
FAR? FAR-tier?

should the FAR-tier be included in the content of the message, 
or should two models (with different ids) be made for SNEWS-LOW and SNEWS

SignificanceObservation:
content of AlertObservation
p-value: float

TimingObservation:
content of SignificanceObservation
time-series: two possibilities, reconstruction of single events or distribution

two models to include those two possibilities?

reconstruction of single events: 
{channel1: {id1: {time: time1, energy: energy1}, id2: {time: time2, energy2}}, channel2: …}

distribution of binned events:
{list of times, list of number of events}

There are also some other questions I will put as other issues, and reference them here.

habig commented 3 years ago

The way forward on this is to define classes that have all the data format items we want in them. The same class to be used at both ends (experiment client and server), and the class will handle the way it writes itself out to the hop stream, reads itself in and verifies that it read in correctly.

There's an issue about this somewhere, which I'll try to find and link in here.