dataesr/scientific-paragraphs-categorization huggingface dataset:
Calibration and measurement characteristics Before using SenseJoy, a calibration step is necessary to determine the maximum amplitudes of the bidirectional joystick of each EPW. The calibration step is conducted to ensure the correct parameterization of the offline analysis. The joystick is positioned in the maximum rear position and then in maximum front position followed by the maximum left position and the maximum right position, as visible on Fig. 6. Data are recorded during this process and the mean values of each maximum and minimum phases act as bounds to limit the joystick amplitude. This step allows to normalize joystick displacement values. Note that the rest position of the joystick for the backward/forward axis (Y) is not exactly zero on Fig. 6 : for this axis the joystick is slightly inclined forwards in the rest position.
We can deduce two metrological parameters, resolution and response time. The resolution is defined by the standard deviation of the measurement noise. For each axis X and Y, the system is assumed to be recorded in static position. The recorded data is thus assumed to be characteristic of the static position with an additional white noise, due to the measurement chain. After verifying that the noise follows a Gaussian distribution, the standard deviations are respectively estimated to 1. 31% and 1. 23% for the X-and Y-axis. The response time is measured to be the time of the sensor response to reach 95% of the step. It has been measured averaged over multiple samples and is estimated to 95 ms.
Conclusion In this study we propose an easy-to-plug equipment to assess the joystick controls during EPW driving tasks. This equipment can be plugged on any EPW equipped with a joystick control interface. We have demonstrated it is possible to collect the data and to estimate the driving indicators from the literature. These indicators help caregivers in rehabilitation centers to objectively quantify the driving behavior based on the direct measure of joystick actions. We have demonstrated that our system is robust and accurate with thorough and ecological tests. It is comparable to the direct output of the joystick, both quantitatively, as it is validated by a statistical equivalence test, and qualitatively, as we could extract the expert/novice driving profile with an automatic clustering method.
Cells were incubated with a solution of 5% BSA/ 0. 1% Triton X-100 in PBS for 30 min at 22 °C and then with primary antibodies in 5% BSA/0. 1% Triton X-100 in PBS overnight at 4 °C. After washing, the cells were incubated with the secondary antibodies for 45 min at room temperature and mounted in Prolong Gold reagent (Thermo Scientific). Images were acquired with a Zeiss upright microscope equipped with a Plan-APOCHROMAT objective (×63; NA: 1. 4), allowing acquisition of optical section images (Apotome 2 microscope). Lysosome positioning. The position of lysosomes was assessed using ImageJ and MATLAB software. Signals from the nucleus (DAPI) and lysosomes (LAMP1) from an optical section were acquired with an Apotome 2 microscope. The centroid of the nucleus was determined using the DAPI signal and centroids of each lysosome were determined as the pixel with the highest intensity for each LAMP1positive vesicle.
4, 1 mM EGTA, 2 mM MgCl 2 , 1% Triton X-100, and Halt™ Protease Inhibitor Cocktail (Thermo Scientific) for 15 min at 4 °C. Lysates were cleared by a 15-min centrifugation at 16,000 × g at 4 °C. The subcellular localization of TFEB was evaluated by preparing the cells as described previously  55. Protein concentration was determined with the BCA assay kit. Western blots were performed as described previously  56. Signals were visualized with a chemiluminescence substrate (SuperSignal West Dura) or acquired with an Odyssey ClX (Li-COR) instrument. Signal intensities were quantified using ImageJ software. Uncroped western blots are presented in Supplementary Fig. 5. Total internal reflection fluorescence microscopy. TIRF experiments were performed on fibroblasts transfected with vectors expressing STIM1-mCherry, using a previously described protocol  57.
Analyses were performed using ImageJ software. The TIRF signal was obtained by thresholding and the area containing the TIRF signal normalized to the surface for each cell. Statistics and data analysis. All statistical tests were performed using GraphPad Prism 6 and the tests are described in the figure legends. Multiple comparisons were performed using ANOVA when data had a normal distribution. Holm-Sidak multiple comparison tests allowed to compare the means of the different sets of data. P < 0. 05 was considered to be statistically significant. Ethical approval. The care and treatment of animals followed European legislation (N°2010/63/UE) and national (Ministère de l'Agriculture, France) guidelines for the detention, use, and ethical treatment of laboratory animals. All experiments on animals were approved by the local ethics committee (approval APAFIS-5199) and conducted by authorized personnel.
Acknowledgements We thank  Phenoparc, IGenSeq ,  Celis , and the  ICM. quant facilities of the  Institut du Cerveau et de la Moelle Épinière  for their contributions. The 1D4B monoclonal antibody was obtained from the  Developmental Studies Hybridoma Bank  ( University of Iowa, Department of Biology, IA 52242 ). This work was supported by the " Investissements d'avenir" program  grants [ ANR-10-IAIHU-06 ] and [ ANR-11-INBS-0011 ] and received funding from the  Verum Foundation  (to A. B. and G. S. ), the  French Agency for Research (ANR)  (to G. S. ), the  GIS-Maladies Rares Foundation  (to G. S. ), the  Fondation Roger de Spoelberch  (to A. B. ), and the  European Union  with the  ANR  (to A. B. ,  Seventh Framework Programme -FP7 , Omics call; to G. S. , the  E-Rare  programme) and the  European Research Council (European Research Council Starting  [grant No  311149 ] to F.
The processing of ATLAS event data requires access to conditions data which are stored in database systems. This data includes, for example alignment, calibration, and configuration information which may be characterized by large volumes, diverse content, and/or information which evolves over time as refinements are made in those conditions. Additional layers of complexity are added by the need to provide this information across the worldwide ATLAS computing grid and the sheer number of simultaneously executing processes on the grid, each demanding a unique set of conditions to proceed. Distributing this data to all the processes that require it in an efficient manner has proven to be an increasing challenge with the growing needs and numbers of event-wise tasks. In this presentation, we briefly describe the systems in which we have collected information about the database content and the use of conditions in event data processing.
The ATLAS Conditions Database All processing of event data collected by the ATLAS [1] experiment at the CERN LHC is performed using a complementary set of data in the ATLAS Conditions Database (DB) which describes the configuration, state, calibration and alignment of the detector sub-components during the time interval in which the event data was taken. The database design is based on the LCG Conditions Database and the database is accessed by clients using the COOL API, both of which were developed by the CERN IT department for the LCG  [2]. The cardinal repositories of the data reside in two Oracle DBMS instances at CERN; one for online data taking and another for offline processing. The offline instance is replicated to three Tier 1 sites (TRIUMF in Canada, IN2P3 in France, and RAL in the UK) to provide global access to the data on the WLCG.
Conditions data are in general not event-wise, but extend over longer time intervals from minutes to hours in duration. The data collectively characterizes the states of all ATLAS subsystems, organized by "Intervals of Validity" (IOV), which is the span in time over which that data is valid. The data is collected from many sub-systems such as the Detector Control System (DCS), trigger and DAQ, Data Quality, ATLAS sub-detectors, and the LHC accelerator complex. Conditions data are stored in several Oracle schemas according to subsystem and whether the data is used online or exclusively offline. This division is historic, dating from before the start of LHC Run 1 data taking, in order to cleanly divide the data in the database for the different subsystems and its online usage. Within each schema, the data is logically grouped into "folders" so that clients may selectively access that folder's data when needed.
At the present time, all such data is stored in the ATLAS Conditions DB, which currently contains data in over 2300 folders, distributed over 32 schemas. Conditions data are accessed in all ATLAS event data processing activities, in many phases of analysis, as well as in monitoring and calibration studies by subsystems. A folder's "payload" is the set of values stored in the relational database columns of that folder. The LCG Conditions database software leaves a lot of freedom in the choice of the payload structure and on the column data types. Allowed data types include the standard numeric and string types, along with LOB (Character or Binary Large Object types, i. e. CLOBs and BLOBs). In addition, special string-type columns are used to designate references to external data files (file GUIDs and internal files pointers) registered in the ATLAS DDM/Rucio system  [3].
In offline distributed computing, Athena [4] jobs are efficiently provided with concurrent conditions data access from the ATLAS Conditions DB via a caching system which mediates client requests: the Frontier [5] system. If a client queries data from a folder with the special external references, Athena methods provide the data from a distributed CVMFS [6] file system. For the case of clients operating in environments without network access to Frontier, the required conditions are extracted into SQLite files which can be provided to the processing server so that jobs can access the data file locally. In this proceedings, we describe how we have built upon existing tools and resources to gain an improved understanding of database usage by clients and of the structure and content of the database itself.
Conditions DB Content The LGC Conditions database and COOL API were designed and implemented in the years before the start of LHC Run 1 for generic use by experiments. The design factored in the experience from previous experiments as well as from feedback from the experiments who planned to use it (including ATLAS). Knowing that some database tables may be large and that all queries via the COOL API would be qualified with filters on key columns such as IOV and tag names, the database design includes the indexing of those columns and the COOL API includes SQL hints with every query: these measures considerably improve the read performance of the database for clients by instructing the database how best to execute each query (e. g. whether to use the index or not). The above design considerations served the experiments using COOL well throughout Run 1 as long as, it was thought, the table volumes were well regulated.
In order to manage volumes, ATLAS deployed an "COOL Monitor" application which stores daily a set of metrics associated with each folder and generates a simple HTML report based on that data. The report is intended for subsystem and database experts to use to view folder-wise insert rates and volume. A snapshot of this report is shown in Figure  1. Specifically, this web page shows, for each COOL DB schema and instance, the folder name and type (SV or MV), the average row length of the payload tables, the number of rows, channels and tags in the last day, week and month. This interface worked well enough in the Run 1 start-up to recognize and reduce unnecessarily high rates, but the interface gradually fell into disuse once data entry procedures stabilized. With the start of Run 2, the application was updated to include new folders as they were created over time.
There was a slight degradation in read performance which was not immediately recognized, obscured by Oracle storage capacity improvements. As Run 2 evolved however, demands for conditions increased with an ever increasing number of jobs on the grid, creating a significant degradation in conditions delivery per job. The COOL Monitor itself was found to have a number of limitations in its misleading assumptions in the use of its input data and limited scope for improvement in its current implementation. We realized that we needed better tools to understand not only job requests, but also to understand the data content in a more thorough and systematic way, not only for current operations, but to design a better system for Run 3[7] as well. The COMA application, which had already aggregated metadata about Conditions DB folder and tags [8] was a natural place to add more detailed information about each folder.
A new approach for the distributed deployment of centralized algorithms in smart grids T. T. Q. Nguyen 1, 2 , V. Debusschere 1 , Ch. Bobineau 2 , A. Labonne 1 , C. Boudinet 1 , Q. H. Giap 3 , and N. HadjSaid 1   1 Univ. Grenoble Alpes, CNRS, Grenoble INP * , G2ELab, 38000 Grenoble, France 2 Univ. Grenoble Alpes, CNRS, Grenoble INP * , LIG, 38000 Grenoble, France 3 Da Nang University of Technology, 550000 Da Nang, Vietnam thi-thanh-quynh. nguyen@g2elab. grenoble-inp. fr Abstract-Distributed algorithms are regularly used to deploy distributed paradigms in smart grids. Computations are executed without any centralized server even in a limited bandwidth network. However, there are still some drawbacks in the proof of convergence as well as a lack of programming abstraction. In this paper, we propose a new approach to the distributed paradigm by using distributed programming in a data manipulation language called Smartlog.
A distributed programming methodology will automatically divide a centralized Smartlog program into multiple rules while ensuring the correct transformation of the centralized computations. An application of voltage control in a distribution grid with high penetration of PV systems is used as an illustration of this approach. Two implementations are compared: centralized programming and distributed programming. Both are deployed in a real-time simulation with OPAL-RT and a network of Raspberry Pis. The response time of each implementation is analyzed to evaluate their respective performance, showing that the Smartlog language is particularly appropriate to smart grids in terms of compacity and simplicity. Index Terms-Distributed programming, distributed database, over-voltage regulation, smart grids, Smartlog.
This allows taking advantage of two paradigms while ensuring the response to any change of system, as fast as possible. Most of the imperative languages such as Java or Python support distributed programming in centralized memories. Nevertheless, that is not appropriate for a distributed paradigm in smart grids. Thus, in this paper, we approach the distributed programming with a declarative language, called Smartlog  [7]. In  [7] , each smart device plays the role of a node in the IP network of the smart grids. Each node is a rule-based system with a local database and can operate simultaneously as a client and a server. Based on that architecture, a high-level programming of the data manipulation language Smartlog is developed to support the proposed distributed programming. A methodology, proposed in this paper, helps splitting a centralized program into distributed rules which are executed in multiple nodes of the grid.
A. Network architecture Smart grids are considered as heterogeneous. It is composed of a lot of smart devices which are in charge of collecting data and establishing communications among them. Each smart device can be in charge of computations and communications at each node of the grid. Fig. 1  presents their typical architecture. There are four main components in the architecture of each node: • The Local database : stores the node's information in the infrastructure of the grid, such as parameters, the measured data which are collected from local sensors or directly from the network. • The Sensor interface: is set up to collect data from sensors, to store these data into the local database and to transfer the output values to the regulator in order to control the active electrical components.
• The Rule engine: is the most critical part of the architecture because it supplies an environment to execute the declarative programs. In our implementation, the PostgreSQL trigger is used as a rule engine. • The Communication interface: is in charge of the interaction between nodes over the communication network. Received data, after unpacking, will be stored in the local database. The communication is developed based on the TCP/IP protocol and the transferred data are in the form of a JSON Object. Each participating node in the grid possesses the same architecture. This constructs an IP network in which each node can operate simultaneously as both client and server. That increases the robustness and reduces the damage when there is a single point of failure in the system  [8]. The distributed programming is developed based on the available infrastructure of information network such as WiFi, 3G, 4G and is deploy in the test-cases of an isolated microgrid.
B. The Smartlog language 1) The structure of a Smartlog program: The structure of a Smartlog program is presented in Listing 1  [7] : 2) Rule syntax: The Rule is in charge of defining the action which is executed in each node. The syntax of a rule in Smartlog is the same as in other logic programming languages: Head : Body [terminator] Where Body = B 1 ,. , B n , the body part of the rule, is a conjunction of terms. Each term in the body part B i can be a relational atom R(r 1 , r 2 ,. , r n ), a condition term or an assignment term. 3) Operators for the head part: The Head part holds the variables with assigned values in the body part and defines the execution of the rule. If all the terms of the body are approved, the execution of the head part (H) is launched. By default, the execution of the head part is a storing mode, which means that the results will be stored in its local database.
C. How Smartlog supports distributed programming Rules in a Smartlog program are grouped into many modules. Each module defines all actions of the system with the modification of a specific data_type. Measured data can trigger calculations in a local database. Meanwhile, immediate data is used to support data sharing. These data, transferred between nodes, are in the form of data_type. The data reception allows triggering consecutive calculations in other nodes. For example, consider two modules in two programs as follows: Module(A){ ^TmpC(i, v, c) :-A(i, v, c), B(i,@j); } Listing 2. A Module A in node i. Module(TmpC){ C(i, v, c) :-TmpC(i, v, c); } Listing 3. A Module T mpC in node j. When the rule of node i in Listing 2 is executed, an atom named TmpC is sent to j. The module in Listing 3 will continue to perform its actions after receiving TmpC.
B. Setup and Smartlog implementation The PREDIS distribution grid  [10]  is used as a test object in our case. This grid comprises 14 nodes, with five distributed sources, three asynchronous machines and static loads. This grid is simulated in MATLAB/SIMULINK and executed in OPAL/RT Real-time simulation. Each Raspberry Pi plays the role of a local computing unit which is installed near a distributed source (e. g. , PV). The description of the data schemes used in this application is presented in Table  I.
Atom Scheme description Measure(i,t,vi,p,pmi) Measure(ID key, Times, VOLT, POW, PMA) Slope(i,j,s,dv) Slope(CRI-ID key, ID key, SLOPE, VVAR) Warning(i, t) Warning(ID key, TIMES) Alert(i, t, co) Alert(ID key, TIMES, proportion). WarningMeasure(i,j,v,p) WarningMeasure(CRI-ID key, ID, VOLT, POW). Curtail(i, pe) Curtail(ID key, PCUR) Actuator(i, pe) Actuator(ID key, PERFORMANCE). Plimit(i, j, pli) Plimit(CRI-ID key, ID, PREF). The rules are expressed in a centralized Smartlog program as presented in Listing 1.
Set of rules for the AAPC implementation in Smartlog. An experiment was performed with three implementations of the same model and algorithms: a centralized java programming, a centralized Smartlog programming, and a distributed Smartlog programming. 1) Data distribution: In the distributed implementation, we suppose that each distributed PV source corresponds to a Raspberry Pi which is in charge of a local computing unit. Five Raspberry Pis were used in the experiment and eight data_types. These data_types are fragmented horizontally for each Raspberry. A centralized Smartlog program and its data distribution are the input of the distributed programming methodology. Five distributed programs (corresponding to five Raspberry Pis) are its output. 2) Data sets: The data sets are generated automatically during the real-time simulation.
Aims: Several scientific landers and rovers have reached the Martian surface since the 1970s. Communication between the asset (i. e. , lander or rover) and Mars orbiters or Earth antennas uses radio signals in UHF to X-band frequencies passing through the Mars' ionosphere. It is consequently necessary to take into account electron density variation in the Mars' ionosphere to correct the refraction of the signal transmitted. Methods: We developed a new empirical model of the Mars' ionosphere called MoMo. It is based on the large database of Total Electron Content (TEC) derived from the subsurface mode of the Mars Express MARSIS radar. The model provides vertical TEC as a function of solar zenith angle, solar activity, solar longitude and location. For validation, the model is compared with Mars Express radio occultation data as well as with the numerical model IPIM (IRAP Plasmasphere-Ionosphere Model).
Results: We discussed the output of the model in terms of climatology behaviour of the Mars' ionosphere. The output of MoMo is then uses to quantify the impact of the Martian ionosphere for radio-science experiments. From our results, the effect is of the order of 10 À3 mm s À1 in Doppler observables especially around sunrise and sunset. Consequently, this new model could be used to support the data analysis of any radio-science experiment and especially for present InSight RISE and futur ExoMars LARA instruments aiming at better understand the deep-interior of Mars.
g. ,  Zuber et al. , 2007)  when combined with data acquired at larger angle. Concerning the Mars' ionosphere, several models exist. Let us cite the IPIM model (IRAP Plasmasphere-Ionosphere Model,  Marchaudon & Blelly, 2015) , a state of the art numerical model, which is heavy to run for routine processes. Another existing model is the recent empirical model called NeMars  (Sánchez-Cano et al. , 2013)  constructed from MARSIS data. This model is based on data from a special mode of the Mars Express radar (active ionospheric sounding), which does not probe the entire ionospheric layer  (Sánchez-Cano et al. , 2012; Morgan et al. , 2013). Peter et al. (2014)  published a 1-dimensional model of the ionosphere, used to interpret the Mars Express radio-occultation data. Recently, the Mars International Reference Ionosphere  (MIRI-2018 , Mendillo et al.
In order to build such tool, we used existing radar data derived from Mars Express TEC measurements between the surface up to 900 km. Our model is called model of Mars' ionosphere (MoMo) and can be used to predict the Martian ionospheric TEC in a simple way. The goal is to provide corrections to be applied for any investigations using radio signal probing the Mars' ionosphere at a given location, at a given time and for a given solar activity level. The first section of the paper describes the data used to build our model, the model itself and the validation of our approach with independent radio occultation data and the IPIM model. The second section describes the climatology behaviour of the Mars' ionosphere using our model, and provides some applications to radio-science experiments.