Alert support for the Ampel system
Alert support for AMPEL
This add-on enables the processing of
alerts by AMPEL.
The central class of this repository,
is capable of
ingesting these alerts.
- The loading part involves system (or instrument) specific classes.
- The optional filtering part allows the selection of events based on pre-defined rules. High-throughput systems, such as ZTF or LSST in astronomy, rely on such filters.
ingestionis the step where the content of alerts is saved into the AMPEL database, possibly along with different other documents which can be created according to pre-defined directives.
The AlertProcessor operates on the first three tiers of AMPEL: T0, T1 and T2.
Performed by subclasses of
Concrete implementation examples:
- Load bytes (tar, network, ...)
- Deserialize (avro, bson, json, ...)
- First shape (instrument specific): morph into
PhotoAlertPurpose: having a common format that the
AlertProcessorand alert filters understand. A
PhotoAlerttypically contains two distinct flat sequences, one for photopoints and one for upperlimits. The associated object ID, such as the ZTF name, is converted into nummerical ampel IDs. This is necessary for all alerts (rejected one as well) since "autocomplete" is based on true Ampel IDs.
Filtering alerts is performed per channel by subclasses of
AlertProcessor instance can handle multiple filters.
Alert filters methods provided by user units are called by the class
that handles associated operations (what happens to rejected alerts ? what about auto-complete, etc...)
FilterBlock instances are themselves embedded in
Filters can return:
Noneto reject an alert.
Trueto accept the alert and create all t1/t2 documents defined in the alert processor directive
intnumber to accept the alert and create only the t1/t2 documents associated with this group id (as defined in the alert processor directive)
If any channel accepts a given alert, DB updates need to occur.
v0.7 brought many updates regarding how ingestion happens.
More details later
Nesting is chaining
Second shape: morph into
Alerts that pass any T0 filter are further shaped in order to fullfill
some requirements for DB storage and easy later retrieval.
Among other things, individual datapoints can be tagged during this step.
For ZTF, upper limits do not feature a unique ID, so we have to build our own.
Each datapoint is shaped into a
Optimize the number of created documents
Create and upserts documents into the DB
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Hashes for ampel_alerts-0.7.2-py3-none-any.whl