dataesr/scientific-paragraphs-categorization huggingface dataset:
The RUDP Core keeps track of all the active frames and generates timeouts used to re-send frames in case an acknowledge is not received. When a frame is allowed to pass through the data stopper the frame is marked as active in the RUDP Core. The next step in the frame lifecycle is for the timeout countdown to start. This happens when the frame has passed through the Header Extraction module. In this way the timeout won't be affected by frames read back from the memory delaying the frame transmission. The timer is now running. If the acknowledgement frame is received before the timeout occurs the frame is marked as inactive and the RUDP Core is finished with the frame. If the acknowledgement frame isn't received in time the frame times out. When this happens, a request is sent to the Memory Interface block triggering the frame to be read from memory.
Control and monitoring All control and monitoring of the STARE is done by the IPbus interface. All the STARE parameters are software controlled. In addition, the STARE firmware has an automatic setup interface using IPbus and a dedicated Controller to correctly reset, initialise and make the STARE ready to receive data without any external or manual commands. All the startup procedure are automatically launched through Ipbus. The CAP IPbus interface is developed inside the STARE firmware and converts each ipbus command into an SPI format sent to the CAP board. The slow control software will have access to continuous monitoring of the STARE FPGA temperatures, and the Aurora interface synchronisation status as well as the UDP interface modules. Error status can be monitored to see if there are any transfer problems by configuring the data generators and by spying on the error counter registers or the error data registers.
STARE prototype validation and results The production of ten STARE prototypes has been completed and the boards have been qualified and validated using a new software readout SQM developed by the AGATA Data Flow team for the HTC server. The eye-diagram test for the high speed transfer lines was validated using the Rhode & Schwartz 16 Ghz bandwidth 60 Gbps sampling rate oscilloscope. The eye diagram in Fig. 21  shows the time for a digital signal to be logic 1 or logic 0 at a certain frequency. In the case of the STARE the signal in the eye diagram has a signal width of 50 ps and the time which is stable @ logic 1 or 0 is about 80%, which is close to the theoretical values. The 20% are for the rise time and the fall time. The measurements shows jitter < 20 ps and a transmission Bit Error Rate (BER) of 10 -12.
Presently, the production of STARE boards is ongoing, 150 modules will be delivered within the fourth quarter of 2023. The UDP 10 Gbps transfer rate was validated with the server receiver software. The first tests used only 1 optical   22  shows a 3 days test made with 0 losses. 972 Tbytes were tested by the 3 servers @ 10 Gbps on each server. The RUDP firmware will be implemented after the validation of the production boards inside the AGATA electronics.
Fifo event The Fifo event module stores incoming GTS requests through the Aurora Rx interfaces, then generates the GTS validate/reject response requests. It works as follows: as soon as a trigger request is received on the Aurora Rx interface, it is stored into the fifo event and an analysis window is opened. The TP_GUI software defines the analysis window width through the CFG_TIMEOUT register with respect to the following requirement. During the analysis window, if the logic equation condition is met, then all the stored requests are validated and sent back to the GTS tree through the Aurora Tx interface. If the logic equation is not met during the analysis window, the fifo event content is flushed and reject responses are generated. The global flowchart is shown in Fig. 28.
Interfacing AGATA with other detectors using SMART The coupling of AGATA to complementary detectors has played a major role in spectroscopic investigations in the last decade. AGATA was coupled to the PRISMA or VAMOS++ magnetic spectrometer  [33, 34] , large volume scintillators  [35] [36] [37] , heavy-ions detectors like DANTE, LYCCA or TRACE  [38, 39] , fast-timing array  [40] , the neutron detectors NEDA  [41] , the charged particle arrays DIAMANT  [42]  and MUGAST  [43]  and LEPS detectors. So far, the time stamping and trigger validation was performed using the GTS system (see Sect. 2 and introduction to Sect. 8). The AGAVA VME board  [1]  ensured the distribution of the AGATA current time stamp value to the complementary detectors data flow and sent trigger request from the complementary detectors, allowing them to participate in the global trigger decisions, to reduce the AGATA readout rate and increase sensitivity.
Control and monitoring As already mentioned in previous Sects. 5. 2, 5. 3, 6. 3, the IPBus  [44]  flexible Ethernet-based control system is being used for the slow control and monitoring of the new boards. Specific software is under development to help users to deal with up to 180 cards for the AGATA 4π configuration. A general scheme is displayed in Fig. 31. The core of the architecture is a python server (blue box in Fig. 31 ) that will run on a Debian Linux platform. The python language was chosen to take advantage of existing code used to develop and test STARE boards prototypes. The server uses the end-user python API for IPBus, provided by the uhal library, for the transactions with the boards (red line in Fig. 31 ). The Django framework has been selected to generate the web site and manage interactions with a MySQL database used to store necessary information about users, commands and parameter values.
Two user interfaces are provided. The most user oriented one consists of an interactive web interface, running in current web browsers, programmed using classical web languages HTML, CSS and Javascript. The software will allow users to perform configurations and actions applied to individual or global sets of STARE boards and present views of the 180 crystals. Direct access to the server through a python console is also available for more expert users. Finally, a REST (REpresentational State Transfer) API is provided to allow software interoperability: this is indeed required to catch actions sent by other user interfaces such as, for instance, the run control which should deliver at least start/stop signals to the cards. For the monitoring of the boards, several systems are to be set up. From the user interfaces, it will be possible to register which specific parameter is to be monitored and at which frequency.
Once registered, the python server will automatically request, at the selected period, the parameter and push it in an InfluxDB time series database. Users can then visualise the time evolution of the sampled parameter through Grafana web based dashboards. Control spectra can be built also directly inside the cards. Thanks to the versatility of the ADF frame definition, such spectra can be pushed, if required and needed, into the standard UDP data stream (green lines in Fig. 31 ). Once they have reached a processing node of the workflow, they can be part of the global monitoring system of the DAQ box (see XREF Advances in Software Developments). A third way to monitor the card is to be realised using another UDP, 10 Gbits/s, output channel of the STARE board. Raw data streams are sent through the python server to a web embedded, oscilloscope like, application able to visualise simultaneously up to 10 channels.
31 General slow control and monitoring scheme. The blue box in the center is the python server, core of the whole system. Attached to the server there is an SQL database (SQLDB) to store all the parameters required. Transactions with the PACE boards are realized using the IPBus protocol (red lines). Two user interfaces are shown. The blue one corresponds to the web browser oriented interface while the grey one is for a direct console attached to the server. Monitoring can be performed from the time series database (TSDB) using Grafana dashboards, through in-card produced spectra sent embedded in the UDP data stream to the DAQ box (grey cloud) or through raw data streams feeding an oscilloscope like application 10 Outlook: improvements in the pre-processing firmware of AGATA Several areas were identified for possible firmware improvements, the pre-amplifier pulse reconstruction, the high rate performance, particularly in the case of pileup and the single/multiple interactions identification.
When we examine the pre-amplifier block diagram in Fig. 32 , it is evident that the transfer function to be expected is of a higher order, due to the 1st (charge loop) and 2nd (Passive P/Z) stages. We have conducted a preliminary analysis of captured AGATA pre-amplifier output waveforms, focusing on the trailing edge of the pulse. Currently for pulse reconstruction in AGATA, the MWD algorithm used  [13]  assumes a first-order pre-amplifier transfer function. The offline model that is used to fit the pre-amplifier output is Ae -t/τ + B (Fig. 33 ) and is actually a higher order model(1 zero/2 poles) to get a more accurate fit. However, even with this model, Fig. 34  Residual of the pre-amplifier output (dataset 01A/Segment3. dat) and its fit (Ae -t/τ +B). NRMSE = 97. 50%. A pattern is visible at the left hand-side of the plot due to fit mismatches a pattern is still visible in the residual plot of some of the data sets (Fig.
Outlook beyond phase 2: digital preamplifier and ASIC technologies The AGATA collaboration is pursuing electronics R&D towards new concepts and technologies beyond the present Phase 2. The idea, already mentioned in the early AGATA conceptual design, is to bring closer to the HPGe diode the signal pre-amplification and its numerical conversion. An ambitious extension of this idea would be to locate the signal pre-amplification in a high resolution cryogenic ASIC inside the cold part of the detector coupled to a sampling ADC placed in the warm part of the cryostat, in the location presently housing the warm pre-amplifiers. Such development can be only implemented in AGATA together with a redesign of the detector module cryostat, considered as well in our R&D programme beyond phase 2. Such development requires, firstly, a cryogenic ASIC preamplifier development.
Acknowledgements The authors acknowledge the support of the AGATA collaboration in the work described in this publication. This work is supported by grants from the  UK Science and Technology Facilities Council , including  ST/F004052/1 , by  MCIN/AEI/ 10. 13039/501100011033 , Spain with grant  PID2020-118265GB-C42  and  PID2020-118265GB-C44 , by  Generalitat Valenciana, Spain  with grants  PROMETEO/2019/005 ,  CIBEST/2021/210  and  CIAPOS/2021/114  and by the  EU FEDER  funds. We thank all the technical staff involved in this project. The STARE R&D development have been financed by  CNRS ,  IN2P3 , France. Special thanks to  Andrea Triossi  who supported the  STARE Proof Of Concept.
e. , when x (k+1) = x  (k)  and y (k+1) = y (k) ) or a maximum number of iterations is reached. (2a) PUC(x C ) min {y ij ∈Y C : i∈V ,j∈C } s∈S U s (y ij ; x C , θ s ), (2b) s. t. b min,s ≤ ρ s (y ij ; x C ) ≤ b max,s , ∀s ∈ S. (3) EV-i(x R ) min {y ij ∈Y R : j∈R } j∈R D ij (y ij ; x R , w ij ). Experimental setup. Data sources. Our case study is based on ride requests from the lower Manhattan area, in New York City, NY. We use real data recorded by the Taxi and Limousine Commission (TLC)  40  on Tuesday, March 1, 2022, between 6:00 and 24:00. The total number of ride requests collected during this time window is 19935, from which we keep a random sample of 2480 to have a number of ride requests that can be handled by a fleet of 100 EVs. The ride requests have been categorized according to their submission time, and grouped into one-minute time slots.
Note that the ride requests sub-sampling is due to the fact that we require to keep the simulation of several experiments manageable on a 2. 4 GHz Quad-Core Intel Core i5 laptop with 8 GB RAM memory. The proposed algorithm on average converges in 2 iterations and takes 2. 6 seconds per iteration. We obtain approximated power generation profiles for PV systems from the renewable historical data of New York Independent System Operator  41. As a point of reference, we extracted the PV shape from the renewable energy generated within New York State on a sunny day, and modify it accordingly to represent also a cloudy day. To test our model, we consider three scenarios, corresponding to different weather conditions: sunny day (i. e. , maximum PV generation), and cloudy day, which presents two alternatives: cloudy morning and cloudy afternoon.
Data availability Data for the ride requests was obtained from the Taxi and Limousine Commission (TLC), publicly available on the website: https:// www. nyc. gov/ site/ tlc/ about/ tlc-trip-record-data. page. All analyses were performed using Python software that was custom developed as part of our methods. It is available in the repository: https:// github. com/ Elispe/ renew ableEV. Here we deploy the open source CVXPY  53  package for convex optimization problems and PuLP 54 for the linear assignment problem, with the COIN_CMD solver.
Results Of the four LLMs evaluated, OpenAI's GPT-4 and Anthropic's Claude demonstrated the best performance and were chosen for the implementation of the candidate gene prioritization and selection workflow. This workflow was run in parallel for each of the 11 erythroid cell modules by participants in a data mining workshop. Module M9. 2 served as an illustrative use case. The 30 candidate genes forming this module were assessed, and the top five scoring genes were identified as BCL2L1, ALAS2, SLC4A1, CA1, and FECH. Researchers carefully fact-checked the summarized scoring justifications, after which the LLMs were prompted to select a top candidate based on this information. GPT-4 initially chose BCL2L1, while Claude selected ALAS2. When transcriptional profiling data from three reference datasets were provided for additional context, GPT-4 revised its initial choice to ALAS2, whereas Claude reaffirmed its original selection for this module.
The critical task of selecting relevant candidate genes for inclusion in targeted assays can be guided by both prior knowledge and analysis of existing omics data. As demonstrated in our previous work, we leveraged a combination of data-and knowledge-driven strategies to develop a targeted transcriptional panel for monitoring immune responses to SARS-CoV-2 infection  [14]. This selection process relied on the well-established BloodGen3 fixed blood transcriptome repertoire, which we employed as a framework for data-driven identification of candidate gene pools  [17]. By leveraging reference blood transcriptome datasets from SARS-CoV-2 infected subjects, 23 distinct sets of modules comprising co-expressed genes were identified. To finalize the selection of the gene panel from these pools of candidates, which included 3176 transcripts in total, we used a knowledge-driven approach.
5, GPT-4 (from OpenAI), Bard (from Google), and Claude (from Anthropic) across various tasks and created a standardized workflow inclusive of validation checks. We applied this workflow to the ongoing prioritization of 11 BloodGen3 modules that encompass the module aggregate A37. This meta-signature has been correlated with respiratory syncytial virus (RSV) infection severity  [15] , vaccine response  [16] , and elevated abundance of transcripts in patients with metastatic melanoma  [15]. Our results demonstrate that LLMs can effectively prioritize large candidate gene pools for inclusion in targeted biomarker panels with minimal human input. Notably LLMs were also able to interpret and factor in reference transcriptional data when tasked to pick a top candidate for a given module.
BloodGen3 module repertoire The construction and characterization of the BloodGen3 repertoire has been described in detail previously  [17]. Briefly, we used as input a collection of 16 reference datasets encompassing 985 unique blood transcriptome profiles, representing 16 disease and physiological states, including infectious and autoimmune diseases, pregnancy, transplantation. Co-clustering patterns were identified and served as a basis for the constitution of a weighted network, from which densely inter-connected networks (modules or cliques) were identified. Modules were subsequently grouped into aggregates, based on patterns of transcript abundance observed across the 16 datasets. It is possible thus to obtain two tiers of dimension reduction: at the module (382 variables) or module aggregate level  (38 variables).
Large language models ChatGPT-3. 5 (OpenAI, San Francisco, CA, https:// openai. com/). Description provided by GPT-3. 5: "The Generalized Pre-training Transformer 3. 5 (GPT-3. 5) is an advanced language model. Its primary objective is to comprehend and generate human-like text. Leveraging unsupervised learning, GPT-3. 5 is trained on a diverse dataset sourced from internet text, ensuring comprehensive exposure to various linguistic patterns and contexts. As of its last training cut-off in September 2021, GPT-3. 5 does not integrate new information, and its responses are solely derived from the knowledge acquired during the training period. " ChatGPT-4 (OpenAI, San Francisco CA, https:// openai. com/). Description provided by GPT-4: "The Generalized Pre-training Transformer 4 (GPT-4) is similar to its predecessor GPT-3, as it uses unsupervised learning and is trained on a diverse range of internet text.
However, GPT-4 has more parameters, enabling it to generate more coherent and contextually relevant outputs. As of its last training cut-off in September 2021, the model does not incorporate new data or information, and its responses are purely based on patterns and information it has learned during the training period". Bard (Google, Mountain View, CA, https:// bard. google. com/). Description provided by Bard: "Bard is a LLM chatbot developed by Google AI. It is trained on a massive dataset of text and code, which includes books, articles, code repositories, and other forms of text data. Bard is able to communicate and generate human-like text in response to a wide range of prompts and questions. For example, Bard can provide summaries of factual topics, create stories, translate languages, and answer questions in an informative way.
Factoring in transcriptome profiling data to finalize the selection of the top candidate gene (Step 7) In this step transcriptional profiles for the top 5 candidates from three references datasets are submitted to GPT-4 and Claude and these models are prompted to take this new information in consideration to finalize their selection. Transcriptional profiling data were retrieved for the top 5 genes from three reference datasets and plots were generated in Google sheets. The reference datasets were contributed to the NCBI GEO repository by: Speake et al. (GSE6042459)  [18] , which comprises profiles of whole blood and isolated circulating blood leukocytes. The profiles were accessed via a data browsing web application, the Gene eXpression Browser (GXB) "CD2K" collection. This team of investigators analyzed the sequencing libraries on an Illumina HiScan, targeting a read depth of approximately 20 M.
They demultiplexed the reads, aligned them to ENSEMBL's human gene models, and quantified the results using HTSeq  [19]. Following this, they normalized the read counts utilizing the TMM method from the edgeR package  [20]. http:// cd2k. gxbsi dra. org/ dm3/ geneB rowser/ show/ 40000 98. Novershtern et al. (GSE24759)  [21] , which comprises profiles of isolated leukocyte populations and hematopoietic progenitors. The profiles were accessed via a data browsing web application, the Gene eXpression Browser (GXB) developmental immunology collection  [22]. For this dataset transcript levels were extracted from data image files using the RMA method  [23]  with corrections for sample variations via quantile normalization through the Bioconductor R package  [24]. Batch effects were mitigated using the ComBat method  [25]  (  Johnson et al.
, 2007). http:// devel opmen talim munol ogy. gxbsi dra. org/ dm3/ geneB rowser/ show/ 40000 26. Altman, Rinchai et al. (GSE100150)  [17] , which comprises bulk blood transcriptional profiles of 16 reference cohorts encompassing 985 transcriptional profiles. The 16 cohorts encompass a wide range of pathological or physiological states, including autoimmune/inflammatory diseases, infectious diseases, transplantation, cancer or pregnancy. Gene expression profiles from whole blood samples, gathered using Illumina HumanHT-12 v3. 0 expression BeadChips, were obtained from 16 patient and control groups. Each dataset underwent a preprocessing procedure, which included filtering based on detection levels, normalization using the BeadStudio algorithm, and transformations focusing on fold changes. Final data were represented as the log2 of the calculated fold changes.
A concatenating function was used to generate text that includes the relevant data and metadata. For instance, the following text was generated for BCL2L1: From the Speake et al. dataset: This text was submitted to GPT-4 and Claude as input using the following stepwise prompting strategy: PROMPT 7. 1: Based on the summary below, please recommend the top candidate gene to include in a targeted blood transcriptional profiling panel. The intent is for the selected gene to be representative of an erythroid cell signature associated with response to mRNA vaccines, severity of RSV infection and that found to be expressed at high levels in patients with metastatic melanoma and in liver transplant recipients. Please weigh the following criteria equally in your recommendation: (1) Relevance to erythroid cells and erythropoiesis, (2) Current use as a biomarker, (3) Potential use as a blood transcriptional biomarker, (4) Relevance to leukocyte immune biology, (5) Status as a known drug target, (6) Therapeutic relevance for immune mediated diseases [the narratives generated earlier in step 5 are compiled and provided as input in the same prompt]".
This "fixed transcriptional repertoire" provides a stable framework over time for data analysis and interpretation. The BloodGen3 repertoire consists of 382 modules in 38 aggregates representing 14,168 transcripts, constructed and characterized as described in the Methods and a prior publication  [17]. Using BloodGen3 in multiple studies provided insight into the potential biological and clinical relevance of its modular signatures (B). One signature, corresponding to the module aggregate A37, was associated with circulating erythroid cells, vaccine responses, and respiratory viral infection severity  [15, 16] , leading to its prioritization for inclusion in a generic Immune Profiling TFA panel (ImmP-TFA). Modules within this aggregate were selected to pilot the novel workflow for the prioritization of candidate gene pools (C).
In doing so, we investigated the versatility of large LLMs for a range of tasks, from scoring candidates to the selection of top candidates for more comprehensive characterization in a separate workflow (D)  [30, 31]  constructed and characterized  [17]  (Fig. 1A  and see methods for details). Among the 38 module aggregates, aggregate A37 comprised 11 modules, which expression in one of the reference datasets appeared to be restricted to CD71 + Glycophorin A + erythroid cells  [15]. It was chosen to be subjected to candidate gene prioritization on the basis of its biological significance and potential clinical relevance (Fig. 1B ):  (1)  we have shown in our previous work this erythroid cell signature to be associated with RSV disease severity  [15] ; (2) It was also increased in patients with late-stage melanoma  [15] , which is consistent with reports that have attributed immunomodulatory functions to this cell population  [26, 27] ; (3) More recently we described pronounced changes in abundance for the transcripts included in this signature following the administration of the second dose of COVID-19 mRNA vaccines  [16] ; and (4) Others have also found erythroid cell signatures to be associated with COVID-19  [28]  and pregnancy  [29].