dataesr/scientific-paragraphs-categorization huggingface dataset:
D. G. , X. B. , S. C. , M. F. and J. L. acknowledge their roles as ESA-appointed CHEOPS science team members. This project has received funding from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation programme  (project  FOUR ACES ; grant agreement No  724427 ). It has also been carried out in the frame of the  National Centre for Competence in Research PlanetS  supported by the  Swiss National Science Foundation  (SNSF). DE acknowledges financial support from the  Swiss National Science Foundation  for project  200021_200726. The Belgian participation to CHEOPS has been supported by the  Belgian Federal Science Policy Office (BELSPO)  in the framework of the  PRODEX Program , and by the  University of Liège  through an  ARC grant for Concerted Research Actions  financed by the  Wallonia-Brussels Federation ; L.
D. is an F. R. S. -FNRS Postdoctoral Researcher. A. C. C. and T. W. acknowledge support from  STFC  consolidated grant numbers  ST/R000824/1  and  ST/V000861/1 , and  UKSA  grant number  ST/R003203/1. S. H. gratefully acknowledges CNES funding through the grant  837319. This work was also partially supported by a grant from the  Simons Foundation (PI Queloz , grant number  327127 ). Y. A. and M. J. H. acknowledge the support of the  Swiss National Fund  under grant  200020_172746. M. L. and B. A. acknowledges support of the  Swiss National Science Foundation  under grant number  PCEFP2_194576. S. G. S. acknowledges support from  FCT  through  FCT  contract nr. CEECIND/00826/2018  and  POPH/FSE (EC). We acknowledge support from the  Spanish Ministry of Science and Innovation  and the  European Regional Development Fund through grants  ESP2016-80435-C2-1-R ,  ESP2016-80435-C2-2-R, PGC2018-098153-B-C33 ,  PGC2018-098153-B-C31 ,  ESP2017-87676-C5-1-R , MDM-2017-0737  Unidad de Excelencia Maria de Maeztu-Centro de Astrobiología (INTA-CSIC) , as well as the support of the  Generalitat de Catalunya/CERCA  programme.
The MOC activities have been supported by the  ESA  contract No. 4000124370. S. C. C. B. acknowledges support from FCT through FCT contracts nr. IF/01312/2014/CP1215/CT0004. A. Br. was supported by the  SNSA. This project was supported by the  CNES. This work was supported by  FCT -Fundação para a Ciência e a Tecnologia  through national funds and by  FEDER  through  COMPETE2020 -Programa Operacional Competitividade e Internacionalizaç  ao by these grants:  UID/FIS/04434/2019 ,  UIDB/04434/2020 ,  UIDP/04434/2020 ,  PTDC/FIS-AST/32113/2017 & POCI-01-0145-FEDER-032113 ,  PTDC/FIS-AST/28953/2017 & POCI-01-0145-FEDER-028953 ,  PTDC/FIS-AST/28987/2017 & POCI-01-0145-FEDER-028987 ,  O. D. S. D. is supported in the form of work contract ( DL 57/2016/CP1364/CT0004 ) funded by national funds through FCT.
B. -O. D. acknowledges support from the  Swiss National Science Foundation  ( PP00P2-190080 ). M. F. and C. M. P. gratefully acknowledge the support of the  Swedish National Space Agency  ( DNR 65/19 ,  174/18 ). D. G. gratefully acknowledges financial support from the  CRT foundation  under Grant No. 2018. 2323"Gaseousor rocky?Unveiling the nature of small worlds". M. G. is an F. R. S. - FNRS Senior Research Associate. This work was granted access to the HPC resources of MesoPSL financed by the  Région Île-de-France  and the project  Equip@Meso  (reference  ANR-10-EQPX-29-01 ) of the programme Investissements d'Avenir supervised by the  Agence Nationale pour la Recherche. P. M. acknowledges support from  STFC  research grant number  ST/M001040/1. L. Bo. , G. Br. , V. Na. , I. Pa. , G. Pi.
Finally, the SA score, for synthetic accessibility score,  16  is a heuristic based score where molecular complexity and fragment contributions are used to evaluate synthetic tractability. Low SA scores indicate less complex molecules and consequently more feasible compounds. To address some of the challenges of synthesizability estimation and to help synthetic, medicinal, and computational chemists in CADD projects and related fields, Iktos has developed Spaya, 19 a template-based retrosynthesis AI software that computes synthetic routes and ranks them based on a synthesizability score. In this paper, we describe the Retro-Score (RScore), a synthetic feasibility score derived from the output of a full Spaya retrosynthetic analysis for a given molecule, and we compare it with three other synthesizability scores known in the literature (RA score, SC score and SA score).
Datasets The ChEMBL 24  20  dataset was used, with the same post-processing as described in the Guacamol Benchmark experiments. 9  The post-processed ChEMBL dataset can be downloaded from the following link. 21  Another dataset, that we have named 'Pi3K/mTOR',  22  was also used. It is a library of 463 structurally homogeneous molecules containing values of IC50 for the two targets Pi3K (pKi measured on the Phosphoinositide 3-Kinase) and mTOR (pKi measured on the mechanistic Target Of Rapamycin), from the Chembl database. After the definition of a threshold of activity, pIC50 Pi3K ≥ 7 and pIC50 mTOR ≥ 8. 5, the molecules active for both targets were removed. The dataset is accessible in the GitHub project associated with this paper. 23  The RScore from Spaya API The score of a retrosynthesis route in Spaya is a proprietary score composed of four separate scores as follows, score(route) = f (d, p, c, a) (1) where:  d = number of The score is rounded to one decimal, and hence can take 11 different values (from 0.
Prediction of RScore The RScore1min computation implies a full retrosynthesis, which is time consuming, with an average of 42 seconds per molecule to trigger the early stopping. For that reason a regression model was built, with the goal of replacing the computation of the RScore1min with a simple neural network inference. The dataset used was composed of 70K molecules from the pre-processed ChEMBL dataset, and 300K molecules sampled from the generator Guacamol pre-trained on ChEMBL. The molecules were represented by real vectors of the ECFP2 fingerprints with a radius of 2, modulo-folded to size 8192 and then ln(x + 1)-pre-processed. The dataset was split into a training set (90%), a validation set (5%), and a test set (5%). To build this continuous predictor of the RScore1min, a neural network was trained on features of the molecules.
Generations of molecules For all the generations, the package Guacamol 30 provided by BenevolentAI was used. The generator is a Recurrent Neural Network, containing three layers of Long Short-Term Memory (LSTM) of size 1024. The network was initialized with the weights given by Guacamol on their GitHub project, 30 which was obtained by training on the large dataset ChEMBL 24. 20  For each generation, the reward used was a geometric mean of the different scoring functions on which modifier functions (described in Score modifiers section) were applied. The generators were optimized in order to sample molecules that have a good reward. The optimization algorithm used was the Hill Climbing MLE 1 , in which at each step 1024 molecules are being sampled from the generator, then scored, and 2 epochs of teacher forcing 31 are performed on the top scored 152 molecules.
Overall 49 generations were run: 3 generations for in-silico validation of the RScore (presented in the next section), 40 Guacamol generations (one generation without synthetic constraint and three with synthetic constraint for each of the 10 tasks), and 6 Pi3K/mTOR generations (one generation without synthetic constraint and five with synthetic constraint). The implementations of those generations can be found on GitHub. 23  In-silico validation of the RScore In this section the selected synthetic scores of the literature are evaluated regarding their quality as proxies of synthetic accessibility. This experiment serves as a first justification for using RScore3min as ground truth of synthetic accessibility in the other experiments described in the paper. The experiment consists in : 1) Sampling molecules from 3 different similarity constrained generation runs 2) Selecting a bench of molecules from those samples for feasibility assessment 3) Asking chemists to label each molecule as either feasible or not feasible 4) Assessing how well the different scores discriminate feasible and non feasible molecules as assessed by chemists The generator used was exactly the one presented in the previous section, and the reward was Tanimoto Similarity on ECFP4 fingerprints (computed with a radius of 2 and 8192 bits) to a target molecule.
The number of hill climbing steps was 300. The three reference molecules selected were imatinib, acetylsalicylic acid and a molecule from the Pi3K/mTOR dataset. Reference molecules and their associated synthetic feasibility scores are displayed in Table  1. At the end of each generation, 100 molecules were randomly chosen among molecules with Tanimoto Similarity to the reference molecule higher than 0. 8. Over those 100 molecules, 5 were randomly selected with RScore3min ≥ 0. 5, and 5 others with RScore3min = 0, when it was possible. This led to a dataset of 30 molecules. Seven chemists were asked to blindly label molecules as either feasible (label 1) or not feasible (label 0). The final label of a molecule is the label given by the majority of chemists. This label is considered as a ground truth of synthetic feasibility.
Generations without any synthetic accessibility constraint Ten generations were performed using the standardized Guacamol Benchmark. Molecules were generated over 20 epochs on each of the 10 MPO tasks of the Guacamol Benchmark, which are: Osimertinib MPO, Fexofenadine MPO, Ranolazine MPO, Perindopril MPO, Amlodipine MPO, Sitagliptin MPO, Zaleplon MPO, valsartan SMARTS, Deco Hop and Scaffold Hop. Each task is associated with an objective function, the description of each task can be found in the original paper. 9 The next generation aimed at solving a lead optimization problem on the Pi3K/mTOR dataset. The constraints for this task were the Tanimoto similarity of ECFP4 fingerprints to the initial dataset, the Quantitative Estimate of Drug-likeness (QED), 32 and predicted Pi3K and mTOR pKi values.
(  4 ). Score(mol) = GeoM ean score 1 (mol),. , score 5 (mol) (4)  where: smarts 1 = c1cncc(c1)C#Cc1cncnc1 (3) GeoM ean(x 1 ,. , x n ) = n i=1 x i 1 n = n √ x 1 x 2 • • • x n (5) The prior model was the one trained on ChEMBL, then two steps of transfer learning were run on the Pi3K/mTOR dataset in order to remain within the applicability domain of the QSAR regressors. For the training part, the batch size was 1024, the learning rate 1e-3 and the generation run over 250 epochs.
Results and discussions In this section, first we compare the values of the different synthetic scores on molecules from the ChEMBL dataset, then we evaluate the performance of the RScore1min predictor (RSPred), then we analyze the results of the in-silico validation of the RScore3min, and finally we analyze the results of the different generations with and without synthetic constraints. It can be seen that few synthesis steps (fewer than 6) is a necessary condition for having a good RScore, though the contrary is not true. For instance a 2 steps route may have a bad score due to disconnections with low predicted probabilities. Indeed, the scoring function in eq. (  1 ) considers other elements than the number of steps to evaluate the route.
Comparison of synthetic scores As previously discussed, existing literature scores designed to estimate synthesizability do not perform a full retrosynthetic analysis of the target molecule. Those scores were compared on a bench of molecules in order to analyze the extent to which they agreed with one another. On the ChEMBL dataset sample, the RA score (fig. 4 ) often predicts a score of almost 1. Hence, this score is not useful to measure the difficulty of synthesis of feasible compounds (fig. 5 ). This can be explained by the fact that the model computing the RA score was trained on a subset of ChEMBL. The SA score is significantly correlated to the RScore1min (fig. 6 ). Having a good SA score seems to be a sufficient condition to have a good RScore, while the contrary is not true: molecules with complex fragments will often have a bad SA score, even if they are synthesizable.
Evaluations of generations performed on the Pi3K/mTOR dataset This task is a generation around a library of 463 structurally homogeneous Pi3K and mTOR inhibitors. The objective and targets can be found in table 2. This dataset serves as a simplified proxy for a real life MPO in a lead optimization project with four objectives to be optimized (table  2 ). Six generations were run based on this dataset: one without any synthetic score constraint, and five with synthetic score constraints (RA, SC, SA, RScore1min, and RSPred). When looking at the evolution of each component of the score among epochs in Figure  S2 , it can be noted that the reward increases and saturates systematically around epoch 60.
When used as a constraint in the reward of a generation, most molecules get a high RA score, so the generator cannot be optimized towards easier to make molecules. The SC score has no correlation to the RScore3min, so it comes as no surprise that generation under SC score constraint fails to optimize the RScore3min during the generation and gives poor results. This work has several limitations: first, we acknowledge that the validation of the RScore as a good synthetic feasibility score has been performed on a small number of molecules (30), and the validation dataset can be expanded. For such purpose, it would be a useful contribution to the community to develop and make available benchmark datasets of generated molecules with synthetic feasibility labels assigned by chemists which could be used to assess the value of synthetic feasiblity scores in a generative chemistry context.
Second, the example use case with RScore1min as a synthetic constraint during complex MPO generation was conducted on only one dataset. The reason for this is the difficulty to find adequate publicly available datasets which are representative of the challenges of multi-parametric optimization in real-life lead optimization projects. We found the MPO datasets and tasks available in the Guacamol benchmark trivial to solve, and therefore not adequate for our purpose. Additional work has been performed by Iktos on other MPO datasets (not disclosed), showing similar results and conclusions aligned with the Pi3K/mTOR experiment. Third, in all our experiments of generations under synthetic constraint, we consider the "ground truth" of synthetic accessibility to be the RScore3min, which creates a strong bias, since by construction the RScore1min is strongly correlated to the RScore3min.
Conclusion Molecular generation methods are known to produce unrealistic structures which can be impossible to synthesize, and known synthetic scores often fail to address that issue. In this paper, we introduce a new synthetic accessibility score, RScore, derived from Spaya, 19 a data-driven synthetic planning software developed by Iktos. The main advantage that distinguishes RScore from other synthetic scores is that it is computed from the output of a full retrosynthetic analysis performed by Spaya. We show on a limited validation dataset that the RScore correlates very well, and better than other synthetic feasibility scores, with the assessment made by seven chemists regarding the synthetic feasibility of generated molecules. An important feature of the RScore is that it can be customized to better reflect the synthetic constraints of real life situations: the user can impose intermediate products to be in the routes, limit the number of steps, and customize the list of starting materials or the reaction space.
In a relatively difficult MPO task where generations under constraint of different synthetic scores were compared, RSPred constrained generations gave the best results second to RScore. We feel that RSPred strikes a good compromise, producing good results while being fast to compute. However, just as any machine learning model, the RSPred predictor has an applicability domain, in this case that of the ChEMBL dataset on which it was trained. Although the RSPred results were good in our experiment, this may be explained by the fact that the initial chemical space was already within the applicability domain of the predictor. In other cases, when the initial chemical space is far from ChEMBL, the predictor may have poor results and might lead the generation to an area of false positives. To address that issue, a preliminary fine tuning of the predictor on the chemical space of the generation might be helpful, if not necessary, to make sure the predictor's performance is still sufficient.
The ATLAS EventIndex system comprises the catalogue of all events collected, processed or generated by the ATLAS experiment at the CERN LHC accelerator, and all associated software tools to collect, store and query this information. ATLAS records several billion particle interactions every year of operation, processes them for analysis and generates even larger simulated data samples; a global catalogue is needed to keep track of the location of each event record and be able to search and retrieve specific events for in-depth investigations. Each EventIndex record includes summary information on the event itself and the pointers to the files containing the full event. Most components of the EventIndex system are implemented using BigData free and open-source software. This paper describes the architectural choices and their evolution in time, as well as the past, current and foreseen future implementations of all EventIndex components.
For LHC Run 2 and Run 3, L2 and EF were merged into a single system, the High-Level Trigger (HLT), implemented in software running on commercial processors. In order to keep the possibility to select rare physics processes, events satisfying triggers matching common physics processes or used for monitoring were prescaled, i. e. reduced randomly in number in order to save output bandwidth. The trigger configurations and the prescale factors applied to each trigger type were recorded in the trigger database for each run  [3]. Trigger decisions were stored in event data files as trigger masks, where each bit corresponds to the specific set of trigger selections (trigger chains). Depending on the trigger configuration, the same bit in the trigger mask (chain counter) may correspond to a different trigger chain.
The relation between chain name and counter is uniquely defined in the trigger database table, indexed by the trigger key (SMK). Trigger keys depend on the run number for the data recorded by the detector and on the production settings for Monte Carlo simulation. The events recorded by the ATLAS detector are transferred in real time to the CERN computer centre and processed within 48 h from the end of a run using the ATLAS "Tier-0" cluster. This procedure consists of calculating the time-dependent detector calibration and alignment parameters, and then using them to compute for each event the physical quantities of interest for the final analyses. The events can be re-processed when improved reconstruction algorithms or detector calibration and alignment constants become available, usually at the end of each major data-taking period; the result is the creation of additional versions of the same events, some of which replace older versions.
Every unique file, regardless of its format, is assigned a distinct GUID (Globally Unique IDentifier [5]), which is used to catalogue and retrieve it. Currently ATLAS has over 100 million files on disk, containing over 400 billion event records. Files are grouped into datasets that can be hierarchically assembled into containers. The distributed data management system Rucio  [6]  is used to keep track of each file, dataset and container, including their properties (metadata) and replica locations, as well as to manage the data movements between different storage sites and the CPU farms where the data are processed and analysed.
Need for an Event Catalogue Rucio is extremely efficient at managing 100 million files stored in 120 sites world-wide and using over 200 PB of disk space and similar quantities of tape storage space. Rucio allows analysers to easily access data and simulation samples using the existing organization of files in datasets and containers, but it does not store any information about individual events. Nevertheless there is also a need to be able to retrieve different versions of one or a few events, given the often reduced information contained in the last data reduction stages, either to produce nice event displays for publications, or to check in detail if all reconstruction procedures worked as expected. The EventIndex was designed for this primary use case (quick and direct event selection and retrieval), but the same system can fulfil several other tasks, such as checking the correctness and completeness of data processing procedures, detecting duplicated events that can occur for temporary faults of the data acquisition or processing procedures, studying trigger correlations and the overlaps between selected data streams.
The EventIndex is the second-generation event catalogue for ATLAS. The first-generation catalogue deployed for LHC Run 1 was called the "TAG DB"  [7]. Its content was based on the direct import of event-wise information from ATLAS TAG files into an Oracle [8] database to facilitate queries of all events across entire datasets, which could speed up the analysis workflow. TAG files were thumbnails of the AOD format files produced in the final stage of the central production chain. The TAGs contained, in principle, sufficient information for identification and selection of events of interest to most physics analyses for the purpose of subsequent event skimming, i. e. the pre-selection of events based on any of the TAG quantities before accessing the full AOD file content. There were generally two problems with the TAG database: 1.
TAG information included immutable content (such as event identification and trigger decisions) as well as mutable content (basic physics quantities such as the number of loose electron candidates and their kinetic information). The inclusion of the mutable content was problematic because in practice, recalibrations and software improvements were made in post-processing or reprocessing steps, which skipped the production of new TAG files, so the TAG DB mutable content became out-of-date (stale) for accurate event selection based on that content. There was no easy way to refresh mutable content without fresh TAG files. 2. The TAG database structure was, for simplicity, dictated by the TAG files because the skimming functionality was based on being able to produce TAG files from the database.
This meant that mutable content could not be easily separated from the immutable content, so all content was put into single database tables with hundreds of columns. To enable fast queries based on any of the content every column was indexed, which was a very heavy implementation on the database side, requiring a lot more storage than was ever actually used due to the first problem. While the mutable content became a dead weight on the system, there were many use cases for the immutable content which were utilized. An inherent problem with the TAG DB was the dependence of the system on the ATLAS production processing chain to produce TAG files with each iteration of recalibration and software improvements which was rarely fulfilled (except in full reprocessing after years of data taking).