dataesr/scientific-paragraphs-categorization huggingface dataset:
Combining Multimodal Data for Detecting Suicide Risk We proposed a method that given the profile of a user: (1) it uses a text-based model, described previously as the SPVC, which selects a subset of relevant tweets related to suicidal ideation. The set of tweets for which the SPVC provides a score over a given threshold is retained in SPV itself; (2) mostly from the outputted SPV, it extracts a set of relational, textual, behavioral, lexical, statistical, suicidal ideation-related, and image-based features from the content and metadata of the tweets; and (3) it builds and evaluates different predictive models resulting from the combination of these features. Our features are organized into 3 different groups: (1) BoW or n-grams and word embeddings as a representation of textual features; (2) a set of features known as social networks and psychological (SNPSY) features containing a group of relational, behavioral, lexical, sentiment analysis, and statistical features, in addition to a set of features that attempt to map to the social media context certain signs and symptoms, which are usually considered by clinicians at the time of screening; and (3) an image-based score.
Bag of Words and N-Grams These are features that have been used to address similar tasks, such as depression detection and eating disorders screening  [7, 31]. These models represent terms or sequences of terms (n-grams) based on their frequencies on the documents analyzed. In our case, each user was represented by a document consisting of the concatenation of the text of all their tweets. Afterward, we used the Scikit-learn  [32]  Python library: TfIdfVectorizer to generate a tf. idf representation of 1 to 5 grams at the word level. A set of Spanish stop words were considered to build this representation  [33]. These features are referred to as BoW features in further sections. We also used ekphrasis  [34]  as a text preprocessing tool to replace generic tag elements such as money, phone numbers, digits, hashtags, and emoticons.
Word Embeddings Word embeddings are representations of textual terms as vectors of real numbers. Words that are semantically related have a similar representation over the vector space. Most of the recent predictive models dealing with textual features using deep learning techniques make use of word embeddings to represent terms. The sequences of these representations are fed as inputs to train the predictive models. These types of representations have been recently used in state-of-the-art approaches to address suicide risk assessment  [3, 11]. We made use of word embeddings previously learned over a dataset with 2 million Spanish tweets  [35].
Behavioral Features These features are based on the information extracted from the metadata of tweets. Here, we measured the behavior of users based on their activity within certain periods, which are defined at different granularity levels. These features are detailed in Table  1. The intention of the sleep time tweets ratio (STTR) and the daytime tweets ratio (DTTR) features is to identify the differences between control users and users at risk regarding the periods of the day on which they post. Considering that our data collection is delimited by language but not by location, that the posting time provided for a tweet is in coordinated universal time and not the time of the user location, and that not enough information from our data was found to automatically identify the location of all the users, we defined an approach to address this issue.
Image-Based Feature We followed the methodology proposed in the study by Rodriguez et al  [39] , where a method for inferring the personality under the OCEAN model was presented. In this sense, we created a classifier trained on images extracted from Instagram using a subset of the phrases and keywords used in the data collection process for Twitter. These images were considered suicide related, whereas a set of unrelated images was considered as our control cases. Afterward, this first model was applied to each of the images extracted from the users' tweets of our dataset. To create this model, we used 90,000 images for training and 60,000 images for validation. To obtain a single score per user (images user score), the average of the individual scores of the images of each user was considered as the user's aggregated score.
To define the image classifier, we used a convolutional neural network (CNN)  [40]  because CNNs are especially suited for image data. There are several variants of this type of network, but the most popular ones are based on the residual networks introduced by He et al  [41]. They used skip connections between layers that force the gradient to flow directly between convolutional blocks. This makes backpropagation much more effective in deep architectures. The training process is performed by minimizing the cross-entropy loss function through gradient descent. The problem when training CNNs is that they require many images (often in the range of millions) to successfully extract relevant features for the final classifier. As most of the time datasets are not large, networks are usually trained on a large dataset (eg, ImageNet  [42] ) and then fine-tuned on the target dataset.
Fine-tuning refers to the process of using an already trained model and retraining it to fit a new distribution. This is much faster because the weights in the model are not randomly initialized, and one can often skip the training of the shallower layers, given the fact that they focus on detecting corners and edges, and thus the model converges faster. Note that the fully connected layer that acts as a classifier in the network must be trained from scratch because the target classes between datasets vary. For our experiments, we used 101-layer ResneXt  [43] , which is a residual architecture that uses grouped convolution. This particular architecture uses convolution groups of size 32 with a dimensionality of 8 and a fully connected layer at the end that performs the actual classification.
Classification Tasks As we wanted to evaluate the change in the performance of models that use 2 different types of control groups, one constituted by users who make use of vocabulary related to suicide (focused control) and another group of users who might not make use of these terms at all (generic control), we created experiments for comparing (1) users at risk versus focused control users (task 1) and (2) users at risk versus generic control users (task 2). These were selected as our 2 supervised predictive tasks. Our instances and their features for the predictive models were previously defined following the process described in the Combining Multimodal Data for Detecting Suicide Risk section.
Dataset Description Following the description of the Data Collection section, to evaluate our approach, we selected a sample of 252 users with a total of 1,214,474 tweets and 305,637 images, from which up to 1000 images per user were selected for our experiments. We selected a balanced sample of 84 users presenting signs of suicidal ideation (users at risk), 84 focused control users, and 84 generic control users, who were classified within these groups by clinicians after seeing samples of their posts. Table  5  shows the statistics regarding the users belonging to each of the defined groups. We can notice that the median tweet length (in words) is lower for users at risk than for the control and generic cases. We also saw that generic control users produce lower amounts of tweets compared with other types of users.
For each task, 70% of all the instances were retained for training, and the remaining 30% (around 25 users per class) were left for testing purposes as unseen cases. To keep balanced instances from each class, we used stratification for these sets. In addition to these test sets, we also evaluated our best models over a sample of 200 users labeled as doubtful cases. This is done to verify if, as the human annotator, the models are capable of identifying most of these cases as users that are likely to be at risk. The PowerTransformer class from Python's Scikit-learn library was used to transform the feature values to a normal distribution-like representation using Yeo-Johnson's  [32]. To choose the best classifier, a 10-fold cross-validation process was followed over the training set with all the algorithms to evaluate.
Acknowledgments This study was supported by the  Spanish Ministry of Economy and Competitiveness  under the  Maria de Maeztu Units of Excellence Program  ( MDM-2015-0502 ). The authors acknowledge the funding received by the  Spanish  project  TIN2015-65464-R (MINECO/FEDER ). The authors also acknowledge the support of  NVIDIA Corporation  for the donation of a Tesla K40 GPU and a GTX TITAN GPU, used for this research.
Our contributions are summarized as follows. 1. We augment the BPEL modeling language with timing parameters, and we equip it with a formal semantics in the form of a labeled transition system. 2. Given a composite service modeled using BPEL, we develop a sound method for synthesizing the local time requirement in the form of a set of constraints, which can be applied at the design stage of service composition. 3. We introduce a refinement procedure on the sLTC of a composite service based on the runtime information, which results in a more relaxed rLTC. The rLTC can be used to verify whether the composite service could still eventually satisfy the global time requirement at runtime. 4. We implement our algorithms into a tool Selamat. We then conduct experiments on several examples. The results show that the rLTC can indeed help to improve the accuracy of the sLTC.
A BPEL example with timed requirements Let us introduce a Stock Market Indices Service (SMIS) that will be used as a running example. SMIS is a paid service and its goal is to provide updated stock indices to the subscribed users. It provides a service level agreement (SLA) to the subscribed users stating that it always responds within three seconds upon request. SMIS has three component Web services, i. e. , a database service (DS), a free news feed service (FS) and a paid news feed service (PS). The strategy of the  SMIS is calling the free service FS before calling the paid service PS in order to minimize the cost. Upon returning the result to the user, the SMIS also stores the latest results in an external database service provided by DS (storage of the results is omitted here). The workflow of the SMIS is sketched in Fig.
2  in the form of a tree. When a request is received from a subscribed customer (Receive User), it synchronously invokes (i. e. , invoke and wait for reply) the database service (Sync. Invoke DS) to request stock indices stored in the past minute. Upon receiving the response from DS, the process reaches an <if> branch (denoted by ). If the indices are available (Indices exist), then they are returned to the user (Reply indices). Otherwise, FS is invoked asynchronously (i. e. , the system moves on after the invocation without waiting for the reply). A <pick> construct (denoted by ) is used here to await an incoming response (<onMessage>) from previous asynchronous invocation or timeout (<onAlarm>), whichever occurs. If the response from FS (OnMessage FS) is received within one second, then the result is returned to the user (Reply indices).
We refer to the runtime refined LTC as the runtime LTC (denoted by rLTC). In addition to this refinement, we can also simplify the LTS by pruning the states corresponding to past states (e. g. , s 0 , s 1 in Fig. 7 ), as well as the successors of these past states that were not met in practice (e. g. , s 3 and s 5 in Fig. 7 ), because another branch was taken at runtime. We show the LTS of SMIS before and after simplification in Figs. 8a  and 8b  respectively. We now introduce a service adaptation framework to improve the conformance of global time requirement for a composite service. The architecture of the framework is shown in Fig. 9. There are two modules in the framework-the Runtime Engine Module (RE ) and the Service Monitoring Module (SM ). RE provides an environment for the execution of a BPEL service; here, we use ApacheODE  [Fou07] , an open source BPEL engine.
We instrument the runtime component of Apache ODE to communicate with the service monitoring module. s 0 s 1 s 2 s 3 s 5 s 4 s 6 s 7 • • • • • • (a) Before simplification s 2 s 4 s 6 s 7 • • • • • • (b) After simplification ((λ FS ≤ 1) ⇒ (r + λ FS ≤ 3)) ∧ ((λ FS ≥ 1 ∧ λ PS ≤ 1) ⇒ (r + λ PS ≤ 2)) ∧ ¬ (λ FS ≥ 1 ∧ λ PS ≥ 1) SM is used to monitor the execution of a BPEL service. During the deployment of a service CS, SM generates the LTS of CS and stores it in the cache of SM so that it is available when CS is executing. During the execution of the composite service CS, the sequences of rules from RE are used to update the active state sa ∈ S of LTS stored in SM. The sequence of rules is also stored as part of the current execution run. SM also keeps track of the total execution time for this execution run, as well as the response time for each component service invocation.
are partially supported by  CNRS STIC-Asie  project  CATS ("Compositional Analysis of Timed Systems "). Étienne André  is partially supported by the  ANR  national research program  ANR-14-CE28-0002 PACS  (" Parametric Analyses of Concurrent Systems "). Étienne André  and  Jun Sun  are partially supported by the  ANR-NRF   French-Singaporean research program ProMiS  ( ANR-19-CE25-0015 ).
The high instantaneous luminosities expected following the upgrade of the Large Hadron Collider (LHC) to the High-Luminosity LHC (HL-LHC) pose major experimental challenges for the CMS experiment. A central component to allow efficient operation under these conditions is the reconstruction of charged particle trajectories and their inclusion in the hardwarebased trigger system. There are many challenges involved in achieving this: a large input data rate of about 20-40 Tb/s; processing a new batch of input data every 25 ns, each consisting of about 15,000 precise position measurements and rough transverse momentum measurements of particles ("stubs"); performing the pattern recognition on these stubs to find the trajectories; and producing the list of trajectory parameters within 4 µs. This paper describes a proposed solution to this problem, specifically, it presents a novel approach to pattern recognition and charged particle trajectory reconstruction using an all-FPGA solution.
The other two approaches that were studied were a Hough-transform based approach using FPGAs  [5]  and an associative memory based approach using a custom ASIC  [6]. The tracklet approach is a "road-search" algorithm, implemented using commercially available FPGA technology. Ever-increasing capability and programming flexibility make FPGAs ideal for performing fast track finding. The tracklet approach allows a naturally pipelined implementation with a modest overall system size. It also allows for simple software emulation of the algorithm. We present here the design of such a system and results from a hardware demonstrator system that implements end-to-end reconstruction, from input stubs to output trajectories, within the available latency and with a reasonable system size, for a slice of the detector.
Tracklet algorithm The goal of the real-time hardware-based track finding is to reconstruct the charged particle trajectories as an estimator of their momenta for particles with p T > 2 GeV, and to identify the track z 0 position with about 1 mm precision. The z 0 resolution is similar to the expected average separation of proton-proton collisions in the bunch collisions of the upgraded LHC, and thus allows precise determination of the collision vertices. The proposed tracklet method forms track seeds, "tracklets", from pairs of stubs in adjacent layers or disks. The tracklets provide roads to search for compatible stubs that are attached to form track candidates. A linearized χ 2 -fit determines the final track parameters. The tracklet algorithm has been optimized to provide full coverage of the tracker with a small amount of redundancy in data duplication.
These smaller units are referred to as "Virtual Modules" (VMs). Only a small fraction of VM pairs can form a valid tracklet -the majority would be inconsistent with a track originating at the point of collision and with high enough transverse momentum. Data are distributed into those VMs satisfying these requirements in an early stage of the algorithm. This subdivision efficiently reduces the number of combinations that need to be considered by the algorithm from the start. Additionally, each VM is processed in parallel. At the next stage of the algorithm, the amount of parallelism is reduced when the accepted VM pairs' (the tracklets) initial track parameters are calculated. Two different configurations of VMs are considered. In the first, used in tracklet 1. 0 for the demonstrator, a sector is divided into 8z × 3φ (8z × 4φ) VMs for the odd (even) layers, resulting in 24 (32) VMs per layer.
Firmware implementation The tracklet algorithm is implemented in the V Hardware Description Language (HDL) [7] as nine processing steps and two transmission steps  [8]. These processing steps are illustrated in Figure  4. The red boxes are processing modules and the data are stored in memories (blue boxes) between the different processing steps. The black lines indicate which processing modules read and write data from which memory. The implementation of the algorithm in the FPGA takes place in the following steps. • Stub organization: (1) Sort the input stubs by their corresponding layer (LayerRouter), and (2) into smaller units in z and φ, the VMs (VMRouter). • Tracklet formation: (3) Select candidate stub pairs for the formation of tracklets (Track-letEngine), and (4) calculate the tracklet parameters and projections to other layers (Track-letCalculator module).
• Projections: (5) Transmission of projections pointing to neighboring sectors (Projection-Tranceiver). (6)  Route the projections based on smaller units (VMs) in z and φ (Projection-Router). • Stub matching: (7) Match projected tracklets to stubs (MatchEngine), and (8) calculate the difference in position between the stubs and projected tracklet (MatchCalculator). (  9 ) Transmission of matches between sectors (MatchTransceiver). • Track fit: (10) Perform track fit; update the initial tracklet parameter estimate (TrackFit). • Duplicate Removal:  (11)  Remove tracks found multiple times (PurgeDuplicate). Both the tracklet 1. 0 and tracklet 2. 0 projects follow the same structure; they differ in the internals of some of the modules and how the modules are inter-connected. Each of the steps outlined above corresponds to HDL modules (named in bold).
These modules are hand-optimized. They can be customized with V parameter statements on instantiation to account for differences between use cases. For example, in the second step of stub organization, six router modules are needed to process the stubs in each layer. The bit assignment in the data differs between the inner and outer three layers of the barrel. On instantiation, a parameter is used to select the appropriate version. The project illustrated in Figure  4  corresponds to 1 ⁄4 of the barrel for one sector for the tracklet 1. 0 configuration. A complete project would contain approximately eight times as many instantiations of the same set of modules. The wiring between modules is specified in a master project configuration file. This configuration file is processed with scripts to generate the top-level V , which is then synthesized using Xilinx Vivado 2016.
1. These scripts also generate the module connection diagram shown in Figure  4  and drive a bit-level C++ emulation of the system. All processing modules follow a similar format where the input is read from memories filled by the previous step and the output is written to another set of memories. All processing modules across all sector processors use a single common clock (currently, 240 MHz). As soon as a new event arrives, the next step in the chain will start processing the previous event. This implies that at any given time, several events are in the processing pipeline depending on the number of processing steps. Though the project as implemented in the demonstrator used the same clock for all processing steps, the fact that we use memories as buffers between the different steps allows the use of different clock speeds for different processing modules.
Module examples To illustrate the method in more detail, we present the functionality of two processing modules. Figure  5  shows schematically how the VMRouter works. The module receives a start signal every 150 ns for every new event. This VMRouter module reads stubs from three input layer memories. All stubs are written to the "AllStubs" memory in the full 36-bit format. In addition, based on their coordinates (φ and z), the stubs are routed to a specific output memory (VM stub memory) corresponding to a specific small area of the detector. Here, only coarse position information is retained and a six bit index into the AllStubs memory is saved such that we can later retrieve the precise stub position. The process loops over the input stubs and writes them out to different memories based on their position information.
A more complex example is the TrackletEngine processing module illustrated in Figure  6. This module forms pairs of stubs as seed candidates. As such, this module reads input stubs from two VM stub memories filled by the VMRouter module described previously, but since we are interested in forming pairs of stubs, this module implements a double nested loop over all pairs. For each pair the coarse position information is used in two LUTs to check that the seed candidate is consistent with a trajectory with the p T and z 0 requirements described above. If the stub pair passes this  check, the indices of the stubs in the AllStub memories are saved in the output memory of candidate stub pairs. These indices are used in the next step, the TrackletCalculator, to retrieve the stubs and calculate the precise trajectory.
Data sets used included single particle (electron, muon, and pion) events, as well as fully simulated top quark-antiquark (t t) events. To accurately simulate HL-LHC conditions, up to 200 extra pp collisions were included in addition to the event under study. The demonstrator system consisted of three φ sectors and one time-multiplexing slice. A total of four MicroTCA processing blades were used, one for the central φ sector, two for its nearest neighbor sectors, and one blade that acted as a data source (providing input stubs) and a data sink (accepting the final output tracks). The system configuration is shown in Figure  8. The demonstrator  was fed with simulated data derived from the simulation of the CMS detector mentioned above. An Advanced Mezzanine Card (AMC13)  [14]  provided the central clock distribution.
System latency For both the demonstrator system as well as the current configuration, each processing step of the tracklet algorithm takes a fixed number of clock cycles to process its input data. The processing modules' latency from receiving upstream data to producing the first result varies between 1-50 cycles depending on the module. Each module then continues to handle the data of the same event and writes to the memories for 150 ns (for a time multiplexing factor of six) before switching to the next event. For some of the steps where data transmission between the neighboring sectors was necessary, latency due to inter-board links was also included. The measured transmission latency was 316. 7 ns (76 clock cycles), which included serialization and de-serialization via the Xilinx GTH transceivers, data propagation in 15 m long optical fibers, channel bonding, and time needed to prepare and pass data from processing modules to the transceivers.