dataesr/scientific-paragraphs-categorization huggingface dataset:
e71 9 PAGE#' 5 'Figure 7. 957 Figure 7. Experimental validation of the miRNA binding sites found by our method. (A) Left panel: the motifs identified by miRBShunter for the in-house dataset with CS ≥ 1 are reported with the corresponding miRNA matching and the type of binding site (BS). Right panel: distribution of the different types of miRNA:mRNA duplexes identified by miRBShunter. Color code is indicated. (B) Relative luciferase activity of reporter constructs containing two either wild-type or mutant miRNA binding sites. HEK-293T cells were transfected with either the indicated mimic miRNA or control. The data were normalized using Renilla activity. miRNA::RNA heteroduplex structure expected to result from base pairing of the indicated miRNAs with the indicated binding sites are shown below the corresponding luciferase activity.
Transport and decomposition of DOC in the river network To evaluate the simulated DOC concentrations and fluxes, we used data from the CAMREX (Carbon in the Amazon River Experiment) program  (Richey et al. , 2008) , during which 13 cruises were performed over the period 1982-1991; the data from the ORE HYBAM sampling network (Cochonneau et al. , 2006) , which was designed to capture the land-ocean matter transfer through the Amazon River network from the Andes down to Obidos with regular sampling campaigns; and the data from the study of  Moreira-Turcq et al. (2003). Comparing observed versus simulated DOC concentrations, we were able to reproduce the average concentrations at least in the main stem of Rio Solimoes-Amazon River and in the Rio Negro (Fig. 13 ). However, apart for the Rio Negro, we generally underestimate the seasonal variability of DOC concentrations.
Code availability. ORCHILEAK is derived from ORCHIDEE with the modifications presented in Sect. 2. A description of the general code of ORCHIDEE can be found here: http://forge. ipsl. jussieu. fr/ orchidee/browser#tags/ORCHIDEE_1_9_6/ORCHIDEE. For OR-CHIDEE, the main part of the code was written by  Krinner al. (2005). For the general description of the basic river routing scheme see d 'Orgeval et al. (2008). For the upgraded soil C module see Camino  Serrano (2015). The Supplement to this paper contains the source code of ORCHILEAK and a short instruction how to install the code. For more general information about how to install ORCHIDEE and its different branches, please consult the user guide: http://forge. ipsl. jussieu. fr/orchidee/ wiki/Documentation/UserGuide.
Galaxy surveys require support from massive datasets in order to achieve precise estimations of cosmological parameters. The CosmoHub platform (https://cosmohub. pic. es), a web portal to perform interactive analysis of massive cosmological data, and the SciPIC pipeline have been developed at the Port d'Informació Científica (PIC) to provide this support, achieving nearly interactive performance in the processing of multi-terabyte datasets. Cosmology projects currently supported include European Space Agency Euclid space mission, the Dark Energy Survey (DES), the Physics of the Accelerating Universe (PAU) survey and the Marenostrum Institut de Ciències de l'Espai Simulations (MICE). Support for additional projects can be added as needed. Cos-moHub enables users to interactively explore and distribute data without any SQL knowledge.
It is built on top of Apache Hive, part of the Apache Hadoop ecosystem, which facilitates reading, writing, and managing large datasets. More than 50 billion objects, from public and private data, as well as observed and simulated data, are available. Over 500 registered scientists have produced about 2000 custom catalogs occupying 10TiB in compressed format over the last three years. All those datasets can be interactively explored using an integrated visualization tool. The current implementation allows an interactive analysis of 1. 1 billion object datasets to complete in 45 seconds. The SciPIC scientific pipeline has been developed to efficiently generate mock galaxy catalogs using as input a dark matter halo population. It runs on top of the Hadoop platform using Apache Spark, which is an open-source cluster-computing framework.
Introduction In the recent years, experimental astronomy has entered into the Big Data data regime mainly due to the incessant construction and development of ground-and space-based sky surveys in the whole electromagnetic spectrum, from gamma rays and X-rays, ultraviolet, optical, and infrared to radio bands, e. g. the future 3. 2 gigapixel LSST camera will take images every 30 seconds and the data rate will be about 15 TiB per night  [1]. Besides calibrating and reducing the data coming from the telescopes, easily sharing and quickly overviewing and distributing the data is key to know about its veracity and finally to be able to get value from the data. This means that the way scientists access large data volumes has to be revisited. As a result, new interfaces that allow to get to the datasets without downloading them have become necessary.
The main problem is not the storage capacity but the time it is going to take the user to get an answer out of the data, so it is very important to choose the proper technology, data formats and software tools to manage the data. Since technologies evolve very rapidly, one can design and develop software and data management tools to be ready for real data and these can quickly become obsolete as new technologies and tools are developed in the meantime. PostgreSQL solution was not working as we expected for our use cases. As an example, we generated, and ingested into our database the second version of the MICE mock galaxy catalog (MICECAT2)  [2] ,  [3]  and  [4] , which contains about 500 million entries and more than 120 fields per entry. The aim of the MICE project is to reproduce, with unprecedented detail, the history of the universe from much before the first stars formed up to nowadays, and to determine how well future astronomical surveys can answer these fundamental open questions.
MICECAT2 is composed of several tables that can be efficiently joined. Also, indexes on the most used fields for filtering, such as sky position, redshift or magnitude, were created to ensure fast query response times. However, most queries took a lot of time to finish, up to several hours. This happens because relational databases resort to execute queries through a full table sequential scan when the requested data is larger than 15% of the total volume of the table  1. In those cases, using indices offers no performance benefit, so they are ignored. Furthermore, other operations such as schema modifications, or removing large subsets of rows are also very time consuming. Finally, due to the non-distributed nature of a PostgreSQL database, there is a limit on the amount of storage space it can handle.
Big data platform at PIC The PIC Big Data platform is based on the Apache Hadoop framework, which enables distributed processing of large datasets. It relies on commodity hardware and it is designed to scale up from dozens to thousands of machines, and to automatically detect and recover from failures in a transparent way. The fundamental technology behind Hadoop is HDFS (Hadoop Distributed File System), which is a highly fault-tolerant distributed file system providing high throughput access for large datasets. HDFS splits data in blocks and distributes them across different data nodes. Like other technologies such like Ceph 3  or GPFS  4  , HDFS also makes use of data replication, where a minimum of 3 replicas is recommended for production environments. Thanks to its fault-tolerant and replicated design we are able to extend the HDFS cluster with cheap commodity hardware or recycled machines knowing that, in the event of losing one node, a replica will always be present in a different physical location.
Data stored in HDFS can be managed with a HDFS specific client or, alternatively, mounted through NFS  5  and managed with standard tools. Several applications have been developed on top of HDFS: Apache Hive is a data warehouse that facilitates reading, writing and managing large datasets residing in distributed storage using SQL, and Apache Spark is a distributed processing framework capable of dealing with large volumes of data. All these software components, in addition to administration tools, are provided by the the Hortonworks Data Platform (HDP), which is an open-source Apache Hadoop distribution containing a set of very well tested and integrated Apache Hadoop components. Currently, our Big Data platform at PIC is composed by 30 nodes, with a total of 360 cores, 1080 GiB RAM and 90 TiB HDD.
SciPIC SciPIC is a scientific pipeline developed in a collaborative effort between ICE and PIC, to generate mock galaxy catalogs using the Halo Occupation Distribution (HOD) model. This pipeline has been designed to deal with one of the most difficult challenges within the Euclid consortium project: to generate the largest mock galaxy catalog ever using as input the Flagship dark matter N-body simulation produced by the University of Zurich  [5]. The dark matter halo catalog used as input contains more than 40 billion dark matter haloes, occupies 5. 5TiB in compressed CSV format  6  , while covering the full sky up to redshift 2. 4. The pipeline, written in python, is separated in different modules, each one of them in charge of generating a different set of galaxy properties. The resulting galaxy catalog follows some of the most important observed global properties of the galaxy population, such as the luminosity function, the galaxy clustering as a function of the luminosity and color, galaxy shape distribution and lensing properties.
In order to calibrate our algorithm with the Flaship dark matter halo catalog we use SDSS observed data  [6]. In particular we use the distribution of galaxies as a function of their luminosity. To achieve this we integrated the 'treecorr' algorithm 7   [7] , which estimates 2-point correlation functions, in our Big Data platform. This implementation is useful for many other projects as it is able to deal with very large datasets. The SciPIC pipeline is able to generate one octant of the sky with 2. 6 billion galaxies, with 130 properties each, in 5. 3 hours. The resulting catalog is accessible through CosmoHub. Figure  1  shows a slice of the 3-dimension light-cone projected from a 40 Mpc/h width in the direction orthogonal to the image plane. The three different panels correspond to different galaxy samples: the top one shows all galaxies in the catalog, the middle and the bottom ones show galaxies which are going to be observed with the VIS instrument  8  , and with the NISP channel 9  respectively.
CosmoHub CosmoHub is a web application to perform interactive exploration and distribution of massive cosmological data without any SQL knowledge required. It is built on top of Apache Hive, part of the Apache Hadoop ecosystem, which allows users to use a very familiar SQL language and, from the user's perspective, it works similarly as it did before with PostgreSQL. Hive is able to access files stored in HDFS, but also in other data storage systems such like Apache HBase. Figure  2  is a Heatmap plot generated in 45 seconds using "Step 5: Analysis" of the guided process and shows the distribution in the sky of stars in the Milky Way in equatorial coordinates. Data comes from the public first Gaia 10 data release catalog, which contains 1. 1 billion objects. The web portal has been built using a set of widely community supported web development frameworks, such as AngularJS 11 for the HTML and JavaScript 12 , Twitter Bootstrap CSS framework 13 for the styling, JavaScript WebSockets 14 for server-client communication, Plot.
ly 15 for the charts generated in the Analysis step and Wordpress 16 for some parts of the backend (news, contact form, etc. ). CosmoHub catalogs come from different surveys, which in general produce data of the order of terabytes, which need to be stored, analyzed and distributed. Most of them are galaxy catalogs, but there are also star catalogs such as the first release of the project Gaia 17 ). Each entry in a catalog is usually a galaxy, which can be characterized by hundreds of properties (as fields in a table) such as the position in the sky, luminosity, color or morphological properties, etc. The main feature of CosmoHub is the ability for users to generate their own custom catalogs without any SQL knowledge through a guided process, which can then be analyzed or downloaded in several formats such as CSV.
Conclusions Relational databases are one of the most powerful tools for dealing with structured data. Well optimized, they can manage hundreds of millions of entries, even some billions, in a single table. They are optimized to handle thousands of queries per second, each one of them involving a small number of records. However, they are not designed to work with queries involving massive subsets of the table. In these cases, a query response may take up to several hours, which precludes any real interactive usage of the results. After migrating the CosmoHub database infrastructure to Apache Hive on top of our PIC Big Data platform, we have experienced a great improvement in the response time: depending on the query, they can run up to 100 times faster. Migrating to an Apache Hadoop platform enables us to use all the other applications in the ecosystem.
For instance, one of these components is the cluster computing framework Apache Spark, which has been key to generate the Euclid Flagship mock galaxy catalog, the largest synthetic galaxy catalog up to date, in just 5 hours. Finally, we are exploring the possibility of offering the scientists a platform to develop and run complex analysis over our Big Data platform. Projects such as Jupyter 20 or Apache Zeppelin 21 provide such a development and execution environment on top of Apache Spark, and may open a future full of opportunities never foreseen.
The Fly Algorithm was initially developed for 3-D robot vision applications. It consists in solving the inverse problem of shape reconstruction from projections by evolving a population of 3-D points in space (the 'flies'), using an evolutionary optimisation strategy. Here, in its version dedicated to tomographic reconstruction in medical imaging, the flies are mimicking radioactive photon sources. Evolution is controlled using a fitness function based on the discrepancy of the projections simulated by the flies with the actual pattern received by the sensors. The reconstructed radioactive concentration is derived from the population of flies, i. e. a collection of points in the 3-D Euclidean space, after convergence. 'Good' flies were previously binned into voxels. In this paper, we study which flies to include in the final solution and how this information can be sampled to provide more accurate datasets in a reduced computation time.
I. INTRODUCTION "Big Data" has become a reality in the past years, with enormous amounts of data generated humans (e. g. , Soocial Networks) and by all sorts of sensors (e. g. , Internet of Things). For instance, it is estimated that we create 2. 5 quintillion bytes of data every day and that 90% of all data has been created in the last two years  [1]. While managing and storing large amount of data has been a focus of interest, processing them is challenging as it is skill and labour intensive  [2]. MapReduce  [3]  and similar frameworks have been proposed to simplify the ingestion, storage and processing of large amount of data on distributed architectures. For instance Hadoop  [4]  is extensively used by companies by companies, for instance Ebay, Facebook or Google  [5]. The quality of such software systems is difficult to assess though, as testing any distributed systems is a known complex challenge.
Issues in a distributed software system can come from various elements: software or hardware components, their integration, or the communication between components  [6]. Another risk is also to introduce artificial defects or to impact the performance of the system with the monitoring apparatus. In this poster we present BDTest, a system that aims at testing Big Data Platforms, such as, Hadoop. BDTest uses a lower tester architecture  [7]  which has a limited impact on the system under test (SUT), while offering the possibility to run complex test scenarios. While BDTest could test functional properties, we focus on non-functional ones -for instance, changing artificially the performance or availability of computing nodes in the SUT, i. e. , only for the test scenarios. We plan to address in our future work a variety of research questions, such as: • Can we test the performance of the partitioning and load balancing mechanisms of Hadoop? • Can we discover performance bottlenecks in Hadoop using BDTest and, for instance, model-based testing techniques?.
II. RELATED WORK The increased interest in and use of Big Data platforms like Hadoop has led to a lot of research and the development of testing techniques and tools. One of the most interesting attempts is MRUnit  [8] , a Java framework that aims at creating JUnit  [9]  tests like test cases for MapReduce jobs. However, this tool requires to introduce specific calls to its API in the SUT and can generate new bugs or decrease performance of the SUT. BDTest tries to avoid any modification of the SUT. PigUnit  [10]  is another interesting tool which uses the unit test model with some success. However, PigUnit works only for Pig, one of the many applications/modules of the Hadoop ecosystem. On the contrary, BDTest being independent of the exact running systems, should be able to interact with any Big Data platform -and in particular any Hadoop module.
Testing distributed systems has been studied quite a lot in the past, however with poor success at times. GridUnit  [11] ,  [12]  proposed a mixed model: a centralised architecture with the execution of tests on the node level, but GridUnit does not handle the volatility of computing nodes, which is an important element in distributed systems. P2PTester  [13]  and Pigeon  [14]  proposed to use a fully distributed architecture but they require to modify the code of the SUT which brings the same limitations as MRUnit for Big Data systems. PeerUnit  [15] ,  [7]  is a project that inspired BDTest. PeerUnit creates complex unit tests for distributed (peer-to-peer) systems without modifying the SUT. Test scenarios in PeerUnit are synchronised over all the computing nodes using either a centralised or a decentralised architecture  [16]  -PeerUnit can work using both modes.
This decentralised architecture scales up better compared to the centralised one and limits the communication overhead. Validating global properties is one of the key challenges in testing distributed systems  [18]. BDTest makes sure that each tester manages its own data which is later aggregated in to a global view (a test oracle) by the coordinator (centralised architecture) or the root node (decentralised architecture). BDTest implements assertions and value comparisons as they are the easiest testing methods  [19] ,  [20]. Log file (offline) analysis is not yet implemented in BDTest but this is a potential direction of research. V. CONCLUSION This poster presents BDTest, a system to test Big Data platforms, such as Hadoop. Software testers using BDTest create test scenarios using simple unit tests (assertions and value comparisons) and BDTest manages the dissemination of the actions to every tester (each in charge of a computing node).
BDTest can simulate all sorts of defects (e. g. , performance defects) and as such can be used to test non-functional properties as well as functional characteristics of Big Data platforms. As a future direction, we would like to extend the number of Big Data modules (from the Hadoop galaxy) that BDTest can work on -e. g. , Spark  [21]. We would also like to evaluate the performance of Big Data platforms on different architectures and see whether BDTest can be used for benchmarking as well as for testing.
The Calphad method is an important tool to assist the development of new alloys. There are several different thermodynamic software and databases available for such calculations. In some of these alloys there are is an important order/disorder transition, like in superalloys (Ni-based)  or Al-Ti alloys. This paper describes the modeling of such systems and a new software that has improved the implementation of the modeling of this transition which can extend the composition range of the application of the model.
Introduction The use of the Calphad method is described extensivly in many pares and in the book by Saunders and Miodownik  [1]. In the Calphad method each phase is described with a model for the Gibbs energy as a function of T, P and the phase constitution. With appropriate software and assessed databases the user can calculate phase equilibria, phase diagram and to simulate phase transformations. The Calphad method has been implemented in several commercial software and databases  [2] [3] [4] [5]. More recently a free software has been developed with improved modeling and software techniques. This will be briefly described in section 3.
is the Gibbs energy of formation of endmember I from the reference states of the components. In the configurational entropy a s is the number of sites on sublattice s. The mole fraction of a component i can be calculated from the constituent fractions as:  (5)  where b ij is the stoichiometric factor of component i in constituent j. This model has been used successfully to describe many different kinds of phases with long range ordering (LRO) like interstitial solution  [6] , intermetallics  [7]  and phases with order/disorder transitions  [8]. But frequently the models have simplified the real crystallography because the number of endmembers increases rapidly with the number of constituents on the sublattices. For example the  phase has 5 crystallographic lattice sites but it is often described with just 3 to simplify the calculations and the database development.
In order to be compatible with the modeling of the B2 phase in the Al-Ni system the vacancy, denoted "Va" is also included on all sublattices because the B2 phase in the Al-Ni system is stable at higher concentration that 50% Al due to the replacement of Ni atoms by vacancies. There are 81 endmembers in the model for the ordered BCC in the Al-Fe system but many of them describe the same state, they are permutations and this will be further discussed in section 2. 5. Written explicitly for a 4 sublattice model eq. 3 becomes:  (8)  For the expressions for E G M and phys G M please refer to the book by Lukas et al. [9]. Model compatibility is an important feature when assessing experimental and theoretical data to describe the Gibbs energy of the phases in binary and ternary system. The same models must be used for the same phases in different systems in order to combine Bo Sundman / JMM 53 (  3 ( y G G G is E M phys M    them in a thermodynamic database.
Model parameter permutations A final problem when dealing with ordering in FCC, BCC and HCP is that many endmember parameters represent the same state. For example in Au-Cu system using a 4 sublattice model for the FCC phase with all superlattices the L1 2 ordered AuCu 3 phase is described by 4 different endmembers that must be equal:  (11)  An ordered model for the FCC phase with 4 constituents modeled with 4 sublattices has 256 endmembers but only 35 unique values. This is a complication for the administration of databases as it is very easy to forget a permutation which will make the phase always ordered and give wrong thermodynamic properties even in the disordered state. But it is possible to implement these permutations in the software and thus the databases need only to provide values for the unique endmembers.