Virgo detector characterization and data quality: results from the O3 run

While data acquisition was the highest priority during the O3 run, a limited fraction of the time had to be dedicated to other activities. The two main recurring ones were:

• The maintenance periods, held every Tuesday morning, staggered with respect to the similar times in LIGO, in order to maximize the two-detector network coverage. Maintenance, limited to about 4 h per week, was used to look after the detector components, to perform various cleaning actions, and to host noisy activities incompatible with data taking—for instance the refilling of liquid nitrogen tanks located nearby the CEB, NEB and WEB, delivered by heavy trucks.
• The calibration shifts, held almost every week on Wednesday afternoons or evenings. These campaigns allowed to check the accuracy of the reconstruction of the h(t) stream [34], to monitor its stability over time and to test new, complimentary calibration methods, like the use of a Newtonian calibration system [35] in addition to the usual photon calibrators [36].

In addition, commissioning time was allocated irregularly to tune or optimize some aspects of the detector, depending on the needs and opportunities. Finally, some time was spent studying and fixing problems impacting the data taking.

The Virgo data taking is largely automated and usually only requires a single operator on duty in the control room. Operators are present 24/7 during a run and take shifts every 8 hr.

The AdV detector automation, called Metatron, relies on the Guardian [37, 38] framework, developed by LIGO and based on hierarchical finite state machines. The Virgo implementation links this framework to the DAQ: automation nodes become DAQ nodes that get data directly from shared memories and are synchronized with a 1 s data availability period. A generic mechanism to read and write DAQ channels has been introduced and can be used within user codes via dedicated functions.

The full Virgo control acquisition procedure has been implemented in Metatron, initially prior to the O2 run and then updated for the O3 configuration, the main difference being the addition of the frequency-independent squeezing [28]. The scheme adopted, depicted in figure 4, strictly follows a top-down approach, with the lower-level nodes being automatically managed by higher-level ones.

Zoom In Zoom Out Reset image size

The suspension nodes (yellow background in the graph) are tasked to align/misalign the Virgo optics, each of them is managed by the most appropriate control node (purple background), divided on the basis of the degrees of freedom to be controlled. The main node—Interferometer Control—is usually the only one operated manually to steer the detector. It defines the control paths, such as for instance the main global control procedure that allows reaching the Science mode (the nominal data taking state), plus other procedures to control various configurations of the optics, or to perform automated calibrations. It relies on the underlying managed nodes to perform these actions on the instrument. During the final steps of the control procedure, each single part of the interferometer is ultimately entangled with the others, and the interferometer is naturally treated as a single system. For these reasons, the last part of the procedure is directly managed by the upper level node, which sets the control parameters to the whole system, while the lower level nodes are only used as watchdogs for the correct functioning of their own sub-systems.

Additionally, the Metatron main node manages:

• The injection system, from the laser source to the IMC (Metatron node Injection System, orange background);
• The two OMCs, which are controlled in sequence in the final steps of the nominal control acquisition procedure (Metatron node Output Mode Cleaner, red background);
• The detection system at the interferometer output port (Metatron node Detection Safety, red background);
• The frequency-independent squeezing system (Metatron node Squeezing System, blue background), whose control proceeds in parallel to the one followed for the main detector. As Virgo can take valid Science data with or without this system being in its nominal state, the corresponding Metatron node is a bit apart from the others logic-wise.

Only during the calibration measurements, the Interferometer Control node is automatically managed by the Calibration node (pink background).

The Metatron framework also takes care of generating high-level flags that provide the overall status of the interferometer: this is done within the Interferometer Status node (green background). Finally, the Interferometer Events node (green background) records all state transitions of the detector. Information from these last two nodes is passed onto the Virgo live monitoring system, documented in [16].

Figure 5 shows the flow of data, from the interferometers (IFOs, on the left), to the physics analyses (on the right). While focusing on the GW candidates, this schematic highlights the three main pillars of DetChar activities during a run:

• The first timescale on which DetChar activities take place is online (latency: $\mathcal{O}(\textrm{s})$). Quick automated checks are run on live data to mark out (quality: good or bad) the data stream used as input by the 'pipelines'—that is the algorithms that scan the network data in real time, as soon as they become available. Initial data quality information is indeed shipped alongside the reconstructed GW stream, as explained in section 4.
• The second timescale is near real-time (latency: $\mathcal{O}(\textrm{min})$), crucial to assess the quality of the GW candidate public alerts. Thanks to a dedicated framework that is described in section 5, the data around a significant candidate are vet for each detector and a global decision is then taken: either to confirm the public alert sent to the telescopes or to retract it (see section 3.1.4 below for a description of the procedure).
• Finally, the last timescale is offline (much higher latency: up to months after the data taking). The goals of these studies are twofold: first, to finalize the dataset that all offline analyses will use, regardless of whether they look for transient or continuous signals; then, to validate the events that will be included in the final publications and whose parameters will be used to extract astrophysical information.

Zoom In Zoom Out Reset image size

To ensure a continuous monitoring of the data quality, DetChar shifts were organized during the entire O3 run on a weekly basis, with two people (working onsite or remotely) on duty. The shifter crew changed every Tuesday morning, during the weekly maintenance of the Virgo detector. In addition to attending all relevant meetings, DetChar shifters usually reported their findings at the weekly DetChar meeting on Fridays and at the weekly detector meeting on Tuesdays (thus at the end of their weekly shift).

An on-call service was organized during the O3 run to ensure a 24/7 expert coverage for all the Virgo detector components, from hardware systems to online computing and DetChar. In case of a problem, the operator on duty would contact the relevant experts from the control room, as well as the data taking coordinators if needed.

In addition, a joint LIGO-Virgo low-latency automated alert system was setup to contact the RRT experts—specialists of data taking, data quality or GW transient searches—who would meet remotely on short notice each time a public alert candidate was identified in real time. They would vet that candidate, using all raw information available, plus the output of several data quality checks, triggered automatically by the generation of the signal candidate: the DQR (see section 5.1 for details). The outcome of an RRT meeting could be twofold: either to confirm the public alert, or to retract it when the astrophysical origin of the candidate was questionable.

The noise budget compares the measured detector sensitivity with the incoherent sum of all known noise contributions. Each noise projection depends on the noise level, as measured by external probes, and of its coupling to the strain channel h(t), that is estimated by dedicated measurements called noise injections [32].

The AdV noise budget is based on the SimulinkNb [39] software package. It includes a complete model of the four main longitudinal DOFs of the interferometer (DARM, CARM, MICH, PRCL), with the interferometer optical response simulated using Optickle [40]. The mirror suspensions are approximated by a double pendulum state space model of the mirror and marionette (the steel body to which the mirror is suspended, a component of the Virgo suspension's last stage, called payload [41]). It also includes the feedback response measured from the transfer function between the photodiode signal and the mirror and marionette corrections. This approach allows to simply add different noise sources at their physical entry into the interferometer control loop, and also includes the expected cross couplings between the longitudinal DOFs.

This model has been verified to match the measured open loop transfer functions of the four modeled DOFs, and to reproduce the interferometer strain data calibration with errors smaller than 10%. In total, more than 100 noise sources are taken into account, and the total of those noises is summarized in figure 6.

Zoom In Zoom Out Reset image size

The noises are summed in log-spaced frequency bins, which allows resolving narrow lines at low frequencies and a low statistical error on the broadband noise estimation at high frequencies. The noises taken into account are the following: ASC

– Angular Sensing and Control. This represents the control noise of 12 angular DOFs of the interferometer (two per mirror) and four DOFs of the beam injected into the interferometer. The coupling of these noises has been measured by injecting broadband noise into each DOF [42].

– Digital Analog Converter. This is the electronic noise of the digital to analog converters used to drive the six main mirrors and marionettes of the interferometer. This electronic noise has been measured in the laboratory before installation, and the noise coupling is modeled using SimulinkNb.

This is the electronic and dark noise of the photodiodes used in the four longitudinal DOFs control. The dark noise of each photodiode is measured by closing the mechanical shutter in front of it. The noise coupling is part of the model of the longitudinal control loops in SimulinkNb.

This is the phase noise of the demodulation of radio-frequency signals from photodiodes to control CARM, MICH and PRCL. That phase noise mixes the two demodulation quadratures. This bi-linear noise source is measured, and the noise coupling is modeled using SimulinkNb.

– Environment. This is the sum of three contributions: acoustic, magnetic and scattered light. The acoustic and magnetic noises are measured with four microphones and three-axis magnetometers, located in the experimental buildings near the interferometer components (see [32, 33] for details). Their couplings are measured by broadband and sweeping sine noise injections. Scattered light noise is projected in two ways: (i) using the measured relative intensity noise on auxiliary photodiodes and measuring a linear coupling by shaking the bench hosting that photodiode to elevate the noise in the detector sensitivity; (ii) using position sensors of suspended benches that couple in a non-linear way, with a modeled coupling that is scaled based on measurement obtained by displacing intentionally the bench by tens of microns per second to elevate the noise in the detector sensitivity [43].

– Length Sensing and Control. This represents the control noise of four DOFs: MICH, PRCL, OMC length, and residual intensity noise. The noise is measured in all cases, the coupling is measured for all except for the OMC length where it is modeled. Note that this results in double counting the dark and quantum noise of the sensors used for MICH and PRCL control, however these double counted contributions are negligible.

Quantum noise of the detector and shot noise of the sensors used for MICH, PRCL and CARM control. The noise and the coupling are modeled using SimulinkNb.

This represents the control noise of the relative error between CARM and the laser wavelength. The noise is measured, the frequency dependent coupling is modeled using SimulinkNb and a time dependent scaling factor is measured.

This is the sum of the negligible seismic noise and three thermal noise contributions: suspension, mirror coatings and residual gas pressure in the arm vacuum tubes. The noise sources and the couplings are modeled using analytical functions in separate dedicated codes.

It is a noise source of not yet understood physical origin. Its level has been measured proportional to the square root of the DARM offset used to obtain the interferometer DC readout [44, 45].

The sum of the noises described above correspond to a BNS range of 66 Mpc, while the actual BNS range in the corresponding data was measured at 59 Mpc. Hence, about 10% of the noise limiting BNS detections is unaccounted for, not understood and not described in this section.

More in detail, at frequencies above 1 kHz the sensitivity is mostly limited by quantum shot noise. The measured level is about 5% higher than expected. This is due to a slow degradation of the frequency-independent light squeezing during O3, from 3 dB at the beginning of the run to about 2.5 dB at the end of it.

In the most sensitive frequency range, between 80 Hz and 200 Hz, there are significant contributions from three sources: quantum shot noise, mirror coating thermal noise and the "flat noise" of unknown physical origin. Assuming that the 'flat noise' estimate is correct, removing completely this unknown noise source would have resulted in 10 Mpc improvement in the BNS range.

At low frequencies between 20 Hz and 50 Hz, the dominant noise sources are quantum radiation pressure noise that is increased by the frequency independent light squeezing and the laser intensity noise. However, 30% of the noise remains not understood in that frequency range, so other significant noise sources are yet to be identified.

Table 1 summarizes the performance of the global control acquisition procedure for the Virgo detector during O3. This performance has been stable over the whole run, showing the robustness of that procedure. As not all control acquisition attempts are successful, a global control acquisition sequence is defined as a set of successive control attempts that leads to the global control of the instrument.

Table 1. Summary of the Virgo global control acquisition performance during O3: the control is acquired after a successful control acquisition sequence that counts one or more control acquisition attempts.

Global control acquisition attempt
Median duration	18 min
Distribution of this time
Reaching the detector working point	∼30%
Controlling the two OMCs	${\sim}50$%
Acquiring the lowest noise configuration	${\sim}20$%
Global control acquisition sequence
Median number of attempts	2
Median duration	25 min

The dataset analyzed here spans the whole O3 run and includes more than 700 successful global control acquisition sequences. Only the periods during which detector activities incompatible with data taking (maintenance, commissioning, calibration and known hardware problems) were ongoing have been excluded. In order to be less sensitive to the tails of the statistical distributions—which do impact the duty cycle (see the 'Locking' contributions to the pie charts below) but can have multiple origins (human errors, hardware or software failures possibly hard to diagnose quickly, or external conditions like bad weather) which are not directly related to the global control acquisition procedure—we have decided to report median durations in the following.

The median duration of a successful global control acquisition attempt is 18 min: 30% of this time is spent reaching the detector working point (Michelson interferometer at the dark fringe, power recycling cavity and arm cavities resonant, SSFS enabled); 50% is spent to control the two OMCs at the Virgo output port; the final 20% are used to reach the lowest noise configuration at the level of the suspension actuation. The median number of attempts needed to complete a global control sequence is 2 and the median duration of a successful global control acquisition sequence is 25 min. During O3 the quickest sequence took however 13 min.

Table 2 details the control stability of the Virgo detector, separately for the sub-runs O3a and O3b, and averaged over the whole O3 run. The 'global control segments' are stretches of data during which Virgo is controlled in its nominal low-noise configuration, while, as already defined, the 'Science segments' are the subset of the global control segments during which Virgo is taking data of good quality, to be used by analyses. The difference of duration between the global control and Science segments is dominated by limited disruptions of the data taking, that usually stop the Science mode for a short time. The dominant source of these breaks is the frequency-independent squeezer that lost its nominal configuration about 240 times during the O3 run; the median time to restore it and switch back to Science data taking was about 140 s.

We note that the Virgo segment duration summary numbers listed here are lower than those reported by LIGO [46, 47]. Yet, this difference has no significant impact on the duty cycle that is very similar for the three detectors of the global LIGO-Virgo network. The comparison between the O3a and O3b sub-runs shows that the impact of the winter season (larger sea seismic activity, wind, and more generally bad weather), although real, has been limited. Overall, the global network duty cycle has improved during O3, mainly due to the increase of the LIGO detectors duty cycle, while the Virgo one has been very stable. With an average of 76%, the Virgo O3 duty cycle is lower than that measured during August 2017, the final weeks of the O2 run Virgo took part of: ∼85%. Yet, the O3 performance has been achieved over 11 months spanning a whole calendar year and cannot be directly compared to the duty cycle of a short (only 25 days) run in Summer time, the most favorable period to operate an instrument like Virgo. Running one full year instead of one month is also more complex person-power wise, and the Virgo organization implemented during O3, although perfectible, held on during the whole run. This experience represents a good base on which to build upon in order to improve the Virgo performance for the O4 run and beyond.

Figure 7 shows the breakdown of the time spent in different modes by Virgo during O3. Overall, the O3a and O3b distributions are quite consistent. Breaking these 11 month-averaged duty cycle figures down to a 24 hr period, Virgo took data during 18 hr, with the remaining 6 hr roughly divided into three blocks of the same duration: ${\sim}2$ hr for controlling the detector (Locking), ${\sim}2$ hr for recurring activities (Calibration, Commissioning and Maintenance) and ${\sim}2$ hr for solving issues (Any other state).

Zoom In Zoom Out Reset image size

The analysis of these pie charts shows that increasing the duty cycle during future runs will not be straightforward. The room for improvement is limited in each area and so any significant duty cycle gain will likely stem from a combination of various small progresses, each made possible by the redesign or the optimization of a particular process.

To conclude this overview, figure 8 summarizes the improvement of the sensitivity of the AdV detector. The BNS range associated to each curve is given in the legend. From O2 to O3b, the record BNS range has more than doubled from 28 Mpc to 60 Mpc, with a continuous improvement of the sensitivity in the whole bandwidth of the detector. Many spectral features of the residual noise structures have either been removed or significantly reduced over time.

Zoom In Zoom Out Reset image size

The final Virgo O3 dataset consists of more than 250 days of data recorded during the O3a and O3b sub-runs and whose quality has been checked and validated (described in section 6.4.1). It is built upon and supersedes the online good-quality Science dataset that was used as input by the analysis pipelines that looked for GWs in real time (see section 4). Dedicated studies have been performed offline to refine the quality assessment of the data. In addition to running more in-depth analyses, new checks have been added during the run, as potential flaws got discovered in the existing analyses, or new problems identified at the detector level. Moreover, small sets of good data that had not been automatically included in the dataset (either because they were incorrectly labeled or because part of their data quality information was missing) were added by hand.

The main categories of checks applied to assess the quality of the Virgo data are the following:

• Are key components of the Virgo hardware (suspensions and photodiodes) having transient problems? These checks, described in section 4.1.2, were fast enough to be performed online on live data.
• Is the reconstruction of the GW strain time series h(t) nominal? This is a prerequisite for any further use of the Virgo data. The online reconstruction of the Virgo data was satisfactory during O3: only data from the very end of O3a (16–30 September 2019) were reprocessed offline to increase the sensitivity by a few percents [34]. Yet, during periods of high seismic activities (bad weather, high wind or the passing of seismic waves from strong and distant earthquakes), the nominal global control configuration could be replaced [33]) by a more robust one, the so-called 'earthquake (EQ)-mode' [34]. Although that procedure saved some losses of the working point (whose recovery would have costed time), it could not be validated against the nominal reconstruction of the h(t) strain stream until the final two months of O3b. Therefore, during most of the O3 run, data taken in these peculiar conditions had to be excluded from the final dataset.
• Do the data suffer from known problems? Tailored checks were run offline to identify and isolate periods during which the detector was not behaving nominally, although it was still controlled. One example of such studies is the fact that the NI mirror suspension was randomly suffering from transient (a few second-long) losses of data. This was usually enough to lose the control of the entire detector, and hence to lose at least 20 min to 30 min of data: the time to reacquire the global working point and to restore Science data taking. Therefore, a patch was developed by experts to detect the data loss and switch in real time to a less robust—but still available—control until the missing data were back. This saved hours of running time for Virgo overall, but a dedicated scan of the data had to be performed offline to identify the occurrences of these control switches (potentially inducing transients and artifacts of instrumental origin in the data) and to remove them from the final dataset.
• Are the data consistent? The last few seconds of a segment preceding a control loss of the detector have been removed offline, as the h(t) data could be corrupted (see section 6.4.1 for details). In addition, we have verified that the detector was nominally controlled during all segments flagged online as Science, and we also have looked for segments which could be included in the final offline dataset although they had not been categorized as Science online.
• Is the dataset complete? There could be data segments with missing or corrupted h(t) channel that would require a limited reprocessing. Or there could be segments with missing data segments due to problems in the DAQ, etc. Dedicated checks were setup to target these problems specifically, before analysts would run into them when processing the data.

Data segments that fail one of the checks defined above are classified as 'Category 1' (CAT1) vetoes and are excluded from all analyses. Overall, only 0.18% of the Virgo O3 Science dataset have been CAT1-vetoed.

To conclude this overview of the Virgo performance during the O3 run, figure 9 compares the Virgo BNS range distributions before (red) and after (blue) applying data quality cuts to determine the final O3 dataset. As expected, data quality requirements remove periods of low BNS range, i.e. when the sensitivity was poor. Yet, about 1% of the data have a BNS range lower than 35 Mpc, that is significantly below the typical values achieved during O3 for that sensitivity estimator. While these data have not been flagged as bad by the various checks run on the dataset, they correspond to periods during which the detector was less accurately controlled, in particular due to bad weather.

Zoom In Zoom Out Reset image size

Table 3 defines the 16 bits of the Virgo state vector integer channel in use during the O3 run. A bit is said to be active when its value is 1, meaning that the corresponding check is passed. A value at 0 means instead that a problem, or a non-nominal state, has been detected. The information provided by these bits is on purpose partially redundant, in the sense that several bits can be at 0 when proper data taking conditions are not met. During O3, the bits 0, 1 and 10 were required to be active to have the corresponding 1-second data frame processed by real-time analyses.

During the O3 run, the problems detected online and leading to CAT1 vetoes are listed below. These are:

• No saturation of any of the 4 dark fringe photodiodes, using the 'DC' (from 0 to a few Hz) and 'Audio' (from a few Hz to 10–50 kHz) demodulated signals.
• No saturation of the correction signal of any of the 16 suspension stages monitored.
• No saturation of the rate of glitches reported by the online Omicron framework for the DARM correction channel ¹¹⁶ .

These saturation checks were combined using a logical OR to produce CAT1 vetoes with a 1 s granularity. Section 6.4.1 describes the corresponding set of offline CAT1 vetoes, used by all analyses processing the final O3 Virgo dataset, including these online CAT1 vetoes.

Any channel provided by the DAQ or by the online processing (for instance DMS monitors or the BRMSMon process) can be used by the SegOnline process to build segments of data quality flags which are sent online to DQSEGDB [16].

SegOnline writes down segments into XML files with a latency of about 10 s and those XML files are then read by a rsync process to upload the segments into DQSEGDB every 5 min. Such data quality segments can then be used by any analysis, or can be viewed and downloaded through a dedicated web interface [48].

During O3, 24 public alerts out of 80 have been retracted: 8 during O3a and 16 during O3b. Out of these retractions, only two were due to Virgo data:

• S191124be [56] was due to a problem in the noise removal procedure included in the online reconstruction of the h(t) GW stream [34]. Two such cleaning algorithms running in sequence started interfering, leading to a noise increase over time. An online pipeline started triggering on that excess noise, creating several non-astrophysical GW candidates in rapid succession (figure 12), until one of them had a false alarm rate lower than the public alert threshold. That led to the generation of an automated alert that was then quickly retracted, the problem of the noise cleaning procedure was fixed as well.A similar problem should not happen again in future runs for three reasons: (i) improved noise cleaning procedures are being developed within the Virgo h(t) reconstruction; (ii) an online monitoring dedicated to such noise removal interferences will be in place during O4; (iii) a monitoring of the pipeline trigger rates in GraceDB will be running as well during future data taking periods, in order to spot quickly any misbehavior, like an excess trigger rate (in the case of S191124be) or the opposite: a too long data-taking time period without any trigger, even of low significance.
• S200303ba [57] was a single-pipeline trigger with most of its SNR concentrated in Virgo. At that time, Virgo data were quite noisy due to bad weather. An Omicron-scan around the trigger time (figure 13) showed evidence of scattering light noise at low frequency. The unusually-long delay to send out the retraction circular (80 min) was partly due to an issue with the Gamma-ray Coordinates Network broker connection.

Zoom In Zoom Out Reset image size

Zoom In Zoom Out Reset image size

Out of the 56 non-retracted O3 public alerts, 42 involved the Virgo detector. For 10 out of the 14 LIGO-only alerts, Virgo was not controlled in its nominal configuration at the GPS time of the trigger. This fraction is consistent with the average duty cycle of Virgo during O3 (see section 3.2.2). For the four remaining alerts, described in detail next, Virgo was fully controlled at the time of the trigger and had a BNS range consistent with its typical performance at that moment.

S190720a occurred during a ${\sim} 1$ min segment in between the end of the acquisition of the detector global working point and the beginning of the nominal Science mode. Therefore, Virgo data were not used for low-latency analyses. Offline analyses later confirmed S190720a as a significant detection and were able to use the low-noise Virgo data, finding a non-negligible amount of signal power in them. S190720a was published as GW190720_00 0836 in GWTC-2 [8].

S190910d occurred during nominal Science mode data-taking in Virgo. It was a marginal candidate, only reported by a subset of the low-latency searches. These searches did not find a significant amount of signal power in Virgo data, and did not report Virgo as being used for the candidate. S190910d was not confirmed by offline analyses.

S190923y occurred while Virgo was undergoing commissioning activity. It was not confirmed by offline analyses.

S200225q occurred while Virgo was undergoing a calibration run. Offline analyses confirmed S200225q as a significant detection and were able to include the low-noise Virgo data, although no significant signal power was found there. S200225q was published as GW200225_06 0421 in GWTC-3 [10].

During data taking, Omicron runs online on a few hundred channels, including the GW strain h(t), and monitors glitches in real time: these triggers are stored on disk with a few minutes latency. Figure 14 displays the evolution of the glitch rate during the O3 run, and constitutes a reference for the detailed view of figure 15, where the global Omicron glitch rate has been broken down into SNR (top plot) and peak frequency (bottom plot) bands. In these plots, the rates have been averaged by computing their daily moving median to ease the reading. From the top plot in figure 15, we can notice that the ratio of glitches in the various SNR bands is approximately constant. On the contrary, the bottom plots highlight several temporary increases in glitch rates, different for the various frequency bands. The choice of these frequency bands has been made to try to isolate some possible classes of glitches, and consequently of their sources: the region below $45\,\mathrm{Hz}$ is characteristic of scattered-light glitches, enhanced during bad weather conditions; the regions around 50 and $150\,\mathrm{Hz}$ contain the mains fundamental frequency in Europe and its second harmonics, hence is likely related to glitches of electrical origin; the region around $450\,\mathrm{Hz}$ contains the frequencies of the suspension wire violin modes for the test masses, and of another harmonic of the mains frequency.

Zoom In Zoom Out Reset image size

Zoom In Zoom Out Reset image size

The large majority of glitches identified by Omicron have a moderate SNR: between 5 (the minimum value from which the Omicron trigger is kept) and 8. The highest trigger rate at the very beginning of O3a corresponding to glitches with a peak frequency between 440 Hz and 460 Hz is an artefact due to a mis-configuration of the Omicron online server that was quickly fixed. The significant increase of the trigger rate in O3b with respect to O3a is mainly due to the bad weather conditions during the fall and winter seasons (see [33] for more details). The weather was actually very quiet in January 2020 and the associated drop in glitch rate is quite strong.

Non-stationary instrumental noise can potentially impact searches for transient GWs, which must include methods to robustly separate astrophysical candidates from noise fluctuations. Despite the power of such methods, inspecting the candidates produced by a search remains an important way to identify problematic operating conditions of GW detectors, and to understand if the search needs to be tuned in different ways for different detectors.

In this section, we perform a detailed inspection of the candidates produced from Virgo O3 final data by one of the analyses used for compiling the GWTC catalog, namely the PyCBC offline analysis [51] which we already considered in section 4.2. As a reminder, this analysis performs a broad-space search for compact binary mergers involving neutron stars, black holes, or both. It uses a bank of model waveforms and matched filtering to generate candidates from LIGO and Virgo data. Each single-detector candidate is ranked by a reweighted SNR, i.e. a combination of its matched-filter SNR and two χ² signal-based discriminators [54, 55] designed to reject candidates produced by non-stationary noise. Such discriminators have been mainly tuned on noise from Advanced LIGO so far, and to the best of our knowledge, their behavior on Virgo data has not been published before.

Figure 16 shows the rate of candidate events recorded by PyCBC from Virgo data. The horizontal axis shows either the matched-filter SNR of the candidate (left plot) or its reweighted SNR (right plot). The vertical axis shows the rate of candidates that are ranked higher than the value in the horizontal axis ¹¹⁷ .

Zoom In Zoom Out Reset image size

If the Virgo noise had been perfectly Gaussian and stationary throughout O3, we would expect the rate to decrease exponentially for larger and larger values of the matched-filter SNR, and be independent on the template parameters and particular chunks of data (subsets of the full O3 dataset, each lasting about five days and analyzed as a single block of data). Instead, the rate-vs-SNR curves show a more complicated behavior, with a large variation across the search space and particular data chunks. We observe a non-negligible rate at SNRs as high as 100, while astrophysical signals are typically expected to have SNRs between ∼5 and ∼10. After the application of the χ² discriminators, the behavior changes drastically, and the exponential behavior of the rate is recovered, at least as long as we restrict to a subset of the search space. We still observe a large variation of the exponential slope and amplitude across the search space and data chunks, except for the longest templates (green curves of figure 16), which are more robust to instrumental artifacts due to their particular time-frequency signature. The same variation is also seen with candidates from the LIGO detectors, and it is taken into account by the analysis when ranking the multi-detector candidates [58].

Even if properly accounted for, however, a higher rate of noise triggers still reduces our ability to discover compact binaries. Hence, it is informative to inspect the data quality around the triggers in the tail of the curves, in order to understand if a particularly problematic behavior of the detector or analysis can be improved in the future, or if a more robust ranking of the triggers can be found. To this end, we find that the highest SNRs can be attributed to a single segment of ${\sim}15$ min of data on 11 November 2019. These data contain narrow-band, loud and rapidly-varying excesses of power which temporarily affected the data conditioning algorithm used by PyCBC. We determined these excesses to be coming from transient problems with the noise subtraction algorithms used to reconstruct the GW strain channel h(t). Most of the associated high-SNR triggers were automatically removed by the χ² discriminators, effectively vetoing the entire problematic segment, however it would have been unlikely for a signal to be detected in Virgo data during this segment. When inspecting the top candidates by χ²-weighted SNR, instead, we find that most of the tail is clearly associated with scattered-light glitches.

We conclude from this section that the data conditioning procedure and χ² discriminators used by PyCBC, albeit designed for and tuned on LIGO data, are also reasonably effective in Virgo noise. Nevertheless, there seems to be room for further sensitivity gain via a more effective removal of scattered light. One possible way is through better tuning of the Virgo veto stream mechanism introduced in section 4.2, provided that the fraction of affected astrophysical signals can be kept to negligible levels. Another avenue to investigate in the future is a signal-based discriminator or conditioning procedure specifically targeting scattered-light transients, as proposed for example in [59]. Improved tuning and vetoes would have to be evaluated with injection studies and a corresponding calculation of the relative sensitive time-volume of the search.

Combs are families of lines separated by a constant frequency interval. Typically, noise combs are electromagnetic disturbances generated by digital devices (e.g. microprocessors, programmable communication devices like logical controllers, Ethernet cables, wireless repeaters) that leak into the GW strain channel. Comb lines can have an impact on searches for persistent GWs due to their large number and usually high strength. This makes the identification of combs an important task. There are several combs present in Virgo O3 data, which we describe in the following. They are typically made of many (up to O(10)) lines, covering from a few to several Hertz in frequency.

A 1 Hz-spaced comb with 0 Hz offset was already present during previous runs. A new 1 Hz-spaced comb discovered during O3 has a 0.333 Hz offset with respect to integer frequencies. This comb was found during investigations of a line at 22.333 Hz that falls within a region of interest for the Vela pulsar CW search. The instrumental origin of the comb has been confirmed by finding lines at the same frequency in the magnetometers deployed at EGO.

Figure 17 shows the line persistency computed over the frequency range 21.8–23.5 Hz on O3 Virgo data. Both 1 Hz combs are clearly visible. Furthermore, there is a comb with 0.2 Hz spacing, whose origin is unknown. The grey shaded area indicates the frequency region explored by a narrow-band CW search targeting the Vela pulsar. The strong line at 22.333 Hz produced an outlier in the search, which was discarded after its instrumental origin was understood.

Zoom In Zoom Out Reset image size

Finally, two more combs which have been identified by DetChar studies, have both ∼9.99 Hz spacing, one with 0 Hz offset and the other with 0.5 Hz offset.

A wandering line is a peculiar kind of spectral noise where the frequency of a spectral line changes with time, with no apparent reason. This is also called a drifting line once the mechanism driving the frequency change is at least partially identified, making its variations not entirely random anymore.

An example that triggered lots of DetChar investigations during O3 is the line, normally located between 83 and 84 Hz, as shown in figure 18, that reached about 110 Hz at the maximum of its excursion and had variations of a few Hz over about 1 h [66, 67]. Its origin dates back to the Virgo commissioning run 10 (C10) of August 2018 [68], and possibly even earlier, in the preparatory phase preceding O2 [69]. Neither of the mechanisms that make the line to depart from its typical frequency of about 83 Hz or what produces its variations with time have ever been understood, although several data analysis techniques have been applied and newer ones developed for line tracking [68]. An analysis with Bruco [16] revealed no witness channel coherent with h(t) around that line. Moreover, we tracked the frequency evolution of this line, and we correlated the corresponding time series with the auxiliary channels monitoring Virgo [66]. This technique has proven successful in the past, in the case of drifting lines driven by the temperature of some optical components [70], but has produced no convincing correlation in the case of this line, whose origin remains unknown.

Zoom In Zoom Out Reset image size

Figure 19(a) shows the power spectrum of the Virgo GW strain channel h(t) computed at two different dates, 26 February and 2 March 2019 (before the start of the O3 run). Comparing the two plots, one can see that a wide bump around 55 Hz was cured in the meantime. Indeed, a detailed study showed that this disturbance was present most of the time and was observed also in the PRCL channel. This allowed to remove most of this noise excess when producing the reconstructed strain h(t), by accurately subtracting the remaining PRCL contribution [34]. Note that this 55 Hz bump affected the frequencies around 55.6 Hz, where the CW signal possibly emitted by pulsar PSR J1913+1011 is expected. Furthermore, this bump was located within the most sensitive region of the Virgo spectrum for an (isotropic) SQWB search.

Zoom In Zoom Out Reset image size

The GW strain channel h(t) in the frequency region between 45 Hz and 55 Hz was significantly affected by ambient electromagnetic fields originating from the interferometer infrastructure. This noise was studied and mitigated in subsequent steps during the run [32].

The intense 50 Hz line, corresponding to the frequency of the electricity mains, was mitigated and substantially eliminated from h(t) (see figure 19(b)), by implementing a feed-forward noise cancellation scheme using as sensor a voltage monitor of the detector uninterruptible power supply system [32]. This operation did not reduce the 50 Hz harmonics also present in the h(t) spectrum (see figure 8) because they are not due to a non-linear response of the interferometer. They are present in the global environmental disturbances and enter the GW strain channel through different coupling paths.

Sidebands of the mains frequency, at approximately 49.5 Hz and 50.5 Hz, were generated by the pulse width modulation of the electric heater controller of the IMC building. The noise was mitigated by decoupling the electric ground of the building from the central experimental area with an isolation transformer.

Figure 19(c) illustrates a wide-band noise affecting the same region. The origin of this noise was eventually found to be a noisy static voltage accidentally applied to the signal wires of the motors used for positioning and balancing the WE mirror suspension, then coupling capacitively to the mirror coil actuator wires. The noise was mitigated by un-plugging the drivers of the motors, which are not used in Science mode.

Finally, figure 19(d) illustrates a family of lines between 47 Hz and 49 Hz which have been identified as vertical mechanical modes of the last stage of the test mass suspension system. These modes are excited by ambient magnetic fields coupling to the magnetic actuators along the suspension chain. This noise was suppressed by an active mechanical damping of the modes.

While section 4.1.2 described the online CAT1 vetoes, we focus here on the final set of offline CAT1 vetoes. They supersede online vetoes and have been used by all analyses processing the final O3 Virgo dataset. These include analyses using the O3 LIGO-Virgo public dataset: that is why the GWOSC website [71] includes detailed public information about these vetoes [72].

Like the online CAT1 vetoes, all these veto flag segments of bad data that are unusable. They are defined with a 1 s granularity and the figure-of-merit used to quantify their impact is their dead time, that is the fraction of Science time that is removed by applying them individually. Yet, the vetoes are not independent and they may overlap. Therefore, they are meant to be applied globally on the dataset, by taking the logical OR of all of them.

Offline vetoes are computed by reanalyzing the whole dataset, using more complex algorithms and additional input information not available online. All the online data quality assessments are reviewed and updated where needed. GPS segments are added to (or removed from) the final dataset by this, possibly iterative, procedure. The offline vetoes defined during the O3 run can be classified into three main categories.

• The duplication—after crosscheck and potential additions or fixes—of online CAT1 vetoes: this includes the saturations of dark fringe photodiodes or mirror suspensions, and the monitoring of the reconstructed GW strain h(t).
• The upgrade of existing online vetoes: the excess rate of glitches is monitored offline using h(t), whereas only the DARM channel could be used online due to latency constraints.
• The addition of new vetoes, based on information that was not available in low latency, or that was not known at the time online flags were generated. These categories are:
  • Checks of the consistency and of the completeness of the files storing the h(t) GW stream: these vetoes flag segments in which h(t) is missing or contains missing samples.
  • The h(t) stream is reconstructed by blocks of eight consecutive seconds of data. Therefore, a control loss can possibly impact up to the eight seconds of data that predate it. As the exact time of a control loss is not easy to define, the last ten seconds preceding each recorded control loss have been removed.
  • The Science dataset has been scanned accurately to identify segments during which the detector was not taking good quality data, contrary to what its status was indicating. These segments were removed from the final dataset.
  • Finally, a workaround was applied to the detector control system during some weeks in O3b in order to mitigate transient data losses due the failure of an hardware component. That patch allowed to maintain the working point of the instrument, thus sparing a ∼20 min control acquisition procedure each time it prevented a global control loss. Yet, the application of that workaround could degrade the quality of the data. Thus, the impacted segments were removed from the final dataset, with some safety margin on both ends (the last 10 s before having the control patch be applied automatically, and the first 110 s following the end of the transition back to the nominal control system).

Table 7 summarizes the impact of CAT1 vetoes on the final O3 Science dataset: overall, only 0.2% of the Science data have had to be removed due to various problems.

Conversely, a few minutes of good quality data that had not been included in the online Science dataset for various and clearly understood reasons (software issue, human error, etc) were added to the offline, final, dataset.

To assess whether the detection alerts produced by transient searches [49, 50, 73, 74] should be considered as 'candidate events', a procedure of validation is implemented for each generated trigger [10, 47]. This task has the role to verify if data quality issues, such as instrumental artifacts, environmental disturbances, etc can impact the analysis results and decrease the confidence of a detection, or even foster a rejection [75].

The validation of the online triggers found by GW transient searches includes two separate stages. A prompt evaluation is typically completed within few tens of minutes after an event trigger has been generated, as represented by the data flow in figure 5. Its goal is to determine a preliminary detection confidence and sky localization, in order to deliver public alerts to the astronomy community and support for multi-messenger follow up observations [75], as described in section 5, or to vet that trigger if evidence of severe contamination from non-astrophysical artifacts is present. A team of Virgo DetChar shifters is in charge of this task as part of the RRT (see section 3.1.4). The decision about the event is primarily based on the quick results provided by the DQR, within a few minutes from the trigger. This decision takes into account the evaluation of the operational status of the detector and its subsystems, the environmental conditions, as well as preliminary checks on the strain data. In particular, the shifters are asked to verify the presence of excess noise, namely glitches, around the time of the trigger and the validity of the hypotheses of stationarity and Gaussianity of the data, as discussed in [16]. Moreover, it is examined the possible presence of correlations between the strain data and the auxiliary sensors, which may advise a non-astrophysical origin of the trigger.

With higher latency, a second stage of validation is performed by a validation team to finally check candidate events before publications, including those found by offline analyses [51, 76]. Besides of (double-)checking the astrophysical origin of the event trigger, the main purpose of this process is to carefully assess whether the parameter estimation of the source properties can be affected by noise artifacts. This procedure takes advantage of dedicated reruns of the DQR, as well as from additional tools and metrics, including, for example, signal consistency checks [47, 77].

For those events where non-stationary noise, such as glitches, are found in the vicinity of the putative GW signal, or even overlapping with it, a procedure of noise mitigation is implemented [78, 79]. During O3b, such process has involved 12 events, including one with Virgo data, GW191105e [10, 80], where the process of mitigation and validation of the data quality has improved the parameter estimation results and credibility. Various O3a events have undertaken a preliminary version of this procedure [8].