dataesr/scientific-paragraphs-categorization huggingface dataset:
GAN can be associated with reinforcement learning to optimise properties, while using their discriminator to evaluate the likeliness of the solutions  [6, 18]. This setting provides credible molecules in the neighbourhood of the training dataset. Recurrent neural networks can also be tuned by REINFORCE  [19]  or Monte-Carlo Tree Search  [20, 21]  algorithms to optimise properties. Kwon et al. proposed recently a reinforced VAE for the generation of molecular graphs  [22]. Some authors also take advantage of the sequential nature of deep reinforcement learning to filter invalid solutions at each step and thus guarantee the validity of the generated molecules  [23, 24, 25]. These methods have been able to achieve higher performances by using increasingly complex architectures, which has led to a decrease in their interpretability.
Furthermore, only the work of Zhou et al. is independent of a starting dataset for training  [24]. There is renewed interest with recent evolutionary methods leading to competitive results  [26, 27, 28]. This interest is motivated by their simplicity as well as their higher level of interpretability. In evolutionary algorithms, the chemical subspace to be explored can be defined through the choice of the domains and operators. These rules can be set by different approaches, such as a grammar  [26, 28]  or a statistical definition of mutations  [27]. Recent evolutionary algorithms tend to use mutations closer to the atomic level, as it allows a smoother exploration of the chemical space. The implementation of such methods was made possible by the emergence of tools such as RDKit, simplifying the programming and allowing for easy sanity testing of the molecules  [29].
The objective of our work is to design a molecular generator capable of exploring known as well as unfamiliar areas of the chemical space. Between drug-like generation and organic materials, the chemical space of interest is different  [30]. The molecular materials space is less known and has probably been only intensively searched around the few known successes. Thus, our method must be flexible to adapt to very different problems. Furthermore, we have previously found that quantum mechanics datasets for small organic molecules (QM9 and PC9) present generalizability issues  [31]. There is currently no reliable and diverse training dataset for organic materials. Therefore, our method has to be able to work with or without the influence of prior data and knowledge. Moreover, the exploration should be as interpretable as possible to allow for structure property studies and for chemical interpretation of the building process.
In the original article, these properties are normalised on a subset of the ZINC dataset  [40] , but it has also been optimised without normalisation  [24]. Likewise, we note plogP ‡ the normalised version. We have adapted the implementations of You et al. and Zhou et al. respectively  [23, 24]. We also use our method to optimise the recently proposed CLscore  [35]. It is another drug-likeness evaluation metric, based purely on the structural similarity with a subset of biologically active molecules in the ChEMBL  [41]. To define the CLscore, weights are assigned on molecular subgraphs, named shingles, proportionally to their representation in the chosen subset of ChEMBL. The score of a molecule is computed by performing the mean of the weights of its shingles. The shingles take into account the circular substructures but contrary to the SAscore, the CLscore does not penalise explicitly uncommon rings and numerous stereo centres.
The best run column contains the values of the run with best total score across all 30 runs. The best scores column corresponds to the best score for each single benchmark independently of the run. First, it can be observed that the execution of EvoMol starting from methane has an important liability on some tasks, although it performs very well on others. Especially, it obtains a null score on the Valsartan SMARTS benchmark. This can be easily explained, as this problem is defined as a geometric mean containing a binary constraint on the presence of a complex structure. Therefore, our model with no prior knowledge is not guided to find the structure and remains at the lowest score. A single molecule with this structure as a starting dataset would be sufficient to allow our method to go beyond this minimum.
Case 3: HOMO/LUMO optimisation The last case consists in optimising an electronic property. The frontier molecular orbital levels are key points for any reactivity problems, electroactive molecules and electronic or photonic organic materials. So, we choose to focus on the HOMO and LUMO energies. The energy levels are obtained with a geometric optimisation calculation in DFT. In a previous article we studied the QM9 and PC9 datasets that together encompass more than 200k different molecular calculations with up to 9 heavy atoms of C, N, O and F types  [31]. Initially computed with different methods, we relaunched them using our BOINC collaborative computing project, called QuChemPedIA@home, in order to have a homogeneous and clean dataset. The Figure  8  presents the distributions of these MO energies in the union of QM9 and PC9.
One could hope for a fast evaluation of quantum mechanics properties thanks to machine learning predictions to limit the cost of computation. However, we have demonstrated that the currently available datasets of molecular quantum chemistry results, like QM9 and PC9, are not diverse enough to train a general predictor  [31]. It is clear that solving this issue in the future would significantly accelerate the generation of molecules with such objectives. Meanwhile, DFT calculations are mandatory for the exploration process in this problem. The data for methane are highlighted in the Figure  8  to show that this molecule has one of the lowest HOMO energies and one of the highest LUMO energies. It is a very poor candidate choice when the specification is often an ability to give electrons (high energy HOMO) or an ability to yield electrons (low energy LUMO).
We have therefore tested the ability of EvoMol to optimise the HOMO energy (to the highest) and LUMO energy (to the lowest) starting from only a methane molecule. To make the optimisation tractable, we set the population size to 20 and the number of replaced individuals at each step to 2. The solutions can have up to 9 heavy atoms of the same kind as QM9 and PC9. The Figure  9  presents the best five solutions of the QM9 and PC9 datasets (without radicals and zwitterions) and those obtained with EvoMol. For the LUMO energies, QM9 and PC9 lowest values correspond to highly nitrogenous cycles and carbonyl groups. It is worth pointing out here that the compounds 1 and 3 correspond probably to very strained structures due to cumulated double bonds in a 5-member ring, and that the tetranitrogen is also very unstable.
Conclusions In this article, we present EvoMol, an efficient evolutionary algorithm for molecular generation. By design, it generates only valid and unique solutions. EvoMol can be used with a maximum population size of one molecule. In optimisation, this corresponds to a very naive approach called the hill-climbing algorithm. This simple climber finds a direct pathway to very good solutions for classical objective functions (QED, penalised logP). Therefore, it showcases the limitations of such objectives as benchmarks. EvoMol can also generate large datasets of high scoring solutions, by intensifying thoroughly on promising areas of the chemical space. We show in this article that EvoMol is highly configurable and provides state of the art performances for both classical drug design (QED, penalised logP, SAscore, GuacaMol benchmarks) and molecular material problems.
Contrary to many methods, EvoMol does not require prior knowledge extracted from a dataset to obtain high scoring solutions. It can therefore tackle very different problems and explore different chemical subspaces depending on the objective. We demonstrate that in EvoMol, bias can be strictly controlled. Prior knowledge can be introduced easily through the objective function or the starting dataset. The mutation operator is composed of 7 general atom centred actions that define an interpretable neighbourhood on the molecular graph. As the exploration process only depends on this operator, it becomes thoroughly traceable and allows for chemically meaningful visualisations. This interpretability will be useful for further fine-tuning of the exploration process. The optimum found with EvoMol highlighted several limitations on the commonly used objective functions.
Acknowledgements The calculation resources were provided by the  LERIA  and  MOLTECH-Anjou laboratories. The authors would therefore like to thanks  Jean-Mathieu Chantrein  for his technical help. TC and BDM would especially thanks the  BOINC community , since the more than 200k compounds corresponding to the union of the QM9 and PC9 datasets (used in Figure 8 have been recalculated at the  B3LYP/3-21G  level of theory using our BOINC collaborative computing project, called QuChemPedIA@home (https://quchempedia. univ-angers. fr/athome/).
The Electromagnetic Calorimeter (ECAL) is one of the subdetectors of the Compact Muon Solenoid (CMS), a general-purpose particle detector at the CERN Large Hadron Collider (LHC). The CMS ECAL Detector Control System (DCS) and the CMS ECAL Safety System (ESS) have supported the detector operations and ensured the detector's integrity since the CMS commissioning phase, more than 10 years ago. Over this long period, several changes to both systems were necessary to correct issues, extend functionality and keep them in-line with current hardware technologies and the evolution of software platforms. Due to the constraints imposed on significant changes to a running system, major hardware and software upgrades were therefore deferred to the second LHC Long Shutdown (LS2). This paper presents the architectures of the CMS ECAL control and safety systems, discusses the ongoing and planned upgrades, details implementation processes and validation methods and highlights the expectations for the post-LS2 systems.
Introduction The CMS ECAL detector  [1]  is composed of a scintillating crystal calorimeter and lead/silicon preshowers. The detector is divided into three major partitions known as the ECAL Barrel (EB), the Endcaps (EE) and the Preshowers (ES). The EB and EE partitions are subdivided in smaller partitions as follows: 36 super modules in the barrel and 4 Dees in the Endcaps. Each of these EE/EB partitions contain a set of four paired thermistors and a water leakage sensor to provide environmental information. This data is used by the ECAL Safety system (ESS) to protect the detector from multiple hazardous situations: e. g. temperature overheating when the detector is powered on. The ESS also monitors a set of digital input signals (DIs) to protect the detector from external conditions such as cooling system faults or changes in the CMS solenoid magnetic field that could damage the crystal photo-sensors.
In total, the ESS monitors 352 thermistors, 4 water leakage sensors and 96 DIs. The ESS implements protection mechanisms through Siemens Programmable Logic Controllers (PLC)  [2]. The EE/EB partitions are monitored by a single redundant controller, known as the ESS PLC. In its original configuration, the ESS PLC was designed to acquire environmental information using a custom middle hardware approach (readout units). These readout units can interface the detector from the CMS experimental cavern and retransmit data to the PLC at the service cavern, protected from the experiment's radiation field. This particular approach requires the usage of serial communication interfaces (RS-485) and a custom communication protocol to operate. After more than 10 years of operations, additional requirements were identified.
The ECAL Safety System upgrade The replacement during the LS2 of the previous ESS sensor readout system (with custom readout units) by industrial analogue input (AI) modules is the cornerstone of the CMS ECAL Detector Control System (DCS) upgrade plan  [4]. In contrast to the custom readout units, the new AI modules introduce a fully transparent acquisition method of the environmental information. The resulting hardware setup removes the 12 readout units and the RS-485 interfaces, introducing instead a total of 45 AI modules across six rails. The AI modules are standard SIEMENS certified peripherals connected through the profibus  [5]  communication buses. This type of connection provides access to extensive diagnostics information and enables a full sensor's readout at a very quick sampling rate (approximately 100 milliseconds, compared to the initial 23 seconds).
This hardware modification does not only alleviate the PLC program from having to support a complex communication protocol, but also provides the PLC with a fresh snapshot of the environmental data at every cycle. Following the update of the readout method, the ESS PLC was reprogrammed with a completely new software based on the CMS PLC framework. The CMS PLC framework allowed the developers to re-implement the features of the original system and to introduce the new ones, while reducing the overall system complexity.
The CMS PLC framework The CMS PLC framework (also known as the CMS Tracker PLC framework) is a compilation of tools to develop PLC-based control applications for particle detectors. The framework consists of two main parts: the PLC program and a configuration toolkit to monitor the PLCs from the supervisory layer. The PLC program is written in a high-level language, the Siemens Structured Control Language (SCL)  [6]. The PLC framework does not model specific applications directly. It focuses instead on modelling several types of devices, which are commonly used across the CMS experiment. The framework provides a set of basic data structures with more than 30 types of device definitions (PLCs, sensors, relays, DIs, etc. ). The toolkit can be easily extended, allowing developers to introduce new definitions and using existing ones as templates.
CMS PLC toolkit The CMS PLC toolkit is a WinCCOA [7] application that encloses knowledge from the PLC. Among other things, this toolkit provides a massive configuration tool to help mapping large collections of objects into the DCS. The toolkit requires a set of configuration files with the list of inputs and outputs channels connected to the PLC. This information is stored in the DCS, using specific data structures known as data points. Each channel is represented by three different data points, identified by a numeric triplet and the following suffixes: "read", "write" and "readback". The numeric triplet refers to the crate, module and channel used in the hardware setup, while the suffixes refers to the data access mode. The toolkit provides a library of device definitions with various types of PLC models, sensors and other device definitions using the JCOP  [8]  convention.
Environmental data The ESS has been designed to monitor 352 temperature sensors and water-leakage sensors distributed across the EE and EB partitions. In the past years, four temperature sensors presented readout problems and were disabled. However, during the current LS2, these four sensors seem to be recovered after the removal of the middle readout hardware. They will be closely monitored during the re-validation of the ESS and considered for inclusion into the action matrix by the end of the LS2. Inside the PLC, temperature sensors are modelled as objects with multiple attributes such as quality flags, the probe identifiers or a range of alarm thresholds (upper and lower thresholds). These data structures are, in most of the cases, sufficient to store sensor's information. However, the ESS specification requires two upper alarm thresholds to implement a multi-layered set of actions on temperature sensors (see figure  3 ).
Individual temperature thresholds One of the main features introduced in this version of the software is the individual temperature thresholds. In the legacy system, alarm thresholds were configured in groups of eight sensors (per Supermodule or Dee) without an adequate calibration. A thorough analysis of the archived data was done to extract the nominal values of the air temperatures inside the detector at standard operational conditions. Using these values as reference, the alarm thresholds were adjusted for each sensor, to trigger interlocks at +4°C and +8°C over the nominal temperatures. This adjustment will result in a quicker reaction of the PLC in the event of detector overheating. The calculations, based on a real overheating event, estimate the reaction of the PLC after 5 minutes overheating, instead of the 20 minutes observed in the original system.
Digital inputs Most of the features of the PLC program are based on the standards of the CMS PLC framework. However, there are some functionalities that differ significantly from these standards. This is the case for the DI alarms. In the current version of the software, the DI objects contain a few additional elements to store the following data: 1) flags to register deviations from the normal state ("in alarm" state), 2) flags to set the DI "in alarm" state (which means that the state is abnormal) and, 3) timers to register for how long the DI has been in alarm. The fact that a specific timer runs out means that the DI has been in an abnormal state longer than the admissible time. Once the timer expires, any interlocks associated with the DI will be triggered. Similar to the acknowledgement mechanism of the sensor alarms, once a DI object reports a timed-out alarm state, interlocks are set and cannot be removed until the DI resumes to its normal state.
The ESS supervisory software The ESS supervisory software is part of the CMS ECAL DCS applications. In the CMS experiment, the DCS applications are implemented using the SIMATIC WinCCOA platform, mostly written in its native programming language known as control language (CTRL). A new version of the ESS/DCS application was implemented to accommodate the changes in the PLC program's data. Inputs and output channels are modelled inside the PLC data blocks as objects, which in turn are mapped as data points in the DCS using the configuration toolkit. The new data structures do not provide the complex functionality required by the CMS ECAL DCS by themselves. They need to be grouped into logical units according to the distribution of the hardware within the detector, to give the feeling of a whole (e.
g. Supermodule is the aggregation of 4 relays, 8 thermistors and 1 water leakage sensor). To achieve this feature, the ESS/DCS application has been structured in layers, separating the presentation layer (user interfaces, scripts, etc. ) from the data access layer (backend to manipulate data). The software backend has been implemented as an application programming interface, so that the ESS data can be used in a coherent way across any of the CMS ECAL DCS applications. The ESS data is used in the DCS by a variety of applications. Among other things, the data need to be archived, displayed, processed and monitored at different levels of the architecture. More concretely, the ESS data are used by several applications to execute preventive automatic actions, configure alarms and notifications, interact with interlock system, and to display the status of the detector from the safety point of view.
Automatic software testing A test setup was built in the ECAL labs using a mock-up of the CMS ECAL DCS and a test PLC. This setup has been used for the following purposes: 1) automatic testing of part of the PLC functionality 2) unit testing of the DCS software and, 3) integration tests into the CMS ECAL DCS environment. As mentioned before, the programming of the PLC using the CMS PLC framework is reduced to a matter of configuration. This means, that one of the main aspects covered by the testing procedures is to ensure the correctness of the PLC matrix. To this purpose, a unit test program was developed to extract and compare data from the PLC, verifying the correct configuration of the PLC: This includes the 702 individual threshold alarms for the thermistors, probe identifiers and the physical output addresses of the interlock system.
Conclusion The adoption of industrial equipment for the readout of environmental information does not only solve the limitations identified by the developers during the analysis phase. This modification also brings multiple other benefits such as standardization, provisioning and support from the vendor. The replacement of the PLC program using the CMS PLC framework enables the ECAL detector to comply with all the new requirements, while making the system simpler and easier to maintain. After this migration, the ESS is part of the pool of CMS PLC framework applications, sharing the knowledge and experiences about the system with the rest of the community. Many relevant details about the system have been disclosed, documented and brought to the supervisory layer, resulting in a more intelligent and self-descriptive system.
A new DCS software has been designed to provide a better user experience, with a good balance between technical information and detectororiented constructs, while respecting the concept of the original design. After almost two years of planning and development, and thanks to the collaboration between experts from different teams, the new version of the ESS has been deployed in August 2019. During this time, many hardware and software components of the architecture have been replaced, by better and more efficient ones. The first part of the validations is currently on-going. In this context, the DCS has proven to be a useful tool to identify and understand the different configurations of the detector during the interactions with the ESS. A second validation stage will provide us with sufficient information, confirming the correctness of the system according to the specification and the safety of the CMS ECAL detector for the next operational period.
A regional neural network-based method, "CANYON-MED" is developed to estimate nutrients and carbonate system variables specifically in the Mediterranean Sea over the water column from pressure, temperature, salinity, and oxygen together with geolocation and date of sampling. Six neural network ensembles were developed, one for each variable (i. e. , three macronutrients: nitrates (NO - 3 ), phosphates (PO 3- 4 ) and silicates (SiOH 4 ), and three carbonate system variables: pH on the total scale (pH T ), total alkalinity (A T ), and dissolved inorganic carbon or total carbon (C T ), trained using a specific quality-controlled dataset of reference "bottle" data in the Mediterranean Sea. This dataset is representative of the peculiar conditions of this semi-enclosed sea, as opposed to the global ocean.
These active autonomous networks have thus contributed to the progressive densification of databases of key variables at global scale  (Abram et al. , 2019). Some variables are presently almost systematically measured regardless of the acquisition platform, for instance physical data (temperature, salinity, pressure) and dissolved oxygen concentration (O 2 ). However, measurements from these autonomous platforms remain limited to a small type of biogeochemical variables, owing to the high cost of some sensors and technological limitations  (Bittig et al. , 2019; Chai et al. , 2020). Machine learning methods represent a promising way to fill these "observational gaps". They have the potential to predict, from variables systematically measured by autonomous platforms, variables still difficult to measure accurately and cost-effectively with these platforms (e.