dataesr/scientific-paragraphs-categorization huggingface dataset:
Novel gene identification Identification of novel genes in the new reference genome was performed with the help of gene prediction algorithms trained on all available RNA-Seq data sets. Augustus training was done with BRAKER1 pipeline  (Hoff et al. 2019)  with support from mapped RNA-Seq reads. SNAP gene predictor was trained within MAKER using maker documentation. Both the gene prediction methods were used to find novel genes. Updated ITAG gene models were used as passthrough (parameter: model_gff) during the annotation process. The newly identified gene models were screened for potential repeats. Gene Ontology enrichment for novel genes was performed based on R/Bioconductor package topGO. Overrepresented GO-terms were calculated using Fisher's exact test.
Functional annotation Functional annotation has been done with Araport11, SwissProt and TrEMBL plant databases using BLAST  (Altschul et al. 1990 ). Blast results were input to Automated Assignment of Human Readable Descriptions (AHRD) (https://github. com/groupschoof/AHRD) and get functional descriptions. We also run InterproScan  (Zdobnov and Apweiler 2001)  and BLAST  (Altschul et al. 1990 ) to get GO terms (G. O. Consortium and Gene Ontology Consortium 2006), Pfam domains  (El-Gebali et al. 2019). AHRD results together with Interproscan results were used to assign functional descriptions to ITAG4. 0.
Long non-coding RNA prediction Prediction of long non-coding RNA (lncRNA) was based on transcript generated using Mikado software  (Venturini et al. 2018). For Mikado, an extensive expression data was used including full-length Iso-Seq data. Mikado resulted in 153K non-coding genes. To identify lncRNA within 153K transcripts, FEELnc pipeline was used with default parameters and further filtered based on genomic overlap with ITAG4. 0 protein-coding genes.
Gene family analysis Solanum lyocpersicum gene family analysis has been performed with Orthofinder  (Emms and Kelly, n. d. ) , Interproscan  (Zdobnov and Apweiler 2001) , KinFin  (Laetsch and Blaxter 2017)  and CAFE software (De  Bie et al. 2006). protein family analysis has been done using Oryza Sativa, Arabidopsis thaliana, Vitis vinifera, Ipomoea Nil, Petunia axilliaris, Petunia inflata, Capsicum chinense, Capsicum annuum, Solanum tuberosum and Solanum pennellii proteins downloaded from Phytozome (https://phytozome. jgi. doe. gov/).
The ATLAS EventIndex has been in operation since the beginning of LHC Run 2 in 2015. Like all software projects, its components have been constantly evolving and improving in performance. The main data store in Hadoop, based on MapFiles and HBase, can work for the rest of Run 2 but new solutions are explored for the future. Kudu offers an interesting environment, with a mixture of BigData and relational database features, which look promising at the design level. This environment is used to build a prototype to measure the scaling capabilities as functions of data input rates, total data volumes and data query and retrieval rates. In this proceedings we report on the selected data schemas and on the current performance measurements with the Kudu prototype.
Motivation for the project evolution The current EventIndex was designed in 2012-2013 using the best BigData technology available at that time (Hadoop), implemented in 2014 using MapFiles and HBase, and in operation since 2015 with satisfactory results  [3]. However, the use cases evolved in the meantime and have been extended from event picking and production completeness checks to trigger overlap studies, duplicate event detection and derivation streams (offline triggers) overlaps. At the same time, the implementation of fast data querying based on a traditional relational database involves only a subset of information and is available for real events  [4]. Also the event rate increased steadily throughout Run 2. In the meantime BigData technologies advanced and now we have the choice between many different products and options.
Apache Kudu Apache Kudu is a next-generation scalable and distributed table-based storage designed for HTAP systems -Hybrid Transactional and Analytical Processing  [6]. Unlike most of the data formats available for the Hadoop Distributed File System (HDFS)  1  , Kudu provides indexing and columnar data organization natively -this is to establish a good compromise between random data lookups and analytics performance. The data organization in shared tables with named columns, types and a primary index makes Kudu very attractive for systems with relational data models that need to scale out. Apache Kudu is supported by top open-source frameworks for parallel data processing and computation including Apache Spark, Apache Impala, Apache Hive, MapReduce and others. Bringing on-board Kudu, a storage supported by many computing frameworks, offers to the ATLAS EventIndex a possibility to have a modular architecture and increases its flexibility in further evolution.
Any module responsible today for one of the functions, the data ingestion layer, data access layer or data analytic layer could be replaced with a modern one, without significant effort. In the new architecture presented in Figure  1 , we foresee to keep the data ingestion/production part without significant modification. It has been already modernized by introducing a staging area implemented with an object store layer  [7]  (based on Ceph storage) staging all recently indexed event data from WLCG 2  jobs. The only work foreseen in this area is to build a data pipeline between the object store and the Kudu storage. Such a pipeline will need to enrich the data with necessary information regarding trigger state, event provenance etc. from the AMI  [8]  and Rucio  [9]  metadata systems.
Concept of the new ATLAS EventIndex platform The main modernization touches the data access layer that has to be redesigned in order to fully profit from the functionality and performance offered by Apache Kudu. Notably, the MapReduce framework has to be replaced with low-latency SQL-based frameworks like Apache Impala  3. Impala is well integrated with Kudu and allows to start event lookups queries within milliseconds. Moreover, the addition of an SQL interface to the ATLAS EventIndex data will open a possibility to integrate the project with external tools and systems over the JDBC protocol. So eventually currently available web front-ends implemented for a relational back-end can be reconnected to the Kudu-based storage. As more analytic use cases have been added to the system recently, Apache Spark 4  , a modern and highly scalable and feature-rich data processing engine, would be an obvious choice for the implementation of such use cases.
Schema design in Apache Kudu When designing a schema in Apache Kudu we had to make decisions on a few aspects that ultimately have a great impact on a data access time, scalability and usability of the data stored in Kudu tables. This includes the number of tables and relations between them, choosing appropriate primary keys and partitioning strategies for each of the tables, and finally, data types, encodings and compression algorithms for each of the columns in the tables. In this section, we will describe the schema for Kudu tables that we prototyped to store the ATLAS EventIndex data and criteria that led us to make certain design choices.
Furthermore, in order to reduce the work done by the scanners, the number of rows to be visited by the scanning operation can be narrowed/pruned to those stored in certain partitions. This can happen if a partitioning key is present in a filter predicate of a query. In theory the 'runnumber' column from ATLAS EventIndex data is the best candidate for a table partition key, as it exists in all the queries and it has very high selectivity, as only a few partitions will be chosen for scanning. However, since the amount of data per run number is skewed, we would have too many almost empty partitions and sub-partitions too. With respect to the limitation 3) we would quickly reach the maximum number of supported partitions. We could group more runs into a single partition in order to keep all partitions with a unified size; however, due to the limitation 4) grouping cannot be done dynamically.
Tables Following a process of multiple iterations, we have concluded that the following list of tables should be sufficient to store the system data in an efficient way and provide the required functionality: -DATASETS -metadata table, grouping events into datasets. This table assigns a unique id for each dataset, maps each dataset to a partition, and provides basic statistics about each dataset, notably the number of events, import time, how much time it took to load it and corresponding statistics copied from the AMI system for consistency verification. The full schema of the table can be found in the Table  1. Since this table is expected to not grow significantly in size, it does not have to be partitioned. -EVENTS -contains metadata about each event. Most of the data access use cases will query this table to obtain information about the events, such as: trigger chain, GUID of a file with actual event data, and provenance of an event -what files it originated from.
The partitioning strategy should be the same as in case of the events table. -EVENTSOVERLAP -the purpose of this table is to store the results of datasets overlap computations -how many events two given datasets are sharing. Therefore it has a basic schema, containing two primary key columns defining datasets id being compared, and a big integer counter column. This table is expected to grow slowly, so no partitioning is needed. -TRIGGERCOUNT -similarly to eventsoverlap, it should store the results of computations on trigger masks. This table has just 4 columns. Three -dataset_id, trig1 and trig2 are making the primary key. The remaining column is just a big integer counter, representing the https://doi. org/10. 1051/epjconf/201921404057 CHEP 2018 Figure  2. Data ingestion speed measured on representative data set number of occurrences of the two given triggers within a dataset.
Hardware and software used All the performance tests have been performed on a cluster composed of 12 physical machines, each equipped with 2 CPUs with 8 physical cores with clock speed 2. 60 GHz, 64 GB of RAM and 48 SAS drives with 4 TB each. Apache Kudu was compiled from version 1. 7. 0 on the SLC6 Linux distribution (equivalent to RedHat 6). The software was configured to use at maximum 10 GB of RAM and 10 cores for maintenance tasks.
Data access In Figure  3  we present the time to look up eight thousand random event records (full record or just a GUID attribute) from Apache Kudu with a simple client written in Python. The results for each type of a lookup were grouped into two cases; a pessimistic one (no cache used) and an optimistic one (all data were looked up from the Kudu cache). The average event lookup time below 1 s and the ability to handle more then 400 requests per second fully satisfies the future system needs.
Analytics Data analytics tests were performed with Apache Spark 2. 2. 1 reading ATLAS EventIndex records from data stored in Apache Kudu. Figure  4  shows the execution times for the test case, where we count the occurrences of all combinations of trigger bit pairs within a dataset of 100M events. The trigger count computation on a Spark cluster takes the majority of the wall time (52 hours), with data retrieval from Kudu being just a small fraction of it (45 minutes, or < 2%). A single scanner thread could deliver 40k records per second.
Full data flow tests We want to test a schema that is flexible to evolve, and check the performance that we can obtain with the data ingestion procedure. The testbed setup that we have used for these tests is located at IFIC in Valencia, and is currently composed of 5 machines with 2 × Xeon E5-2690 CPU, and 256 GB of memory each. The software installation included Kudu release 1. 7, Impala 2. 11 for accessing the data, and Spark 1. 6 from the Cloudera distribution release cdh5. 14. 2. The current Kudu configuration uses 1 of these machines as master, and the other 4 as tablet servers. There are 8 × 6TB data hard disk per machine configured as one big Raid 10 disk to store tablets, summing up 22TB per machine to a total of 88TB of storage. The write ahead log is located in the extra NVMe SSD of 1.
In this case we can represent the 1536 bits of Level 1 trigger (L1) as 24 columns of 64 bits each, and the 12288 bits of the High Level Trigger (HLT) with 192 columns. We can benefit from accessing only the columns that contain the specific triggers that we want to access (projection push-down), omitting unnecessary fields when doing table scans. We also wanted to test a JSON representation of the trigger, as it provides versatility to operations and some databases also currently offer direct access to JSON fields in a performant manner. We have just one string column for representing the Level 1 in JSON (L1mask) and another for the High Level Trigger (HLTmask). Table  3  shows the results of the encoding tests, representing the number of bytes an event occupies in the storage using the corresponding encoding and codification and compression schemas.
Ingestion tests In this section we review the ingestion tests done with a typical Consumer adapted to write into Kudu. We selected the datasets from Tier-0 recorded during May 2018 as input for our test experiment, and we tested 4 different partition schemas independently. Figure  5  shows the number of ingested events per second for a single consumer on the x-axis, with the 4 schemas in different colors. The schema 'base-t1' in black, represents 8 partitions based on the hash of the event number of the events, and 8 partitions based on the run number. In our case datasets from the same month have very similar run numbers, so partitioning on the run number does not affect the result. The schema 'base-t2' in red follows the same approach, but with the difference that the primary key of the table ends with <.
,runnumber,eventnumber>, reversing the fields of 'base-t1'. Most of the datasets are ingested with a performance of 5k events per second. Epoch based schemas in blue and green use a range partition based on an epoch that can be set per dataset, instead of a runnumber, in order to distribute it more evenly. In this case we obtain in the range from 5k to 6k events per second. There are spurious better performances and lower performances for the smaller datasets, but we can claim that the ingestion mean rate is roughly 5k events per second. In Figure  6  we see a breakdown of the time that a Consumer uses doing the ingestion, by stage type. Basically for most of the schemas it spends 1% of the time waiting for data from the Object Store, then 4% of the time doing parse and data conversion from the input data, and then the insertion phase into Kudu client buffers is roughly 23% of the time, with the last flush phase taking the bulk of the time (72%).
Summary The prototype and the performed tests have proven that the ATLAS EventIndex can profit from migrating the core storage to Apache Kudu in many aspects. Apache Kudu allows maintaining a hybrid system in a single piece of software. Notably, it enables features like streaming data ingestion, fast data access by index, and columnar storage for analytics. An eventual migration to a new back-end brings some obvious costs to the project, as it requires the re-implementation of most of the current components. However, it should bring a lot of simplification to the code as the vast majority of the logic needed so far is already built-in in existing frameworks that support Kudu or in Kudu itself. The scalable data scan performance in combination with modern data processors (Spark, Impala) opens the system to new use cases on a field of data exploration and analytics (like counting trigger correlations).
Morphological smoothing to connect the area of voxels was then applied (D), and segmented area was defined according to the predefined contrast threshold (E). Images corresponding to the whole tumor were processed, and values were merged for a 3D reconstruction of the tumor volume (F). with the PIXSCAN-FLI prototype allowed clear detection of neoplastic areas, which appeared without contrast agent with respect to the liver tissue (Figure  1B ). Next, we performed a series of processing steps of acquired images for qualitative and quantitative analyses. To quantify the tumor volume, we elaborated a semiautomatic segmentation protocol using the open software 3D Slicer. This segmentation protocol is based on contrast thresholds, in Hounsfield units (HU), defined relative to the liver CT value (HU L ) and the tumor CT value (HU T ): Th q = HU T + q (HU L -HU T ), with 0 < q < 1.
Long-Term Longitudinal PC-CT Imaging Applied to the Alb-R26 Met Genetic Model Revealed Distinct Kinetics in Liver Tumor Growth at Initiation and Evolution Phases As reported above, the Alb-R26 Met HCC model corresponds to the ''proliferative-progenitor'' HCC patient subgroup  (Arechederra et al. , 2018; Fan et al. , 2017). We revisited a set of data from the Alb-R26 Met tumors related to (1) qPCR expression of 96 HCC markers  (Fan et al. , 2017) , (2) phosphokinome analysis of 23 signals  (Fan et al. , 2017) , and (3) methylome of CpG islands  (Arechederra et al. , 2018). These analyses revealed that even though the Alb-R26 Met tumors clearly segregate from control livers, they belong to a broad cluster (Figures  3A-3C ). This may reflect the heterogeneity reported among patients with HCC even when belonging to the same subgroup (Cancer Genome Atlas Research Network.
ACKNOWLEDGMENTS We thank: all members of our laboratories for helpful discussions and comments,  A. Abdouni  and  F. Helmbacher  for valuable feedback on the study, and people at the IBDM mouse facility platform for excellent help with animal husbandry. This work was funded by  FdF (Fondation de France ;  2014_00051580  and  2016_00067080 ),  ARC (Association pour la Recherche contre le Cancer ;  SFE2011_1203807  and  PJA20181208172 ),  GEFLUC -Les Entreprises contre le Cancer , and  SATT Sud-Est  to F. M. M. A. was supported by an  FdF  fellowship. The contribution of the  Region Provence Alpes Cotes d'Azur and of the Aix-Marseille Univ  to the IBDM animal facility is also acknowledged. The development of the PC-CT PIXSCAN-FLI prototype was partly supported by  France Life Imaging  (grant  ANR-11-INBS-44-0006  from the  French ''Investissement d'Avenir'' program ) and by the  Canceropole Provence-Alpes-Cote d'Azur.
The fluorescence intensity was measured at 340 nm excitation and 665 and 620 nm emission on an Envision (PerkinElmer). The TR-FRET 665 nm/620 nm ratio, which is inversely proportional to the production of cAMP, was used to determine the cAMP response. Nonspecific binding was assessed using 100 μmol/L nonlabeled cAMP. The data were analyzed in PRISM to yield the EC50 and E max. No significant results were obtained with any of the compounds when they were tested in naïve cells. MicroBeta TriLux (PerkinElmer, France). We assessed and validated these methodologies for melatonin receptors (Dupré et al, 2018). No significant results were obtained with any of the compounds when they were tested in naïve cells.
30 The approach was utilized here with minor modifications. Briefly, 40 000 cells per well were plated on MDS Analytical 96-well assay plates with embedded electrodes (MDS Analytical). The plates were incubated at 37°C in a 6% CO 2 atmosphere for 48 hour. Prior to the measurement, the cells were washed three times with Hanks balanced salt solution (0. 1% BSA, 20 mm HEPES, pH 7. 4). The cells were left to equilibrate at 28°C for 30 minutes. Impedance was measured on a CellKey instrument (MDS Analytical). The signal was recorded for 5 minutes before the addition of the compounds and 15 minutes thereafter. The cells in each well were stimulated once with a single concentration of compound. The resulting data were expressed as the maximal signal corrected for the baseline and represented as a percentage of the full agonist effect (melatonin, which served as a positive control in these experiments).
| Biased agonism calculation The technique described by  Kenakin 10, 39, 40  was applied to our data. Briefly, log(max/EC50) values were calculated from the data gathered in each assay. These values were then subtracted from the log(max/EC50) value of melatonin, the natural ligand for each assay, to obtain the Δlog(max/EC50), which was used to build the radar plots.
In view of the details obtained here for these compounds and signaling pathways, the "antagonist" notion is at best vague, if not completely misleading. In general terms, the notion of antagonism   S2  and S3  TA B L E 1 Summary of available ligands for melatonin receptors and their functionalities From IUPHAR database (http://www. guide topha rmaco logy. org/GRAC/Famil yDisp layFo rward ?famil yId=39); the color code correspond to the nature of the functionality; : superagonist; , partial agonist; , agonist; , antagonist. NA, not applicable. in a given system, particularly regarding drug candidates (with receptors still being a major family of targets for marketed drugs), is essential for the therapeutic role of the compound(s). If it were understood upfront that the antagonistic property of a given candidate at a given receptor is biased to a point that only some of the signaling pathways are antagonized, it would give a completely different picture of the potential therapeutic benefit of such a drug in a given disease context, maybe up to a point where it can also give an idea of the reverse effect of a given compound.
The various data currently available on the melatonin receptor ligands presented here are summarized in Table  1. The data were taken from the IUPHAR website, and we further completed the panel of functional ligands with new entities. It is obvious from Figure  7  that most analogs are less active as agonists at MT 1 and MT 2 than melatonin (note vertices inside the shaded area), and that there is some difference within pathways regarding Δ(max/EC 50 ) values. Values of ΔLog(max/EC 50 ) provided the relative activities of the compounds vs melatonin for each receptor and were then used to derive estimates of receptor selectivity through ΔΔLog(max/EC 50 ) (Figure  7C ). There are some notable exceptions to the pathway uniformity in which the calculated receptor selectivity was more pronounced for some pathways than for others (i.
In this study, we provide a comparative analysis of several popular RRAM models tested within the same simulation environment. We also introduce a unique implementation of all the models in Verilog-A. The different RRAM models used in this work include the Linear Ion Drift Model  [5] , Non-Linear Ion Drift Model  [6] , Simmons Tunnel Barrier Model  [7] , TEAM Model  [8] , VTEAM model  [9] , Stanford model  [10] , SPICE model  [11] , and IM2NP model  [12]. The manuscript is organized as follows. Section II gives an overview of RRAM technology. Section III reviews various previously published RRAM device models and novel modeling techniques. Section IV presents the simulation results of the various models at the cell level in different configurations. Section V is a comparative analysis of the different models with experimental validation.
H. IM2NP RRAM MODEL The IM2NP Eldo model is a compact model that describes well the SET and RESET operations in bipolar resistive switching in Oxide-based memory devises. The model takes into account the conductive filament (CF) electric fieldinduced creation and dissolution as well, by including in a unique equation of electrochemical reaction and thermal mechanism. This model is also the first that includes the electroforming process of RRAM devices. The model has been calibrated on dynamic and quasi-static experimental data  [12]. Figure  6  gives a representation of the model and its main parameters.