Closed mlincett closed 1 month ago
If we want it to be compatible with the alerts from the past we should implement it in a way that can look for an alert for both SplitUncleanedInIcePulses
and SplitInIcePulses
, right?
Yes, but this fallback logic needs be implemented individually in each reco module because they all read from cfg.INPUT_PULSES_NAME
.
The fastest option for a temporary solution is replacing this:
build/lib/skymap_scanner/config.py:INPUT_PULSES_NAME: Final = "SplitUncleanedInIcePulses"
and have a tag of the scanner ready to run on a new alert if it comes.
I created the branch pulse-tag-new-filters
with that modification
I think changing it in config.py
with a major version update could work.
Do we know how it behaves for replayed past alerts? It might be that with the new realtime software replayed old alerts will have SplitInIcePulses
, in which case this replacement could be the solution.
I think changing it in
config.py
with a major version update could work.Do we know how it behaves for replayed past alerts? It might be that with the new realtime software replayed old alerts will have
SplitInIcePulses
, in which case this replacement could be the solution.
The pulse series name is frozen in the IceTray serialized data blob part of the JSON, so this will not be backwards compatible.
It should be possible on the other hand to map the realtime data "version" string (that it's in the input JSON) to the appropriate pulse series name, instead of having it fixed.
after decoding the json blob, could have a conditional rename of the frame object.
The new pole data format replaces
SplitUncleanedInIcePulses
withSplitInIcePulses
. The former is still somewhat hardcoded in Skymap Scanner.It is VERY URGENT to support this because we may be soon left without a working scanner for the incoming alerts.