search

SNEWS2 / snewpdag

SNEWS2 alert calculations
BSD 3-Clause "New" or "Revised" License
1 stars 13 forks source link

Dts plugin develop #62

Closed dallaval5u closed 2 years ago

dallaval5u commented 2 years ago

1.Added sigma,bias and variance to the payload. 2.Implemented method calculating dts from the best detector( the one with the smallest uncertainty). 3.Fixed bug that was allowing to use only 10 detectors for the calculation

Comment: I was wondering how to get the name of the alerting detectors in an easy way. Will one have an entry data['name'] ? So far, we are getting them from data['gen']['neutrino_times']. I am also not one hundred percent sure about dsig1 and dsig2, for now we have dsig1 = sigma1 and dsig2 = -sigma2. I have the impression this code looks really complicated now.

tsengj10 commented 2 years ago

Good question - it seems that people have thought of messages related to individual experiments, and the coincidence logic only flags that a coincidence was found. We only just recently started talking about further details of how information on the coincidence is published.

Have you ever tried running the hop client? They have a way to run a test setup, which I've run in the past but not recently. This would the mechanism for getting the coincidence information from SNEWS2 - so it would actually be a logical extension of what you've been doing, which is essentially to turn the coincidence information into a payload for DiffPointing. There is a tutorial from the hackathon (link in earlier Google doc), which at least did work several months ago. I suspect that if you check out the branches mentioned in the tutorial, it should still work.

tsengj10 commented 2 years ago

I had planned on each detector sending an individual alert with just its data. Each alert payload would presumably have a field like 'detector_name' (which is what I'm calling it for now).

That said, there are actually two circumstances: (1) immediately after a coincidence is detected, we would get several alerts one after another, but we'd like to request another field which lists the detectors which contributed to the coincidence, e.g. 'coincident_detectors'. (2) after the coincidence is detected the first time, more detectors may join with their own alerts. These will be individual detector alerts, though I suspect we can get an updated 'coincident_detectors' list as well.

I've tended to keep the actual detector alert messages separate, rather than trying to get them consolidated, because they will be stored in the hop database individually. It seems more direct to fetch these records and make a payload out of each one.