adv short=AdV, long=Advanced Virgo, asd short=ASD, long=amplitude spectral
density, bh short=BH, long=black hole, bns short=BNS, long=binary neutron
star, bristol short=BRiSTOL, long=Band-limited RMS Stationarity Test Tool,
brms short=BRMS, long=band-limited RMS, bruco short=BruCo, long=brute-force
coherence tool, bs short=BS, long=beam splitter, carm short=CARM, long=common
(i.e. average) length of the two arm cavities, ceb short=CEB, long=central
building, cw short=CW, long=continuous gravitational waves, daq short=DAQ,
long=data acquisition system, darm short=DARM, long=difference of the two arm
cavity lengths, dms short=DMS, long=Detector Monitoring System, dof short=DOF,
long=degree of freedom, dq short=DQ, long=data quality, dqr short=DQR,
long=Data Quality Report, dqsegdb short=DQSEGDB, long=Data Quality SEGment
Database, eom short=EOM, long=electro-optical modulator, fft short=FFT,
long=fast Fourier transform, gracedb short=GraceDB, long=GRAvitational-wave
Candidate Event Database, gw short=GW, long=gravitational wave, gwosc
short=GWOSC, long=Gravitational Wave Open Science Center, imc short=IMC,
long=input mode-cleaner, lvalert short=LVAlert, long=LIGO-Virgo Alert System,
mich short=MICH, long=length difference between the Virgo Michelson
interferometer short arms monet short=MONET, long=Modulated NoisE Tool ne
short=NE, long=north end, neb short=NEB, long=north-end building, ni short=NI,
long=north input, noemi short=NoEMi, long=Noise Frequency Event Miner, ns
short=NS, long=neutron star, omc short=OMC, long=output mode-cleaner, pr
short=PR, long=power recycling, prcl short=PRCL, long=power recycling cavity
length, psd short=PSD, long=power spectral density, rrt short=RRT, long=rapid-
response team, sgwb short=SGWB, long=stochastic gravitational-wave background,
sneb short=SNEB, long=suspended north-end bench, snr short=SNR, long=signal-
to-noise ratio, sr short=SR, long=signal recycling, ssfs short=SSFS,
long=second-stage frequency stabilization system, sweb short=SWEB,
long=suspended west-end bench, upv short=UPV, long=Use-Percentage Veto, vim
short=VIM, long=Virgo Interferometer Monitor, vpm short=VPM, long=Virgo
Process Monitoring we short=WE, long=west end, web short=WEB, long=west-end
building, wi short=WI, long=west input,

Dated:

# Virgo Detector Characterization and Data Quality: results from the O3 run

F Acernese1,2, M Agathos3, A Ain4, S Albanesi5,6, A Allocca7,2, A Amato8, T
Andrade9, N Andres10, M Andrés-Carcasona11, T Andrić12, S Ansoldi13,14, S
Antier15,16, T Apostolatos17, E Z Appavuravther18,19, M Arène20, N
Arnaud21,22, M Assiduo23,24, S Assis de Souza Melo22, P Astone25, F Aubin24, S
Babak20, F Badaracco26, M K M Bader27, S Bagnasco6, J Baird20, T Baka28, G
Ballardin22, G Baltus29, B Banerjee12, C Barbieri30,31,32, P Barneo9, F
Barone33,2, M Barsuglia20, D Barta34, A Basti35,4, M Bawaj18,36, M
Bazzan37,38, F Beirnaert39, M Bejger40, I Belahcene21, V Benedetto41, M
Berbel42, S Bernuzzi3, D Bersanetti43, A Bertolini27, U Bhardwaj16,27, A
Bianchi27,44, S Bini45,46, M Bischi23,24, M Bitossi22,4, M-A Bizouard15, F
Bobba47,48, M Boër15, G Bogaert15, M Boldrini49,25, L D Bonavena37, F Bondu50,
R Bonnand10, B A Boom27, V Boschi4, V Boudart29, Y Bouffanais37,38, A Bozzi22,
C Bradaschia4, M Branchesi12,51, M Breschi3, T Briant52, A Brillet15, J
Brooks22, G Bruno26, F Bucci24, T Bulik53, H J Bulten27, D Buskulic10, C
Buy54, G S Cabourn Davies55, G Cabras13,14, R Cabrita26, G Cagnoli8, E
Calloni7,2, M Canepa56,43, S Canevarolo28, M Cannavacciuolo47, E Capocasa20, G
Carapella47,48, F Carbognani22, M Carpinelli57,58,22, G Carullo35,4, J
Casanueva Diaz22, C Casentini59,60, S Caudill27,28, F Cavalier21, R
Cavalieri22, G Cella4, P Cerdá-Durán61, E Cesarini60, W Chaibi15, P Chanial22,
E Chassande-Mottin20, S Chaty20, F Chiadini62,48, G Chiarini38, R Chierici63,
A Chincarini43, M L Chiofalo35,4, A Chiummo22, S Choudhary64, N Christensen15,
G Ciani37,38, P Ciecielag40, M Cieślar40, M Cifaldi59,60, R Ciolfi65,38, F
Cipriano15, S Clesse66, F Cleva15, E Coccia12,51, E Codazzo12, P-F Cohadon52,
D E Cohen21, A Colombo30,31, M Colpi30,31, L Conti38, I Cordero-Carrión67, S
Corezzi36,18, D Corre21, S Cortese22, J-P Coulon15, M Croquette52, J R
Cudell29, E Cuoco22,68,4, M Curyło53, P Dabadie8, T Dal Canton21, S
Dall’Osso12, G Dálya39, B D’Angelo56,43, S Danilishin69,27, S D’Antonio60, V
Dattilo22, M Davier21, D Davis70, J Degallaix71, M De Laurentis7,2, S
Deléglise52, F De Lillo26, D Dell’Aquila57, W Del Pozzo35,4, F De
Matteis59,60, A Depasse26, R De Pietri72,73, R De Rosa7,2, C De Rossi22, R De
Simone62, L Di Fiore2, C Di Giorgio47,48, F Di Giovanni61, M Di Giovanni12, T
Di Girolamo7,2, A Di Lieto35,4, A Di Michele36, S Di Pace49,25, I Di
Palma49,25, F Di Renzo35,4, L D’Onofrio7,2, M Drago49,25, J-G Ducoin21, U
Dupletsa12, O Durante47,48, D D’Urso57,58, P-A Duverne21, M Eisenmann10, L
Errico7,2, D Estevez74, F Fabrizi23,24, F Faedi24, V Fafone59,60,12, S
Farinon43, G Favaro37, M Fays29, E Fenyvesi34,75, I Ferrante35,4, F
Fidecaro35,4, P Figura53, A Fiori4,35, I Fiori22, R Fittipaldi76,48, V
Fiumara77,48, R Flaminio10,78, J A Font61,79, S Frasca49,25, F Frasconi4, A
Freise27,44, O Freitas80, G G Fronzé6, B U Gadre81,28, R Gamba3, B
Garaventa43,56, F Garufi7,2, G Gemme43, A Gennai4, Archisman Ghosh39, B
Giacomazzo30,31,32, L Giacoppo49,25, P Giri4,35, F Gissi41, S Gkaitatzis4,35,
B Goncharov12, M Gosselin22, R Gouaty10, A Grado82,2, M Granata71, V
Granata47, G Greco18, G Grignani36,18, A Grimaldi45,46, S J Grimm12,51, P
Gruning21, D Guerra61, G M Guidi23,24, G Guixé9, Y Guo27, P Gupta27,28, L
Haegel20, O Halim14, O Hannuksela28,27, T Harder15, K Haris27,28, J
Harms12,51, B Haskell40, A Heidmann52, H Heitmann15, P Hello21, G Hemming22, E
Hennes27, S Hild69,27, D Hofman71, V Hui10, B Idzkowski53, A Iess59,60, P
Iosif83, T Jacqmin52, P-E Jacquet52, S P Jadhav64, J Janquart28,27, K
Janssens84,15, P Jaranowski85, V Juste74, C Kalaghatgi28,27,86, C
Karathanasis11, S Katsanevas22, F Kéfélian15, N Khetan12,51, G Koekoek27,69, S
Koley12, M Kolstein11, A Królak87,88, P Kuijer27, P Lagabbe10, D Laghi54, M
Lalleman84, A Lamberts15,89, I La Rosa10, A Lartaux-Vollard21, C Lazzaro37,38,
P Leaci49,25, A Lemaître90, M Lenti24,91, E Leonova16, N Leroy21, N
Letendre10, K Leyde20, F Linde86,27, L London16, A Longo92, M Lopez
Portilla28, M Lorenzini59,60, V Loriette93, G Losurdo4, D Lumaca59,60, A
Macquet15, C Magazzù4, M Magnozzi43,56, E Majorana49,25, I Maksimovic93, N
Man15, V Mangano49,25, M Mantovani22, M Mapelli37,38, F Marchesoni19,18,94, D
Marín Pina9, F Marion10, A Marquina67, S Marsat20, F Martelli23,24, M
Martinez11, V Martinez8, A Masserot10, S Mastrogiovanni20, Q Meijer28, A
Menendez-Vazquez11, L Mereni71, M Merzougui15, A Miani45,46, C Michel71, L
Milano7111Deceased, April 2021., A Miller26, B Miller16,27, E Milotti95,14, Y
Minenkov60, Ll M Mir11, M Miravet-Tenés61, M Montani23,24, F Morawski40, B
Mours74, C M Mow-Lowry27,44, S Mozzon55, F Muciaccia49,25, Suvodip
Mukherjee16, R Musenich43,56, A Nagar6,96, V Napolano22, I Nardecchia59,60, H
Narola28, L Naticchioni25, J Neilson41,48, C Nguyen20, S Nissanke16,27, E
Nitoglia63, F Nocera22, G Oganesyan12,51, C Olivetto22, G Pagano35,4, G
Pagliaroli12,51, C Palomba25, P T H Pang27,28, F Pannarale49,25, F Paoletti4,
A Paoli22, A Paolone25,97, G Pappas83, D Pascucci27,39, A Pasqualetti22, R
Passaquieti35,4, D Passuello4, B Patricelli22,4, R Pedurand48, M Pegoraro38, A
Perego45,46, A Pereira8, C Périgois10, A Perreca45,46, S Perriès63, D
Pesios83, K S Phukon27,86, O J Piccinni25, M Pichot15, M Piendibene35,4, F
Piergiovanni23,24, L Pierini49,25, V Pierro41,48, G Pillant22, M Pillas21, F
Pilo4, L Pinard71, I M Pinto41,48,98, M Pinto22, K Piotrzkowski26, A
Placidi18,36, E Placidi49,25, W Plastino99,92, R Poggiani35,4, E Polini10, E K
Porter20, R Poulton22, M Pracchia10, T Pradier74, M Principe41,98,48, G A
Prodi100,46, P Prosposito59,60, A Puecher27,28, M Punturo18, F Puosi4,35, P
Puppo25, G Raaijmakers16,27, N Radulesco15, P Rapagnani49,25, M Razzano35,4, T
Regimbau10, L Rei43, P Rettegno5,6, B Revenu20, A Reza27, F Ricci49,25, G
Riemenschneider5,6, S Rinaldi35,4, F Robinet21, A Rocchi60, L Rolland10, M
Romanelli50, R Romano1,2, A Romero11, S Ronchini12,51, L Rosa2,7, D
Rosińska53, S Roy28, D Rozza57,58, P Ruggi22, J Sadiq101, O S Salafia32,31,30,
L Salconi22, F Salemi45,46, A Samajdar31, N Sanchis-Gual102, A Sanuy9, B
Sassolas71, S Sayah71, S Schmidt28, M Seglar-Arroyo10, D Sentenac22, V
Sequino7,2, Y Setyawati28, A Sharma12,51, N S Shcheblanov90, M Sieniawska26, L
Silenzi18,19, N Singh53, A Singha69,27, V Sipala57,58, J Soldateschi91,103,24,
K Soni64, V Sordini63, F Sorrentino43, N Sorrentino35,4, R Soulard15, V
Spagnuolo69,27, M Spera37,38, P Spinicelli22, C Stachie15, D A Steer20, J
Steinlechner69,27, S Steinlechner69,27, N Stergioulas83, G Stratta104,25, M
Suchenek40, A Sur40, B L Swinkels27, P Szewczyk53, M Tacca27, A J
Tanasijczuk26, E N Tapia San Martín27, C Taranto59, A E Tolley55, M
Tonelli35,4, A Torres-Forné61, I Tosta e Melo58, A Trapananti19,18, F
Travasso18,19, M Trevor105, M C Tringali22, L Troiano106,48, A Trovato20, L
Trozzo2, K W Tsang27,107,28, K Turbang108,84, M Turconi15, A Utina69,27, M
Valentini45,46, N van Bakel27, M van Beuzekom27, M van Dael27,109, J F J van
den Brand69,44,27, C Van Den Broeck28,27, H van Haevermaet84, J V van
Heijningen26, N van Remortel84, M Vardaro86,27, M Vasúth34, G Vedovato38, D
Verkindt10, P Verma88, F Vetrano23, A Viceré23,24, V Villa-Ortega101, J-Y
Vinet15, A Virtuoso95,14, H Vocca36,18, R C Walet27, M Was10, A R
Williamson55, J L Willis70, A Zadrożny88, T Zelenova22, and J-P Zendri38
0000-0002-5288-1351 0000-0001-9557-651X 0000-0002-5360-943X
0000-0002-8738-1672 0000-0002-9277-9773 0000-0002-7686-3334
0000-0001-6589-8673 0000-0003-4981-4120 0000-0003-1613-3142
0000-0001-7469-4250 0000-0001-8553-7904 0000-0001-6062-6505
0000-0002-0304-8152 0000-0002-8008-2485 0000-0002-8883-7280
0000-0002-8069-8490 0000-0002-1180-4050 0000-0001-6841-550X
0000-0003-3611-3042 0000-0002-4003-7233 0000-0002-4991-8213
0000-0001-6345-1798 0000-0002-2334-0935 0000-0002-7377-415X
0000-0003-1233-4174 0000-0002-4618-1674 0000-0001-5013-5913
0000-0001-8665-2293 0000-0001-9923-4154 0000-0003-1643-0526
0000-0002-3327-3676 0000-0002-6013-1729 0000-0003-2872-8186
0000-0002-4289-3439 0000-0002-6852-6856 0000-0003-0133-1306
0000-0002-7086-6550 0000-0003-3762-6958 0000-0001-9090-1862
0000-0002-3658-7240 0000-0001-6064-0569 0000-0002-0752-0338
0000-0001-9127-3167 0000-0003-1753-524X 0000-0003-3768-9908
0000-0002-5769-8601 0000-0002-9339-8622 0000-0003-4094-9942
0000-0003-2165-2967 0000-0003-0949-7298 0000-0002-6870-4202
0000-0003-4258-9338 0000-0001-8912-5587 0000-0003-3140-8933
0000-0001-7170-8733 0000-0003-3452-9415 0000-0002-0583-9919
0000-0002-7439-4773 0000-0003-2731-2656 0000-0002-1985-1361
0000-0002-6504-0973 0000-0002-8581-5393 0000-0002-2003-4238
0000-0001-5078-9044 0000-0003-4366-8265 0000-0003-3258-5763
0000-0001-9143-8427 0000-0001-7758-7493 0000-0001-5620-6751
0000-0002-1019-6911 0000-0002-8680-5170 0000-0003-4977-0789
0000-0001-5895-0664 0000-0003-1014-8394 0000-0003-1556-8304
0000-0002-4004-947X 0000-0003-2127-3991 0000-0001-8568-9334
0000-0003-2339-4471 0000-0002-4787-0754 0000-0002-0357-2608
0000-0001-6759-5676 0000-0003-1544-8943 0000-0002-5447-3810
0000-0001-9546-5959 0000-0002-3738-2431 0000-0002-8215-4542
0000-0002-3021-5964 0000-0002-3809-065X 0000-0003-1314-1622
0000-0002-0351-6833 0000-0002-4390-9746 0000-0003-2777-3719
0000-0002-0083-7228 0000-0002-6189-3311 0000-0002-8925-0393
0000-0003-3174-0688 0000-0002-0210-516X 0000-0001-6650-2634
0000-0003-4204-6587 0000-0001-6586-9901 0000-0003-0966-4279
0000-0002-1534-9761 0000-0003-2490-404X 0000-0003-1391-6168
0000-0002-1127-7406 0000-0003-0149-2089 0000-0003-0423-3533
0000-0002-6947-4023 0000-0002-4628-2432 0000-0001-9420-7499
0000-0003-3189-5807 0000-0002-0501-8256 0000-0003-3275-1186
0000-0002-6956-4301 0000-0003-0029-5390 0000-0002-3061-9870
0000-0002-3680-5519 0000-0003-1326-5481 0000-0002-7332-9806
0000-0002-0784-5175 0000-0003-0625-5461 0000-0001-5268-4465
0000-0002-2246-5496 0000-0002-0233-2346 0000-0001-5869-2714
0000-0003-1621-7709 0000-0002-0693-4838 0000-0001-9552-0057
0000-0001-8760-4429 0000-0001-8085-3414 0000-0002-0642-5507
0000-0003-0324-0758 0000-0002-5793-6665 0000-0002-5482-6743
0000-0003-4514-7690 0000-0002-6987-2048 0000-0001-7462-3794
0000-0002-3997-5046 0000-0002-2765-3955 0000-0002-2321-1017
0000-0003-4254-8579 0000-0002-2765-7905 0000-0003-0452-746X
0000-0002-3628-1591 0000-0002-9913-381X 0000-0003-4512-8430
0000-0001-7902-8505 0000-0002-4424-5726 0000-0001-8799-2548
0000-0001-6482-1842 0000-0001-9449-1071 0000-0003-1606-4183
0000-0001-7737-3129 0000-0003-0606-725X 0000-0002-8766-1156
0000-0002-6444-6402 0000-0002-0351-4555 0000-0002-8855-2509
0000-0002-3373-5236 0000-0002-2168-5462 0000-0001-5558-2595
0000-0001-8623-0306 0000-0001-8906-9159 0000-0002-4450-9883
0000-0002-7537-3210 0000-0001-8898-1963 0000-0003-1907-0175
0000-0003-4753-9428 0000-0001-6709-0969 0000-0002-6269-2490
0000-0003-1561-0760 0000-0001-5478-3950 0000-0002-4439-8968
0000-0003-0945-2196 0000-0002-6020-5521 0000-0001-8032-4416
0000-0002-5737-6346 0000-0002-9968-2464 0000-0003-4059-0765
0000-0003-2049-520X 0000-0001-5256-915X 0000-0001-8722-4485
0000-0003-4825-1629 0000-0002-8690-9180 0000-0001-8088-3517
0000-0002-7629-4805 0000-0001-5799-4155 0000-0002-1382-9016
0000-0003-0589-9687 0000-0003-2275-4164 0000-0003-0020-687X
0000-0002-7378-6353 0000-0001-5931-3624 0000-0003-4924-7322
0000-0002-9511-3846 0000-0002-0857-6018 0000-0001-5375-7494
0000-0002-5767-3623 0000-0001-8654-409X 0000-0003-3718-4491
0000-0001-8696-2435 0000-0001-7316-3239 0000-0002-1135-3456
0000-0002-9944-5573 0000-0002-5458-5206 0000-0001-8051-7883
0000-0002-1855-5966 0000-0003-0930-6930 0000-0002-8781-1273
0000-0003-4710-8548 0000-0003-1055-7980 0000-0001-6635-5080
0000-0002-3066-3601 0000-0002-4817-5606 0000-0001-9841-943X
0000-0001-8709-5118 0000-0001-5833-4052 0000-0001-7763-5758
0000-0002-4653-6156 0000-0002-2728-9508 0000-0001-5087-189X
0000-0002-9714-1904 0000-0002-9296-8603 0000-0003-2975-9208
0000-0003-1215-4552 0000-0002-0500-1286 0000-0003-4434-5353
0000-0003-2386-957X 0000-0002-8391-7513 0000-0003-4180-8199
0000-0003-4573-8781 0000-0003-4344-7227 0000-0003-0624-6231
0000-0001-7983-1963 0000-0002-1890-1128 0000-0002-7627-8688
0000-0002-9929-0225 1Dipartimento di Farmacia, Università di Salerno, I-84084
Fisciano, Salerno, Italy  2INFN, Sezione di Napoli, Complesso Universitario di
Monte S. Angelo, I-80126 Napoli, Italy  3Theoretisch-Physikalisches Institut,
Friedrich-Schiller-Universität Jena, D-07743 Jena, Germany  4INFN, Sezione di
Pisa, I-56127 Pisa, Italy  5Dipartimento di Fisica, Università degli Studi di
Torino, I-10125 Torino, Italy  6INFN Sezione di Torino, I-10125 Torino, Italy
7Università di Napoli “Federico II”, Complesso Universitario di Monte S.
Angelo, I-80126 Napoli, Italy  8Université de Lyon, Université Claude Bernard
Lyon 1, CNRS, Institut Lumière Matière, F-69622 Villeurbanne, France
9Institut de Ciències del Cosmos (ICCUB), Universitat de Barcelona, C/ Martí i
Franquès 1, Barcelona, 08028, Spain  10Univ. Savoie Mont Blanc, CNRS,
Laboratoire d’Annecy de Physique des Particules - IN2P3, F-74000 Annecy,
France  11Institut de Física d’Altes Energies (IFAE), Barcelona Institute of
Science and Technology, and ICREA, E-08193 Barcelona, Spain  12Gran Sasso
Science Institute (GSSI), I-67100 L’Aquila, Italy  13Dipartimento di Scienze
Matematiche, Informatiche e Fisiche, Università di Udine, I-33100 Udine, Italy
14INFN, Sezione di Trieste, I-34127 Trieste, Italy  15Artemis, Université Côte
d’Azur, Observatoire de la Côte d’Azur, CNRS, F-06304 Nice, France  16GRAPPA,
Anton Pannekoek Institute for Astronomy and Institute for High-Energy Physics,
University of Amsterdam, Science Park 904, 1098 XH Amsterdam, Netherlands
17Department of Physics, National and Kapodistrian University of Athens,
School of Science Building, 2nd floor, Panepistimiopolis, 15771 Ilissia,
Greece  18INFN, Sezione di Perugia, I-06123 Perugia, Italy  19Università di
Camerino, I-62032 Camerino, Italy  20Université de Paris, CNRS, Astroparticule
et Cosmologie, F-75006 Paris, France  21Université Paris-Saclay, CNRS/IN2P3,
IJCLab, 91405 Orsay, France  22European Gravitational Observatory (EGO),
I-56021 Cascina, Pisa, Italy  23Università degli Studi di Urbino “Carlo Bo”,
I-61029 Urbino, Italy  24INFN, Sezione di Firenze, I-50019 Sesto Fiorentino,
Firenze, Italy  25INFN, Sezione di Roma, I-00185 Roma, Italy  26Université
catholique de Louvain, B-1348 Louvain-la-Neuve, Belgium  27Nikhef, Science
Park 105, 1098 XG Amsterdam, Netherlands  28Institute for Gravitational and
Subatomic Physics (GRASP), Utrecht University, Princetonplein 1, 3584 CC
Utrecht, Netherlands  29Université de Liège, B-4000 Liège, Belgium
30Università degli Studi di Milano-Bicocca, I-20126 Milano, Italy  31INFN,
Sezione di Milano-Bicocca, I-20126 Milano, Italy  32INAF, Osservatorio
Astronomico di Brera sede di Merate, I-23807 Merate, Lecco, Italy
33Dipartimento di Medicina, Chirurgia e Odontoiatria “Scuola Medica
Salernitana”, Università di Salerno, I-84081 Baronissi, Salerno, Italy
34Wigner RCP, RMKI, H-1121 Budapest, Konkoly Thege Miklós út 29-33, Hungary
35Università di Pisa, I-56127 Pisa, Italy  36Università di Perugia, I-06123
Perugia, Italy  37Università di Padova, Dipartimento di Fisica e Astronomia,
I-35131 Padova, Italy  38INFN, Sezione di Padova, I-35131 Padova, Italy
39Universiteit Gent, B-9000 Gent, Belgium  40Nicolaus Copernicus Astronomical
Center, Polish Academy of Sciences, 00-716, Warsaw, Poland  41Dipartimento di
Ingegneria, Università del Sannio, I-82100 Benevento, Italy  42Departamento de
Matemáticas, Universitat Autònoma de Barcelona, Edificio C Facultad de
Ciencias 08193 Bellaterra (Barcelona), Spain  43INFN, Sezione di Genova,
I-16146 Genova, Italy  44Vrije Universiteit Amsterdam, 1081 HV Amsterdam,
Netherlands  45Università di Trento, Dipartimento di Fisica, I-38123 Povo,
Trento, Italy  46INFN, Trento Institute for Fundamental Physics and
Applications, I-38123 Povo, Trento, Italy  47Dipartimento di Fisica “E.R.
Caianiello”, Università di Salerno, I-84084 Fisciano, Salerno, Italy  48INFN,
Sezione di Napoli, Gruppo Collegato di Salerno, Complesso Universitario di
Monte S. Angelo, I-80126 Napoli, Italy  49Università di Roma “La Sapienza”,
I-00185 Roma, Italy  50Univ Rennes, CNRS, Institut FOTON - UMR6082, F-3500
Rennes, France  51INFN, Laboratori Nazionali del Gran Sasso, I-67100 Assergi,
Italy  52Laboratoire Kastler Brossel, Sorbonne Université, CNRS, ENS-
Université PSL, Collège de France, F-75005 Paris, France  53Astronomical
Observatory Warsaw University, 00-478 Warsaw, Poland  54L2IT, Laboratoire des
2 Infinis - Toulouse, Université de Toulouse, CNRS/IN2P3, UPS, F-31062
Toulouse Cedex 9, France  55University of Portsmouth, Portsmouth, PO1 3FX,
United Kingdom  56Dipartimento di Fisica, Università degli Studi di Genova,
I-16146 Genova, Italy  57Università degli Studi di Sassari, I-07100 Sassari,
Italy  58INFN, Laboratori Nazionali del Sud, I-95125 Catania, Italy
59Università di Roma Tor Vergata, I-00133 Roma, Italy  60INFN, Sezione di Roma
Tor Vergata, I-00133 Roma, Italy  61Departamento de Astronomía y Astrofísica,
Universitat de València, E-46100 Burjassot, València, Spain  62Dipartimento di
Ingegneria Industriale (DIIN), Università di Salerno, I-84084 Fisciano,
Salerno, Italy  63Université Lyon, Université Claude Bernard Lyon 1, CNRS,
IP2I Lyon / IN2P3, UMR 5822, F-69622 Villeurbanne, France  64Inter-University
Centre for Astronomy and Astrophysics, Post Bag 4, Ganeshkhind, Pune 411 007,
India  65INAF, Osservatorio Astronomico di Padova, I-35122 Padova, Italy
66Université libre de Bruxelles, Avenue Franklin Roosevelt 50 - 1050
Bruxelles, Belgium  67Departamento de Matemáticas, Universitat de València,
E-46100 Burjassot, València, Spain  68Scuola Normale Superiore, Piazza dei
Cavalieri, 7 - 56126 Pisa, Italy  69Maastricht University, P.O. Box 616, 6200
MD Maastricht, Netherlands  70LIGO Laboratory, California Institute of
Technology, Pasadena, CA 91125, USA  71Université Lyon, Université Claude
Bernard Lyon 1, CNRS, Laboratoire des Matériaux Avancés (LMA), IP2I Lyon /
IN2P3, UMR 5822, F-69622 Villeurbanne, France  72Dipartimento di Scienze
Matematiche, Fisiche e Informatiche, Università di Parma, I-43124 Parma, Italy
73INFN, Sezione di Milano Bicocca, Gruppo Collegato di Parma, I-43124 Parma,
Italy  74Université de Strasbourg, CNRS, IPHC UMR 7178, F-67000 Strasbourg,
France  75Institute for Nuclear Research, Bem t’er 18/c, H-4026 Debrecen,
Hungary  76CNR-SPIN, c/o Università di Salerno, I-84084 Fisciano, Salerno,
Italy  77Scuola di Ingegneria, Università della Basilicata, I-85100 Potenza,
Italy  78Gravitational Wave Science Project, National Astronomical Observatory
of Japan (NAOJ), Mitaka City, Tokyo 181-8588, Japan  79Observatori Astronòmic,
Universitat de València, E-46980 Paterna, València, Spain  80Centro de Física
das Universidades do Minho e do Porto, Universidade do Minho, Campus de
Gualtar, PT-4710 - 057 Braga, Portugal  81Max Planck Institute for
Gravitational Physics (Albert Einstein Institute), D-14476 Potsdam, Germany
82INAF, Osservatorio Astronomico di Capodimonte, I-80131 Napoli, Italy
83Department of Physics, Aristotle University of Thessaloniki, University
Campus, 54124 Thessaloniki, Greece  84Universiteit Antwerpen, Prinsstraat 13,
2000 Antwerpen, Belgium  85University of Białystok, 15-424 Białystok, Poland
86Institute for High-Energy Physics, University of Amsterdam, Science Park
904, 1098 XH Amsterdam, Netherlands  87Institute of Mathematics, Polish
Academy of Sciences, 00656 Warsaw, Poland  88National Center for Nuclear
Research, 05-400 Świerk-Otwock, Poland  89Laboratoire Lagrange, Université
Côte d’Azur, Observatoire Côte d’Azur, CNRS, F-06304 Nice, France  90NAVIER,
École des Ponts, Univ Gustave Eiffel, CNRS, Marne-la-Vallée, France
91Università di Firenze, Sesto Fiorentino I-50019, Italy  92INFN, Sezione di
Roma Tre, I-00146 Roma, Italy  93ESPCI, CNRS, F-75005 Paris, France  94School
of Physics Science and Engineering, Tongji University, Shanghai 200092, China
95Dipartimento di Fisica, Università di Trieste, I-34127 Trieste, Italy
96Institut des Hautes Etudes Scientifiques, F-91440 Bures-sur-Yvette, France
97Consiglio Nazionale delle Ricerche - Istituto dei Sistemi Complessi,
Piazzale Aldo Moro 5, I-00185 Roma, Italy  98Museo Storico della Fisica e
Centro Studi e Ricerche “Enrico Fermi”, I-00184 Roma, Italy  99Dipartimento di
Matematica e Fisica, Università degli Studi Roma Tre, I-00146 Roma, Italy
100Università di Trento, Dipartimento di Matematica, I-38123 Povo, Trento,
Italy  101Instituto Galego de Física de Altas Enerxías, Universidade de
Santiago de Compostela, 15782, Santiago de Compostela, Spain  102Departamento
de Matemática da Universidade de Aveiro and Centre for Research and
Development in Mathematics and Applications, Campus de Santiago, 3810-183
Aveiro, Portugal  103INAF, Osservatorio Astrofisico di Arcetri, Largo E. Fermi
5, I-50125 Firenze, Italy  104Istituto di Astrofisica e Planetologia Spaziali
di Roma, Via del Fosso del Cavaliere, 100, 00133 Roma RM, Italy  105University
of Maryland, College Park, MD 20742, USA  106Dipartimento di Scienze Aziendali
- Management and Innovation Systems (DISA-MIS), Università di Salerno, I-84084
Fisciano, Salerno, Italy  107Van Swinderen Institute for Particle Physics and
Gravity, University of Groningen, Nijenborgh 4, 9747 AG Groningen, Netherlands
108Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussel, Belgium
109Eindhoven University of Technology, Postbus 513, 5600 MB Eindhoven,
Netherlands

###### Abstract

The Advanced Virgo detector has contributed with its data to the rapid growth
of the number of detected gravitational-wave (GW) signals in the past few
years, alongside the two Advanced LIGO instruments. First during the last
month of the Observation Run 2 (O2) in August 2017 (with, most notably, the
compact binary mergers GW170814 and GW170817), and then during the full
Observation Run 3 (O3): an 11-months data taking period, between April 2019
and March 2020, that led to the addition of about 80 events to the catalog of
transient GW sources maintained by LIGO, Virgo and now KAGRA. These
discoveries and the manifold exploitation of the detected waveforms require an
accurate characterization of the quality of the data, such as continuous study
and monitoring of the detector noise sources. These activities, collectively
named detector characterization and data quality or DetChar, span the whole
workflow of the Virgo data, from the instrument front-end hardware to the
final analyses. They are described in details in the following article, with a
focus on the results achieved by the Virgo DetChar group during the O3 run.
Concurrently, a companion article describes the tools that have been used by
the Virgo DetChar group to perform this work.

###### Contents

  1. 1 Introduction
  2. 2 The Advanced Virgo Detector
    1. 2.1 The path to the O3 run
    2. 2.2 The O3 configuration
    3. 2.3 Virgo data and DetChar products
  3. 3 The O3 run
    1. 3.1 Organisation
      1. 3.1.1 Data taking
      2. 3.1.2 Detector steering
      3. 3.1.3 DetChar organization and tools
      4. 3.1.4 On call duty service and rapid response team meetings
    2. 3.2 Performance
      1. 3.2.1 Noise Budget
      2. 3.2.2 Virgo O3 duty cycle
      3. 3.2.3 The Virgo O3 dataset
  4. 4 Real-time data quality
    1. 4.1 The Virgo O3 online data quality framework
      1. 4.1.1 State vector
      2. 4.1.2 Online CAT1 vetoes
      3. 4.1.3 SegOnline
    2. 4.2 Veto streams
  5. 5 Public alerts
    1. 5.1 Performance of the Virgo O3 DQR framework
    2. 5.2 O3 public alerts
      1. 5.2.1 Public alerts retracted because of an issue with Virgo data
      2. 5.2.2 Virgo contribution to O3 public alerts
  6. 6 Global data quality studies
    1. 6.1 Glitches and pipeline triggers
      1. 6.1.1 Glitch rates during the O3 run
      2. 6.1.2 Offline searches
    2. 6.2 Channel safety: channel (in)sensitivity to gravitational waves
    3. 6.3 Spectral noise
      1. 6.3.1 Combs
      2. 6.3.2 Wandering line around 83 Hz – 84 Hz
      3. 6.3.3 Spectral noise bump around 55 Hz
      4. 6.3.4 Spectral noise around the 50 Hz power line frequency
    4. 6.4 Offline data quality
      1. 6.4.1 Offline studies and checks
      2. 6.4.2 Event validation
  7. 7 Preparation of the O4 run
  8. Acknowledgments

##  1 Introduction

A century after being predicted by Albert Einstein in the framework of general
relativity, gw have been detected by a global network of ground-based
interferometric detectors [1]. The LIGO [2] and Virgo [3] collaborations, now
joined by the KAGRA [4] collaboration, have observed in the past seven years
dozens of gw signals coming from merging compact binary systems. Compact
binaries composed of two bh, two ns, or both kinds of compact object have now
all been observed. GW150914 [1], the first gw signal ever detected (at that
time by the two Advanced LIGO detectors only) was a binary bh merger. Two
years later, shortly after the adv detector had started operating, the LIGO-
Virgo 3-interferometer network detected the signal GW170817 [5], emitted by
the fusion of two ns and associated with counterparts in the entire
electromagnetic spectrum, leading to the birth of multi-messenger astronomy
with gw. More recently, LIGO, Virgo and KAGRA (in short “LVK”) have announced
the first detections of ns-bh mergers in data taken in January 2020 [6].

All these events add up in a gw Transient Catalog whose first four versions —
GWTC-1 [7], GWTC-2 [8], GWTC-2.1 [9] and GWTC-3 [10] — have been successively
released. Such catalogs allow scientists to analyze all detections globally:
to probe the populations of compact stars, estimate the merger rate of binary
systems, test general relativity in the strong-field regime, and perform
searches for counterparts using archival data from other observatories. The
reconstructed gw strain data — the so-called $h(t)$ streams — are regularly
released in chunks of several months on the gwosc website [11].

Producing these results requires a thorough characterization of the data
quality, a large part of which involves studying and monitoring the noise of
gw detectors. This activity, often referred to as detector characterization or
DetChar, is an expertise which has been constructed over many years, starting
with the initial detectors in the years 2000 [12, 13]. Analysis methods and
tools have been developed and implemented to characterize the Virgo data both
with low latency and offline. They cover a physics-driven chain that starts
from the raw data recorded by the instrument and extends all the way to the
final set of gw events and the related analyses. The results of DetChar
studies are used to improve the detector performances during the commissioning
periods and to maximize the sensitivity to gw signals during an Observation
Run, when good-quality data are recorded.

This article reports the work of the Virgo DetChar group over the past few
years. It will mainly focus on the activities carried out for the preparation
of the third LIGO-Virgo observation run O3, from April 2019 to March 2020 as
well as on the final results achieved after the run. The experience
accumulated in view of the future runs of the LVK network will also be
presented. These achievements stem from the developments made before and
during the O2 run (for Virgo: 25 days of data taking in August 2017) and those
will also be described here when appropriate.

Concurrently, a companion article [14] describes in details all the tools the
Virgo DetChar group has been relying on, in order to obtain the results
presented here.

This article is organized as follows. Section 2 provides an overview of the
adv detector configuration during the O3 run, preceded by a short summary of
the path that led to this data taking period. The same section also introduces
notions and concepts that will be extensively used in the rest of the article,
and defines a few related abbreviations. Then, section 3 summarizes the O3 run
from a Virgo perspective: how the data taking was organized, what the
performances of the detector and the final O3 dataset were. Section 4 presents
the Virgo online data quality framework built for the O3 run. Section 5 deals
with the software developed to vet signals candidate to be released as public
alerts to the astronomical community. Section 6 presents the main DetChar
analyses done on the O3 dataset to study noise transients, their impact on gw
searches, the noise spectrum, and the final validation of events. Finally,
section 7 provides some information about the ongoing preparation of the
future O4 run, that is currently scheduled to begin in March 2023. A list of
the main abbreviations used throughout the article is provided as well, for
reference.

##  2 The Advanced Virgo Detector

This section focuses on the Virgo detector during the O3 run. First, we
briefly review the main steps of the adv project up to the beginning of O3. In
particular, we emphasize its participation to the last four weeks of the O2
run in August 2017 that were rich of discoveries. Then, we summarize the
activities during the 1.5 year-long shutdown between O2 and O3 that allowed
the Virgo Collaboration to improve the instrument significantly. Finally, we
describe the detector configuration during O3 and present the main features of
the data it has collected.

###  2.1 The path to the O3 run

Virgo [15] is an interferometric detector of gw located at the European
Gravitational Observatory (EGO) in Cascina, Italy. The adv project [3] allowed
to upgrade the original instrument to a second-generation detector, similarly
to what LIGO has done with its two interferometers [2], located in Hanford
(WA, USA) and Livingston (LA, USA). The funding of adv was approved in
December 2009 by CNRS (France) and INFN (Italy), with an in-kind contribution
from Nikhef (The Netherlands). The decommissioning of the first-generation
Virgo detector started in Fall 2011, after the completion of the science run
VSR4 [16], pursued together with the GEO600 detector [17] (the Advanced LIGO
upgrade project had already started). The installation of the Advanced Virgo
equipment started mid-2012 and was completed in 2016. The upgraded
interferometer was robustly controlled in March 2017 and the next few months
were dedicated to commissioning activities: noise hunting and sensitivity
improvement. At the end of July, the detector was very stable and had a
sensitivity corresponding to a bns range222The bns range is the average
distance up to which the merger of a bns system can be detected. The average
is taken over the source location in the sky and the bns system orientation,
while a detection is defined as a signal-to-noise ratio of 8 or above of
${\sim}30$ Mpc, that is more than a factor two above the performance of the
Virgo+ detector during the VSR4 run.

Therefore, adv started taking data on August 1st, 2017, joining the second
Observing Run O2, which had started on November 30th, 2016 for the two LIGO
interferometers [18]. On August 14th, 2017, the adv detector made its first
detection of a gw. That event, labeled GW170814, was also recorded by the two
LIGO interferometers. It was the first ever triple detection of a binary black
hole coalescence, allowing an unprecedented accuracy in the localization of
the source in the sky [5]. A few days later, on August 17, the three
interferometers jointly detected, for the first time, a gw signal emitted by
the coalescence of two neutron stars [19]. This event, known as GW170817, was
accompanied by the almost simultaneous detection of a gamma-ray burst by the
Fermi Gamma-ray and Integral space telescopes [20]. The accuracy in the
localization of the gw source (approx. 30$\deg^{2}$) allowed to identify the
optical counterpart in the galaxy NGC4993 [21]. The O2 run ended on August
25th, 2017.

The LIGO-Virgo shutdown between O2 and the third Observation Run O3, lasted 19
months. On the Virgo side, it was divided into four periods:

  * •

A post-O2 commissioning phase, until early December 2017.
The goal was twofold: to make a series of measurements on the O2 detector
configuration that would have been too invasive during the run, and to perform
some tests to try to further improve the instrument.

  * •

Hardware upgrades until mid-March 2018. Four main projects were pursued:

    * –

The re-installation of the monolithic suspensions and various vacuum upgrades.
The steel wires, with which the adv arm cavity mirrors were suspended for the
O2 run, were replaced with quartz fibers. Monolithic suspensions, successfully
tested in the Virgo+ configuration [22, 23], was foreseen in the adv Technical
Design Report [24]. Yet, multiple breakages of fused silica fibers when
installed in vacuum were observed during Fall 2016, forcing the recourse of
steel wires to preserve the participation of Virgo to the O2 run. The fiber
breaking issue was eventually demonstrated to be caused by a spurious dust
contamination generated by some vacuum pumps [25]. Therefore, the Virgo vacuum
system was improved in order to avoid contamination with dust particles while
the suspension fibers were shielded.

    * –

A higher laser power.
The power of the laser injected into the interferometer was increased,
reducing the photon shot noise that is limiting the high-frequency
sensitivity: 10 W (19 W) were injected in Virgo during the O2 run (at the
beginning of the O3 run).

    * –

The installation of a squeezed light source.
This allows to further reduce the shot noise limit at high frequencies by
modifying the quantum properties of the light coming out of the interferometer
[26].

    * –

The test installation of an array of seismic sensors.
An in-depth characterization of the seismic noise field at the test mass
locations was performed in order to prepare for the subtraction of the
Newtonian noise contribution that may limit the low-frequency sensitivity in
the future [27].

  * •

A commissioning period, until Fall 2018, to improve the sensitivity and the
duty cycle of the detector.

  * •

Finally, the transition phase to the O3 run, that officially started on April
1st, 2019 at 15:00 UTC.

###  2.2 The O3 configuration

The adv detector has been designed to achieve a sensitivity about one order of
magnitude better compared to the initial Virgo detector, corresponding to an
increase in the detection rate by about three orders of magnitude. The adv
design choices were made on the basis of the outcome of the different research
and development activities carried out within the gw community and the
experience gained with Virgo, while also taking into account budget and
schedule constraints.

Figure 1: Schematics of the adv configuration during the O3 run (not to
scale), showing optics, photodiodes and quadrant photodiodes, such as the main
components of the global feedback system used to steer the detector. The
suspended optical benches introduced in the text are not represented here.
This figure is taken from [28].

The simplified optical schematic of adv during the O2 and O3 runs is shown in
figure 1. In the following, we briefly outline the different parts of the
detector layout and define the main abbreviations that are labeled on the
schematic or used later in the article. Further information about the O3
configuration and control system of the Virgo detector can be found in [28].

The Virgo power-stabilized infrared laser beam (PSL, wavelength: 1.064 $\mu$m)
is filtered at the interferometer input by a 144 m triangular cavity called
the imc; the two flat mirrors of the imc are located on the first suspended
injection bench (SIB1), that also hosts various optics for beam matching.
Then, the beam goes through the partially reflective pr mirror before being
split into two perpendicular beams at the bs mirror. The two 3 km-long arms
hosting Fabry-Perot cavities are called “North” and “West” as they are roughly
oriented along these geographical directions. The cavity mirrors closest
(furthest away) from the bs are called “input” (“end”) mirrors. So, following
these conventions, the test masses (the four mirrors forming the two 3-km long
Fabry-Perot cavities) are labeled ni, ne, wi and we, respectively. Both arms
end with a suspended terminal bench — called sneb or sweb — hosting a
photodiode (B7 or B8) receiving the cavity transmitted beam. After propagation
and storage in the kilometric cavities, the arm beams recombine on the bs and
the beam resulting from this interference goes to the interferometer output
port. As indicated in figure 1, the location of the foreseen sr mirror was
occupied by the first lens of the detection system during the O3 run (and
during O2 as well)333The installation of that additional mirror only took
place during the shutdown period that followed the end of O3.. The beam from
the frequency-independent squeezed light source enters the detector further
downstream along the path of the interferometer output beam. Finally, prior to
being detected on the B1 photodiode located on the suspended detection bench 2
(SDB2), the output port beam is filtered in sequence by two omc cavities, omc1
and omc2, located on the suspended detection bench 1 (SDB1).

A complex active feedback system, made of several automated control feedback
loops, is necessary to bring and maintain the detector at its global working
point. In particular, it aims at controlling the four main longitudinal dof of
the adv detector in its O2-O3 configuration are:

  * •

The mich, $l_{N}-l_{W}$, sets the destructive interference (“dark fringe”)
optimal condition.

  * •

The prcl, $l_{PR}+(l_{N}+l_{W})/2$, must be resonant.

  * •

The lengths of the kilometric Fabry-Perot cavities, $L_{N}$ and $L_{W}$, must
be resonant as well, or rather their average and difference that are more
physical:

    * –

The carm, $(L_{N}+L_{W})/2$, used as a length etalon by the ssfs to stabilize
further the frequency of the input laser.

    * –

The darm, $L_{N}-L_{W}$, the quantity sensitive to a passing gw.

This global control relies on radio-frequency sidebands for the carrier beam
that are generated by the eom located in between the laser source and the imc
on Figure 1. The 6, 8 and 56 MHz sidebands are used to control the
interferometer, while the 22 MHz one is used to control the injection system.

###  2.3 Virgo data and DetChar products

The gw strain data stream $h(t)$ reconstructed at the Virgo detector is
dominated by noise with, up-to-now, rare and weak gw signals. The noise
contributions can be roughly classified into two main categories:

  * •

Fundamental noises, that are inherent to the instrument and represent the
ultimate limit of its sensitivity. Their combination is usually Gaussian and
stationary, meaning that their properties do not change in time.

  * •

Various noise artifacts, whose origins are manifold (hardware components of
the detector, feedback control loops, interaction with the external
environment, etc.) and that represent potential issues, not only because they
may impact the running of the instrument but also — and above all — because
they show up in the background of searches for gw signals, thus limiting their
sensitivity. Noise transients, called glitches, can either look like real
signals or overlap in time with one, either impairing its detection or
confusing the inference of its source parameters. These glitches are monitored
and studied with time-frequency representations that are used to classify
their numerous signatures into families and separate them from real gw events.
In addition, long-lasting noise excesses, also called spectral noises, are
also seen around particular frequencies (power main frequency and its
harmonics, suspension resonating modes, etc.): the narrow ones, (nearly)
monochromatic, are called lines and the wider ones bumps. Both can manifest
themselves in several “flavours”. For instance, lines can exist individually,
but sometimes appear as combs, that is families of lines separated by a
constant frequency interval. They are typically due to processes with a strict
time periodicity, like electronic clock signals. Bumps may have some specific
structure, depending on the source. Both lines and bumps can exhibit
structures symmetric around their main frequency, called sidebands, that are
due to non-linear interactions among different disturbances. Moreover,
spectral noises can be persistent across a full run, or only be present in a
portion of it.

Both the glitch rate in a particular frequency band and the properties
(amplitude, peak frequency and bandwidth) of spectral noises can vary in time,
to reflect changes occurring at the level of the detector or its environment.

To allow investigating these variations, hundreds of auxiliary channels are
acquired by the Virgo daq, providing both a detailed status of the detector
control systems and a complete monitoring of the local environment [29, 30].
Integer GPS ranges used to flag data with common properties (data quality
level, particular detector condition, etc.) are called segments in the
following.

The Virgo gw strain data $h(t)$ and the many associated auxiliary channels are
analysed by a wide set of DetChar tools described in details in Reference
[14]. As an example, figure 2 describes the joint application of various
DetChar analysis and monitoring tools to the study of transient noise. This
flowchart focuses specifically on how these tools are used and complement each
other to investigate transient noise. Omicron is the main tool to identify
glitches in all the relevant daq channels. Those glitch triggers are stored on
disk and mined by the upv tool, to look for coincidences between them,
allowing to assign confidently a terrestrial origin to a fraction of these
triggers. VetoPerf monitors the performance of these tools to find an optimum
balance between the fraction of glitches flagged as non-astrophysical and the
amount of data removed by these associations. Other tools like BRMSMon look
for patterns in the data that are known to be due to noise. All these inputs
are used to trigger further noise investigations and are gathered to allow a
global assessment of the quality of the data. The hypothesis of stationary
(and Gaussian) data are also tested around all gw candidates as they are basic
assumptions for the algorithms searching for gw in the data, whether they are
run in real-time or offline. Parallel to this dataflow, dedicated monitoring
tools like the dms and the vim continuously provide information about the
status of all the Virgo components, from the hardware blocks to the online
software processes.

Figure 2: Generic workflow of transient noise studies in Virgo, using the full
set of DetChar and monitoring tools described in Reference [14].

##  3 The O3 run

The joint LIGO-Virgo Observing Run 3 O3, has been divided into two consecutive
sub-data-taking periods, separated by a one-month commissioning break in
October 2019:

  * •

O3a: from April 1st, 2019 at 15:00 UTC (GPS: 1238166018), to October 1st, 2019
at 15:00 UTC (GPS: 1253977218).

  * •

O3b: from November 1st, 2019 at 15:00 UTC (GPS: 1256655618), to March 27th,
2020 at 17:00 UTC (GPS: 1269363618).

All three detectors have participated to the whole run. The O3b end date has
been anticipated by about a month, due to the worldwide Covid-19 pandemic.

This section presents the LIGO-Virgo O3 run, seen from a Virgo perspective.
First, we describe the main activities into which the data taking was divided,
before summarizing how the detector was steered from the EGO control room.
Then, we focus on actions taken to maximize the amount of data collected and
to ensure their good quality. In particular, we highlight the main DetChar
activities during O3, explaining how they fit and complement each other,
following the flow of data from the detector to the final analyses. Key to
achieve this level of performance and to maintain it over almost a year, were
the 24/7 on-call duty service and the rrt: both will be briefly described as
well.

Then, we review the performance of the Virgo detector during O3, mainly from
the point of view of the duty cycle. A high duty cycle requires not only a
stable and robust detector against external disturbances (see [30] for a
comprehensive study of that topic) but also a quick and reliable procedure to
bring the instrument to its working point, starting from an uncontrolled
global state. The main statistics of the Virgo O3 global control acquisition
are thus provided, before studying the actual duty cycle. We also present the
evolution of the adv detector sensitivity, from the O2 run to the end of O3.

This section ends with a brief overview of the final Virgo O3 dataset,
describing how it was constructed offline, building upon the preliminary
dataset established by the live monitoring and data quality checks.

###  3.1 Organisation

####  3.1.1 Data taking

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 hr 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 [31], to monitor its stability over time and to test new,
complimentary calibration methods, like the use of a Newtonian calibration
system [32] in addition to the usual photon calibrators [33].

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.

####  3.1.2 Detector steering

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 [34, 35]
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
[26]. The scheme adopted, depicted in figure 3, strictly follows a top-down
approach, with the lower-level nodes being automatically managed by higher-
level ones.

Figure 3: Metatron nodes hierarchy used during the O3 run.

The suspension nodes (violet background in the graph) are tasked to
align/misalign the Virgo optics, each of them is managed by the most
appropriate control node (dark blue 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 omc, which are controlled in sequence in the final steps of the
nominal control acquisition procedure (Metatron node Output Mode Cleaner, pale
green background);

  * •

The detection system at the interferometer output port (Metatron node
Detection Safety, pale green background);

  * •

The frequency-independent squeezing system (Metatron node Squeezing System,
light 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 (magenta 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 (dark green background). Finally, the
Interferometer Events node (dark 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 Reference [14].

####  3.1.3 DetChar organization and tools

Figure 4 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.

Figure 4: Dataflow from the interferometers (labeled "IFOs" on the left) to
the offline validation of gw candidates and the completion of the final
dataset (right). It focuses on the generation and the vetting of the public
alerts that are a key product of the LIGO-Virgo observing runs. It shows the
three main timescales at which the Virgo DetChar group operates: online, near
real-time and offline (see text for details).

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 attend 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).

####  3.1.4 On call duty service and rapid response team meetings

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.

###  3.2 Performance

####  3.2.1 Noise Budget

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 [36].

The adv noise budget is based on the SimulinkNb [37] software package. It
includes a complete model of the four main longitudinal dof of the
interferometer (darm, carm, mich, prcl), with the interferometer optical
response simulated using Optickle [38]. The mirror suspension 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 [39]). 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 dof.

This model has been verified to match the measured open loop transfer
functions of the four modeled dof, 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 5.

Figure 5: Snapshot of the adv O3 noise budget generated at a time of near best
sensitivity of the detector (February 8th, 2020). The different noise sources
shown are described in the text. The green line (bns range: 66 Mpc) represents
the sum of these noises: it can be compared to the measured total noise shown
in black (bns range: 59 Mpc).

The noises are summed in log-spaced frequency bins, which allows resolving
narrow lines at low frequencies and a precise representation of broadband
noise at high frequencies. The noises taken into account are the following:

ASC

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

DAC

– 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.

Dark.

This is the electronic and dark noise of the photodiodes used in the four
longitudinal dof control. The noise is measured by closing shutters of each
photodiode, and the noise coupling is modeled.

Demodulation.

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.

ENV

– 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 3-axis magnetometers, located in the experimental
buildings near the interferometer components (see [29, 30] for details). Their
couplings are measured by broadband and sweeping sine noise injections.
Scattered light is measured in two ways: i) using the signal from auxiliary
photodiodes which have a linear coupling that is modeled; ii) using position
sensors of suspended benches that couple in a non-linear way modeled with a
measured scaling factor [41].

LSC

– Length Sensing and Control. This represents the control noise of four dof:
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.

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.

ssfs.

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.

Seismic-Thermal.

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.

“flat noise”.

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 [42, 43].

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.

More in details, 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.

####  3.2.2 Virgo O3 duty cycle

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.

The median duration of a successful global control acquisition attempt is 18
min: about 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 omc 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 about 13 min.

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 minutes
| Distribution of this time |
| Reaching the detector working point |  ${\sim}$30%
| Controlling the two omc |  ${\sim}50$%
| Acquiring the lowest noise configuration |  ${\sim}20$%
Global control acquisition sequence
| Median number of attempts | 2
| Median duration | 25 min
Table 2: Summary of the O3 data taking performance of the Virgo detector. The last three rows of the table provide duty cycles for different configurations of the 3-detector LIGO-Virgo global network: the fraction of the time during which at least one the three instruments is taking data, at least two are and finally all three are. |  | O3a | O3b | O3
---|---|---|---|---
Virgo global control segments | Mean [hr] | 6.1 | 6.4 | 6.3
Median [hr] | 2.7 | 1.8 | 2.2
Virgo Science segments | Mean [hr] | 5.0 | 4.0 | 4.5
Median [hr] | 2.6 | 1.4 | 1.9
Duty cycles | Virgo [%] | 76.3 | 75.6 | 76.0
Network — at least 1/3 [%] | 96.8 | 96.6 | 96.7
Network — at least 2/3 [%] | 81.9 | 85.4 | 83.4
Network — 3/3 [%] | 44.5 | 51.0 | 47.4

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 [44, 45]. 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:
${\sim}$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 6: Breakdown of the time spent in different modes by the Virgo detector
during the O3 run (larger, top-middle pie chart) and separately during the O3a
and O3b sub-runs (pie charts at the bottom). The “Locking” mode corresponds to
periods when the control of the detector is being acquired. The regular
maintenance and calibration periods have been described in section 3.1.1.
Finally, the Any other state category includes all the other situations
encountered during the whole run: troubleshooting periods, various kinds of
tuning, etc. These results exclude the 1 month-long commissioning break that
took place in October 2019, in between the O3a and O3b sub-runs. In each pie
chart, the modes are sorted by decreasing percentage.

Figure 6 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 about 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).

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.

Figure 7: Comparison between four sensitivity curves of the adv detector:
during O2 (green trace), at the beginning of O3a (purple), at the beginning of
O3b (red) and at the end of O3b (blue). The caption provides the corresponding
estimated bns ranges.

To conclude this overview, figure 7 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 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.

####  3.2.3 The Virgo O3 dataset

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 gw 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 about three
weeks of data at the end of O3a were reprocessed offline to increase the
sensitivity by a few percents [31]. 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 [30]) by a more robust one, the so-called “earthquake (EQ)-mode”
[31]. 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 North Input 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 about 20-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?
For instance, it was decided to remove offline the last few seconds of a
segment preceding a control loss of the detector, as the $h(t)$ data could be
corrupted (see section 6.4.1 for details).

  * •

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
about 0.2% of the Virgo O3 Science dataset have been CAT1-vetoed.

To conclude this overview of the Virgo performance during the O3 run, figure 8
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.

Figure 8: Distributions of the Virgo bns range during O3 for the online (red
histogram and trace) and offline (blue) dataset. The top (bottom) plot
compares the histograms (cumulative distributions).

##  4 Real-time data quality

Online data quality was a key challenge to tackle for DetChar during the O3
run. The availability and the reliability of that information, supporting the
data taking, had to be high in order to allow the real-time transient gw
searches to make the best use of the Virgo data. Significant candidates
identified by those analyses — usually found in data from at least two of the
three detectors of the global network, but sometimes identified in a single
instrument — would then lead to public alerts, used by telescopes worldwide to
search for counterparts of potential gw signals.

In this section, we first describe the different blocks of the Virgo online
data quality architecture, in use at EGO during the O3 run. This framework
matches the dataflow shown in figure 4 and is complemented by the vetting of
the most significant triggers identified in low latency, described in the
following section 5.

Real-time information about the detector status was combined with fast data
quality estimators to produce a single integer channel sampled at 1 Hz, the
Virgo state vector. That state vector was shipped alongside the gw strain
channel $h(t)$ to computing centers where data were analysed in real time. Its
integer value was constructed by gathering several binary information
(schematically: good vs. bad) encoded as bits; that bit pattern would later be
decoded by the analysis frameworks to discard any bad data. Parallel to this
data analysis stream, this information — the detector status plus the real-
time assessment of the data quality — was automatically uploaded by a
dedicated online process (called SegOnline) to the dqsegdb [14].

Finally, we present the experience gained during O3 with additional data-
quality inputs, called veto streams whose aim is to help searches to reduce
their false alarm rate by identifying triggers that are very unlikely to be of
astrophysical origin.

###  4.1 The Virgo O3 online data quality framework

The online data quality architecture is designed to deliver data quality
products to online transient searches. It is based on a set of servers
connected to the daq and providing relevant information about the quality of
the data (the whole raw data, plus the reconstructed $h(t)$ stream). In the
following, the main elements of this architecture, summarized in figure 9, are
presented.

Figure 9: Online architecture to produce data quality products during the O3
run. The status of the interferometer is monitored by a dedicated Metatron
server (see section 3.1.2). Data quality flags are generated by dedicated
servers described in [14]: the dms, the BRMSMon process (environment), the
VetoMerger process (large deviations in auxiliary signals), the Hrec process
($h(t)$ reconstruction), and the Omicron algorithm (glitches in $h(t)$ and
auxiliary signals). Data quality segments are then generated by the SegOnline
process and saved in the LIGO-Virgo segment database, while the online $h(t)$
stream, the state vector and the veto channels are sent to online data
analysis pipelines through the V1FromOnline server.

####  4.1.1 State vector

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.

Table 3: Definition of the bits of the Virgo state vector during the O3 run (see text for details). Bit number | Active when
---|---
0 |  $h(t)$ successfully computed.
1-2 | Science mode enabled.
3 |  $h(t)$ successfully produced by the calibration pipeline.
4-7 | Bits irrelevant for the present discussion:
either redundant with other bits or unused during O3.
8 | No DetChar-related hardware injection
(see section 6.2 for more details).
9 | No continuous wave hardware injection
(the only type of non calibration-related injections
performed for a short period during O3, while taking nominal data).
10 | Online data quality is good (no CAT1-type veto).
11 | Virgo interferometer fully controlled,
with a nominal working point or close to it.
12-15 | Not used.

####  4.1.2 Online CAT1 vetoes

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 channel444A more correct way to monitor the glitch
rate would have been to scan $h(t)$, but the latency added by that Omicron
check would have delayed too much the gw strain channel for online processing.
The offline equivalent version of that check did use $h(t)$, as latency was
not an issue anymore in that case..

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.

####  4.1.3 SegOnline

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 [14].

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 be then used by any
analysis, or can be viewed and downloaded through a dedicated web interface
[46].

###  4.2 Veto streams

Low-latency transient searches are limited by glitches in the $h(t)$ data.
Each search pipeline is sensitive to specific families of glitches. The online
data quality architecture is designed to deliver a channel to flag glitches
relevant to a given low-latency pipeline. These channels are called veto
streams. A veto stream is a time series which can only take two values: 0
means good quality and 1 bad quality. A veto stream is generated by the
VetoMerger process which combines information from many online data quality
processes, carefully selected to target the glitches limiting the search of
interest [14].

Some Omicron processes [14] are configured to select triggers detected in
auxiliary channels with a signal-to-noise ratio above a threshold tuned with
the upv algorithm [14]. These triggers are known to witness glitches in the
$h(t)$ channel. When this is the case, the veto channel is set to 1.
VetoMerger also ingests the data quality flags generated by BRMSMon [14] to
veto environmental disturbances.

In O3, the veto stream system was experimented as an input to one of the low-
latency searches for compact binary mergers, PyCBC Live [47, 48]. The veto
stream, named DQ_VETO_PYCBC, combined two elements: a veto channel delivered
by Omicron to target scattered-light glitches, and a data quality flag
produced by BRMSMon to tag occasional glitches associated to lightning
strikes. A conservative approach was adopted to tune the vetoes: their
thresholds were set at high values to reliably flag really limiting glitches,
while keeping the rejected time low. As a result, only 0.05% of the O3 Science
time was flagged by the DQ_VETO_PYCBC veto stream. PyCBC Live used the veto
stream to simply prevent the generation of a candidate event from Virgo data,
or remove Virgo’s contribution from a LIGO-Virgo candidate, during periods of
active veto. In future runs, the veto streams may be integrated in a more
general framework based on auxiliary channels to discard or down-weight
transient noise events.

The effect of the veto streams has also been evaluated on the PyCBC offline
analysis, using Virgo single-detector triggers generated by the broad-space
PyCBC search [49] during the period from April 1st to May 11th, 2019. The
triggers used for this study are ranked by the reweighted snr, the signal-to-
noise ratio returned by the matched filtering technique [50, 51], weighted by
the result of $\chi^{2}$ tests that quantify how well the time-frequency
distribution of power observed in the data is consistent with the one expected
from the matching template. For practical reasons, only triggers with
reweighted snr higher than 6 are considered. After this selection, the sample
is composed of roughly 2.5 105 triggers. To evaluate the impact of the vetoes
on the offline search, triggers with a merger time belonging to a vetoed
segment are removed. The study is performed separately for vetoes targeting
scattered-light glitches and glitches from lightning. The fraction of vetoed
triggers is shown by the red points in figure 10, and in both cases is found
to be of the order of $10^{-4}$, mainly affecting low reweighted snr.

Figure 10: Cumulative fraction of vetoed PyCBC triggers with reweighted snr
higher than a given threshold, as a function of the threshold value. The grey
band shows the envelope of the fraction of rejected triggers from 1000 time-
shifted trials (covering from the minimum to the maximum obtained value),
while the red points show the results obtained using the unshifted veto
segments. The fractions are relative to the overall number of triggers
generated by the offline PyCBC broad-space search. The left plot considers
vetoes targeting scattered-light glitches, and the right plot considers vetoes
associated with glitches from lightning.

The statistical significance of the impact of the vetoes on the offline PyCBC
triggers is assessed by performing a time-shifted analysis, and using it to
calculate the probability that the fraction of vetoed triggers obtained from
the unshifted analysis corresponds to triggers that have no correlation with
the veto segments. To this end, we shift the veto segments by a constant time
offset and recompute the fraction of vetoed triggers, obtaining a “null
sample” that we can compare to the fraction obtained using the unshifted
segments. Note that the null fraction is rescaled to account for the overlap
between the Science mode segments and the time-shifted veto segments. We
construct 1000 of such null samples by repeating the time-shifted analysis
with time offsets covering the range of $[-50000,+50000]$ s in steps of 100 s.
The spread (i.e. the range between the minimum and the maximum value) of the
obtained fractions of rejected triggers is shown in gray in figure 10. At a
reweighted-snr threshold of 6, the unshifted fraction is higher than any time-
shifted fraction, for both scattered-light (left plot) and lightning (right
plot) vetoes. We conclude that the probability for the observed effect of the
vetoes on the PyCBC offline triggers to be a statistical fluctuation is less
than $10^{-3}$. For higher reweighted-snr thresholds of 8.5 (10.5), this
probability is $2\times 10^{-3}$ ($2\times 10^{-2}$) for vetoes targeting
scattered-light glitches, and less than $10^{-3}$ ($6\times 10^{-3}$) for
vetoes associated with lightning glitches. It does therefore appear that
scattered light and lightning strikes are correlated with a small population
of PyCBC triggers, and that the veto streams can in principle be used to
remove or down-weight these triggers.

##  5 Public alerts

As demonstrated with the extraordinary GW170817 [5] event from the O2 run,
public alerts sent by the LIGO-Virgo network are key deliverables targeting
the astronomy community. Yet, how successful these are depends on the accuracy
of the information provided, and of the latency at which they are delivered.
For O3, the main contribution of the DetChar group to this effort has been the
design and the implementation of the dqr framework. A dqr is a set of data
quality checks, automatically triggered by the finding of a new gw candidate.
Its output allowed the rrt team to vet the associated data in a timely way.
Moreover, its usage extended way beyond the data taking period, as it was the
main tool used to assess the data quality of all gw candidates identified by
analyses, in some cases with a latency longer than a year (compared to when
the corresponding data were acquired).

The performance of the Virgo O3 dqr is described below, before summarizing how
Virgo contributed to the LIGO-Virgo public alerts during the O3 run. The dqr
implementation can be found in [14].

###  5.1 Performance of the Virgo O3 DQR framework

This section briefly summarizes the performance of the Virgo dqr, via a
statistical analysis using data from O3b that correspond to the final, most
complete, version of that framework during the O3 run. As time distributions
can include outliers due to occasional technical problems impacting the dqr
dataflow somewhere along its way, from the gracedb [14] to the EGO HTCondor
farm and back, the results presented in the following two tables include the
$50^{\rm th}$ and $95^{\rm th}$ percentiles in addition to the mean values.

Table 4 provides the measured latencies for the processing steps that occur
upstream of the dqr with the following meaning:

  * •

The first line is the difference between the time when the trigger is recorded
in gracedb and the time when the corresponding data were acquired.

  * •

The second measures the time needed for gracedb to notify the lvalert and to
have this message trigger the Virgo dqr framework upon reception.

  * •

The third reports the time needed to create and configure a new dqr instance,
until it is ready for processing. One should note that this duration includes
a 300 s wait time, imposed in order to allow gracedb to receive, process and
gather all triggers found by the different online searches that analyse strain
data in parallel and independently. The assumption is that, after these 5 min,
the low-latency information available in gracedb should be optimal and stable
in the vast majority of cases. Therefore, the actual dqr configuration phase
only takes a few tens of seconds: the needed data are located in the low-
latency streams just made available by the daq and more than 30 scripts (each
corresponding to a data quality check) are generated one after the other.

  * •

Finally, the last reported duration accounts for the time needed to start
processing the dqr on the EGO HTCondor farm. This depends on the occupancy of
the farm and of the EGO internal network performance.

Table 4: Summary of the performance of the low-latency with Virgo dqr dataflow during O3b, from the GPS time of a trigger to the start of the Virgo dqr on the EGO HTCondor farm: see text for details. Operation | Time taken [s]
---|---
Median | Mean |  $95^{\rm th}$ percentile
Data acquired $\to$ Candidate on gracedb | 52 | 166 | 331
Candidate on gracedb $\to$ lvalert trigger | 4 | 4 | 11
lvalert trigger $\to$ Virgo dqr configured | 331 | 339 | 383
Virgo dqr configured $\to$ Virgo dqr started | 8 | 10 | 21

We can see that the mean time elapsed between the recording of the data by the
different detectors and the creation of a new record in gracedb is under 3
min. The median time is even under 1 min while the tail of the time
distribution extends beyond 5 min. This includes the reconstruction of the gw
strain channels, the transfer of these data alongside the associated online
data quality information to computing centers, the processing of these data by
real-time gw searches, the automated analysis of the results and the final
transfer of trigger information to gracedb where it is made centrally
available. Then, the new alert is received at EGO a few seconds later,
triggering the creation and the configuration of a new dqr instance. Removing
the compulsory wait time of 300 s, the dqr configuration takes a few tens of
seconds only. Finally, about 10 additional seconds are needed on average to
have the first dqr jobs processed on the EGO HTCondor farm.

Table 5 summarizes the performance of the Virgo O3 dqr framework in terms of
running time. Each row corresponds to a category of checks. The quoted
durations increase from one row to the next, as each new set of checks
includes the previous ones.

The quick checks whose outputs are mandatory to vet a trigger take about 6 min
to be all available, with a few minutes spread. Adding information about the
Omicron triggers around the candidate takes about 10 more minutes. During O3,
this latency was dominated by the fact that Omicron triggers were computed in
real time and stored internally by the online server: they were only written
to disk every 600 s, in order to allow the framework to cope with the incoming
data flow. Work will be done prior to O4 to optimize this latency and to make
the dqr aware of when the needed data have been written to disk, so that their
processing can start immediately after. Omicron-scanning all the available
channels (more than 2000 in total, with the vast majority of them sampled at
10 kHz) around the trigger time requires 15-20 additional minutes. Finally,
the full dqr took from 1.5 to 2 h to complete. The longest checks were bruco
[14] and upv, plus the scan of all online logfiles described above.

Table 5: Summary performance of the Virgo dqr processing during the last $\sim$100 days of the O3b run. The quoted durations include the time to upload dqr check results back to gracedb that usually takes from $\sim$5 to $\sim$20 s. Operation | Time from dqr start [s]
---|---
Median | Mean |  $95^{th}$ percentile
Quick key checks | 374 | 383 | 619
Adding Omicron trigger distributions | 868 | 816 | 935
Adding full Omicron scans | 1740 | 2159 | 4690
End | 5185 | 4954 | 6330

Another key figure of merit of the dqr framework is the number of (software)
check failures per dqr instance. Table 6 shows the results of a statistical
analysis based on the subset of the dqr that were automatically processed in
real time during O3b because the candidate false-alarm rate was below the
1/day threshold. Only 13% (2%) of the dqr had 1 (2) failed checks. No
exhaustive analysis of these failures has been performed, as most of these dqr
were never checked by hand because the associated trigger was not significant
enough. The two main causes of problems were, however, incomplete handling of
edge-cases with the input data and actual bugs in processing algorithms. These
issues did not affect the rapid vetting of any public alert during O3, and
this framework worked smoothly as well for the validation of the offline
events found later by the archival gw searches. Both issues are being
addressed as part of the upgrade of the dqr framework for the O4 run.

Table 6: Percentages of the O3b Virgo dqr with 0, 1 and 2 unsuccessful checks respectively. Number of unsuccessful checks | 0 | 1 | 2
---|---|---|---
Percentage of O3b automatically processed dqr | 85% | 13% | 2%

###  5.2 O3 public alerts

####  5.2.1 Public alerts retracted because of an issue with Virgo data

Figure 11: Number of Virgo dqr automatically processed per day during the O3b
run. The peak of 31 entries corresponds to November 24th, 2019 when there was
a transient problem with the Virgo $h(t)$ reconstruction: that generated
several online triggers, finally including S191124be that passed the public
alert threshold and was promptly retracted.

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 [52] was due to a problem in the noise removal procedure included in
the online reconstruction of the $h(t)$ gw stream [31]. 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 11), 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 [53] 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 12) showed evidence of scattering
light noise at low frequency. The unusually-long delay to send out the
retraction circular (about 80 min) was partly due to an issue with the Gamma-
ray Coordinates Network (GCN) broker connection.

Figure 12: Omicron spectrogram around the time of the S200303ba trigger. The
search template time-frequency track (solid line) overlaps with low-frequency
scattering-light glitches (yellow color) caused by bad weather.

####  5.2.2 Virgo contribution to O3 public alerts

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_000836 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_060421 in GWTC-3 [10].

##  6 Global data quality studies

This final section presents examples of global data quality studies made
during or after the O3 run: noise transients, spectral analyses,
classification of auxiliary channels based on their potential sensitivity to
gw signals and offline data quality studies leading to the final Virgo O3
dataset.

###  6.1 Glitches and pipeline triggers

####  6.1.1 Glitch rates during the O3 run

Figure 13: Virgo glitch rate, using Omicron triggers, for the final O3 dataset
(Science segments that have not been CAT1-vetoed). The blue dots are averages
over one hour while the red curve shows the corresponding weekly moving
average. The gap in between O3a and O3b corresponds to the 1-month
commissioning break.

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 13 displays the evolution of
the glitch rate during the O3 run. Figure 14 provides more details by breaking
the global Omicron glitch rate into snr (top plot) and peak frequencies
(bottom plot). In these plots, the glitch rates have been smoothed by
computing their weekly moving average to ease the reading.

Figure 14: Glitch rates (weekly moving average) using Omicron triggers during
the O3 run for Virgo. The gap in between O3a and O3b corresponds to the
1-month commissioning break. The top plot breaks the glitch rate into snr
ranges, while the bottom one categorizes it in terms of frequency ranges for
the glitch peak frequency. The choice of the frequency bands has been mainly
driven by the need to isolate some frequencies: 50 Hz (mains fundamental power
in Europe), 150 Hz (second harmonics of the mains) and the range around 450 Hz
(another harmonics of the mains, plus the range in which the frequencies of
the suspension wire violin modes are located).

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 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 [30]
for more details). The weather was actually very quiet in January 2020 and the
associated drop in glitch rate is quite strong.

####  6.1.2 Offline searches

Non-stationary instrumental noise can potentially impact searches for
transient gw, 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 a sensitive way to
identify problematic operating conditions of gw detectors.

In this section, we focus on candidates produced from Virgo O3 final dataset
by one of the pipelines used by the LIGO and Virgo collaborations to detect
compact binary mergers, namely PyCBC [49]. This analysis performs a broad-
space search for compact binary mergers involving neutron stars, black holes,
or a mix of 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 combination of its matched-filter snr and various statistics
designed to reject candidates produced by non-stationary noise.

Figure 15 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 a ranking statistic which combines the snr of the candidate and
two $\chi^{2}$ signal-based discriminators [54, 55] (right plot). The vertical
axis shows the rate of candidates that are ranked higher than the value in the
horizontal axis555At this early stage of the PyCBC analysis, candidates with
merger times within fractions of a second from each other can be highly
correlated, because a given transient in the data typically “rings off”
several templates with high overlaps between each other. The estimated rate of
candidates is biased if this correlation is not accounted for. We do so by
means of a clustering procedure: a given candidate is ignored if a higher-
ranked one exists within a time window of $\pm$5 s..

Figure 15: Rate of compact binary merger candidates produced from Virgo O3
data using a broad-space search based on PyCBC. Left: rate as a function of
the matched-filter snr. Right: rate as a function of the reweighted snr, which
combines the snr and two $\chi^{2}$ discriminators. Red, blue and green curves
correspond respectively to templates lasting less than 0.6 s, 0.6—4 s, and
more than 4 s. Curves of the same color represent different chunks of Virgo
data, each lasting $\sim$5 days. The black curves show the rate over the
entire run and search space. They extend to lower rates than the individual
chunks due to the much longer duration of the entire run.

If the Virgo noise had been Gaussian and stationary throughout O3, we would
expect the rate to decrease exponentially for larger and larger values of the
ranking, and be independent on the template parameters and particular chunks
of data (subsets of the full O3 dataset, each lasting about five days and
analysed as a single block o 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 snr as high as
100, while astrophysical signals are typically expected to have snr between
${\sim}$5 and ${\sim}$10\. After the application of the $\chi^{2}$
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 15), which are more robust to instrumental
artifacts due to their particular time-frequency signature. However, 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
[56].

A detailed inspection of the candidates in the tails of these plots shows that
the highest snr can be attributed to a single segment of ${\sim}$15 min of
data on November 11th, 2019. These data contain narrow-band, loud and rapidly-
varying excesses of power (coming from transient problems with the noise
subtraction algorithms used to reconstruct the gw strain channel $h(t)$) which
temporarily affected the data conditioning algorithm used by PyCBC. Most of
these high-snr triggers were removed by the $\chi^{2}$ discriminators,
effectively vetoing the entire problematic segment. On the other hand, most
top candidates by $\chi^{2}$-weighted snr are clearly associated with
scattered-light glitches. We conclude that the $\chi^{2}$ discriminators used
by PyCBC, which were designed for and tuned on LIGO data, are also reasonably
effective in Virgo, and should be further developed to more effectively reduce
the impact of scattered light.

###  6.2 Channel safety: channel (in)sensitivity to gravitational waves

Many Virgo data quality analyses aim at ensuring that gw candidates are of
astrophysical origin and not caused by terrestrial noises. Typically, searches
for correlations between auxiliary channels (monitoring the environment, the
detector status, the accuracy of its control, etc.) and the $h(t)$ strain
channel are run to produce vetoes, that reject times when such correlations
are identified. This strategy can lead to a loss of interesting signals if any
of the auxiliary channels is sensitive to gw, which means that it picks up
disturbances induced in the detector by these. Hence, a good knowledge of the
couplings of auxiliary channels to $h(t)$ is essential. To gather such
information, a statistical analysis of all auxiliary channels is performed,
using the approach proposed in [57].

This method relies on hardware injections that mimic the effects of gw on the
detector, by moving in a deterministic way one of its test masses. They are
used to workaround the fact that the transfer functions between $h(t)$ and
most auxiliary channels are not well-known, nor understood. The injected
signals are 0.6 s long sinusoidal Gaussian functions of various frequencies
(between 19 Hz and 811 Hz) and amplitudes (snr between ${\sim}$20 and
${\sim}$500). The frequencies injected are chosen to scan the entire detection
band while avoiding any known resonant frequency (like violin modes). Each
waveform is injected three times, spaced by 15 s.

This safety analysis assumes that glitches in a given auxiliary channel are
distributed according to a stationary Poisson process, whose rate and
$p$-value time series are measured using stretches of data during which no
hardware injection is performed. These $p$-value time series are used to
define a classification threshold. Then, a null test is applied to see whether
the $p$-value distribution changes significantly in the presence of hardware
injections. Auxiliary channels that exhibit anomalously small $p$-values (i.e.
lower than the defined threshold) are classified as unsafe, meaning that they
are likely to mirror excess power coming from the strain channel. The other
channels, called safe, are the only ones used to produce vetoes.

Virgo DetChar hardware injections were organized at short notice, in the few
days between the anticipated end of the O3b run and the moment when the
detector had to be switched off because of the pandemic. Among the
${\sim}$2500 auxiliary channels analysed, 69 are found to be unsafe. The
safety analysis of these data allowed to validate the existing sets of safe
and unsafe channels determined by a previous study. These results matched as
well the a priori safe status one could infer based on the definition of the
auxiliary channels, i.e. what quantity they measure and how the measurement is
done.

###  6.3 Spectral noise

The term spectral noise, introduced in section 2.3, identifies the class of
detector disturbances appearing as an persistent excess in the noise power
spectrum estimation of the data.

Spectral noise has a negative impact especially on searches for persistent gw,
which aim at detecting astrophysical or cosmological signals mainly through
the identification of their spectral features. Two typical signal categories
of persistent waves are cw [58] and a sgwb [59]. The signals are very weak
with respect to the already detected coalescing binary emission. Due to their
persistent nature, they can be looked for in the frequency domain where the
accumulated power over long observation times can show up at a detectable
level, after applying effective signal processing techniques. Moreover, some
spectral features of the signals can help in discriminating them from detector
noise. On the other hand, spectral noise can mask signals, or produce false
candidates, in both cases reducing the search sensitivity.

Searches for persistent signals are typically run off-line, once long
stretches of data have been collected. An early identification of spectral
disturbances and of their instrumental source would allow to remove, or at
least reduce, the source of noise, thus improving the quality of the data.

Different actions can be accomplished at the detector characterization level
in support of data analysis. A first action is to identify, and possibly
remove, the instrumental source of spectral noises as soon as possible during
a data taking period. This is a non trivial task that typically requires a
significant amount of work to nail down which detector component is
responsible for a given disturbance and to eliminate the noise source, which
may imply to replace the noisy component (for instance a cooling fan, an
electric motor, etc.) [36], to shut it down (if not needed) or to modify it
properly. This could consist, for instance, in shifting the frequency of a
calibration line which non-linearly couples to another noise source, in order
to move the noise line frequency into a band less relevant for gw searches
[12, 60].

A second action is the use of additional techniques to differentiate between
possible signals and other spectral features. These methods strongly depend on
the analysis and on the type of gw signals searched. An example of such
techniques relies on the Doppler effect. An astrophysical cw signal is
expected to be modulated in frequency by the Doppler effect, due to the Earth
rotation, which induces a shift

$\Delta f(t)\simeq f_{0}\frac{\vec{v}(t)\cdot\hat{n}}{c},$

where $f_{0}$ is the source frequency, $\vec{v}$ the detector velocity,
$\hat{n}$ the unit vector identifying the sky direction of the gw source, and
$c$ the speed of light. cw searches correct this Doppler effect, thus any
monochromatic line present in the $h(t)$ signal is spread by a maximum amount
of $\Delta f_{max}\simeq 10^{-4}f_{0}\cdot cos{\beta}$, where $\beta$ is the
ecliptic declination. This shift corresponds to up of hundreds or even
thousands of frequency bins for typical cw searches.

Potential candidates found in the analysis lead to follow-up investigations to
identify a possible instrumental source. This follow-up is also based on a
combination of DetChar activity, to spot the source of the disturbances, and
application of cw or sgwb algorithms to build confidence in the astrophysical
nature of the candidate, see for example [61].

Although spectral noises cannot always be removed, it is still useful to
characterize them by constructing a list of noisy lines. This list can be used
to exclude those disturbing frequency bands from the analyses, or to veto
candidates with frequency too close to those noisy lines

The identification of lines is typically done by automated pipelines [14],
based on:

  * •

User-defined thresholds set on data power spectrum or on line persistency,
defined as the fraction of fft, compared to the total number covering the full
observation time, in which the “normalized” power content of a given frequency
bin was above such a threshold (typically set to six times the average value);

  * •

Highlighting coincidences or significant coherence among different channels;

  * •

Highlighting a pattern in time-frequency maps of the data.

Candidates found in gw searches are subject to verification steps, in which
the identification of possible noise counterparts is done by processing the
data in the relevant frequency band and period of time and/or running manually
one or more of the line identification pipelines. In the following, we report
and discuss a few examples of lines identified in Virgo O3 data. Readers can
refer to the LIGO-Virgo gwosc [62] for the official full list of lines.

####  6.3.1 Combs

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 gw 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 16 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.

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

Figure 16: Plot of line persistency over the frequency band 20-30 Hz. The grey
box identifies the frequency range covered by a narrow-band search of cw
signals from the Vela pulsar in O3a data. The line at 23.333 Hz, which
contributed to produce a candidate in the search is clearly visible. In fact,
several other lines belonging to the 1 Hz comb, both at integer frequencies
and shifted by 0.333 Hz, and to a weaker 0.2 Hz-spaced comb, are present.

####  6.3.2 Wandering line around 83 Hz – 84 Hz

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.

Figure 17: A typical 7-day spectrogram of the $h(t)$ channel, generated by the
Spectro tool [14] and allowing the monitoring of a wandering spectral line
whose main frequency was first stable around 83 Hz before increasing up to
around 100 Hz in about a day.

An example that triggered lots of DetChar investigations during O3 is the
line, normally located between 83 and 84 Hz, as shown in figure 17, that
reached about 110 Hz at the maximum of its excursion and had variations of a
few Hz over about one hour [63, 64]. Its origin dates back to the Virgo
commissioning run 10 (C10) of August 2018 [65], and possibly even earlier, in
the preparatory phase preceding O2 [66]. 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_ [65]. An analysis with Bruco [14] 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 [63]. This technique has proven
successful in the past, in the case of drifting lines driven by the
temperature of some optical components [67], but has produced no convincing
correlation in the case of this line, whose origin remains unknown.

####  6.3.3 Spectral noise bump around 55 Hz

Figure 18a) shows the power spectrum of the Virgo gw strain channel $h(t)$
computed at two different dates, February 26 and March 2, 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 [31]. 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) sgwb search.

####  6.3.4 Spectral noise around the 50 Hz power line frequency

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 [36].

The intense 50 Hz line, corresponding to the frequency of the electricity
mains, was mitigated and substantially eliminated from $h(t)$ (see figure
18b), by implementing a feed-forward noise cancellation scheme using as sensor
a voltage monitor of the detector uninterruptible power supply system [36].
This operation did not reduce the 50 Hz harmonics also present in the $h(t)$
spectrum (see figure 7) 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 18c) 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 18d) 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.

Figure 18: Four steps of the reduction process of the strain spectral noise
between 40 Hz and 60 Hz during O3. In all sub-figures the blue curve is before
the mitigation, and the red curve is after the mitigation. a) Cancellation of
the spectral noise structure around 55 Hz which was common to the prcl signal.
b) Subtraction of the 50 Hz line associated to the power grid. c) Mitigation
of a wide-band noise associated to the motor driver crate of the WE
suspension. d) Suppression of a few noise lines associated to mechanical modes
of the test masses payload.

###  6.4 Offline data quality

####  6.4.1 Offline studies and checks

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
[68] includes detailed public information about these vetoes [69].

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.

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 ${\sim}$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.

Table 7: Virgo O3 offline Science dataset and CAT1 vetoes. | O3a | O3b | O3a + O3b
---|---|---|---
Science dataset | 12,057,731 s | 9,611,843 s | 21,669,574 s
Logical OR | 18,802 s | 20,636 s | 39,438 s
of all offline CAT1 vetoes | (0.16%) | (0.22%) | (0.18%)

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.

####  6.4.2 Event validation

To assess whether the detection alerts produced by transient searches [48, 47,
70, 71] should be considered as “candidate events”, a procedure of
_validation_ is implemented for each generated trigger [10, 45]. 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 [72].

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 4. 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
[72], 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 [14]. 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 [49, 73]. 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 [45, 74].

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 [75, 76]. During O3b, such
process has involved 12 events, including one with Virgo data, GW191105e [10,
77], 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].

##  7 Preparation of the O4 run

The LIGO-Virgo O3 run has lead to the discovery of dozens of new gw signals
from compact binary mergers, which have boosted our knowledge of these
populations in our local Universe and allowed further, more stringent, tests
of general relativity. The O3 run has also been the first long data-taking
period for the adv detector. Thus, it represents a full-scale, extended and
non-stop stress test of the organization and work methods of the Virgo DetChar
group. The experience accumulated during these 11 months form the base of the
DetChar activities, both to prepare and operate for O4 and the following runs.

Although the Virgo DetChar group has fulfilled all its main requirements
during the O3 run, work has been going on since then to improve its
performance and extend its activities. In particular, the anticipated
differences between the O3 and O4 runs lead to new challenges that the group
should tackle. The adv detector will have evolved significantly, with the
completion of the Phase I of the adv+ project [78]. The main changes on the