Gaia Data Release 1 Documentation release 0

Figure 2.20: Example of a match candidate group; in this case comprising three catalogue sources and about
180 observations. Blue dots correspond to observations, red dots are sources, and the dashed lines represent the
match candidate source links.
128

---

entries, the unique list of matched sources is identified and the corresponding SourceLinksCount information is
loaded. Once loaded, a recursive process is followed to find the isolated and self contained groups of detections
and sources. The final result of this process is a set of MatchCandidateGroups (as shown in Figure 2.20) where all
the input observations are included. In summary, within a group all observations are related to each other by links
to source candidates. Consequently, sources present in a given group are not present in any other group.
In early runs, there is a certain risk to end with unmanageably big groups. For those cases we have introduced a
limit in the number of sources per group so the processing is not stopped. The adopted approach may create spu-
rious or duplicated sources in the overlapped area of these groups. However, as the cyclic processing progresses,
these cases should disappear (groups will be reduced) due to better precision in the catalogue, improved attitude
and calibration and the adoption of smaller match radius. So far we have not encountered any of these cases and
therefore we have not reached the practical limit for the number of sources per group.
After this process each MatchCandidateGroup can be processed independently from the others as the observations
and sources from two di
fferent groups do not have any relation between them.
2.4.9.6
Crossmatch resolution
The final step of the crossmatch is the most complex, resolving the final matches and consolidating the final new
sources. We distinguish three main cases to solve:
• Duplicate matches: when two (or more) detections close in time are matched to the same source.
This will typically be either newly resolved binaries or spurious double detections.
• Duplicate sources: when a pair of sources from the catalogue have never been observed simulta-
neously, thus never identifying two detections within the same time frame, but having the same
matches. This can be caused by double entries in the working catalogue.
• Unmatched observations: observations without any valid source candidate.
For the first cyclic processing, the resolution algorithm has been based on a nearest-neighbour solution where
the conflict between two given observations is resolved independently from the other observations included in the
group. This is a very simple and quick conflict resolution algorithm. However, this approach does not minimize the
number of new sources created, when more than two observations close in time have the same source as primary
match.
The crossmatch resolution algorithms in forthcoming Gaia data releases will be based on much more sophisticated.
In particular, the next crossmatch will use clustering solutions and algorithms where all the relations between the
observations contained in each group are taken into account to generate the best possible resolution.
2.5
Quality assessment and validation
Author(s): Uli Bastian
129

---

2.5.1
Overview
Author(s): Uli Bastian
An extensive continuous assessment and validation was performed on all astrometric and photometric pre-processing
products, as well as on the telemetry input data entering the pre-processing steps.
In this section, the highest emphasis is given to the monitoring of the daily pre-processing (IDT) and to the mon-
itoring of the sole cyclic pre-processing step (namely the IDU crossmatch) for Gaia DR1. These two processes
produced output which directly entered the generation of the astronomical contents of the Gaia DR1.
The other three relevant quality assessment and validation processes — namely the First Look (FL), the AVU
Astrometric Instrument Model (AIM) and the AVU treatment of the Basic-Angle Monitoring data (AVU–BAM)
are described much more briefly and just for completeness. They contributed to the quality of the Gaia DR1 — e.g.
by finding on-ground processing defects and disturbing on-board phenomena, so that those defects and problems
could be mitigated as far as possible. But no data products from FL, AIM and AVU–BAM directly contribute to
the input data generating the astrometric and photometric source parameters in Gaia DR1.
2.5.2
Monitoring of daily pre-processing
Author(s): Jordi Portell, Michael Biermann, Deborah Busonero, Alberto Riva
Daily pre-processing results are closely monitored both by IDT and FL systems. Monitoring in IDT is relatively
simple, being composed of counters, statistics, histograms and the like. The advantage is that IDT must process all
of the science data received from the spacecraft.
On the other hand, FL only handles a subset of data — mainly detections brighter than G
= 16 and some fainter
detections arriving promptly enough from the spacecraft, but these FL checks are more exhaustive. Some simple
statistics and histograms are also determined, but these include automatic alarms to detect unexpected deviations
in any of the many output fields. Also, FL runs complex algorithms to determine one-day calibrations (including
a first astrometric solution), which not only serve as updated calibrations for IDT, but also provide details on
variations and trends in the instrumentation and even in IDT processing outputs in themselves.
2.5.2.1
IDT Monitoring and Validation (IDV)
IDT monitoring is mainly done through a web interface which called WebMon, which acts as a front end to the
many statistics and plots generated by the system on-the-fly. That is, diagnostics are continuously compiled in IDT
(mainly histograms) on the outputs generated by the system. Most of these diagnostics are computed over typically
one day of data. Some of the most remarkable ones are the following:
• Performance monitor:
– Plots with the OBMT (on-board mission time) being processed w.r.t. the UTC (on-ground)
time, to reveal possible delays or gaps in the processing. These, combined with other checks
on the DB outputs, assess that all inputs are processed and that the expected number of outputs
are generated. This is done for all inputs and outputs of IDT — which basically means all data
processed by downstream DPAC systems in one or another Coordination Unit (CU).
130

---