Gaia Data Release 1 Documentation release 0

Figure 2.17: 13 172, mostly spurious, detections from two scans of Sirius, one shown in blue and one in red. The
majority of the spurious detections are fainter than 19 mag.In the red scan Sirius fell in between two CCD rows.
• Spurious detections due to background noise or hot CCD columns. Most are caught on-board, so
they are few and cause no serious problems.
No countermeasures are yet in place for Gaia DR1 for the last two categories, but this has no impact on the
published data, as these detections happen randomly on the sky and there will be no corresponding stellar images
in the astrometric (AF) CCDs.
For Gaia DR1 we identify spurious detections around bright source transits, either using actual Gaia detections of
those or the predicted transits obtained in the scene, and we select all the detections contained within a predefined
set of boxes centred on the brightest transit. The selected detections are then analysed, and they are classified as
spurious if certain distance and magnitude criteria are met. These predefined boxes have been parametrised with
the features and patterns seen in the actual data according to the magnitude of the source producing the spurious
detections.
For very bright sources (brighter than 6 mag) and for the major planets this model has been extended. For these
cases, larger areas around the predicted transits are considered. Also both fields of view are scanned for possible
spurious detections.
Identifying spurious detections around fainter sources (down to 16 mag) is more di
fficult, since there are often only
very few or none. In these cases, a multi-epoch treatment is required to know if a given detection is genuine or
spurious – i.e. checking if more transits are in agreement and resolve to the same new source entry. These cases
will be addressed in future data releases as the data reduction cycles progress and more information from that sky
region is available.
Finally, spurious new sources can also be introduced by excursions of the on-ground attitude reconstruction used
to project the detections on the sky (i.e. short intervals of large errors in OGA1), leading to misplaced detections.
Therefore, the attitude is carefully analysed to identify and clean up these excursions before the crossmatch is run.
125

---

Figure 2.18: Spurious detections from several consecutive Saturn transits. The plot shows more than 22 000
detections during 33 scans and how the planet transits pollute an extended sky region.
Figure 2.19: Cat’s Eye Planetary Nebula (NGC 6543) observed with the Hubble Space Telescope (left image)
and as Gaia detections (the 84 000 blue points in middle and right images) (Credit: Photo: NASA
/ESA/HEIC/The
Hubble Heritage Team
/STScI/AURA).
126

---

2.4.9.4
Detection Processor
This processing step is in charge of providing an initial list of source candidates for each individual observation.
The first step is the determination of the sky coordinates as described in Section 2.4.9.1. This step is executed in
multiple tasks split by time interval blocks. All Gaia observations enter this step, with the exception of Virtual
Objects, and data from dedicated calibration campaigns. Also, all the observations positively classified as spurious
detections are filtered out.
Once the observation sky coordinates are available these are compared with a list of sources. In this step, the
Obs–Src Match
, the sources that cover the sky seen by Gaia in the time interval of each task are extracted from the
Gaia catalogue. These sources are propagated with respect to parallax, proper motion, orbital motion, etc. to the
relevant epoch.
The candidate sources are selected based on a pure distance criterion. The decision of only using distance was
taken because the position of a source changes slowly and predictably, whereas other parameters such as the
magnitude may change in an unpredictable way. Additionally, the initial Gaia catalogue is quite heterogeneous,
exhibiting di
fferent accuracies and errors which suggest the need of a match criterion subjected to the provenance
of the source data. In later stages of the mission, when the source catalogue is dominated by Gaia astrometry, this
dependency can be removed and then the criterion should be updated to take advantage of the better accuracy of
the detection in the along scan direction. At that point it will be possible to use separate along and across scan
criteria, or use an ellipse with the major axis oriented across scan which will benefit the resolution of the most
complex cases.
A special case is the treatment of solar system objects observations. The processing of these objects are the
responsibility of CU4 and for this reason no special considerations have been implemented in the crossmatch.
These observations will have Gaia Catalogue entries created on daily basis by IDT and those entries will remain,
so the corresponding observations will be matched again and again to their respective sources without any major
impact on the other observations.
An additional processing may be required when we find observations with no source candidates at all after these
observation to source matching process. In principle this situation should be rare as IDT has already treated all
observations before IDU runs. However, unmatched observations may arise because of IDT processing failures,
updates in the detection classification, updates in the source catalogue or simply the usage of a more strict match
criterion in IDU. Thus, this additional process is basically in charge of processing the unmatched observations and
creating temporary sources as needed just to remove all the unmatched observations in a second run of the source
matching process. The new sources created by these tasks will ultimately be resolved (by confirmation or deletion)
in the last crossmatch step.
Summarising, the result of this first step is a set of MatchCandidates for the whole accumulated mission data.
Each MatchCandidate corresponds to a single detection and contains a list of source candidates. Together with
the MatchCandidates, an auxiliary table is also produced to track the number of links created to each source,
the SourceLinksCount. Results are stored in a space based structure using HEALPix G´orski et al. (2005) for
convenience of the next processing steps.
2.4.9.5
Sky Partitioner
The Sky Partitioner task is in charge of grouping the results of the Obs–Src Match according to the source can-
didates provided for each individual detection. The purpose of this process is to create self contained groups
of MatchCandidates. The process starts loading all MatchCandidates for a given sky region. From the loaded
127

---