dataesr/scientific-paragraphs-categorization huggingface dataset:
The system is also prepared for a sudden shutdown (for example, power outage). Given that the system only removes the tasks from the stack when they are finished, once the server is turned on, the first task to be executed will be the one that could not be completed. The fact that all these scenarios are taken into account by the stack of tasks, makes CAELIS a robust system and easy to maintain. The system executes maintenance tasks regularly. For example, a daily backup is performed. This task is scheduled every night thanks to activation time information. The maintenance tasks can cover many different activities that need to be done regularly in the system. Other examples of the maintenance tasks include the optimization of the database and regular re-booting. The current implementation of the daemon is developed using bash scripts.
This characteristic allows running tasks written in any language. It is planned to improve the current implementation by using Python and to introduce parallelism into the task chain. If this has not yet been undertaken, it is due to the relatively low load of the system. Processing in sequential mode is still sufficient to provide data in NRT. When more sophisticated algorithms will be run (such as inversion retrieval algorithms) a new implementation of the daemon will be needed. Alternatively, tasks can be launched in a server farm allowing the system to only organize tasks, keeping its load very low. The tasks are currently implemented mainly in C because of its high performance, but any compilable language is allowed in the server. 6 Web tool CAELIS system offers users a web interface (http://www.
caelis. uva. es). The web interface is a high level view of the data model, and thus it shows information in real time, as soon as it is processed. The web system is secured with private access, only for registered users. During the registration process a "role" is assigned to each user. The roles allow identifying groups of users with different permissions into the system, for example, regular users (site managers or researchers) that can access its data or a system administrator that can handle the stack of tasks of the system or reboot it. The web interface provides high-level access to the database. It can extract and relate different data and show them all together as an online real-time CAELIS has implemented many different use cases which are sufficient for common user actions. The system offers different tools depending on the role of the user.
For example, a site manager can check the performance of one instrument, a network manager can modify the location of an instrument and a system administrator can check the tasks that the NRT module is executing. The web interface allows the user to explore the database showing tables and customized plots. Some of these use cases are described below in the example section. The web interface allows one to query information as well as inserting new information. This is specially interesting because it constitutes the second way to insert data into the system: data inserted by the users (data can also be registered by the tasks controlled by the daemon; see previous section). In the case of users, since they work via web interface, the actions can be controlled in two senses: (1) the user has the permission to introduce the information, and (2) the information introduced is validated.
Moreover, the fact that manual information is registered by means of the web interface allows the system to launch "derived tasks" for an specific ac-tion. For example, when a new measurement site is created, the system can add the action of "insert climatology data for the new coordinates". Everything is triggered automatically and controlled by the logic implemented in the web interface. The web interface has been developed using PHP through the Symfony framework, Bootstrap as CSS framework and jQuery as JavaScript framework (used for asynchronous actions and to make the interface more dynamic). The choice for PDO (PHP Data Object) is Propel. Every technology selected in the development has been highly studied: -PHP is a widely developed language for web development. It shows very good performance and popular websites have been developed using it.
It has a big community behind, which offers helpful support. The ecosystem (libraries implemented to be used with PHP) is one of the best for web computing and includes libraries for graphical representation, mathematics, etc. -Symfony framework: at present, for quick development the use of this framework is heavily development. This allows developers to stay focused on main issues and reduce the complexity of common tasks: user management, database access, etc. The selection of Symfony over other alternatives was because it became very popular at the moment web interface development began and the community was very active. Moreover, it is easy to use, contains hundreds of libraries, is powerful and flexible and it performs well. -JavaScript is used for asynchronous connections with the server in order to offer a very dynamic interface.
JavaScript is undisputedly the best for this purpose. -jQuery is used as JavaScript framework. There are alternatives but jQuery is very well integrated with Symfony, it is widely used and fulfills all system requirements. -Propel was selected for the PDO library because it allows one to have primary keys with multiple fields. CAELIS database has been deeply optimized and the use of multi-field primary keys greatly improves performance in comparison with an auto increment ID (common alternative). At the decision time, only Propel managed such kind of keys. The web interface has been structured and designed to grow, being able to add the management of other measurement networks or scientific projects. Those projects can share the core of the developed code. This allows one to start projects from existing code instead of starting from scratch, making it quick to add new features.
), and when a specific day is selected the user can explore all information (raw data, products) received and processed for that particular day. Every day, calibration centers need to solve instrument issues and multiple questions and this is only possible thanks to deep knowledge of the instrumentation. CAELIS helps with routine problems and provides very useful information about the data contained in the database. In the case of new issues, the system offers a data viewer which allows one to customize the data to be displayed in a very flexible and powerful way. Figure  10  shows setting up a specific case in which data from different sources are shown in the same plot in order to help the network manager to understand the problem. We can select one or multiple variables (all available raw data and data products) from one or multiple instruments, and display them for a particular date/time range, with full flexibility in plot configuration  (colors, axis, etc.
Research applications The following example will show a specific project of the research group with the aim of studying the AERONET database. As part of this project, a relational database which organizes AERONET data was created. By querying this database the user can answer general questions about AERONET sites, including the following: since when has an AERONET site been active? How much data (and at what quality) does a site have? This project re-uses at maximum the core of the system (user access, plot tools, etc. ) and lets the developers create a new tool quickly. CAELIS has been used as "framework" for data analysis. The effort required to develop this system is far less than starting from scratch. The features needed in this development are a tool to assimilate the new data and the specific views that show the results.
Additionally, CAELIS can re-use the database added here in other projects. Figure  11  shows the automated aerosol data analysis of an AERONET site (Palencia, Spain). In it, we can see the data coverage (for level 1. 0, 1. 5 and 2. 0 of the AERONET database), monthly statistics of aerosol optical depth and Ångström exponent, frequency histograms and AOD vs. AE scatter plot providing basic aerosol type classification. These plots provide a general overview of the site characteristics in terms of data coverage, aerosol statistics and type classification, which can be used as a first approach in order to select a site for some particular study. Then, based on this general information, the researcher can ask other questions that can be solved by interrogating the database directly. In order to illustrate how it can be done, the next part of the example will show how to identify special aerosol events at the Palencia AERONET site.
For this purpose, we need to explore the CAELIS database. The starting point will be the following questions: how many days of high turbidity occur at the site? How many of these can be classified as desert dust events? To answer these questions we will use the previous (overall) climatology and we will make some assumptions. First, we are going to assume that "a high-turbidity event" takes place when the AOD average is larger than the climatological mean plus 2 SD (standard deviations). Based on that assertion, we can write an SQL query that is launched in the system database and will review every single value and return the result. To create this SQL query it is important to have accurate knowledge of the database model in order to obtain the expected results and within a reasonable time.
For our particular case, we will use the cml-aod table which contains the general information about each AOD measurement, and the cml-aod channel which contains AOD information about each specific wavelength channel. First, we check how many days with AOD measurements we have for Palencia AERONET site: The result is shown in Fig. 12 , where we can see the two peaks of occurrence of Saharan dust episodes over Spain, i. e. , February-March (early spring) and May through September, basically the summer months. This example shows the flexibility and power of a relational database to make data analysis. Using SQL queries, very complex customized questions can be asked and the data can be easily extracted from the database.
Summary and conclusions The atmospheric aerosol particles are one of the most important contributors to the climate forcing uncertainty. They are currently extensively measured from ground and space, with very different techniques. It is therefore important to develop tools using modern technologies to monitor (quality control), process, analyze and combine those data. This paper has described the CAELIS software tool, which has been developed for the management of the photometers that are calibrated and monitored by the calibration facility at the University of Valladolid, Spain, as part of AERONET. CAELIS is intended to provide management for the photometer network, archive the data and allow data analysis and research. Previously to the development of CAELIS, these tasks were done manually.
The use of this kind of advanced system has reduced the number of human errors and allowed one to perform more in-depth and exhaustive analysis. Thanks to CAELIS, we are currently receiving and analyzing data from 80 sites, with a quality control system that provides flagging of the data in real time. This provides great benefits to the network management and allows immediate response to instrument malfunction. The core of the CAELIS system is built in a relational database. It stores user information (with its privileges), data, meta-data, etc. Around this database, different modules use it and offer different services: a web interface to explore the database and a NRT module to perform processing. All this software can be re-used for extending the system, for instance with other instrument types.
The construction of the database requires a balance between normalization and redundancy. The current system has three different layers of data. Layer 0 contains the raw data and the network management information, layer 1 contains direct products, and layer 2 contains advanced derived products that can be calculated. Each layer is based on the information of the previous one. A keystone of the system is to have correct model of the first layer, i. e. , normalized and without redundancy. This helps maintain the congruence of the system. Based on these data, other products can be developed. Depending on the use of these products, some redundancy may be necessary. For instance, pre-calculated products can allow for fast visualization in the web interface, which would be too slow if done on the fly.
The existence of redundancy implies that automated tasks are needed to maintain congruence. This is done by the NRT module, which organizes the actions in separated tasks. The NRT module is always running, thanks to a daemon which is based on a stack of tasks organized by priority, and that decides in every moment what must be done. Users (site managers, calibration centers, researchers, etc. ) can use the web interface for quick access and visualization of data. The relational database is shown to be an appropriate tool for research because it allows one to perform queries and extract data in a fast and very flexible way.
Acknowledgements. The authors gratefully acknowledge the effort of  NASA  to maintain the  AERONET program. This research has received funding from the  European Union 's  Horizon 2020 Research and Innovation Programme  under grant agreement no. 654109  ( ACTRIS-2 ). The funding by  MINECO  ( CTM2015-66742-R ) and  Junta de Castilla y León  ( VA100P17 ) is also acknowledged. We thank all the users of CAELIS for their feedback, especially  Emilio Cuevas ,  Carmen Guirado  and  Roberto Román. Edited by: Luis Vazquez Reviewed by: three anonymous referees.
Phase 3: The facility upgrade Once all the building blocks for the upgrade of the whole facility will be ready at the INFN-LNS, the NUMEN Phase 3, will incorporate the disassembling of the old set-up and re-assembling of the new will start. An estimate of about 18-24 months is evaluated. During this period, the data analysis of the NUMEN Phase 2 experiments will continue. In addition, tests of the new detectors and selected experiments will be performed with Tandem beams at INFN-LNS and in other laboratories in order to provide possible pieces of still missing information in the explored reactions network.
The use of the sophisticated data reduction approaches based on the differential algebra is a unique feature of MAGNEX, that have been developed in the years (see Section 4. 5). This guarantees the above mentioned performances and its relevance in the worldwide scenario of heavy-ion physics  [125]  [126]  [127]  [128]  [129]. The MAGNEX Focal Plane Detector (FPD) consists of a large (active volume 1360 mm × 200 mm × 96 mm) low-pressure gas-filled tracker followed by a wall of 60 silicon pad detectors to stop the particles and provide the acquisition trigger signal  [130]. A schematic view of the present FPD is shown in Figure  4. 1. A set of wire-based drift chambers (DCi) measures the vertical positions  (Yi)  and angles (φi) of the reaction ejectiles, while the induced charge distributions on a set of segmented pads allow to extract the horizontal positions (Xi) and angles (θi).
The first version of the VMM was tested in the NSCR Demokritos Tandem accelerator. The measured cross-section is (4. 1 ± 0. 7) × 10 -24 cm 2 /bit. Taking into account that the total number of bits for the VMM register is 3264, a total of about 300 SEU/yr/VMM is estimated for the maximum neutron flux foreseen in NUMEN (7×10 4 neutrons/(cm 2 s), see Section 6. 8. 5). These SEUs can be partially recovered by register resetting. No data exist regarding the radiation tolerance of the SOM, despite different tests with neutrons and gamma rays have been conducted on similar devices. The main criticalities are the same described for VMM, related to SEU and integrity of registers. The NUMEN collaboration has started a dedicated test campaign of the overall electronics chain, FE and RO, in order to precisely determine the radiation tolerance performances and, in parallel, a possible mitigation strategy.
During the normal operations, when the main server is working, the backup machine can be used for offline data processing. The interface to the storage component is a RAID6 Fibre Channel controller: it can write on disk up to 16 Gbit/s (= 2 GB/s), which is safely above the data rate expected in NUMEN. The targeted dimension for the global RAID6 disk storage is about 500 TB, which is readily available on the market. Since NUMEN will be intrinsically made by many independent runs, with different target nuclei, an alternative layout under consideration is to have a partitioned storage (e. g. blocks of 48 × 4 TB disks, totaling 160 net TB each).
Offline analysis The offline reconstruction of NUMEN will be performed using the MXSoft code, which is already available. MXSoft is the re-engineering in C++ of the software suite already used and validated in MAGNEX; it depends upon ROOT  [225]  for the storage of the final high-level information. In particular, all calibration, selection and reconstruction algorithms are kept exactly the same in MAGNEX. However, MXSoft was specifically designed to be modular and flexible, allowing to easily accommodate for possible extensions or new/alternative algorithms, and to improve the CPU performance and the memory footprint. The performance of MXSoft has been tested and validated with the recent NUMEN Phase 2 runs: based on this, the new code is expected to be appropriate and scalable up to the anticipated data rate of NUMEN Phase 4.
Acknowledgements. List of acronyms. Acknowledgements The authors wish to thank  Prof. F. Iachello  for the encouragement and fruitful discussions during the development of the project. The authors thank also the  INFN-LNS  accelerator, technical and research divisions for the support in all the phases of the project,  Mr. Mauro Raimondo  ( DISAT -Politecnico di Torino ) for the precious work in producing the FESEM images. The authors are also thankful to  Trustech Company  for the valuable expertise in performing the depositions. This project has received funding from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation programme  (grant agreement No  714625 ) and from the  European Union 's  Horizon 2020 research and innovation programme  (grant agreement No  654002 ).
Material and Methods A homogeneous Jaszczak and a Triple Line phantom (3 FDG-filled tubes, 1mm diameter) were acquired on 2 devices (PET1, PET2). 22 volumes of interest (VOI) were drawn in the Jaszczak on 9 acquisition/reconstruction protocols (PET1: N=8, PET2: N=1). An in-home Python code was developed for spatial resampling of images to a new voxel size of 2x2x2mm 3. Spatial resolution was calculated on Triple Line and the set with the worse spatial resolution was chosen as reference. A gaussian filtering was applied to all other images to reach the reference spatial resolution (Fig. 1 ). A multicenter clinical validation of the method was performed retrospectively in 4 institutions totalizing 137 patients, divided in 5 protocols on 3 PET devices: PET1. 1, PET1. 2, PET2. 1, PET2. 2, PET3 with respectively 29, 24, 24, 32, 28 patients.
Results Spatial resolution of reference dataset evaluated on phantom acquisitions was 7. 9mm. Before standardization, only histogram features were robust while varying PSF, iteration number and manufacturer's post-filter width (p>0. 05). 21 features were not robust (p<0. 05). After standardization, range of SNR values was reduced (before: 9. 2-27. 7; after: 20. 7-33. 7). Filtering was highly efficient to harmonize 3 protocols on phantom data (p>0. 05, 36 features) where the only varying parameter was manufacturer's post-filter width. For more complex variations (PSF +/-), no benefit was observed. On original patient data, histogram features were robust (p>0. 05). Differences in textural feature values were highly variable depending on PET scanner.
Material and Methods A total of 89 mice from two centers (Cancer Research UK (CRUK), AstraZeneca (AZ)) underwent therapy and MR images were acquired at varying time points and doses. After the final imaging session, mice were euthanized and the tumour processed for histological evaluation. CRUK: 45 mice, including genetically engineered mice with spontaneous pancreatic adenocarcinoma (KPC, N=13) driven by mutant KRAS and p53 and mice with subcutaneous allografts of a KPC-derived cell line (K8484, N=32) were treated with vehicle or gemcitabine at 100 mg/kg. AZ: 44 immunodeficient mice with PC9 lung adenocarcinoma xenografts were treated daily with vehicle or gefitinib at 6. 25 mg/kg. For both datasets features consisting of first-order statistics, shape, local intensity, texture, fractal dimension, multi-scale filters and textures were extracted from FSE (CRUK only), DW images (AZ only) as well as ADC maps.
Input data and assumptions Power plant reference characteristics: These characteristics are either computed using thermodynamic equations or taken from the literature. Though a closed Brayton cycle is used, most characteristics are close to those of the original project involving the NACC. We assume that the transition times when the operators switch the PP operating modes are sufficiently short compared to the time spent in each mode. Moreover we assume that the temperatures of the coolants in the combined cycle remain constant during the discharge of FIRES. This last statement is made in case of the first approach but needs to be verified to obtain more accurate estimates of R Dt. Admitting those two assumptions is tantamount to making all the PP characteristics just functions of the PP operating mode.
In order to image the animal soft tissues, the specimen was subsequently transferred in a contrast stain solution of 2. 5% phosphomolybdic acid for 10 days  [15]  and scanned at the AST-RX Platform (Acces Scientifique ala Tomographie aRayons X) of the Museum National d'Histoire Naturelle, Paris. We obtained the tomography projection images needed to reconstruct the cross-section images with NRecon volumetric reconstruction software (SkyScan, 1. 4. 0, Kontich, Belgium). Then, the AVIZO software (v. 6. 3; FEI Visualization Sciences Group) allowed us to reconstruct the three-dimensional model of the fish, especially the external three-dimensional shape of the head and pectoral region, as well as the buccal cavity. The three-dimensional model was imported in Geomagic DesignX (3D Systems, Morrisville, NC, USA) for cleaning and generating spline surface patches that can be imported in DesignModeler.
In DesignModeler, we defined the geometry of the fluid domain by creating a sphere of 0. 5 m radius centred on the initial geometry of the fish model. Then, a cylinder of 0. 006 m radius was connected to the mouth aperture of the fish. We applied a Boolean subtraction to obtain a single body containing the cylinder and the fish head inside the sphere. On a second model, named the flat model, we added a box of 0. 0078 m Â 0. 012 m Â 0. 008 m inside the mouth, at the level of the back of the oral cavity. We performed a Boolean subtraction to obtain one body with a flat back of the mouth. Geometries were imported in Meshing software and meshed with 11. 6 million tetrahedral cells. Further refinement to a mesh of 15. 2 million cells only had a negligible influence on drag force (þ0. 6%). At the level of the mouth, we imposed a flow inlet with a prescribed velocity of 0.