Project

General

Profile

Wiki

FINK GRANDMA work

Team

Julien, Sarah, Juliette, add your name

What is Fink?

Fink is a broker that primarily connects surveys (ZTF currently, and LSST later hopefully) to the rest of the world by ingesting input alert streams, enriching all alerts, filtering alert streams based on original and derived information, and finally redistributing alerts to the community. More information can be found at:

Fink operations are made of two parts: the broker infrastructure (that deals with all technical aspects irrespective of the science cases), and the Community Projects (that focus on the science extraction). The Community Projects provide the necessary methods and tools to Fink infrastructure to extract science from alerts. Enrichment of alerts is done on-the-fly during sky observations, and it primarily comes from Fink science modules (e.g. a classifier based on lightcurves), or cross-matches with known catalogues (cured and released, e.g. Gaia), or particular events streams (GW, GRBs). On a different timescale (sometimes several days after observations are made and during post-processing analyses), we also manually ingest information from external verified information and spectral classifications (TNS).

Scope of this collaboration

The way we see the collaboration at this stage between Fink and GRANDMA can be divided into 2 Work Packages (this will evolve through time):

WP1: Kilonovae identification in the ZTF alert stream [lead Fink] Deadline is Spring 2021
WP2: Interoperable communication tools [lead Fink/GRANDMA] Deadline is Summer 2021

The WP1 target is to develop a method in Fink (classifier + series of cuts) to automatically extract potential kilonova candidates from the ZTF alert stream that are suitable for GRANDMA follow-up. The WP2 target is to develop tools to enable efficient communications between Fink and GRANDMA to share interesting alert data (from Fink to GRANDMA), but also to enrich Fink databases with the GRANDMA follow-up information (from GRANDMA to Fink).

Some ideas for the GRANDMA needs (we need to discuss the repartition of tasks)

Scientific and organization needs

  • G1 - GRANDMA needs to trigger on targets that fit its scientific needs (KN candidatess, GW sources, Neutrino sources)
  • G2 - GRANDMA needs to trigger adequate facilities given the potential source origin, its significance, its interest for the science return (level of the sample enrichment, diversity), its current resources, and its prospects to engage further observations
  • G3 - GRANDMA needs to preserve To0 time on sensitive instruments (spectroscopy, deep photometry)
  • G4 - GRANDMA needs to limit the fatigue of the telescope teams and shifters, and other human investments
  • G5 - GRANDMA needs to facilitate any valorization of the follow-up in terms of public reports, scientific publications
  • G6 - GRANDMA needs to supplement the data in case of out-of-scope observations and/or too poor collection of data
  • G7 - GRANDMA needs to target an operational system for 2021A, but also needs to invest into its long term system (O4)

Modules and scientific developments

  • S1 - Reliable scores for determining the nature of the LSST transients
    - Fink: providing scores from the science module using ZTF public alert stream and crossmatch from simbad database. In addition, Fink is providing template filter to select candidates.
    - GRANDMA: Providing KNe simulations, and feedback to improve on the filter
  • S2 - Updates on scores
    - Fink: Update on KNe scores using ZTF public alert stream and GRANDMA simulations (to improve the training).
    - GRANDMA: Providing realistic set of simulations.
  • S3 - Connect to the GRANDMA ICARE
    - Fink/GRANDMA internship 2021
  • S4 - Easy access to LSST but also follow-up partners (interoperability, TAP, etc)
    - Question: can you clarify follow-up partners of whom?
    - Fink: API to provide a list of potential candidates from the ZTF/LSST stream (based on the KN module + associated filter improved by the GRANDMA team). Fink will provide positional crossmatch information between ZTF/LSST public stream and public external streams (GCN/VOEvent).
    - GRANDMA: providing information if an object from the Fink-GRANDMA KNe filter was followed-up by GRANDMA.
  • S5 - Cross-match of personal and public data with access of DB
    - Question: can you clarify DB of whom? FInk or GRANDMA alert DB?
    - Fink has an API where you can upload a small catalog and get positional crossmatches with ZTF objects. Object information can then be downloaded on a separate API call. This is the only procedure in Fink for the moment.
  • S6 - Personal annotations
    - Fink does not provide a mechanism to put personal annotations. One should use a Marshall instead.
  • S7 - Transmit information to private FINK or public partners
    - The current API deals with public data only.
  • S8 - Uniformity in the format of exchange across the process
    - Fink/GRANDMA internship 2021
  • S9 - Alert for the shifters
    - Fink provides both API (to query all the collected and processed alert data) and a livestream service (to receive new alerts automatically).

Work in progress WP1 (04/03/2021)

Cosmin sent KNe and afterglow lightcurves to the Fink team. These lightcurves are currently used to assess the quality of the KNe classifier in Fink. The work is divided into 3 main steps:

  1. Validation of the model used in Fink to detect KNe.
    - Comparison of simulated data sets
    - Validation of Fink models on Cosmin sims
  2. Definition of a series of cut based on current Fink information (incl. KNe module score) to select interesting candidates to be sent to GRANDMA.
    - Running on alerts
    - Defining cuts to select probable candidates
  3. Addition of new external information in Fink to enhance the KNe search in Fink (integration of additional triggers than ZTF information).

Comparison of simulated data sets

In Fink, we started to use ZTF-I simulations to train our models. The simulations are taken from https://arxiv.org/abs/1904.00014. For the lightcurves of each data set (Cosmin LC & Fink LC), the distributions of the magnitude for the first detection are somewhat similar (Fink sims slightly brighter):

The distributions of the observed peak magnitude are also somewhat similar (Fink sims slightly brighter - note the linestyle is inverted with respect to plot above... my bad):

However, Cosmin simulations are based on ZTF-II, which has a different cadence than ZTF-I. This can clearly be seen in the data (time difference between two measurements, all bands):

Validation of Fink models on Cosmin sims

Having the similarities and differences between the two datasets in mind, we trained a model that uses both set of simulations. The model requires at least 1 point in each filter but with strong constraints on the quality of the fit. We injected two different populations in the training (what is the proportion?). Here is the efficiency of the model for each population:

Input population Efficiency
KN-GW 84%
KN-Kasen 65%

These are the validation scores obtained on different KNe classes (Fink simulations):

And the scores obtained on some other selected classes (SNe, TDE, ...):

And here are the scores for all 1000 Kilonova objects in Cosmin simulations:

The model performs quite good on Cosmin sims (86% efficiency). This might indicate that Cosmin sims are based on the KN-GW class.

Running on alerts

I took one night of observation (2021/01/01), and applied the KNe module to all alerts that pass the quality cuts. The quality cuts are currently:

  1. RealBogus scores assigned by the ZTF alert distribution pipeline Mahabal et al. (2019); Duev et al. (2019). The values must be above 0.55.
  2. Number of prior-tagged bad pixels in a 5 x 5 pixel stamp. The value must be 0.
  3. The difference between the aperture magnitude and the PSF-fit magnitude. The absolute value must be lower than 0.1.

These cuts remove about 70% of incoming alerts, and we are left on this night with 48,502 alerts to process. Here are the scores:

Defining cuts to select probable candidates

In order to reduce the number of KNe candidates each night, we can use the KNe module scores, but also additional information contained originally in the alert packets or provided by other Fink modules. In this first iteration, we define a series of cuts similar to our search for supernovae. An alert is considered as KNe candidate iif:

  1. The KNe score is above 0.5
  2. The Deep Learning Real Bogus score, drb, is above 0.5 (filter extra boguses)
  3. The Star/Galaxy score by SExtractor is above 0.4 (filter variable stars)
  4. The number of detections in the ZTF survey is lower or equal than 20 (filter old/long trend objects)
  5. The alert must be associated with a galaxy, a candidate transient or tagged as unknown (Cross-match with SIMBAD, provided in real-time by Fink)

Here are the surviving candidates:

model # alerts after cuts
1PC 47 (0.1%)

The number of candidates is somehow manageable. Let's have a look at their classification in Fink (irrespective of the KNe module):

Liberal (total=47 candidates)
Fink class # of KNe candidates
SN candidate 25
Unknown 22

Half of the candidates are also flagged as SN candidates. The number of candidates can be reduced further, either by improving the scores, or introducing more cuts based on alert data.

We show below the rate (mag/day) versus the score for each band. Positive values mean the detection has been done in the rising part of the curve (before measured peak), negative values mean the detection has been done in the decreasing part of the curve (after measured peak):

the orange circles are KNe candidates, and the grey circles are non-KNE candidates for comparison. Here is a zoomed version of the plot against small rate values:

The rate is naively the difference between the measured peak value and its neighbour, divided by the time gap.

Action item: improve cuts.

Sarah (26.02.2021) after concertation with Michael, Nicolas et Patrice

There are two science objectives
  • 1. build a sample of kilonovae
  • 2. well characterization of the kilonovae

The 1. required some fitting tools to assess or not if there is some serendipitous KNe in the data of a survey. That's why, only with the data, one can apply a score based on criteria and modelization to attest the probability to find kilonovae. This can be done a posterior and does not any "rapid follow-up".
1. can be converted into a "medium latency" follow-up if the score is high enough, to trigger deeper facility that can participate into the decision.

In this scenario, the cuts will be defined regarding the purity. In optical either for deep spectroscopy or deep photometry, it needs to reach an alert rate of less than 10 per year. The transient needs to be also recent enough. So I would say as a refined cut

  1. The KNe score is above 0.5 (or even higher ?)
  2. The Deep Learning Real Bogus score, drb, is above 0.5 (filter extra boguses)
  3. The Star/Galaxy score by SExtractor is above 0.4 (filter variable stars)
  4. The number of detections in the ZTF survey is lower or equal to 20 (filter old/long trend objects)
    --> No here, what it is interesting is the delay between now and the first point
  5. The alert must be associated with a galaxy, a candidate transient or tagged as unknown (Cross-match with SIMBAD, provided in real-time by Fink)

The 2. Objective necessitates to follow-up early kilonovae. Due to the capacity of GRANDMA network and for science return, one need to extensively followup the KN after 24h after the merger time. In this sense, waiting the 3rd point of LSST/ZTF or even the second is not optimal.
In this sense, I propose to engage direct GRANDMA observations after a new discovery, to characterize and define the nature of the new source. I also propose to restrict to close-by KNe and with a strong association of a close-by galaxy.

so I would say as a cut (and I am so excited to hear the rate) with

  1. The Deep Learning Real Bogus score, drb, is above 0.5 (filter extra boguses)
  2. The Star/Galaxy score by SExtractor is above 0.4 (filter variable stars)
  3. The first point of data is less than 6h (it is a very young new detection)
  4. The alert must be clearly associated with a galaxy, with known distance
  5. It is candidate transient or tagged as unknown (Cross-match with SIMBAD, provided in real-time by Fink)
  6. The galaxy distance is less than 230 Mpc

Rate ?

Additional cuts

#we have a measurement in B-V (faintly detected in R?)

Rate ?
#the absolute mag is 16 (apparent rescaled with galaxy distance)
#the galaxy is a high rank in JG catalog (mass etc ?)

Finally,

I would be curious from study one to have the final "detected KNe" with score, overplotted into the injected population on a 2D plots, like one axis the peak mag and on y axis, the slope ?
Just to check if there is a biais on the detection.

Addition of new external information in Fink

TBD

Work in progress WP1 (04/2021): fink kilonova filters

All the alerts that pass this filter will be redirected in the fink_kilonova channel in GRANDMA workspace.

Model

The principle is the following:

A base of principal components (PCs) has been computed on a large number of simulations of various objects.

We then fit the lightcurve as a linear combination of these PCs. Right now only the first PC is used.

This gives 4 features per band:
- coefficient
- maxflux
- residuo
- number of points

We use two bands, r and g, so we have 8 features. We feed them to a random forest classifier that has been trained with the simulations, and we get a score. I we don't have one point per band, we won't be able to compute all the features and the score will be set to 0.

Kilonova filter - classifier-based

A version of the filter has been implemented (https://github.com/astrolabsoftware/fink-filters/blob/master/fink_filters/filter_kn_candidates/filter.py).

The current filter consists of the following cuts:
  1. knscore > 0.5
  2. deep learning real/bogus score > 0.5
  3. Star/galaxy extractor > 0.4
  4. the number of prior detections(`ndethist`) is below 20
  5. the first detection of the object must be recent: less than 20 days between `jd` and `jdstarthist`
  6. Cross-match: object unknown, transient, fail, or SIMBAD galaxy
Boguses filters

The star/galaxy extractor and deep real/bogus score filter a few boguses, but most of the alerts won't be affected.

Filters on history (3 sigma threshold detection)

The history-related filters are meant to filter variable stars and long-trend objects. They should not filter any kilonova as kilonovae are expected to last for a few days of less. They appear to filter most of the alerts passing the `knscore` threshold, leaving less than an alert a day.

knscore filter

On top of using the classifier described in the Model section, the knscore function removes alerts that only have one point in their history (5 sigma detection threshold). These points represent 90% of objects that pass the other cuts.

Around 20 objects pass this cut each night (0.04% of alerts)

Filter as a whole

306 alerts from 204 objects passed the filter in the 17 first months of observation by ZTF.

Around 60% of the objects could be identified thanks to TNS spectroscopic follow-up. Among the objects that were observed, 96% of them were supernovae. The lightcurves of supernovae and kilonovae are very similar, at least in the very beginning, so it makes sense that the kilonova candidates turns out to be supernovae.

The filter may be biased towards rising candidates:

Kilonova filter based on cross-match with galaxies (WIP)

The cuts are the following:
  1. The Deep Learning Real Bogus score, drb, is above 0.5 (filter extra boguses)
  2. The Star/Galaxy score by SExtractor is above 0.4 (filter variable stars)
  3. The first point of data is less than 6h (it is a very young new detection)
  4. It is candidate transient or tagged as unknown (Cross-match with SIMBAD, provided in real-time by Fink)
  5. The alert must be clearly associated with a galaxy from Mangrove, with known distance: as we know the distance between the earth and the galaxies, we can compute the distance between a given galaxy and the alert if the alert were in the galaxy. The threshold implemented in the test is a radius of 10 kpc.
  6. The galaxy distance is less than 230 Mpc (range of GW interferometers)
  7. Absolute magnitude (apparent magnitude rescaled with galaxy distance): -16 ± 1

19 candidates per month.

30% of the 327 candidates observed until 18/05/21 (17,5 months) have been followed up in TNS: the objects are SN except for a galaxy.

Filter for amateurs

same as above, but:
  1. apparent magnitude < 20
  2. Cut on Galactic latitude (>-20, <20)
    The number of candidates per week must be low, right now we have 23 for April.

Sarah (Thoughts 30.04)

Fink follow-up with Kilonona-catcher program

  • We plan to have a meeting with our amateurs (100 participants) 26.05 (20H30) to explain the objectives of the program
  • We can use three strategies of "transient", but we would like to at the beginning to only release the sources who passed the broker selection at a particular day.
1 and 2 follow-up stratetegy
  • We can engage the follow-up "challenge" within 48~h. So concretely, KNC delivers an alert on a day and 48h after it is over.
  • I propose the deliver the alerts on Thursday - Friday night, so that Amateurs in France have their Friday evening and Saturday evening
  • Every Wednesday, we (e.g in charge of GRANDMA) query TNS or others to provide an update of the Thursday night "challenge". I can make a public page on the wiki and give them updated.
  • 1 concerns the KNC scoring filter and 2 concerns the Mangrove selection
  • For 1 and 2, the broker needs to deliver only sources whose last detection was below 19 mag.
3rd follow-up strategy
  • We propose the "month" supernova follow-up from the FINK-supernova team, who variation within the first 3 weeks shouldn't be exceeded 18 mag
    The objective here is to collect a maximum of "random" data and train them on the photometry.
    The supernova chosen needs to be observable by most region of earth and cover large night hours.

To clear, GRANDMA is in charge of all the organization and interaction of the amateurs.

ZTF-Fink follow-up with GRANDMA-program

We have deployed already the KNC score filter and Juliette is working hard on the Mangrove filter.

With rapid calculation, the KN-peak can be detected at max 200 Mpc for 20.5 upper limit of ZTF and at 63 Mpc for 18 mag upper limit.

I think the filter on the mag and observability should be done within the GRANDMA collaboration since it includes some additional info as we might expect to observe the target and on which instruments we can perform rapid observations

As also discussion, the FINK enrichment needs to be performed also within GRANDMA, and the internal processing on cuts to continue to follow-up within GRANDMA (including the decision of triggering CFHT is within GRANDMA)

From the work already done for KNC score, we can study / estimate the proportion of triggers that finally do not necessitate any external info and for which science case

I propose to engage further performance diagnostic already engaged by Juliette

  • How many triggers from the 2 years data (?) have been flagged as KNC as a preferred classification using all available data ?
  • What is the minimal latency between the discovery point and the alert ?
    Then there is an event:
    ZTF process it (~10min)
    It send the information to Fink (instant)
    Fink process it (1-2min)
    Fink sent the alert to slack if needed (instant)
    So about 10 min, for exemple if you look at yesterday candidate, it was sent at 10h25 in France so 8h25 UTC, and the time of the alert was 2021-04-25 08:14:54.004 UTC.
  • For Mangrove filter, what is the potential "host galaxies distribution" of the triggers selected ? And if you enlarge the critereria "with a distance to the alert inferior to 10kpc" to 20 kpc and 50 kpc ?
  • What is the period / latency from the discovery point to degrade the KN score down to 50 %, down to 30 % ? What is the corresponding rates ?
  • What is the proportion of events that passed the cuts KNC score and with a final slope rate > 0.5 mag/day ?
    --> Just let me know if it is under your scope or under mine for the statisics

Statistics

Classifier-based filter

  • 306 kilonova alerts between start of observations and 11/05/21 from 204 distinct objects, 300 as preferred classification so 17 candidates/month.
  • To see how fast the score decays and the corresponding rates:


    The score can decrease very quickly after the classification as kilonova candidate as we often have a point in each filter in a short amount of time. It is possible that the first alert pass the filter and the next does not.
  • Out of the alerts that pass the filter, 29% do so with a rate above 0.5 in absolute value, see graphs above.

Filter based on cross-match with galaxies

  • 325 early kilonova alerts from the second filter so 19 candidates/month, preferred classification will be available soon.
  • Host galaxies characteristics (when a galaxy hosts several alerts, the duplicates are not deleted):

With a radius of 20 kpc there would be 1e3 candidates:

With a radius of 50 kpc there would be 6e3 candidates (mean distance: 43 Mpc):

Rate-based filter (WIP)

Changes:
- no threshold on knscore
- `drb > 0.9` instead of 0.5
- time: max 14 days in total,
- object appeared (`isdiffpos == t`)
- distance to mpc > 10''
- rate > 0.3

This results in 34 candidates in April from 24 objects including 3 SNIa.
1146 candidates in 20 months (before 18 june 2021) so ~ 60 candidates/month. From 1057 objects => usually 1 alert/object, could be change by computing the maximum rate instead of the last rate. Mostly unknown.

36 candidates pass the cuts of both 2PC and rate in 18-20 months

To consider:
- time: max 14 days in total, 10 days for band g, 12 days for band r
- We might want to replace the computation of the rate by a linear fit, and only consider objects if the points in the band are at least 0.5 day apart.
- check if there are other alerts with other ID in 3'' (distnr), could provoke ghost. Problem: we don't know the nature of the object, we might reject galaxies. `distnr < 1 | distnr > 3` actually leaves most alerts (1024/1146)
- sgscore1 < 0.5: no stellar counterpart. It would not leave a lot of objects and relies on SExtractor, so I would not trust this one. Leaves 213 alerts
Adding thresholds on sgscore and distnr leaves 144/1146 alerts.

Telecons

Visio Meeting 15/01/2021

Visio Meeting 29/01/2021

List of FINK triggers

Dedicated page