dataesr/scientific-paragraphs-categorization huggingface dataset:
This pocket was successfully detected by AquaVit, as illustrated in Figure  2 (a). The high density region of hydrophobic probes overlaps well with the all trans retinol ligand that was co-crystallized with CRBP1, 41 as observed in Figure  2(b). Takeout (To) proteins are found exclusively in insects in which they have been proposed to (a) (b) ) (a) (b) Takeout 1 (PDB code 3E8W) (c) (d) (c) (d) Figure  2 : Hydrophobic occupancy maps, black mesh, superimposed onto the PDB structures for a retinol binding protein (RBP, PDB code 5HBS) and a TakeOut 1 protein (To1, PDB code 3E8W). The maps are derived from the densities of hydrophobic probes computed by AquaVit, and represented at +20 σ. Those maps are derived from the apo structure of the protein, i. e. in the absence of all crystallographic ligands and water molecules.
Environments of membrane proteins The subsection above illustrates that AquaVit is able to locate hydrophobic pockets in proteins. However, the solution of the HDPBL system of equations is more comprehensive and also provides information on dipolar density in the presence of a given salt concentration. Here we assess its ability to characterize the polar and non polar environments of membrane proteins. We consider two types of such protein, a member of the G protein coupled receptor (GPCR) family, with a transmembrane domain that consists of a helical bundle (PDB code 2RH1  45  ), and a porin that consist of a β-pleated sheet (PDB code 2POR  46  ). All ligands, ions, and crystallographic water molecules were removed prior to running AquaVit on those structures. In Figure  3  we show the resulting hydrophobic probe occupancy maps and water dipole occupancy maps, superimposed on the PDB structures, including the crystallographic water molecules.
Computing time In Figure  5  we report the computing times for solving the HDPBL system of equations using AquaVit for three systems, DHFR (PDB code 2W9H), GPCR (PDB code 2RH1), and PEBA (PDB code 2X9O) under the standard conditions defined in the Methods section. In addition to the inputs specific to the system under consideration (structure of the solute, concentrations of water dipoles, salt, and hydrophobic probes, dipole moment of the water dipole, and parameters of the Yukawa potential for hydrophobic interactions), AquaVit relies on the parameters of algorithm 1 to solve the HDPBL system. These parameters include on the size of the Cartesian grid used to solve the PDEs, the tolerance TOL that serves as stopping criteria when solving the system self consistently, and the parameter λ used to update the fields u and v (see Algorithm 1 presented in section 3).
In all calculations presented above, TOL is set to 10 -4 and λ is set to 0. 7 (this number is somewhat arbitrary and could in fact be optimized for each system considered). We have also used consistently a grid of size 193 3 , but in figure  5  we report the computing time of AquaVit as a function of this grid size. We observe a near linear dependence of the computing times of AquaVit with respect to the total number of points in the grid, as expected. 31 These computing time do not differ significantly between the three proteins, despite the fact that they are very different in size (157 residues for 2W9H, 237 residues for 2X9O, and 465 residues for 2RH1). The average computing time for a grid of 193 3 points is 1240 s, i. e. approximately 21 minutes. The computing time required to solve the system of equations HDPBL using AquaVit with a residual error lower than T OL = 10 -4 (see text for details) is plotted versus the total number of points in the mesh for the three proteins DHFR (PDB code 2W9H), GPCR (PDB code 2RH1), and PEBA (PDB code 2X9O).
53 Two subsequent independent studies, 54,55 however, identified a cryptic hydrophobic binding site that is close to the original phosphate binding site identified by Cheng et al. 53  The opening of this cryptic binding site is the result of a change in the conformation of the side chains of Tyr417 and Tyr481. This opening enables PBD to bind longer phosphophopeptides. Sledz et al  55  for example presented the structure of the complex of PBD with the phosphopeptide PheAspProProLeuHisSerpThrAla (PDB code 3P37). Interestingly, when we ran AquaVit on a single copy of the PBD domain in the absence of the peptide ligand and of all crystallographic waters in its configuration from 3P37, we were able to identify the longer ligand binding hydrophobic pocket of PBD which includes the cryptic pockets, which can bind this longer phosphopeptide.
Conclusion We have developed the HDBPL model and implemented it in the program AquaVit as a tool for identifying and characterizing binding sites in proteins. A protein of interest is immersed in a lattice gas containing water dipoles, anions, cations, and hydrophobic molecules. The charged molecules interact between themselves and with the solute charges through electrostatic interactions, while the hydrophobic molecules (including non polar groups on the solute) interact based on a Yukawa potential. We impose steric constraints on the lattice, as well as incompressibility, i. e. all sites of the lattice are occupied. The system (protein of interest and its environment) is then characterized with an effective free energy that depends on two fields φ(r) and ψ(r) corresponding to the electrostatics and hydrophobic interactions, respectively.
The Euler-Lagrange equations obtained by minimizing the free energy with respect to those two fields form a system of two Poisson-Boltzmann like PDEs, HDPBL, which we solve using a self consistent approach, implemented in the program AquaVit. The outputs of HDPBL are the densities of the different species, and peaks of densities are expected to reveal the presence of compatible binding sites. We have tested and validated the ability of HDPBL to detect pockets that bind to hydrophobic ligands (the DHFR, a lipid binding protein, HIV protease, and a retinol binding protein), polar ligands (biliverdin), as well as to characterize the environment of membrane proteins such as GPCR and a porin. The HDPBL equations form a system of two coupled second order elliptic nonlinear PDE. While those equations are akin to the PB equation, they cannot be solved directly with a PB solver, mostly because the two equations are strongly dependent.
This could be well adapted to study the solvation of proteins in the presence of large and more complex co-solvents such as acetonitrile or DMSO. AquaVit, our program for solving the HDPBL system of equations, is fast and as such compares favorably with the ligand mapping molecular dynamics simulations that have been designed with the same goal of detecting and characterizing binding sites in proteins. The latter, however, have the significant advantage that they account for the dynamics of the solute. As such, they have been shown to detect cryptic bind sites in proteins,  11, 14, 15, 49  namely sites that are not accessible unless a structural change occur in the protein. In its current formulation, the HDPBL system of equations assumes that the protein is static; such conformational changes are then inaccessible.
Figure1: Hydrophobic occupancy maps, black mesh, superimposed onto the PDB structures for DHFR (PDB code 2W9H) and a lipid binding protein (LBP, PDB code 1FK2). The maps are derived from the densities of hydrophobic probes computed by AquaVit, and represented at +20 σ. Those maps are derived from the apo structure of the protein, i. e. in the absence of all crystallographic ligands and water molecules. In panels (a) and (c) we show the hydrophobic maps for DHFR and LBP superposed to the apo PDB structure, while in panels (b) and (d) we visualize the hydrophobic ligand (trimethoprim for DHFR and myristic acid for LBD) in magenta. All images were generated using Pymol. 43.
Figure5: The computing time required to solve the system of equations HDPBL using AquaVit with a residual error lower than T OL = 10 -4 (see text for details) is plotted versus the total number of points in the mesh for the three proteins DHFR (PDB code 2W9H), GPCR (PDB code 2RH1), and PEBA (PDB code 2X9O). All computations were performed on an Intel Core i7 processor with 8 cores running at 4. 00GHz, and 64GB of memory, although AquaVit was compiled without parallelization options.
System set up The coordinates of the atoms of the solute(s) as well as their partial charges are read from a single file under the PQR format used by APBS. For large biomolecules, PQR files can be readily generated from the correspondent PDB 34 files using the service PDB2PQR. 35 For all examples described below, we used the PARSE parameter dataset 36 to assign charges. The PQR file may contain several molecules. The PQR file was then modified to add hydrophobic charges to all atoms. While those are not charge per se, they enable interactions between the hydrophobic probe in the solvent and the solute. Using the nomenclature of CHARMM, all atoms identified as CT (aliphatic carbon), CH1E (extended carbon, with 1 hydrogen), CH2E (extended carbon, with 2 hydrogens), CH3E (extended carbon, with 3 hydrogens), S (sulfur) and SH1E (extended atom S with one hydrogen) were assigned a non-zero hydrophobic charge of +2, while all other atoms had no non polar charges.
51 Several members of this family have been identified in multiple species. 52 Among those, PebA reduces BV at its C15-C16 double bond to produce 15-16 dihydrobiliverdin (DHBV). The structure of PebA from the cyanobacterium Synechococcus sp. WH8020 with its substrate BV was determined at 1. 55 Å(PDB code 1X9O  50  ). This structure consists of a seven-stranded antiparallel β-sheet surrounded by six α helices (Figure  4(a) ). We used AquaVit to solve the HDPBL system of equations that characterize the environment of PeBA. The calculation was performed on the protein structure alone, i. e. in the absence of the BV ligand and crystallographic water molecules. Figure  4 (b) illustrates the densities of water dipoles, anions, cations, and hydrophobic probes around the structure of PebA in the form of occupancy maps.
The characterization of the Advanced LIGO detectors in the second and third observing runs has increased the sensitivity of the instruments, allowing for a higher number of detectable gravitational-wave signals, and provided confirmation of all observed gravitational-wave events. In this work, we present the methods used to characterize the LIGO detectors and curate the publicly available datasets, including the LIGO strain data and data quality products. We describe the essential role of these datasets in LIGO-Virgo Collaboration analyses of gravitational-waves from both transient and persistent sources and include details on the provenance of these datasets in order to support analyses of LIGO data by the broader community. Finally, we explain anticipated changes in the role of detector characterization and current efforts to prepare for the high rate of gravitational-wave alerts and events in future observing runs.
Web-based services By contrast with the software packages described in section 3. 1, the following services are maintained as broad signal processing platforms primarily accessible to the end user through the Internet, with application programming interfaces (APIs) available on the command-line and through any computing environment that supports Python. Like most LIGO and IGWN web-based services, they utilize Shibboleth Single Signon  [38]  for user authentication to ensure the security of proprietary datasets. 3. 2. 1. DQSEGDB Many detector characterization tasks and pipelines designed to search for gravitational wave signals rely on data quality "flags. " Data quality flags store metadata for measured or derived states within each interferometer, its subsystems, and various components. Data quality flags are used at all current gravitational wave observatories.
These data quality flags are stored in the IGWN Data Quality Segment Database (DQSEGDB)  [39]. For each flag, the database tracks spans of time (called segments) over which the flag's on/off truth value is known. The start and end time of each segment is defined using units of integer seconds. In particular, each interferometer's "observing mode" flag indicates segments over which that interferometer was both locked and taking science-quality data that is flagged by interferometer operators as intended for gravitational wave searches. This flag is used by all downstream analysis pipelines to distinguish spans of time that can and cannot be analyzed. Other flags can be used to reject (or veto) otherwise usable segments in which the data stream contains well-understood artifacts, such as glitches with a known cause, or planned injections of artificial test signals.
It is tightly integrated with the LIGO-Virgo Alert System (LVAlert)  [55]  and Gravitational-Wave Candidate Event Database (GraceDB)  [56]. When an upstream search pipeline identifies a potential gravitational wave signal, the event is recorded in GraceDB and the LVAlert system broadcasts a notice to all subscribers, including the DQR architecture. When the DQR receives an alert it triggers a series of analyses from three LIGO computing clusters. Examples of included analyses are omega scans, statistical checks such as HVeto, and checks of known flags in DQSEGDB. The DQR infrastructure is modular, allowing for additional tools to be added as desired. Within minutes of the first automated notice sent to the the Gamma-ray Coordinates Network (GCN)  [57]  announcing the identification of a gravitational wave event candidate, the DQR architecture begins to upload web-based reports and supporting data to GraceDB for internal review, which then informs the decision to disseminate additional GCN Notices and Circulars or to retract an announced candidate.
Coherence is a useful figure of merit to reject spurious coincidence of spectral artifacts that are not actually correlated and to identify potential coupling mechanisms of non-astrophysical noise into gravitational wave data. Specifically, coherence between two channels d 1 (t) and d 2 (t) is defined as  [11]  Γ (f ) = | d 1 (f ) d2 (f )| 2 | d1 (f )| 2 | d2 (f )| 2 , (1) where di (f ) (i = 1, 2) is the Fourier transform of the time series data d i (t), denotes complex conjugation, and the average • refers to an average over N segments. For Gaussian, uncorrelated noise, the expected distribution of the coherence is given by p(Γ) ∝ e -ΓN , (2) where N is the number of segments used for averaging. Other examples of figures of merit include: FineTooth, a comb identification and tracking tool; NoEMi, a line monitoring and database tool; a coherence tool database that enables efficient look-up of coherences in different time-and frequency-intervals; and studies that fold time-domain data at periodic intervals to check for periodic elevated noise.
For the GravitySpy project, members of the detector characterization group helped create an initial dataset by identifying major glitch categories. Currently, this algorithm classifies transient noise into 23 different classes. The data set used to train GravitySpy, which includes information about glitches in publicly available LIGO gravitational wave strain data, is available  [77]. Certain classes of transient noise, such as Blip, Tomte, Extremely Loud, and Koi-Fish, have not shown any environmental or instrumental coupling yet. Statistical data analysis of these glitch categories has led to an improved noise characterization, and we continue to look for the source of the noise. On the other hand, Scattered Light noise has shown a strong environmental coupling through the ground motion near the detectors.
Other than this, HVeto suggested a statistical correlation between slow scattering in gravitational wave strain and noise in the transmitted light monitors on the TMS. A follow-up data quality investigation confirmed the existence of these two noise couplings, both via the ETM. The first coupling, which came to be known as ETM-AERM scattering is due to the scattered light between the ETM and AERM. A technique called reaction chain (RC) tracking, implemented in Jan 2020 at LLO and LHO, reduced the distance fluctuations between the ETM and AERM, which was found to be the source of noise in gravitational wave strain. Following this RC tracking at both the detectors, the slow scattering glitch rate was reduced for ground motion above 1000 nm/s in the microseismic band. This is shown in the bottom plot of figure  5.
These include two data streams, the state vector and the data quality vector (data quality vector). The state vector is a time-series (recorded at 16 Hz) which contained information about the overall operating state of the detector, the presence of any hardware injections, and the status of the online calibration pipeline encoded as a bit-vector. The operating status information was limited to an indication that the interferometer was ready to take observation-quality data, that the site operators had transitioned to an intended observing mode, and that both the data was of observation quality and the calibration of the data was successful. This information could then immediately be used by search pipelines to know which data should be processed, while the information on hardware injections  [125]  could be used to excise these simulated events from analysis results searching for true gravitational waves.
Finally, the additional information describing the state of the calibration could be used to track the performance of the calibration code, but was designed to be extraneous for the search pipelines themselves. The data quality vector is a time-series (also recorded at 16 Hz) which contained information about the presence of well-known noise sources in the data, again encoded as a bit-vector. Because the data quality vector was distributed at the same time as the calibrated strain, it was able to be made available with effectively zero latency, but was limited in scope. This vector indicated the presence of several types of interferometer control-loop saturations. A prominent example of these was the glitch located very close temporarily with, and subsequently subtracted from, GW170817 in LLO  [7, 126, 8].
These saturations occur when control actuation signals rail against software limits, thereby producing short-duration, broadband excess noise. Importantly, the data quality vector, like the data quality flags described in section 5. 2, only encoded binary state information, and several searches used the data quality vector to automatically reject candidates  [127, 128]. In addition to the state and data quality vectors, an additional data product, the iDQ  [129]  timeseries, was generated in low latency in O2 and O3. iDQ is a statistical inference framework which identifies non-Gaussian noise in the gravitational wave strain based on auxiliary channels and produces probabilistic data quality information. Multiple iDQ timeseries are available which have different interpretations, including p(glitch|aux) and log-likelihood, but all reflect the degree of non-Gaussian noise in the data.
p(glitch|aux) gives the probability that there is a glitch in the gravitational wave strain channel, given auxiliary channel information, aux. The log-likelihood, in contrast, gives the likelihood ratio between the glitch and clean models. p(glitch|aux) is computed from the log-likelihood and also contains prior odds folding in the glitch rate within the detector. In O3, candidates were released publicly for multi-messenger follow up without initial human vetting through GWCelery  [130, 131]. These public alerts were distributed via GCN with latencies as low as a few seconds after merger. At such a low latency, few data quality products are available: the aforementioned state and data quality vectors, and the iDQ timeseries detailing statistics such as P (glitch) and log(likelihood) (iDQ is discussed further in section 5.
2). GWCelery included a detector characterization task which was required to be passed before the distribution of any public alert. This task checked the values of the state vector for a short window of a few seconds centered about the gravitational-wave candidate's event time. The check would pass only if the detectors were in observing mode and no hardware injections were found. The information available from iDQ P (glitch) was not a part of these automated checks, but was reported for human inspection. Early in O3, GWCelery also checked the data quality vector to ensure there were no overflows, but this check was removed once all search pipelines switched to using gated data (see section 5. 3) to avoid vetoing an overflow that would have been gated out prior to the search. All candidates passing this check were assigned the "DQOK" label in Gravitational-Wave Candidate Event Database.
Data Quality Products As a part of searches for gravitational wave transients, multiple types of data quality products are used to indicate the state of the detector and the analyzed data, with the goal of increasing the sensitivity of the searches and reducing the number of false alarms. In addition to the data quality products available in low latency, available data quality products include data quality flags, lists of time segments identifying specific data quality concerns, and higher latency predictions of the data quality from iDQ. When a period of time demonstrating excess noise has been identified along with an auxiliary channel that witnesses the source of the noise, the associated time periods of gravitational wave strain data are marked as likely to contain instrumental artifacts using a data quality flag.
2. 1), and hence the start and end times must be integer seconds. However, many category 1 vetoes last multiple hours. Reasons for category 1 vetoes include incorrect detector configurations, data dropouts, and on-site maintenance work  [136]. In a subset of these cases, operator logs are used to define the category 1 segments instead of auxiliary channel witnesses. Data from segments flagged by category 1 vetoes are not ingested by astrophysical analyses. Because category 1 vetoes prevent the detection of gravitational-wave candidates from the time period they flag, this veto category is not used unless a data segment is not analyzable. In O2 and O3, category 1 vetoes removed less than 2. 0% of analyzable data at each detector. Category 2 vetoes indicate periods of time where the data is impacted by excess noise and should be treated with caution, but can still be used as input to an astrophysical analysis.
Potential candidates that are identified during data flagged as category 2 are recommended to not be considered potential candidates by astrophysical search pipelines as candidates identified during this time have a higher likelihood to have been caused by instrumental artifacts than candidates identified outside  category 2 periods. Category 2 vetoes are also defined using integer second segments in the same manner as categeory 1 vetoes. However, each category 2 segment generally only a few seconds in duration. Figure  8  shows an example of a category 2 veto that was developed during O2. This veto was used to flag periods of excess noise in an optical lever channel at LIGO Hanford that produced glitches in the gravitational wave strain data. Removing these short time periods removed a significant portion of the glitches with SNR > 8 during this data stretch.