dataesr/scientific-paragraphs-categorization huggingface dataset:
Cost monitoring framework The ATLAS cost monitoring framework  [42]  consists of a suite of tools to collect monitoring data on both CPU usage and data-flow over the data-acquisition network during the trigger execution. These tools are executed on a sample of events processed by the HLT, irrespective of whether the events pass or fail the HLT selection. It is primarily used to prepare the trigger menu for physics data-taking through the detailed monitoring of the system, allowing data-driven predictions to be made utilising dedicated datasets (enhanced bias dataset, see Section 7. 3). Monitored data include algorithm execution time, data request size, and the logical flow of the trigger execution for all L1-accepted events. To sample a representative subset of all L1-accepted events, a monitoring fraction of 10% is chosen.
Enhanced bias runs Certain applications such as HLT algorithm development, rate predictions and validation (described in Section 10) require a dataset that is minimally biased by the triggers used to select it. The Enhanced Bias (EB) mechanism allows these applications to be performed utilising dedicated ATLAS datasets. These datasets contain events only biased by the L1 decision, by selecting a higher fraction of high- T triggers and other interesting physics objects than would be selected in a zero bias sample (i. e. a sample collected by triggering on random filled bunches). To collect the EB dataset, a specific trigger menu is used which consists of a selection of representative L1 trigger items spanning a range from high- T primary trigger items to low- T L1 trigger items, plus a random trigger item to add a zero-bias component for very high cross-section processes.
Condition updates in the HLT The HLT event selection is driven by dedicated reconstruction and selection algorithms. The behaviour and performance of some of those algorithms depend on condition parameters, or conditions, which provide settings, such as calibration and alignment constants, to the algorithms. Conditions are valid from the time of their deployment, and until their next update. Depending on the nature of the conditions, these updates can be frequent. While most conditions are updated only between runs and often much less frequently, some are volatile enough to require updates during ongoing data-taking. In the ATLAS experiment, all conditions data and their interval of validity are stored in the dedicated COOL database  [51]. This section describes those special conditions and the procedure that was introduced to configure them consistently and reproducibly across the HLT farm.
Updates of trigger prescales Prescales can be used to either adjust or completely disable the rate of an item/chain, or to only allow its execution after the event has already been accepted (so-called rerun condition). Being able to change trigger prescales during an ongoing run is extremely valuable in providing luminosity-dependent trigger configurations during data-taking and therefore in making optimal use of the available resources. As opposed to L1, where prescales are applied centrally by the CTP, the update of HLT prescales needs to be synchronised across the entire HLT farm. In addition, the HLT nodes need to be able to access the history of prescale sets used for the currently ongoing run to be able to apply the correct prescales due to the processing delay in the HLT. For this purpose, a table holding the mapping between LBs and prescale keys is recorded in the trigger database (see Section 9), and propagated to the HLT farm using the same mechanism as the other conditions updates.
Trigger configuration The settings of both the hardware and software components of the ATLAS trigger system must be accurately recorded to ensure the correct interpretation of the trigger in offline analysis and the reproducibility of the trigger behaviour in the recorded data. The ATLAS trigger configuration system uses a relational database, the TriggerDB, to store these configuration data in a stable and accessible manner. L1Muon and L1Calo maintain additional configuration and condition databases, while the CTP stores most of its information in the TriggerDB. The Run-2 ATLAS trigger configuration system is described in detail in Ref. [55]  and is summarised in the following. The upload of the configuration to the TriggerDB is handled by the TriggerTool via its graphical user interface (GUI).
The trigger database design The TriggerDB  [56]  is an Oracle relational database schema in which all tables have an integer primary key corresponding to a unique combination of a name and version for the object and any dependent object that is stored. The primary key of the top-level table is known as the Super Master Key (SMK) and uniquely defines the L1 and HLT configuration. The SMK together with the Bunch Group Key (BGK), associated with the bunch group set, and Prescale Set Keys (PSK) for L1 and the HLT uniquely define the trigger configuration used to record a run. These keys are saved in COOL for each LB for use by offline analyses. A simplified representation of the database structure for the trigger configuration is shown in Figure  10. There are several instances of the TriggerDB hosted on the CERN Oracle servers, each for different use cases.
The online TriggerDB is accessed by custom C++ configuration classes to load the configuration into the L1 and HLT systems at the start of a run. The online DB is only accessible from within the ATLAS control room network, but there is a read access clone replicated externally. This is needed to be able to run the trigger simulation using the same configuration classes as online. Other TriggerDB instances are used to produce MC simulation and for trigger reprocessing tasks. The design of the TriggerDB is based on two principles: to avoid duplication of records in the database and to maintain every configuration ever used to record data. Link tables are used to allow the same primitive to appear in many configurations and similar primitives to appear within the same configuration. This removes the need to replicate the primitives themselves.
The TriggerTool The commonly used way to upload the trigger configuration into the database is through the TriggerTool GUI  [57] , a Java project developed in the NetBeans  [58]  integrated development environment. Upon launching the tool, the user has to choose their access role and the database connection. Within the TriggerTool, a variety of options are available to display and edit the trigger configuration through a range of panels. The main panel is shown in Figure  11 , which shows the configurations which Figure  10 : A simplified representation of the database structure for the trigger configuration highlighting the primary keys and the relationship between a selection of tables. The primary keys (black rectangles) are associated with an index of a table (rectangles). Most of the top-level table structure is shown (red rectangles) with each of these linking to further tables (for example a trigger chain).
The TriggerPanel The change of the SMK and PSKs is handled by the TriggerPanel, which is included as part of the TDAQ software controlling the finite-state machine of ATLAS in the integrated run control GUI  [59]. The TriggerPanel displays all prescale keys that are associated with the loaded SMK, along with which keys are currently in use, as can be seen in Figure  13. The prescale keys can be set for different data-taking scenarios: standby, emittance scans, or physics. To facilitate the selection of a corresponding L1 and HLT PSK assigned to a particular luminosity range, they can be linked via alias tables in the TriggerDB for this luminosity range. Once an alias is selected in the TriggerPanel, it allows the PSKs to be suggested automatically, based on the current measured luminosity, and these are used only when confirmed by the shifter.
Online release validation The online trigger software release cycle includes development, validation and deployment of the software to ensure the reliability and predictability of the performance of the HLT. This release is kept separate from the offline reconstruction release to be able to make use of new developments and fixes for data-taking. The final validation of the trigger release is done using a suitable EB dataset (see Section 7. 3) and mimicking the configuration and execution during the data-taking. The performance evaluation covers aspects of low-level memory and CPU requirements as well as distributions and efficiencies of high-level physics quantities which are analysed by a range of experts. This multifaceted task is crucial for the successful and efficient operation of the trigger system.
In Figure  14  (right), the HLT rate predictions are compared with online rates for 957 trigger chains of the trigger menu with a non-zero rate at the time of data-taking at the same luminosity. The recorded rates are corrected for prescales applied at L1 and/or the HLT, and the difference in rate between the prediction and the recording is normalised to the combined statistical uncertainty from both samples. The Gaussian fit in the range -3 to 3 indicates that the prediction for the majority of HLT chains is normally distributed. For a small number of chains where the predicted rate was too low, a tail to the negative significance is visible. This is due to a small bias arising from the chosen set of L1 seeds of the EB dataset in addition to luminosity scaling assumptions. Since the enhanced bias data are collected over a one hour period, the mean number of pile-up interactions changes throughout the sample and this introduces another small bias to chains whose rate is not linear with respect to the instantaneous luminosity, due to pile-up sensitivity.
The mean fractional statistical uncertainty per HLT chain is 10% for the predicted rates and 2% for the recorded rates. For the total HLT rate, the statistical uncertainty of the prediction is 1%. The processing of the trigger software on the enhanced bias dataset is run on the Worldwide LHC Computing Grid  [63]  using the ATLAS production system, Prodsys2  [6] , and can be monitored and managed through a web interface. Using the ATLAS Metadata Interface (AMI)  [64] , the software validation expert manages and stores the configurations and parameters of the data reprocessing. The reprocessing runs the HLT algorithms over raw data files, which is the same format as produced by the trigger system during data-taking, and produces another raw data file containing the new trigger decisions. In addition to reprocessing with   [42].
Left: Predicted rates as a function of  T for various L1 triggers. Right: Pull distribution in predicted rates of 957 HLT chains from EB data normalised to the combined statistical error (), and fitted by a Gaussian function with mean,  Fit , and width,  Fit , where R Prediction and R Online refer to the rates from prediction and data-taking for the same luminosity, respectively. Error bars include statistical uncertainties only. the HLT algorithms, it was also possible to run the L1 simulation on the raw data to obtain updated L1 decisions when new L1 trigger items were introduced in the trigger menu. The raw data files containing the new trigger decisions are then processed with the ATLAS production reconstruction software to produce the output necessary for validation. This process of rerunning the trigger and offline reconstruction on about 1M EB events takes around 24 hours and typically requires on the order of 7000 hours of CPU time, with each job using roughly 4 GB of virtual memory.
Throughout Run 2, the HLT reprocessing used about 0. 2% of the ATLAS grid resources. The performance evaluation of a new release is carried out by signature-specific experts who compare various results with those from a previously validated release. The offline and online monitoring is used to sign off a new release similar to the procedure used for the quality assessment of the collected data (see  Section 13). Once the release is validated, it is deployed to the online machines for data-taking and further tested in an ATLAS test run during an LHC inter-fill period to check that there are no problems configuring the HLT with the new release in the online environment and that the release is compatible with software being used by other subsystems.
2 × 10 -6 and 2 × 10 -7 in 2015, 2016, 2017 and 2018, respectively. Table  2 : A breakdown of the number of events in the different debug streams for each year of   data-taking during Run 2. In addition, the total number of events recorded in the physics stream is shown. While the number of events in the debug stream might be very small, an attempt to recover them is still made. The recovery is done offline by rerunning the trigger using the same configuration as online, including relevant databases, except the relevant constraints that caused them to be written out to the corresponding debug stream. In the case of algorithmic errors, the events can be recovered by applying a patch to the software release with a fix for the cause of the failure before rerunning. Out of the total number of debug stream events, 97.
If there are problems spotted during the assessment, a so-called data quality defect is set and recorded in the data quality database. A defect denotes an LB (or several LBs up to the entire run) in which the data-acquisition was not optimal. Many different defects are defined, so that each type of problem can be tracked individually. They can be either tolerable or intolerable. Tolerable defects are used to flag slight abnormalities in the data that do not have a large impact on physics (e. g. spikes in the calorimeter energy, small loss of coverage from some detector, etc. ). Intolerable defects are used to flag data that should not be used for physics (e. g. large loss of coverage from some detector, incorrect trigger configuration, etc. ). The DQ and debug stream on-call expert is responsible for collecting the assessment outcome from the L1 systems and the trigger signatures and reporting them to the ATLAS DQ group.
The DQ efficiency is presented in terms of a luminosity-weighted fraction of good quality data recorded during stable beams periods. Only periods during which the recorded data were intended to be used for physics analysis are considered for the DQ efficiency. The trigger-specific and total ATLAS DQ efficiency both improved over the course of Run 2. Over the full Run 2, the trigger and ATLAS DQ efficiencies are 99. 6% and 95. 6%, respectively, for the standard √  = 13 TeV   dataset, with a corresponding 139 fb -1 of data being good for physics analysis. The inefficiencies of the trigger ATLAS Figure  19 : An example of the web-display for the offline DQ assessment. Shown here are various plots for hadronically decaying -lepton candidates as reconstructed in the HLT. The data (black points) are compared with a reference (blue points), and flagged as green, yellow, or red depending on how well they agree, according to predefined algorithms.
STEM mode combined with EDS was used to extract the elemental composition from the region of interest. The employed EDS silicon drift detector (SDD) is a windowless X-Max 100TLE from Oxford Instruments. APT: APT samples in the form of conical shaped tips with an apex diameter less than 100 nm were prepared using FIB-SEM. The preparation of APT specimens parallel to the substrate is described elsewhere. [89] Laser assisted wide-angle tomographic atom probe (LAWATAP) was operated at 60 K under ultrahigh vacuum conditions (≈2 × 10 -8 Pa). Field evaporation was triggered using femtosecond (10 nJ per pulse, 100 kHz) green (λ = 515 nm) laser pulses with a 100 µm laser beam diameter (full width half maximum). Data reconstructions in three dimensions were performed using the home built GPM 3Dsoft software.
Protein amounts were measured by BCA protein assay (Thermo Fisher Scientific) and used to normalize OCR and ECAR results. Data were viewed and analyzed in Wave Desktop version 2. 2 (Seahorse Bioscience). The XF Glycolysis Stress Test Report Generator and the XF Mito Stress Test Report Generator (Seahorse Bioscience) were used to automatically calculate glycolysis and mitochondrial respiration parameters from Wave data. Three independent experiments of each test were performed with a minimum of 6 replicate wells per condition  [15].
The chromatographic gradient for RPLC was as follows: 0-12 min: increase linearly from 5% B to 60% B; 12-20. 5 min: increase linearly to 80% B; 12. 5-18 min: hold at 80% B; 18-19 min: decrease linearly to 5%B; 19-25 min: hold at 5% B. The chromatographic gradient for HILIC was as follows: 0-4 min: decrease linearly from 80% B to 65% B; 4-13 min: decrease linearly to 40% B; 13-18 min: hold at 40% B; 18-21 min: increase linearly to 80% B. The flow rate was 300 μL/ min and the sample injection volume was 10 μl. For metabolite data analysis, Skyline software from the MacCoss laboratory was used to extract targeted metabolite measurements  [31]  (https://skyline. gs. washington. edu/). The alignment of targeted metabolite peaks was manually checked with standards and final data were normalized by median for each sample by using Excel software.
For heat map analysis, normalized metabolites in arbitrary units extracted from Skyline were compared to maximal intensities of corresponding metabolites and expressed in a range from 0 to 1. Values are means of 4-to-9 biological replicates for each sample. Raw LC-MS data in mzXML format of all metabolites are accessible via the MetaboLights repository (www. ebi. ac. uk/metabolights) under accession number MTBLS405.
MS analysis of polypeptides MS sample preparation was performed essentially as described previously  [9, 25, 33]. Tryptic peptides were concentrated and purified on homemade C18 columns or C18 StageTips (Thermo Fisher Scientific) before liquid chromatography-tandem MS. Peptides were separated by reverse-phase chromatography by using a nanoflow UPLC system (Thermo Fisher Scientific) with a linear gradient. Ultra performance liquid chromatography (UPLC) was coupled online to an Orbitrap Elite or Q-Exactive or Lumos mass spectrometer (Thermo Fisher Scientific). Peptide ions were fragmented by collision-induced dissociation (CID). Analysis of TMT labeled peptide fractions was carried out on an Orbitrap Lumos MS platform (Thermo Scientific). Data acquisition was carried out using a data-dependent acquisition method with multi-notch synchronous precursor selection and MS3 scanning for TMT tags  [26].
For AP-MS and BioID datasets, raw MS files acquired from the MS analyzer were processed by using MaxQuant software (version 1. 3. 0. 5) according to the standard workflow  [34]. MS/ MS spectra were searched against the UniProt human proteome (release 2017) by using the Andromeda search engine  [35]. For statistical evaluation of data, a false discovery rate of 0. 01 was set for peptide and protein identification. Protein label free quantification (LFQ) intensity was chosen as the quantitative value representing protein abundance and used for calculations of protein differential expression. Protein LFQ intensities across different samples were first normalized by the intensities of the SHMT2 bait protein. The logarithmic ratio of protein intensities between two samples and the negative logarithmic p-values of the Welch's t-test obtained from biological triplicates between two samples were calculated for Volcano plot analysis by using Perseus software (perseus-framework.
org/) [36]. Cytoscape version 3. 2. 0 [37]  was used for visualization of protein interaction networks. For TMT labeled samples, raw MS files acquired from the MS analyzer were processed by Proteome Discoverer Software (ver. 2) and Scaffold software (Proteome Software, Inc. , Oregon, USA). The same reference sample, a mixture of 18 samples, was used for two sets of TMT samples. The relative amount of proteins compared to the reference sample were extracted from Proteome Discoverer Software (Thermo, USA), converted to relative fold change compared to control and then transferred to log2 values. For cell culture samples, SHMT2 UP and Down values are relative to control, non-induced cells; i. e. Cont values were set to 1. For tumor samples the Up and Down values are presented relative to the average of three Cont tumor samples.
Perseus software was used for statistical and cluster analyses. In the heatmap white is set as the median value. Proteins identified by TMT methods required more than 95% probability in peptide and protein identification. MS proteomics data described in this paper have been deposited to the ProteomeXchange Consortium (http://www. proteomexchange. org) via the PRIDE partner repository with the dataset identifier PXD004629 for BioID data, and PXD004954 for TMT data.
The mass spectrometry proteomics data describe in this paper have been deposited to the ProteomeXchange Consortium (http://www. proteomexchange. org) via the PRIDE partner repository with the dataset identifier PXD004629 for BioID data, and PXD004954 for TMT data. Raw LC-MS data in mzXML format of all metabolites are accessible via the MetaboLights repository (www. ebi. ac. uk/metabolights) under accession number MTBLS405. All other data are within the manuscript and its supporting information files.
Numbers of colonists varied widely between samples, so diversity was assessed by a rarefaction analysis (BioDiversity Pro), with total individuals pooled over replicates. Single-celled protozoans were not included in nMDS or rarefaction analyses, as their occasional outlier abundances obscured patterns displayed by the metazoans. Colonization data from prior to the eruption were available from several vents located within a few hundred metres of the P-vent site  [24] , and were selected from the East Wall vent collections to represent a range of thermal habitats similar to P-vent, an extended deployment time (37 months), and the most mature successional stage available (85 months after the previous eruption in 1991). These pre-eruption colonization experiments had been conducted on basalt blocks with similar collecting characteristics but smaller surface area than the sandwiches  [25] , so comparisons with post-eruption results were made on relative abundance.
Acknowledgements. We appreciate the contributions of the  Alvin and Nautile groups , the  Captain and crew of Atlantis and L'Atalante, and Chief Scientists Karen von Damm ,  Andreas Thurnherr , and  Jim Ledwell  on the RESET, LADDER-I and LADDER-II cruises, respectively. Tim Shank  and  Breea Govenar  generously set out the initial colonization experiments in June 2006. We thank  J. P. Brulport  for the preparation of chemical sensors. Insightful comments by two anonymous reviewers improved the manuscript. We dedicate this paper to honour the memory of Diane Poehls Adams who was pivotal in launching this study.
MtCRA2 Antagonistically Regulates Root Architecture and Symbiotic Nodulation Using forward genetic screens, we identified from the M. truncatula R108 Tnt1 insertional mutant collection two mutants (NF0903 and NF0805) that display an increased lateral root number and a decreased nodule number (Figure  1A ). These phenotypes corresponded to the previously described "compact root architecture" mutant phenotypes  (Laffont et al. , 2010; Huault et al. , 2014) , and accordingly, Tnt1 flanking sequence tags available in the M. truncatula Mutant Database at the Noble Foundation revealed a Tnt1 insertion in the MtCRA2 locus (Medtr3g110840) in the NF0903 mutant line, which was located between G 1785 and G 1786 in the open reading frame, causing the knockout of MtCRA2 (Supplemental Figure  1A ). However, no Tnt1 flanking sequence tag was associated with this locus in the NF0805 mutant line, but sequencing of the MtCRA2 open reading frame revealed that the missing A 922 caused premature termination at Ser 323 (Supplemental Figure  1A ).