dataesr/scientific-paragraphs-categorization huggingface dataset:
The program XOalign (Legrand, unpublished; https:// github. com/legrandp/xdsme/tree/master/XOalign) calculates possible crystal reorientation using kappa goniometry that can be exploited further for a new strategy calculation. The EDNA characterization module relies on various inputs, such as crystal and beam size, and the photon flux impinging on the sample. In most cases this is either stored as metadata in ISPyB and retrieved for analysis or provided directly by MXCuBE2. A successful characterization produces a 'diffraction plan', automatically added to the data collection queue. If required, the parameters for the diffraction plan data collection can be edited by the users via the 'Details' sub-tab before execution (x4. 3). 4. 3. 3. Helical data collection/characterization. Helical (also known as vector) data collection is performed by continuously rotating a crystal while, at the same time, translating it along a defined line or vector  (Flot et al.
Peak, inflection point and remote energies are automatically stored for the selected sample after each energy scan. X-ray fluorescence spectra are recorded and displayed in a similar way and automatically fitted using the PyMCA package  (Soleet al. , 2007). As for any other data collection, results are displayed in the 'Details' window. Here, moving of the cursor highlights the energy of emission lines and shows the element most likely to have produced it. Absorption-edge scans, X-ray fluorescence spectra and their results are also stored and displayed in the ISPyB database. 4. 3. 5. Advanced data collection. The data collection methods included in this area represent more complex data collection protocols that may require input from external data analyses and/or 'experiment descriptors' to define the actions to be carried out in subsequent steps of the protocol selected.
, 2009)  were used during user operations on a daily basis. The MAX IV team developed their own hardware object and evaluation environment for carrying out XRF scans using an Amptek silicon drift detector. Finally, all samples and related data acquisition and processing results were stored in the ISPyB LIMS database, and were accessible to users after their experiments. At the new MAX IV synchrotron (3 GeV storage ring), the MX team has been developing the next generation interface, MXCuBE3, in close collaboration with the ESRF  (Mueller et al. , 2017). The new MXCuBE3 has been deployed at the first MX-beamline (BioMAX) of the MAX IV Laboratory  (Thunnissen et al. , 2013)  and is used as the beamline control GUI during user experiments. While the hardware object layer of MXCuBE3 has been inherited from MXCuBE2, preserving a high downstream compatibility, a completely new and userfriendly interface for MXCuBE3 has been conceived as a web application.
Under the 'Advanced' collection method, mesh and serial helical-scan data collections [mesh scans with larger rotation angles per line  (Gati et al. , 2014) ] are offered. With small and intense beams, in combination with a high-frame-rate detector at P14, such collections often involve many tens of thousands of frames, requiring the customization of the representation of meshes. After delegating the scan execution to middleware TINE services (and further to the low-level hardware control), MXCuBE2 triggers automatic diffraction detection using the program DOZOR  (Popov & Bourenkov, 2016)  encapsulated in the EDNA plugin  (Incardona et al. , 2009). MXCuBE2 receives the results of the DOZOR analysis via XML-RPC and constructs and presents a diffraction heat map on-the-fly. The heat map is linked to the diffraction image display and provides a broad range of interactive functionalities for analysis and definition of centring points for subsequent data collections.
The overall status of the beamline is managed with a specific Beamline Supervisor TANGO DS. This supervisor defines a set of beamline configurations (or phases) corresponding to different operation procedures such as 'sample change', 'diffraction' or 'beam visualization', providing a robust machine state and safe operation. Furthermore, this implementation allows for a smooth future transition from MXCuBE2 to the web-based MXCuBE3. Test images are processed using EDNA running on a computing cluster at ALBA, and the results are uploaded to the ISPyB database and made available to users. Collected data are processed on the cluster using the autoPROC program from Global Phasing Ltd (Cambridge, UK)  (Vonrhein et al. , 2011). The default data processing is performed using standard parameters, with default resolution cutoffs based on CC1/2.
This entails skipping steps such as the design of strategies using multiple orientations adapted to the symmetry and orientation of each individual crystal. The rationale for this choice is that although such steps are known to have the potential of significantly boosting the quality of the final datasets, they would, in the current state of affairs, require human intervention and thus disrupt automation. GPhL's work on the implementation of fully automated expert protocols was initiated in July 2013 as part of a collaboration with Diamond focused on the I23 beamline, on which the curved geometry and the resulting aspect ratio of the PILATUS 12M detector made it absolutely necessary to use multiple-orientation strategies and to make their design completely automatic, with built-in avoidance of collisions as well as anticipation and remediation of shadowing by the goniometer.
This steering took place through a message bus connecting the workflow with GDA (the Diamond BCS), based on an abstract beamline interface intended to make the task of writing similar connections with other BCSs as simple as possible. Work aimed at creating such a connection with MXCuBE2 began in the summer of 2017 and was able to progress rapidly thanks to access to the MXCuBE2 source code and to its developers, provided by membership of the MXCuBE collaboration. In particular, the need to enlarge the internal execution queue of the old MXCuBE to accommodate the 'third-party design and control' paradigm proposed by GPhL was recognized and assigned a high priority by the developers, and that enlargement was a major structural component of the transition to MXCuBE2. The first live tests of this connection (with the Qt3 version of MXCuBE2) took place on the ESRF ID30B beamline in October 2017, and by May 2018 the GPhL team was able to successfully run remotely a similar (fully automated three-wavelength interleaved MAD) experiment to the one previously performed at Diamond.
Remote access Both MXCuBE and MXCuBE2 offer integrated remote access features  (Gabadinho et al. , 2010)  to the beamlines where they are installed. In the current remote access set-up, access to the local control computer is performed via dedicated software such as NX NoMachine, which connects to a dedicated machine inside the synchrotron site firewall and from there to the local control machine. Although remote control of MX beamlines is increasing, performance can suffer from deterioration in connection speed. In order to facilitate and improve remote access, MXCuBE is currently being redesigned as a web application called MXCuBE3. MXCuBE3 simplifies and speeds up remote-access procedures as it will not require any installation on the client (remote) side other than a recent version of a web browser and the ability of the client to connect to the beamline via a predefined port.
Discussion The MXCuBE Collaboration brings together different partners aiming for the development of a common beamline control environment for macromolecular crystallography experiments. The European MX user-community takes advantage of finding a very similar and intuitive graphical interface when performing their experiments at different beamlines. Currently the collaboration is developing a new interface (MXCuBE3) that can ensure the future sustainability of MXCuBE and permit the evolution of the graphical user interface over time. The software architecture is explicitly designed to facilitate the deployment on any hardware controller layer at different synchrotron sites and the necessary development for the implementation of new hardware and new data collection methods can easily be adopted by all MXCuBE Collaboration partner sites.
Funding information The ESRF-EMBL Joint Structural Biology Group (JSBG) and the ESRF Automation Task Force (ATF) are gratefully acknowledged for supporting the development. Parts of the work presented here were supported by European Commission 6th Framework Programme 'Life Sciences, Genomics and Biotechnology for Health'  (Integrated Research project BIOXHIT, Contract No. LHSG-CT-2003-503420) , by iNEXT, project number 653706, funded by the Horizon 2020 programme of the European Union and by Vetenskapsra ˚det (SwedSTRUCT and MAX IV -SOLEIL).
Results The implementation of Dry Martini. In this section we present a test of the numerical implementation of the force field in the software MUPHY  53. We verify that the structural properties governed by the intra-and intermolecular interactions reproduce those obtained from the original implementation in the Gromacs software (version 4. 5. 5). A dimer of POPC lipids was simulated by standard MD simulation for a few nanoseconds with temperature controlled by the Langevin thermostat and set to 310K. The probability distributions of the values taken by representative degrees of freedom in the dimer are plotted in Fig. 1  and compared to those extracted from a reference simulation carried out using Gromacs. The results show excellent agreement.
Å and transversal dimension = L 300 z Å. Several independent orientations of the nanotube were generated by rotating its axis and maintaining the centre of mass at a distance of 113 Å from the membrane surface. In our simulations the dynam-  Å (cyan circles). For each system the last part of the trajectory (800 ns) was divided into independent blocks of 100 ns. The diffusion coefficient D was obtained for each block from a linear fit of the MSD using a time window of 20-40 ns for the fit. The averages and standard errors were computed over the independent blocks. The continuous line represents a fit of the data performed according to the theory proposed in ref. 55. The fit was done using the bulk fluid viscosity set in LBMD, and the characteristic size of a lipid molecule =. R 0 5 nm. We also assumed the value of the interleaflet friction to be equal to what was obtained for the same CG model by Lyman et al.
Conclusions In this work we coupled the coarse-grained Dry Martini model for lipids  31  to the Lattice Boltzmann Molecular Dynamics technique  [41] [42] [43]. This is a precious combination since it naturally allows including hydrodynamic interactions while still preserving the computational gain related to the implicit solvent nature of the Dry Martini model. It was already demonstrated that the presence of solvent mediated correlations is a necessary ingredient to study biological systems at the mesoscale  35, 36, 75, 76  , including important processes involving membranes, such as lipid aggregation  35  , protein migration in proximity of membranes  37  , vesicle encounter and fusion  38. We first validated the implementation of the force field in the multi-scale simulation software MUPHY  53.
In some simulations, we explored the effect of different values of the friction coefficient γ in order for instance to tune protein diffusion in crowded conditions. Moreover when exploring the size effect on lipid diffusion in membranes we performed the simulations using a multiple-timestep scheme. The friction coefficient used for the lipids was γ =. 0 00025 fs -1 31. In the present implementation all the simulations were performed using a constant volume/constant temperature scheme (NVT). Systems and simulation setups. All simulations were performed using the code MUPHY  53. For verification purposes, comparisons with the original Dry Martini implementation in Gromacs  79, 82  were performed. The setup of the studied systems is provided below. Bilayers. The POPC lipid bilayers were generated using the tool Insane provided with Martini 83.
A total of 10 5 steps of steepest descent minimisation followed by NVT equilibration lasting 50 ns were performed with the Gromacs software (v 4. 5. 5). The equilibrated systems were used to start the LBMD simulations. In order to study system size dependence of the diffusivity of the lipid molecules in the membrane we have assembled several bilayers with lateral sizes = L L x y ranging from 100 Å up to 400 Å. All assembled systems have a surface area per lipid of. 69 4 Å 2. Nanotube. To simulate the adsorption of a carbon nanotube into a membrane we followed the approach designed by Bhaskara et al. 84  based on the Martini force field. The tube had a diameter of  15  Å and was assembled by stacking 11 "carbon" rings each constituted by 11 beads. The distal rings were formed by hydrophilic particles while the inner rings were formed by hydrophobic beads.
The substrate molecules were added inside the vesicle using the Packmol software  86. The largest vesicle was filled with 5 α-chymotrypsin enzymes, 6 crowding bovine serum albumin (BSA) proteins, and 100 substrate molecules (alanyl-phenylalanyl-alanine) in order to generate a model of a nanoreactor and to investigate protein-substrate encounters under the action of confinement, crowding and HI. The vesicle was filled using Packmol  86. The structures of the enzyme (α-chymotrypsin, PDB code 1YPH) and of the crowder proteins (BSA, PDB code 4F5S 87 ) were obtained from the PDB database  88. In the intermediate and largest systems, proteins and peptides were modelled using an elastic network (EN) based on C α and side-chain (SC) beads with a distance cutoff = r 8 c Å and a force constant = k 5 kcal/(mol Å 2 ).
Acknowledgements The research leading to these results has received funding from the  ERC  ( FP7/2007-2013 ) Grant Agreement no. 258748. Part of this work was performed using HPC resources from LBT,  GENCI [CINES  and  TGCC] (Grant x201776818 ) and the allocation Big-Challenge2018 at CINES. We acknowledge the financial support by the " Initiative d'Excellence" program  from the  French State  (Grant " DYNAMO ",  ANR-11-LABX-0011-01 , and " CACSICE ",  ANR-11-EQPX-0008 ), the  People Programme  ( Marie Curie Actions ) of the  European Unions Seventh Framework Programme  ( FP7/2007-2013)  under  REA  grant agreement n. PCOFUND-GA-2013-609102, through the  PRESTIGE programme  coordinated by  Campus France  (S. T. ), and  Sesame Ile-de France. S. T. also acknowledges the  Rothschild Foundation  for fellowship support.
The article is organized as follows: Section 2 overviews green datacenter supplied by renewable energy and schedulers using green energy in order to manage a workload and works on Google Traces dataset. Section 3 describes energy model and the scheduler strategy, Section 4 presents the methodology used and evaluates the scheduler strategy. Section 6 highlights our results for the algorithm adaptation. Section 7 is the analyze on the battery and the solar panel size, to understand the behavior of the green energy use. Section 8 is the balance sheet of this article and the future works.
Related work Over the past ten years, multiple scientific articles have investigated multiples ways to reduce datacenter energy consumption. Different approaches have been studied to reduce the processor frequency in order to save energy like DVFS, or have tested using smart scheduling algorithm to allocate tasks on different servers. These attempts were made possible by using scheduler, genetic algorithm, or smartgrid feeds through several green energies systems including solar panels, wind turbines and storage components (Batteries). To tackle the main research domains related to this article, the following subsections describe some works on Cloud energy simulation, usage of renewable energies due to the localization and the use of green energy in workload scheduling and more importantly completing tasks using Google Traces dataset.
GreenHadoop contrary to GreenSlot does not require job behavior information and can manage data availability while keeping brown energy costs low. GreenHadoop incorporates the principle of dynamic replication of data to ensure the availability of the latter. A module of the prediction of energy production is present with how the charging of the batteries is managed and incorporates five levels of priorities of jobs (Very High, High, Normal, Low, and very low). GreenHadoop behaves differently as Hadoop. This green framework uses servers in three ways : by using as many servers as green energy can supply, by unsing fewer servers when brown energy is cheap, and even fewer when brown energy is expensive. The Algorithm scheduling works with two queues for jobs : Run and Wait. Both queues are used in FIFO order.
Google workload Several studies have previously focused on a better understanding of the Google Traces dataset and of the characteristics of the described tasks. In  [21] , authors described the heterogeneity of the hardware resources in the Google traces. They classified priorities in five categories Infrastructure  (11) , Monitoring  (10) , Normal production  (9) , other  (2) (3) (4) (5) (6) (7) (8)  and Gratis(0-1). In this analyze, they shown that 2% of tasks represent 80% of CPU, Memory and that 92% are long tasks with a Free priority. In  [22] , Reiss et al. analyzed the Google cluster performance. According to this article, many long jobs have stable resource utilization, which helps the adaptive resource schedulers. They concluded that machine configuration and workload composition are heterogeneous.
This analyzed trace allows us to understand the Google dataset, the importance of an heterogeneous datacenter to adapt the resources to the demand. However, they did not provided information related on how to use this workload in another context. Some other articles  [23, 24]  have clustered jobs with a k-mean to classify the size of each each jobs in different categories. The article  [25]  evaluates the gap between the requested resources and the one consumed by tasks within the datacenter. The requested average load for a processor is 10% on the Google datacenter. This Google trace analysis shows that processors are overall under utilized which leads to an increase of the energy consumed (90% of available processor computing power is not used). Moreover, most of the workload has a low priority and is not sensitive to the latency.
A definition of each of these terms and how and why we are going to use them, is also clearly noted. • Studies proposed are based on a central decision system able to take online decision to schedule virtual machines on servers. • The virtual machines scheduling focused on the best possible use of green energy, leading to a smart management of the green energy flow given from the photovoltaic panels. • A section is dedicated to a detailed study of the Google Traces dataset in order to understand and characterize this Cloud input. This part of the work then allow us to proposed experimental phases based on a clear analysis of this workload. • The workload used came from the Google Traces dataset, including more precise parameters which have been analyzed and used to compare the different virtual machines scheduling approaches.
Virtual Machine model based on Google Traces Attributes To evaluate all the algorithm, we used the google traces  [4]. Google provided a dataset of its servers usage in 2011. The monitored datacenter is composed by more than 12,000 servers with heterogeneous characteristics and 25 millions tasks. The different statistics were collected for a period of 29 days. In order to use the traces proposed by Google in the simulator, a cleaning was imposed. We were interested in the data stored in the "task events" directory. During the period of 29 days, they record 100 millions events which describe each task and their life cycle. An event indicates a transition between states  (7). In  [32]  [33], they show that 95% of the task has only three events. In order to clean the traces, we keep only the tasks with three events, an initial one "Submit", a "Schedule" one and an ending event ("Finish","Fail","Kill", "Lost" or "Evict").
A VM is defined as follows: The time when the VM is terminated event The ending event: "fail" or "finish" or "kill" priority The priority (between 0 and 11) latency Its sensitivity to latency (between 0 and 3) vCPU The vCPU demands between (1 and 4) In Table  4 , the schedule time and ending time attributes allow us to calculate the "execution time". The ide attribute is a unique identifier obtained using the concatenation of two values of Google attributes  [4]. Then, the submit time, schedule time and ending time correspond to the time where the event is changing. The event is the ending event of the VMs which corresponds to an event from the Google dataset. This event could be a "fail" or a "finish" or a "kill". We keep only the Google task with Three events, in  [32]  because they analyzed that 95% tasks have only three events.
Experiments set up The following experiments are the implementation of different algorithms. They are introduced in the control module in the RenewSim simulator  [29]  for purposes of obtaining results on energy efficiency and on QoS via a set of indicators. In order to correlate IT and energy flows, these experiments highlight the decision-making on heterogeneous objectives. These algorithms schedule a set of VMs on servers and over time. Here, a set of VMs is given as input to the simulator. These correspond to synthetic traces generated from the Google data  [4]. These synthetic traces follow the model proposed in the section 4. 5. For the following experiments, 1000 Vms (600 short time execution, 200 medium time execution and 200 long time execution) were used. There are more VMs short because Google has more short tasks than long.
This data is extracted from actual data and measured on DELL R630 servers with two CPUs (XEON). The following experiments: -Analyze the scheduling result of the algorithms (Section 6. 2) -Knowledge of the algorithm that consumes the least (Section 6. 3) -Identify the algorithms that eject the most VMs (Section 6. 4) -Pick out the algorithms using the least renewable energy thanks to the GEC indicator All these experiments are related to one another and allowed us to: -Understand the relationship between the number of VMs ejected and the total energy consumption -Compare the share of green energy to total energy consumption.
Experiments set up Through the RenewSim simulator  [29] , the following study highlighted the of battery size and solar production on a workload. A set of simulations was carried out on the same workload by varying the input data of the simulator, in this case the battery storage capacity and the solar production. To evaluate the size of the battery relative to the production of the solar panels, it was chosen to analyze the GEC. The scheduler uses the algorithm FF because it presents the best results in terms of compromise between the various indicators (table  6 ). The same workload is maintained, but the battery size and solar production are modulated to evaluate the behaviour of the GEC. The figures 20a and 20b are an example of an experience where solar production evolves from one scheduling to another with the same battery capacity of 10,000 Joules.