dataesr/scientific-paragraphs-categorization huggingface dataset:
DAQ start & stop Another highly automated procedure is the start and shut down of the DAQ. Starting the DAQ can be done in less than 1 min and stopping in less than 0. 5 min on average. The complete DAQ system can be started or stopped using a single button in the central GUI or running a single command on the shell in a matter of seconds. This starts the Resource Handler, which gets the list and configuration of all the processes that belong to the DAQ from the MySQL database and starts Host Handlers on every machine that has been configured to be part of the DAQ in the database. These handlers are responsible for starting, monitoring and, if necessary, restarting all the processes that run on their machine.
Array operation The H. E. S. S. Array takes data in periods of 28 min, so called runs, during astronomical darkness only. There are observation runs which make up the bulk of the available dark time. Furthermore, dedicated calibration runs 3 are taken with the detector at regular intervals as well as other 3 Calibration runs are needed to determine the conversion of the recorded electrical signal into a number of Cherenkov photons. A more detailed description of the H. E. S. S. calibration is given in  [29]. special purpose runs, e. g. system tests at the beginning of the night. All the different run types are specified in a database and run types can be added, removed or modified without the need to change any code. This includes any combination of hardware that has to take part in a run of a given type.
This is also true for the detailed configuration parameters (Run Parameters) of the hardware used in a given run (which can be different for different run types). Furthermore, the targets scheduled for observations during a given shift are contained in the same database and a dedicated tool, called the "AutoScheduler"  [30]  schedules all observation runs for a given night. The AutoScheduler takes into account various predetermined conditions, e. g. target priority, zenith angle, number of runs already taken on that target and available telescopes and uses an optimisation algorithm to prepare the schedule. This schedule is then written to the database and processed by the DAQ. The Shift Crew can adjust the schedule, e. g. by adding calibration runs manually, but is not allowed to change the observation schedule, unless there are exceptional circumstances, e.
e. the Run Manager is doing a transition to the Safe state. Also the corresponding SubArray is send to the Ready state in case of an Error message and the Safe state in case of a Fatal message as a safety precaution. events). A central graphical user interface (GUI) is used for interaction with the DAQ; a screenshot of the main part of the GUI is shown in Figure  7. It serves as a single point of contact between Shifters and the DAQ where all essential settings and configuration options can be changed. This allows Shifters to take over manual control in case of error recovery and special operations in an easy way. The central GUI, and most other GUIs in the H. E. S. S. DAQ, are implemented in the Python programming language using PyGTK  [31]. Furthermore, all GUI processes implement the state Controller interface and are managed like all other processes in the DAQ, e.
g. they receive Run Parameters and perform transitions like Starting and Stopping. Building upon the common raw data format based on ROOT, a generic data Displayer has been developed (using C++). It uses the object introspection capabilities of the ROOT data analysis framework to gain access to any data member of any H. E. S. S. data storage format. Therefore it is able to plot any data that are recorded in the H. E. S. S. DAQ and can be configured solely using the MySQL database. Different specialisations of this Displayer can plot time lines, bar charts, wind roses, camera images, etc. An example of available displays that are shown in the control room can be seen in Figure  8. Some basic data quality checks can be performed with the Displayer as well, e. g. range checks with warning sounds and pop-up messages.
The lower left part of the GUI is dedicated to giving detailed information about and control over the available SubArrays. This includes information about run duration, observation target, used telescopes, etc. The main part of the GUI is used to show all running DAQ Controllers to the Shifters. They are grouped in contexts and can be expanded to show all processes within this context. The amount of processes in a context as well as their current state are also shown. Detailed control over every single process (even multiple ones if more than one are selected) is possible using the right-click menu. In case of errors, the Controllers at fault are marked with an error flag (not shown). reconstruction as well as gamma-hadron separation. The processed data is collected by AnalysisServer processes; one for each SubArray in use.
Monitoring and shift logs To calculate the data taking efficiency of the H. E. S. S. telescope array the so called Transition Time Tools are used. It is a Python framework that analyses the gaps between the various runs and the timestamps, that were written to a database by the different DAQ Controllers. The DAQ monitors whether there are any gaps in data taking during dark time. If a gap is detected the Shifters are asked to give a reason for each gap between data taking runs. The answers the Shifters provide are stored in the same database. In combination, the information about the transitions, the gaps between runs and their reasons can be used to calculate the data taking efficiency of the H. E. S. S. Array as well as the percentage of lost observation time of the array due to DAQ problems.
Error handling In case of a hardware failure, the DAQ automatically performs a safety shutdown, as described in section 3. 7. Apart from this automatic procedure, manual overrides are available for every automatic configuration and automatic DAQ action. If a hardware device is not available or malfunctioning, its corresponding Controller can be replaced with a noopController which just implements the common interface of the state machine while not doing anything else. This procedure is wrapped in a Python script with the name of the Controller that should be replaced as a single command line parameter allowing the Shift Crew to easily continue observations without the failed hardware. Along with the manual overrides, extensive documentation of all hardware components and the DAQ are available on-site.
The access to these VNC servers is restricted to DAQ experts to prevent tampering with the system by third parties. The remote access to the network is possible with an OpenVPN  [39]  server running on the gateway machine of the DAQ cluster. With this it is possible to access all of the different networks on-site without compromising security or the separation between the data network and users network. To ensure a stable production environment, the Shift Crew as well as other members of the collaboration cannot change the software used for data taking. Only DAQ experts can make software changes and can, therefore, guarantee a properly working DAQ system. The Shifters are given restricted access to the cluster to minimise the possibility of human error.
Test-DAQ cluster & DAQ simulation To test the DAQ software without real hardware, a full DAQ simulation can be set up, i. e. raw camera data are sent from a camera emulation process to the node receivers and a Central Trigger emulation process sends trigger blocks to the corresponding receivers as well. This can be used to test receivers, the node switching as well as the real time analysis with real data as input. However, to process a full run of real data in an acceptable time frame, a computer cluster similar to the one in Namibia has to be used. The H. E. S. S. Test-DAQ-Cluster, a scaled down version of the DAQ cluster on-site (five nodes instead of ten, two storage servers instead of five, one switch instead of four), provides enough computing power for that purpose. Moreover, the same operating system and software is running on the Test-DAQ, making it an ideal test bench for software development.
They provide the basic interface of the state machine and are used to mock missing hardware Controllers in a testing environment. The Dummy Controllers are also used to test the dependency and time-out handling within the DAQ as well as to test the automatic shutdown and mechanisms in case of errors. They mock long-running transitions or can throw exceptions during specified transitions, depending on the options that are passed as command line arguments. To aid other subsystem experts in the development of their own DAQ Controllers for their hardware a dedicated virtual machine, the DAQ-VM, is available. Most of the time the subsystem hardware cannot be shipped to the Test-DAQ-Cluster and a software test environment has to be set up at the location of the hardware (for instance properly configured operating system, database and CORBA omniName server).
Performance The H. E. S. S. DAQ system has been in use since the commissioning of the first H. E. S. S. telescope in 2003. Since then the DAQ system has evolved continuously to its current state as described in the previous sections. Over the 10 year period of operation corruption of data due to central DAQ malfunctions was extremely rare and is negligible. In preparation for H. E. S. S. Phase II the central DAQ software has been overhauled, including being ported from 32 bit to 64 bit, to make full use of the architecture of recent server machines. The performance of the central DAQ software will be presented in the following, focusing on the system that was prepared for H. E. S. S. Phase II.
Shifters have easy access to these data using the different screens in the control room, allowing immediate intervention in case of problems. The operation of the H. E. S. S. Array by non-expert personnel is possible due to the detailed manuals and documen-tation about every hardware subsystem and the high level of automation within the DAQ. This automation and the open-source remote administration and monitoring tools greatly reduce the maintenance cost of the H. E. S. S. central DAQ software, which currently requires approximately a 0. 5 FTE position in Europe.
Flexibility New hardware components can be added easily to the H. E. S. S. Array. Only the software for the Controller responsible for the new hardware has to be written and added to the DAQ. The rest of the system, i. e. data transport, storage and visualisation does not need to be modified. Furthermore, the inter-dependence of the new Controller with already existing ones have to be added to the database. The central DAQ software used for Phase II of the H. E. S. S. telescope array evolved from the central DAQ software designed for Phase I of the experiment. One of the main differences between the new central DAQ software and the earlier implementation is compatibility with 64 bit architecture of recent CPUs, which required many minor patches. However, the principal design ideas of the H.
E. S. S. central DAQ software remained the same. This includes the configuration of the DAQ itself and the controlled hardware from a central database, as well as the common data format for all monitoring and scientific data. For the latter only additional information had to be included, i. e. the-pixel wise timing information that became available with the newer electronics  [11]  of the CT5 camera. The fact that no redesign of the central DAQ software was necessary is due to the uniform interfaces for hard-and software: Ethernet standard for communication to all hardware components and the common interface of the software Controllers for all devices. Another example of the capability of the H. E. S. S. DAQ to quickly adapt to new situations, is the fact that during the whole commissioning of the fifth telescope the live system was used to test and develop Controllers relevant for the new telescope while the array was taking data using the other four.
This includes parallel and joined observations of the old and new telescope. Due to this ability to take data with different SubArrays the CT5 commissioning could be done mostly in parallel to data taking with CT1-4 which had only minor downtime. The commissioning for H. E. S. S. Phase II of the central DAQ went smoothly. This was possible due to the extensive documentation and guides about DAQ Controller development, and the DAQ Virtual Machine (VM) which allowed non-DAQ-Experts to easily develop and test the Controllers for their own custom hardware. For example, the development of the Tracking Controller for CT5, the Controller for the calibration device of the new CT5 camera as well as the adjustment of the Central Trigger Controller has benefited. Moreover, the DAQ VM was used to test the central DAQ software with the camera test-benches (this includes old and new camera hardware, i.
e. test-benches mimicking CT1-4 as well as CT5) during the initial development phase of the DAQ for H. E. S. S. Phase II. The main platform for the development of the H. E. S. S. Phase II central DAQ was the TestDAQ, including a full simulation of the data-taking process. In a simulated observation run, real raw data from previous runs taken with the H. E. S. S. DAQ are fed into the system, which allows the central DAQ to be tested under near real conditions, the main difference being that there is no actual hardware connected to the TestDAQ cluster and Dummy Controllers take the place of real ones. These Dummy Controllers can also be used to fake slow hardware and to test the error handling of the DAQ. The simulation runs can be used to test the real-time analysis, to test data quality checks and to do benchmarks with the hardware of the cluster as well as the DAQ software running on it to identify bottlenecks.
Conclusion The H. E. S. S. central DAQ has been in operation for almost 10 years without any major problems since the inauguration of the first telescope in 2003. The central DAQ did only contribute to a loss of 0. 8 % of the available dark time since 2009 proving its ability to quickly deal with hardware or software problems during data taking. Moreover, the amount of data that have been lost is negligible. At this point we would like to share the most important lessons learned which could be interesting for other experiments like e. g. the upcoming CTA Project. The ROOT-based data format proved to be useful as a common format for both on-line and off-line analysis software. However, the tight dependency on an external framework lead to various issues. The software had to be adapted to the three major releases of the ROOT-framework (v3, v4, v5) during the last years.
This caused additional work in terms of software development (ensuring back-wards compatibility with existing raw data files and classes) and also in terms of system administration (maintaining different ROOT versions on different operating systems). The distributed development of the central DAQ software and hardware Controllers in the H. E. S. S. Collaboration proved to be difficult due to the many different environments at the different member institutes and laboratories. To avoid some of the problems that usually arise during updates on site (i. e. introducing new functionality for Controllers, installing updates for the operating system or cluster hardware drivers) it proved very usefully to integrate the software and test the installation on the TestDAQ and the DAQ Virtual Machine, which helped to resolve many problems beforehand.
While technically the central DAQ software is organized in separate modules, there are a lot of historic interdependencies between the different modules and classes. As a result, it is very difficult to effectively test the different components of the DAQ software without integrating the full software distribution (both DAQ software, and off-line analysis packages). The DAQ Virtual Machine helped to test Controllers in a "standardized" environment. It provides a pre-installed reduced collection of H. E. S. S. DAQ software modules and their dependencies for easy development and testing. Thus it alleviated some of the mentioned problems. For future projects each software module should provide automated tests that can be run without the need to integrate other modules. This helps to ensure a modules functionality and also reduces the coupling between modules, making maintenance a lot easier.
For future projects it is a good idea to decouple the configuration of the DAQ system from the physical set-up of the cluster computing hardware. This could be achieved by creating virtual machines for all critical tasks (e. g. database servers, boot servers, computing nodes, etc. ) and distribute them dynamically on the available physical machines. This would also reduce the time to reconfigure the system after a physical server or computing node failure during data-taking. Another lesson learned concerns the graphical user interfaces in the control room. The control and monitoring interfaces are very valuable to the Shifters and enable them to take charge of observations after a few nights of training. On the technical side it would have been better to decouple the control functionality from the actual display code.
Figure1: Scheme of the network layout on the H. E. S. S. 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. The purple lines with the diamond shaped ends represent the direct optical fibre connections between the Cherenkov camera trigger sytems and the Central Trigger.
Acknowledgements The authors would like to acknowledge the support of their host institutions. We want to thank the whole  H. E. S. S. Collaboration  for their support. The support of the  Namibian authorities and of the University of Namibia  in facilitating the construction and operation of H. E. S. S. is gratefully acknowledged, as is the support by the  German Ministry for Education and Research (BMBF) , the  Max Planck Society , the  German Research Foundation (DFG) , the  French Ministry for Research , the  CNRS-IN2P3  and the  Astroparticle Interdisciplinary Programme of the CNRS , the  U. K. Science and Technology Facilities Council (STFC) , the  IPNP of the Charles University , the  Czech Science Foundation , the  Polish Ministry of Science and Higher Education , the  South African Department of Science and Technology and National Research Foundation , and by the  University of Namibia.
The 3-D field setup is composed of overlapped measuring loops covering the area investigated with SNMR. The SNMR signal is independently measured in each receiving loop while varying the pulse moment in the transmitting loop. All individual soundings are incorporated into one data set for the 3-D inversion  (Legchenko et al. , 2011). For the inversion, the linear Eq. (  1 ) is approximated by a matrix equation Aw = e, (2) where A = [ ãi,j ] is a rectangular matrix with the elements representing the amplitude of the magnetic-resonance signal generated by water in corresponding cells. The experimental data set is e = ( ẽ1 , ẽ2 ,. , ẽi , ẽl ) T , the water content in the corresponding cell is w = (w 1 , w 2 ,. , w j ,. , w J ) T , and the symbol T denotes the transposition. For simplicity, we assume that cell size is constant throughout the investigated volume.
This cavern was also investigated with borehole sonar, but its complex shape disturbed the sonar measurements and it was not possible to obtain an entire 3-D model of the cavern. The volume of 24 500 m 3 obtained from sonar was less than the 55 000 m 3 estimated with the SNMR method and 48 000 m 3 confirmed by pumping. Whatever the mechanism of water penetration into the glacier, this water reached the bottom and was trapped by the thermal barrier formed by cold basal ice. Today, about 3000 people are exposed to the Tête Rousse hazard and the water in the cavity has therefore been pumped every fall since 2010. For monitoring the water accumulation, we used regular 3-D-SNMR surveys. GPR and sonar data were found to be less efficient for monitoring and we did not use these methods for water-volume estimates.
Acknowledgements. The town of  Saint-Gervais (France) ,  Service de Restauration des Terrains en Montagne (RTM) , and the  Préfecture de la Haute Savoie (France)  funded this study. We thank  N. Karr ,  F. Charles  and  V. Tairraz  for useful advice and for helping with the field measurements. We also thank all the people who assisted us during this work. We acknowledge reviewers  A. D. Booth  and  J. West  for their critical comments that contributed to improving the presentation of our results. Edited by:  J. O. Hagen The publication of this article is financed by  CNRS-INSU.
Previous works In the past decade, several studies have derived constraints on the DM lifetime using cosmological data, starting from the study of decaying hot neutrino DM in  [4]. The case of decaying cold DM was first analysed by Ichiki et al. [3] , who found a 95% C. L. bound of 52 Gyr using WMAP-1yr temperature C data, and assuming decay into fully relativistic species. Ref. [5]  developed the formalism to describe the cosmological effects of an unstable relic and its relativistic decay products, both at the background and perturbation levels. Since then, the bounds have been refined in two ways. First, more data sets on CMB temperature/polarization and on large scale structures have been included in the analysis. For example, by including WMAP-5yr, Type Ia supernova data, Lyman-α forest, large scale structure and weak lensing observations, Ref.
Results The results are summarized in Table  2  and Figures  4  and 5  Table  2. Marginalised Bayesian credible intervals for the cosmological parameters of the models considered in our analysis. We quote either mean values and 68% confidence levels or 95% upper/lower bounds. The last lines show the results for the derived parameter τ dcdm = 1/Γ dcdm representing the dcdm lifetime (assuming a flat prior on the rate Γ dcdm , and not on the lifetime). For the ΛCDM + {Γ dcdm , r} model, we find that the best-fit model has a negligible decay rate. Using the A dataset, the upper bound is Γ dcdm < 5. 9 km s -1 Mpc -1 (95% CL). The decay rate is not significantly correlated with any other cosmological parameter, except ω dcdm+dr and r, as can be seen in Figure  4. Indeed, the data prefer a certain amount of DM at early times, corresponding to the correct redshift of equality.
Hence models with a large decay rate have a smaller DM density today, explaining the negative correlation between Γ dcdm and ω dcdm+dr. There is also a correlation between Γ dcdm and r: both parameters can enhance the small-l CMB temperature spectrum, so larger values of r lead to a stronger bound on Γ dcdm. Still, since r is peaked in zero (as usual using Planck data), we know that the bound on Γ dcdm that we would obtain under the assumption r = 0 would be very similar to what we get here. For the same model and the B dataset, the bounds on the tensor-to-scalar ratio moves close to r 0. 17 at k * = 0. 05/Mpc (slightly lower than in the ΛCDM + r model, because of the correlation with Γ dcdm ), pushing the bound on the DDM decay rate down to 4. 8 km s -1 Mpc -1. For the ΛCDM + {Γ dcdm , r, Ω k } model, and using either the A or B data set, we see in Figure  5  that Γ dcdm is not correlated with Ω k , and that the bounds on Γ dcdm are nearly the same as in the flat model.