Skip to content

Graph layout

Jump to bottom
J Tseng edited this page Aug 16, 2021 · 3 revisions

This page proposes how different parts of the DAG are to be laid out for different purposes.

Analysis graph

The analysis graph is the heart of the calculation to be performed by snewpdag in the event of a supernova. It is expected to respond to multiple alerts arising from one supernova.

The input and output graphs may be connected to the analysis graph so the same calculation can be used in multiple circumstances.

The analysis graph begins with a layer of input nodes, which may be made up of validator plugins. The names of the input nodes are either the experiment short names (e.g., IceCube, KamLAND, HALO) or the short name with a data collection name (e.g., SuperK-IBD for filtered IBD events from SuperK, and SuperK-ES for elastic scattering events from SuperK). These nodes check that the payload's experiment name matches, and that the payload has the required fields for its data collection.

If an experiment updates a data collection, the new data collection supersedes the old one; there is no partial update of a data collection. That said, if SuperK has two collections IBD and ES, then it can update either without affecting or invalidating the other.

The internal calculations of the analysis graph start by observing the input nodes. They respond to different actions as follows:

  1. alert: update the node's calculation. If it changes the result, update the payload and forward the alert to observers. If there is no change to the result, do not notify observers.
  2. reset: clear any cached data collections, and forward the reset to observers.
  3. any other actions: forward as by default. There is no need to override the corresponding methods in Node. Results are accumulated in the payload as it is passed down the graph.

Input graphs

Input graphs produce payloads to be sent through the analysis graph.

Hop input graph

This is the input which connects to the hop-based SNEWS infrastructure. Alerts from different experiments will come in asynchronously and in series.

Firedrill input graph

MC trial input graph

This type of input graph is for running MC trials, as if the analysis graph was responding to multiple supernovae.

The typical input of an MC trial consists of multiple iterations of alert followed by reset. burst_id is set to the same value throughout the trial, but the payload key trial_id can be used to index individual trials.

  1. The first node is named Control, which is of type Pass.
  2. The second node generates parameters for a single supernova, all stored in a dictionary under the gen key:
    1. sn_direction: a tuple consisting of (right ascension, declination)
    2. sn_distance: distance from the supernova to the center of the Earth, in kpc
    3. sn_time: a tuple consisting of (seconds, ns), indicating the time the leading edge of the neutrino wavefront reaches the center of the Earth. This node may generate times for different experiments, in which case sn_time is itself a dictionary indexed by experiment names.
  3. The next layer of nodes represents each experiment and data collection and how they respond to the generated supernova at the generated distance and time. An experiment can be modelled using a string of nodes, such as having separate nodes for signal and background generation, pulled together by a gen.Combine node. In the end, the simulated experiment data is added to the main payload under keys as follows:
    1. detector_name (required): experiment short name
    2. neutrino_time: the leading edge of the supernova burst, as will be determined by the experiment. In most cases, this will be time of the first observed event of the burst, or the low edge of the first time bin.
    3. times: an array of event times, with each event time a double-precision float representing the number of seconds relative to neutrino_time. It is not assumed that the array is sorted. It is likely that experiments will publish as part of this array some buffered events before the burst; their event times will be negative.
    4. t_hist: a histogram of event times, of type values.Hist1D. As with times, the zero in time correponds to neutrino_time, and may include a region of negative times.
    5. direction: a reported direction, in the form (right ascension, declination).
    6. direction_error: direction error, in azimuthal degrees at the equator
    7. distance: a reported distance estimate, in kpc. (The fact that SNEWS can estimate distance does not preclude an experiment from making its own estimate based on its own methods, so this key is listed here for completeness.)
    8. distance_error: distance error, in kpc.

The analysis graph is hooked up to the MC trial input graph by having each of the former's input nodes observe the latter's corresponding experiment/data collectio node.

Output graphs

Output graphs observe nodes in the analysis graph and produce output which can be sent back into the outside world.

Hop output graph

The hop output graph consists of one node which formulates the hop message to send back to the hop-based SNEWS infrastructure. It is unclear at this point whether a message needs to be sent back for just the first update, or for any update, or for any update but with a maximum rate. In fact, does one need to send back a message at all, since the relevant information will be stored on disk and the coincidence will be reported in any case?

The "relevant information" will be calculated by the firedrill output graph and stored on disk.

Normal/firedrill output graph

A normal/firedrill output graph (which is also used alongside the hop output graph, if needed) renders alert payloads onto disk.

The first layer of this type of output graph observes the alerts of nodes within the analysis graph, and produces disk output on each alert. Updates may override previous output, though including the internal counter in the output filename can have the effect of storing intermediate results.

MC trial output graph

An MC trial output graph renders report payloads onto disk.

The first layer of this type of output graph observes the alerts of nodes within the analysis graph. However, it usually does not produce disk output on each alert (though it can if it wants). Instead, it produces disk output on report.

In general, it is not expected that MC trials will involve any experiment updates, i.e., a supernova will result in one alert for each experiment/data collection. Therefore, if a Histogram1D node was accumulating time differences from the alerts of another node, it should only have one histogram entry per supernova. This is easy to implement if a result is produced only when all of its input is available; if the result is progressively updated (e.g., a skymap can be produced with only two detectors, and it will be updated as more detectors send data), then one must be clear to validate the result such that only the alert with a complete set of inputs produces an entry.

Clone this wiki locally