dataesr/scientific-paragraphs-categorization huggingface dataset:
Results presented in the following refer to this dataset. We present a model with nine layers. Each layer is 180 km thick so the model encompasses the mantle from Mars surface to its core mantle boundary assumed to be close to 1,600 km in depth  (Rivoldini et al. 2011 ). The core conductivity was set constant and equal to a large value (500 S m -1 ). The depth of this boundary was tested even for non-realistic values to infer its influence on results. A very weak influence on models was observed. In fact, below 1,300-km depth, the models were no longer sensitive to data. Models with nine layers of 180 km were calculated, which appeared to be a reasonable compromise between a limited number of parameters, the depth resolution, and the maximum depth of penetration for the data used. Figure  4  shows our preferred model using the SH coefficients restricted to the acceptable set.
During the inversion process, all the calculated models were consistent with each other, meaning that a strong geophysical signal was embedded in the SH coefficients, even when considering the complete dataset. A sensitivity analysis was run on these models. The conductivity in each layer was varied to observe the change in the misfit value. In all models, changing the conductivity values by approximately 0. 5 log unit between 0 and 1,300 km increased the misfit by approximately 100% (red shaded area in Figure  4 ). Below 1,300 km, the data were insensitive to the conductivity structure. Some resulting fits are presented in Additional file 1. The differences between the data and model responses were small for the modulus of the complex coefficient β whereas the phase was poorly   Mocquet and Menvielle (2000) , while light gray area denotes the model constructed by  Vacher and Verhoeven (2007).
Acknowledgements This work was supported by a grant from the  French Ministry of Research  and from  CNRS-INSU  (program PNP). We thank the  Centre National d'Études Spatiales (CNES). The MGS MAG/ER dataset was obtained from the Planetary Data System (PDS). We are grateful to the anonymous reviewers for their help in improving this article. We also thank  Benoit Langlais  and  Antoine Mocquet  for their useful advices.
In-medium effects 4. 1 Pb-Pb results at 2. 76 TeV From the Pb-Pb data sample, 135 Υ(1S) have been extracted while the signal of Υ(2S) and Υ(3S) is not significant. Upsilon production was measured in two rapidity intervals (centrality-integrated) and in two centrality classes (rapidity-integrated): 0-20% most central and 20-90% most peripheral collisions. The nuclear modification factor is presented in Fig. 3. The centrality of the collision is quantified by the average number of participating nucleons N part. This number, as well as T AA , is estimated by using a Glauber model  [12].
Conclusions Upsilon production in pp, p-Pb and Pb-Pb collisions has been measured with the ALICE forward muon spectrometer. Results obtained in pp collisions are in good agreement with those from LHCb. The Pb-Pb nuclear modification factor of Υ(1S) indicates a suppression that increases with centrality. This suppression is consistent with the measurement by CMS at mid-rapidity. No evidence of rapidity dependence is observed. The suppression amplitude and shape as a function of centrality is well described by theoretical predictions. The p-Pb data show a small Υ(1S) suppression, possibly increasing from backward to forward rapidity, which indicates that cold nuclear matter effects are not negligibles. The comparison of the forward-to-backward ratio with model predictions seems to disfavour a high shadowing effect.
TOMOGRAPHIC MODELLING In this section, we describe the application of our dedicated stellar-surface tomographic-imaging tool to our new spectropolarimetric data set. The software package we are using for this purpose is based on the principles of maximumentropy image reconstruction, assuming that the observed variability is mainly caused by rotational modulation (with an added option for differential rotation). Since the initial release  (Brown et al. 1991; Donati & Brown 1997) , this package underwent several significant upgrades (e. g. ,  Donati 2001; Donati et al. 2006b) , the most recent one being its re-profiling to the specific needs of MaPP observations  (Donati et al. 2010b ). The reader is referred to these papers for more general details on the imaging method. We use here this last version in a slightly modified configuration that allows a more accurate modelling of the MaTYSSE data.
Again, this directly reflects the very distorted shapes of Stokes I LSD profiles at phases in the range 0. 25-0. 60, i. e. , when the plage is most visible to the observer and generates conspicuous absorption dips in spectral lines (at cycles, e. g. , 3. 288, 0. 341, 2. 413, see left panel of Fig. 3 ). No similar fit to the data can be achieved if we force the code to reconstruct dark spots only at the surface of the star -an option implemented in our code and often used in Doppler imaging of cool stars to further constrain the inversion process with prior information on the image to be reconstructed. We therefore conclude that bright plages are clearly present at the surface of LkCa 4, rendering this imaging option mandatory for modelling MaTYSSE data. These two main surface features are found to cover altogether ≃25% of the overall stellar surface.
However, detecting hJs around wTTSs is not obvious given their very large activity levels often generating RV jitters of a few km s -1 , even at nIR wavelengths (e. g. ,  Mahmud et al. 2011; Crockett et al. 2012). MaTYSSE therefore requires that we implement an efficient method for filtering out the RV jitter of wTTSs down to a level at which the RV signatures of hJs can be reliably detected. We propose to achieve this RV filtering through the tomographic modelling of surface features from phase-resolved spectropolarimetric data sets such as that presented herein. As demonstrated in Fig. 7  in the particular case of LkCa 4, this technique is capable of reproducing activity-induced RV signals at a rms precision of 0. 055 km s -1 , i. e. 78× smaller than the full amplitude of RV variations and less than twice the intrinsic RV precision / stability of ES-PaDOnS for narrow-lined low-mass stars (of ≃0.
In the HR diagram, it sits close to the prototypical cTTSs AA Tau and BP Tau, making LkCa 4 a key target for investigating how young Suns evolve once they dissipate their accretion discs and start spinning up towards the MS -a crucial transition for our understanding of star and planet formation. With a rotation period of 3. 37 d, i. e. , 2. 4× shorter than the typical 8-d rotation period of cTTSs in this range of age and mass, LkCa 4 is most likely in a process of rapid spin-up. Using tomographic imaging on our phase-resolved spectropolarimetric data set, we recovered the brightness map and magnetic topology at the surface of LkCa 4 at the epoch of our observations. We find that LkCa 4 features a cool spot near the pole as well as a bright plage at intermediate latitudes, covering altogether ≃25% of the overall stellar surface and generating large distortions in the unpolarized LSD profiles at nearly all rotation phases; the brightness map we derive is in good agreement with our contemporaneous photometric observations.
15 km s -1 (depending on the number of spectra in the data set) and that the planet orbital period is not too close to the rotation period of the star (or its first harmonics); further simulations are needed to confirm and extend these conclusions, and will be presented in a forthcoming companion paper. We report no such evidence for a hJ in the particular case of LkCa 4; applying the same analysis to the whole MaTYSSE sample of about 35 wTTSs should allow us to obtain at least an upper limit on the fraction of wTTSs hosting hJs, and therefore to assess on observational grounds the standard mechanism proposed to explain the existence of hJs through disc migration at a very early stage of star / planet formation. On a broader context and a longer timescale, MaTYSSE studies will be extremely useful as science preparation for SPIRou -the nIR spectropolarimeter / high-precision velocimeter presently in construction for CFHT, for a first light in 2017.
ACKNOWLEDGEMENTS This paper is based on observations obtained at the  Canada-France-Hawaii Telescope (CFHT) , operated by the  National Research Council of Canada , the  Institut National des Sciences de l'Univers of the Centre National de la Recherche Scientifique (INSU/CNRS) of France  and the  University of Hawaii. We thank the  CFHT QSO team  for the its great work and effort at collecting the high-quality MaTYSSE data presented in this paper. MaTYSSE is an international collaborative research programme involving experts from more than 10 different countries ( France, Canada, Brazil, Taiwan, UK, Russia, Chile, USA, Switzerland, Portugal, China and Italy ). We acknowledge funding from the  LabEx OSUG@2020  that allowed purchasing the ProLine PL230 CCD imaging system installed on the 1. 25-m telescope at CrAO.
SGG acknowledges support from the  Science & Technology Facilities Council (STFC)  via an  Ernest Rutherford Fellowship  [ ST/J003255/1 ]. SHPA acknowledges financial support from  CNPq ,  CAPES  and  Fapemig. We  finally thank the referee,  Dr. J. D. Landstreet , for his detailed reading of the manuscript and for suggestions to improve its overall clarity.
Acknowledgements We thank the  ETMC  for making their gauge field configurations publicly available. We are also grateful to  B. Blossier ,  V. Lubicz  and  O. Pène  for discussions related to the subject of this paper. Computations of the relevant correlation functions are made on the HPC resources of IDRIS Orsay, thanks to the computing time given to us by  GENCI  ( 2013-056808 ). M. A. is grateful to the  CNRS Liban  for funding her research.
In the course of the upgrade, the central data acquisition (DAQ) system of the array  [7]  was also revised. The on-site computing cluster (next to the telescopes) was replaced by modern off-the-shelf hardware while the DAQ software was ported to this new environment and adjusted to meet the requirements of H. E. S. S. Phase II. This paper gives an overview of the central DAQ system and the challenges that were met and overcome during the cluster upgrade. Unlike the DAQ systems of VERITAS  [8]  and MAGIC  [9] , the H. E. S. S. DAQ system is also responsible for array control and monitoring. We will therefore address these topics and also mention error propagation within the system, as well as the user interaction with the DAQ. Furthermore, the reliability and performance of the central DAQ are discussed.
Moreover, the common data format allows data that are identical to those recorded by the DAQ to be easily simulated. On top of the mere acquisition of data, their integrity and quality needs to be verified in real time. Furthermore, the data should be checked and analysed by a preliminary analysis during observation. Due to the common data format it is possible to use the standard offline analysis software for this purpose. The array needs to be able to operate in different observation modes with different sets of telescopes. Several independent operation modes with disjoint sets of telescopes, so called SubArrays, should be possible simultaneously, for example, observation runs as well as calibration and maintenance runs. The DAQ system needs to be able to respond to target of opportunity (ToO) alerts, like alerts from the Gamma-Ray Burst Coordinates Network 2  , in real time.
User requirements The H. E. S. S. DAQ should facilitate integration of new hardware and allow a quick response to hardware mal-functions without interfering with the rest of the array. The software should, therefore, be modular and support different hardware configurations. The H. E. S. S. Array is operated by collaboration members (PhD students,. ) during "Shifts" of one moon period. As a result, the array is operated by monthly changing non-expert personnel on-site (Shifters) with remote support by a team of subsystem experts working at the respective member institutes as well as a local shift expert responsible for the training of the Shifters at the beginning of each Shift. As a security precaution the access of Shifters to critical parts of the array has to be limited (for example configuration databases or low-level telescope movement), while subsystem experts must be able to perform remote maintenance.
Moreover, the DAQ software should use stable releases that may not be altered by Shifters for observations, but should still allow subsystem experts on-site to develop and debug their software modules. As subsystem experts are working at their home institutes most of the time and not on the H. E. S. S. site, a remote access to the various subsystems of the array must be available. Due to limitations in internet connectivity, these remote connections need to be simple. To further ease the maintenance of the array, a dedicated logging system with detailed information for Shifters and subsystem experts has to be part of the DAQ software. For testing purposes, and in case of malfunctioning hardware, the ability to manually override automated procedures must be given at all times. Due to the non-expert personnel operating the array during a shift, manuals and documentation have to be available on-site at all times.
Central DAQ hardware The primary data flow starts in the Cherenkov cameras of the five telescopes. If an air shower event is seen by a telescope, i. e. the camera trigger decided to launch the read out of an event, the camera sends a trigger signal via optical fiber to the Central Trigger and begins to digitise the recorded image. The Central Trigger checks for coincidences in at least two telescopes, if no coincidence is site in Namibia. In the upper part, the server room with the five storage servers as well as the ten worker nodes is depicted. Furthermore, the Central Trigger as well as the main switches are shown. The Cherenkov Telescopes (CT) are labeled from one to five, with the last one being the H. E. S. S. II telescope. Black lines with arrows indicate gigabit data network ethernet connections while the green lines with circles represent a physically separated gigabit ethernet network for the mounting of the NFS and GlusterFS servers.
Cluster monitoring & maintainability The maintenance of the H. E. S. S. central DAQ computing cluster and the DAQ software itself is crucial for the operation of the experiment. To facilitate the maintenance and to reduce the complexity of the overall system, the cluster was designed to be as homogeneous as possible. This means that the different computing nodes and storage servers are based on the same hardware and run the same operating system allowing the same spare parts and same software to be used for all machines. To cope with power interruptions, which are quite common at the H. E. S. S. site (several times a week), a diesel generator in combination with online/double-conversion uninterruptible power supplies (UPSs)  [18]  are used to ensure a continuous power supply to the cluster.
Software maintenance & backups A uniform administration of all machines in the cluster is possible, using the same software packages. The System Imager tool  [21]  is used to create daily backups of the current operating system, including all relevant software to run the H. E. S. S. central DAQ. If the operation system is flawed after a software change, the System Imager allows the system to be rolled back to a previous, stable image with a single command. Dedicated backups of important files are performed on a daily basis. With increasing age of the backups, the frequency is reduced from daily, to weekly, to monthly snapshots. The databases (see section 3. 6), that are being used throughout the DAQ, are also backed up on a daily basis.
Data format The transport and storage of objects needs a serialisation mechanism which is provided by the ROOT Data Analysis Framework  [22]  on which the H. E. S. S. raw data format is based. The data which is obtained from the hardware is sent using the Push mode to the corresponding receiver process. In Push mode data integrity is guaranteed. The received data is then stored in ROOT files using the common H. E. S. S. data format. For fast feedback to the Shift Crew, the data processed by a receiver can be pulled by a Displayer process and displayed on one of the available screens in the control room. The data can be sent at an arbitrary rate. Error handling and process synchronisation is taken care of by the Manager process. To ensure a common interface and easy access to all the different raw data formats used in H.
E. S. S. , a common raw data base class is implemented in the software. This base class also takes care of correct time stamps for the different events that are recorded and saved to disk. This enforces a correct order in the loading and processing of events. Both the ROOT-based H. E. S. S. data format and the ROOT graphics and histogram classes are used online and off-line allowing a seamless integration of the high-level data analysis code into the DAQ software, see Section 4. 2.
Data transport The communication between the different processes in the DAQ is built on the CORBA  [23]  distributed, objectoriented inter-process communication standard. A client process can call remote procedures on a server object using CORBA messages. The result of the function call (with possible read, read-write and write parameters) is propagated back to the client after the execution of the code on the server side. Due to the combined usage of CORBA and ROOT, several multi-threading issues in the ROOT Framework were discovered. To achieve the required thread safety, several patches have been contributed to ROOT, and are now part of all ROOT releases  [24, 25]. CORBA allows the use of different programming languages and different operating systems on the server and the client side. The H.
This transport mechanism is used by displaying processes where a sub-sample of the data is sufficient. To store data on disks, multiple instances of a generic receiver process are used throughout the DAQ. These receiver processes are implemented in a generic way which allow the introduction of new data without the need to change existing code. The generic receiver makes use of the common base class of the H. E. S. S. raw data formats and can save any data using the ROOT serialisation mechanism. Moreover, basic data quality checks can be performed while the data is being received, e. g. monitoring if the time that passes between two events or the size of the event is in a certain range and has a certain mean value.
Node switching To be able to deal with high data rates so called Node Switching is used in the H. E. S. S. DAQ, this is a round-robin load balancing scheme  [27]. All the telescopes in a given run send their data to one node for a given amount of time (usually 4 s). After that, the Central Trigger announces the next node that is free to receive data from all the cameras. In case of insufficient computing power the number of nodes can be adjusted manually. Using this scheme the DAQ can receive and process data at higher rates than required by the H. E. S. S. telescope array. A specialisation of the generic receiver mentioned before is the CameraReader, which is the process responsible for receiving, buffering and processing the Cherenkov camera events. The received events are unpacked, converted into the H.
Furthermore, a flat state machine allows processes to be sent to any given target state that need not be adjacent to the current state, i. e. from Safe to Running or vice versa. (The Controller will perform all necessary transitions to get from the Safe to the Running state automatically, i. e. the order of executed transitions would be GettingReady, Configuring and Starting. ) Transitions towards the Running state are called "upwards", and those in the other direction are called "downwards". To be able to monitor the performance of the DAQ processes, time stamps are written into a MySQL database at the beginning of each transition, once all of the dependencies (see Figure  4 ) of a Controller have finished their transition and again at the end of each transition (see Section 4. 3).
Managers & dependencies To synchronise the different processes during data taking Managers are used throughout the DAQ. Each Manager is also a Controller, i. e. a software process running on a computing node of the DAQ cluster, providing an extended interface to deal with collections of Controllers. The Managers are responsible for distributing the run configuration to their subordinated processes as well as managing their states. 5. The Manager of a given context gets the list of the processes needed for a given run from the database. There are three distinct types of processes that can be specified within the database. Disturbing processes are sent to a safe state at the beginning of the run, e. g. the camera lid is disturbing for a park-in run. Therefore, it is closed before the telescopes are parked in (i.
e. moving the camera into the camera shelter and closing its roof). Required processes are necessary for a given run and a run will be stopped or will fail to start if a required process is not in the correct state. Finally, Optional processes are part of a given run but an error or a misoperation of one of these processes does not influence the data taking, e. g. a crash of the process displaying monitoring data to the Shifters does not stop data taking. Once the problem with an optional process is fixed it is allowed to rejoin data taking. In certain cases, a Controller has to be in a certain state before another Controller can begin to perform its transition to its target state. These dependencies are entered into the database and Controllers will get a list of all their dependencies for a given run type from their corresponding Manager.
Configuration database In general, the whole configuration of the H. E. S. S. DAQ is contained in MySQL databases, including the processes and machines in use, as well as common environment variables and the configuration of the various hardware components. This allows a flexible configuration on-site and enables the setup of test and development environments in Europe where only certain pieces of hardware are available. In addition to the on-site database there are duplicates in four different locations in Europe. These replicated databases are also used for off-line quality checks and analysis. The H. E. S. S. DAQ uses a database abstraction layer, called simpletable, to access the database. It was designed and implemented as part of the H. E. S. S. DBTools  [28]  (in C/C++) and additionally implemented in Python for the Central DAQ.
simpletable facilitates the grouping of multiple records in so-called sets. Such a set is for example a collection of calibration parameters for all pixels of a telescope. The library takes care of table locking and transactions, so that either a complete set is written/modified or nothing at all. Another important aspect is that a permanent history of configurations, calibration parameters etc. is provided. It is possible to store and access multiple versions of a configuration set. Under normal circumstances only new sets of data are added, even when these are just minor modifications of older sets still residing in the database. This also makes it easy to create temporary configurations, e. g. deactivating a malfunctioning piece of hardware during the night and to roll back to an earlier version of the configuration when the error is resolved.