dataesr/scientific-paragraphs-categorization huggingface dataset:
This includes estimates of the rates from the detector, the pipeline for processing and storing the data, and how the collaboration members will access the data. Software systems for monitoring, calibration, reconstruction, and analysis are discussed. Estimates of the computing and storage requirements are included. AI detector optimization techniques are also discussed as this is expected to be a large part of the computing effort over the next few years. While we attempt to include some forward thinking plans in this regard, we necessarily do need to rely on past experience with other large experiments such as sPHENIX  [6]  and LHCb  [7]  to serve as guides.
Offline Offline software encompasses many aspects of any experiment. This includes a number of systems, each of which requires either new development or implementation of existing systems using dedicated experts(s). These include: • Calibration system and database • Reconstruction framework • Reconstruction algorithms • Simulation • Offline Monitoring system • Reconstruction workflow (HPC/HTC job management) We intend to develop an offline computing model that aims for "real time analysis" that performs a single reconstruction pass on the data, producing reduced DSTs that are available for physics analysis on the time scale of a few weeks. In this description, the single reconstruction pass includes any relevant calibrations that are determined from specific calibration data sets. In the following sections we describe some of the above systems that will constitute larger efforts in terms of person-hours.
In addition to archived builds, continuous integration is another tool ensuring reproducibility. ECCE has deployed continuous integration in certain repositories; however, automated tools enabled by services such as Jenkins or GitLab Runners will be deployed utilizing code checking tools and benchmark physics analyses. Making software user friendly requires that it is distributed in a convenient way. Currently the ECCE framework is distributed with cvmfs, a package managing software developed at CERN [13], while the software environment is containerized and deployed with Singularity [14]. Any software system that ECCE decides on will necessitate these tools for distribution, to ensure that all users can easily access the software and that a reproducible environment is available when deploying offline analysis and simulation in a federated computing architecture.
The role of hybrid architectures should also be considered in the ECCE reconstruction framework. Specifically, the use of GPU architectures will be important both for integrating machine learning into reconstruction workflows as well as generically taking advantage of the significant computational speed improvements that GPUs can provide, for example in charged particle reconstruction  [15]. This integration has the added benefit of potentially utilizing the various leadership computing facilities that are available at national laboratories around the country, for more see Section 4. Based on the experience of other experiments, reconstruction software should also take advantage of common software projects that are deployed across the world. For example, the A Common Tracking Software (ACTS) package, initially designed for use at the HL-LHC, has been implemented into the sPHENIX track reconstruction framework  [16].
Several collider-physics-based open source projects exist within the broader HEP community and have recently grown in their user base, examples include ACTS  [17] , Rucio  [18] , PanDA  [19] , Fun4All  [20] , JANA  [21] , Gaudi  [22] , and others. These should be evaluated for use within the ECCE software stack in 2022 as a part of the decision making process for the future of the offline software framework.
Calorimetry Calorimetric calibration focuses on the gain calibration. The first order of calorimetric energy scale calibration will be performed during production stage using the calorimeter blocks and SiPM QA database, e. g. light yield and gain measurements. The first iteration for the calorimetric energy scale will be based on cosmic data during the construction phase (e. g. sector testing) and pre-collision cosmic runs. This is expected to be completed before physics data taking. The second iteration of tower-by-tower energy scale variation calibration will be matching the energy slope of the calorimeter tower energy spectrum for the same eta slice. This is expected to be completed within one week of physics data taking. The final energy scale iteration will utilize real collision data in several channels.
The first is using scattered electrons, π • → γγ and η → γγ decays to set the energy scale for the EMCal. The second is using isolated hadronic shower to calibrate the e/h in EMCal and hadronic energy scale in the HCal. The third is using semi-inclusive deepinelastic scattering single high momentum jet production to set the calorimetric jet energy scale. This is expected to take one week of data (O(100) Billion events) and one week of calibration. During steady-state running, the tower-by-tower gain drift will be monitored and calibrated using LED flashes and SiPM temperature monitoring, which can be calibrated in about one hour.
Alignment To fully align the entire detector, each subdetector will be surveyed before and after installation which provides the starting point of the alignment. The first iteration of alignment will use field-off data and cosmic data to adjust major pieces of the detector component to the final installed location. The time latency needed for this task is limited by the availability of such specialized data, but we expect this step is completed before the physics quality data taken at ECCE. The second iteration requires field-on physics quality collision data to provide the final high precision adjustment for the sensor locations and time offset (for TOF) to a small fraction of the resolution. The first period of magnetic-field-on collision data will be used for this alignment. Generic purpose global alignment package such as Millepede II will be used.
Other packages, such as alignment software available in ACTS  [17] , can be considered as well. It is expected to take two weeks to complete the iteration of alignment and checks. Steady-state updates: the vertex tracker requires O(1) µm alignment precision, which could change over long periods. Therefore, during steady-state running, we expect alignment to be checked every few days and possibly updated every week, depending on the final mechanical stability. We expect steady-state alignment updates can be achieved within one hour (e. g. the LHCb vertex tracker is aligned in about 7 minutes  [24] ).
Calibration database For the ECCE streaming DAQ, we expect the calibration record to be time-stamped with a 64-bit beam crossing counter with the start and end time corresponding to the interval of validity. The validity window length will be detector and calibration dependent, but we expect they align with the luminosity block of ECCE streaming data that is O(1) second, at each of the electron ring bunch refills. The size of the calibration data is much smaller than the raw data but still sizable. For the highest channel count in the silicon vertex tracker (O(1)B channels), we do not expect to have frequent calibration as it presents boolean (hit/no-hit) pixel data. As a conservative estimate, consider 300 thousand of the calorimeter, tracker, and PID channels that require a frequent (1 per minute) update of a relative gain and time shift, each represented by a 4-byte float.
This gives an overall calibration dataset size of O(1) TB per run year (8B*(300e3 chan)*60(minute)*24(hour)*7(day)*20(cryo week)). The calibration data will be indexed in a relational database. The actual calibration data files can exist in a distributed file server (e. g. S3 or XROOTD  [25] ) or in a separated database table, depending on the size per entry and frequency of calibration updates. The separation of index database and calibration data payload allows for efficient database implementation management that is capable of accommodating a possible large size of the calibration data. This approach is being deployed in the sPHENIX fixed latency calibration and reconstruction. At the start of a production job, the job manager will pull the calibration data relevant for the job into the local disk buffer according to the index table.
The latter approach improves throughput and reproducability as the same generator-level simulation can be run over different detector configurations or more physics objects can be added later in time when for example the simulation and reconstruction are run separately. It is expected that any new framework used will try to retain as much of these features as possible. The framework has several inbuilt event generators (a particle gun, Pythia6  [26] , Pythia8  [27]  and Sartre  [28] ) and can also read in pre-generated events either via the EIC-smear program  [29]  or a file in HepMC2 format  [30]. The framework is also capable of reading in any previously produced DST, assuming the material hits were saved. If any generated particle has not been decayed by the input generator and is required to decay in the detector volume, this is handled by the built-in Pythia6 decayer.
The detector simulation will likely be handled by Geant4  [31]. The components of the detector can either be rendered in what is called "fast" or "full" simulation. Fast simulation is useful for producing passive volumes such as support or service structures, or testing ideas quickly. Full simulation will involve complete physics responses and digitization, including but not limited to Cherenkov photon production and electron cascades. Efforts are on-going to improve both our simulations, through work conducted with AI-assisted detector designs  [32] , and the infrastructure needed to produce large simulations on short time scales such as with distributed computing and GPU implementations of Geant4. Each individually simulated subsystem is bundled with the software stack which means it is also saved weekly and with every production build.
7 s with a standard deviation of 3. 3 s. This is also reflected in the simulation memory usage where the collisions with a 10 GeV electron beam and 100 GeV proton beam had an average memory usage of 2138 MB with a standard deviation of 16 MB while a 18 GeV electron beam and 275 GeV proton beam had an average memory usage of 2275 MB with a standard deviation of 32 MB. It is also expected that the overall memory footprint will be reduced through code optimisation and new hardware. For example, it has already been demonstrated in sPHENIX (which shares the same framework) that the mean memory usage for pp simulations can be reduced from 4 GB to 1. 7 GB by selective loading of simulated materials. Currently, ECCE simulations load every material described in Geant4 into memory. The distributions for event run time and memory use are given in Figure  2.
Offsite Processing The EIC will be a large international project with many researchers and stakeholders spread throughout the globe. While the accelerator and detectors are necessarily placed at a single locale, the computing need not be and can better reflect the geographic diversity of the collaborations involved in EIC research. In the modern age, high speed network connectivity has become very robust. In the time frame of the EIC (∼ 2030) we can expect even more reliable and even faster networks. This will make transporting data on the scale the EIC is expected to produce fairly routine. To give specific numbers, BNL has a 400Gbps connection to the ESnet backbone in 2021. ECCE is currently estimated to produce 100Gbps of raw data once it is in full production sometime around 2030. Network bandwidths have shown steady growth of about 50% per year over the past few decades  [33].
Thus, over the next 8 years we can expect existing bandwidths to grow by roughly a factor of 25. Even a conservative estimate that the BNL external connection bandwidth grows by only a factor of 10 means the entire ECCE raw data volume can be streamed out using only a few percent of the total available bandwidth. Table  2 : Estimated simulation requirements during operational years. The storage and CPU time estimates are based on the observed performance in 2021 while the number of events assume we will need O(10) times the amount of simulated data for O(10)% of the streaming recorded minimum bias cross section in the real data for each running year that is most relevant for the core physics program at ECCE This section will briefly describe how a federated computing model for the EIC might look, how it will be used to process the raw data, and how it will also be used to process the large amounts of simulation needed for the program.
It also supplies around 20% of the total computing resource and does the initial reconstruction of the data before distributing it to the Tier 1 sites  [35]. The Tier 1 sites perform large scale reprocessing of the data and distribution to the Tier 2 sites. The Tier 2 sites do more specialized analysis and simulations while the Tier 3 sites are end users. Each tier in the system only communicates with tiers directly above or below it in the hierarchy. For the EIC one may consider an alternative model in which the data producer (the experiments of the EIC) and the BNL compute facility (e. g. SDCC) are independent. This allows computing at BNL to become part of a pool of facilities that handle the computing as a federated resource. Figure  3  illustrates such a model referred to here as a "Butterfly" model to the rough shape of the figure.
The raw data read from the streaming DAQ system will need to be reduced over multiple filtering and compression stages to a rate that is reasonable to transport offsite from BNL using its external network connection. Table  3  lists the stages and with in-going and out-going rates and their respective reduction factors. Potential technologies that could be applied at each stage are also listed. The DOE lab systems are connected via the ESNet unclassified network for scientific research  [36]. As of 2021, BNL has a 400Gbps connection to ESNet and JLab has dual 10Gbps connections. In 2022 or 2023, JLab is anticipated to increase its bandwidth to at least 100Gbps. When the EIC begins collecting data around 2030, one may expect a 1Tbps bandwidth between the two labs. This is an order of magnitude higher than the anticipated raw data rate after filtering from the ECCE detector.
Thus, transfer of the entire raw data set offsite from BNL in 2030 seems reasonable. This diagram illustrates how raw data may be distributed to multiple sites in near-real time. On the left side of the plot, multiple filter and buffering stages are used to reduce the data rate. On the right, the data is distributed to multiple facilities. Each facility would store a portion of the raw data. It also need to keep the data live (e. g. on disk) long enough for it to be calibrated and then processed by the reconstruction software.
The event size is used, along with the numbers for the Raw Data Storage from table 4, to calculate the number of events produced in each year. The CPU needed for calibration is estimated to be roughly 5% of that needed for full reconstruction. It is noted that the sPHENIX Computing Plan estimates this to be 25%. The final line in table 6 estimates the number of CPU cores needed to process the data for each year assuming it can be done over a 30 week period. This would mean in year-3 there would be enough CPU to keep up with the raw data production rate. In earlier years, this would not be needed as the production times are much shorter.
Summary The ECCE consortium plans to deploy a federated computing model for the EIC where multiple facilities are used. ECCE recognizes the need for a global EIC model and intends to fully participate in the design and implementation of such a system. A similar strategy has been successfully deployed by the LHC in the form of the Worldwide LHC Computing Grid (WLCG)  [34]. ECCE has developed and, during the EIC detector proposal period, deployed a tiered "Butterfly" model for EIC computing that was inspired by the WLCG model, but updated to better reflect the computing landscape anticipated for the EIC. In this model, the EIC detector supplies the data, but the SDCC at BNL is treated as one of a pool of sites used for. The temporary disk is used to hold raw data for a 3 week period while calibrations are derived and reconstruction is done.
The permanent disk is for holding the reconstructed data. This will be cumulative so collaborators will have access to recon data from all years. long term storage and compute resources. Both BNL and JLab would be considered as Echelon 1 sites with the ability to add others as appropriate. Raw data would be distributed amongst multiple Echelon 2 sites for processing with the processed data being returned to Echelon 1. Researchers would directly access the processed data at the Echelon 1 sites. We have adopted a fixed-latency offline computing model where both the final calibration and reconstruction of raw data occur within 2-3 weeks of acquisition. During this period, raw data will be buffered on disk at all of the Echelon 1 sites, along with permanent archival copies on tapes. Final calibration will be performed semi-automatically including accumulating sufficient data for tracker alignment and energy scale calibration of the calorimeters.
Artificial intelligence and machine learning will be integrated throughout this model. After calibration, data processing will be released to multiple sites including HTC facilities at both Echelon 1 and 2 sites. The EIC will also require large simulation samples to aid in understanding the detector response and physics and background processes being measured. We expect that the produced simulation sample will focus on 10% of the EIC collision cross-section that is directly relevant for the signal and background of the core ECCE physics program. These physics processes will be simulated to O  (10)  times the statistics in real data to constrain systematic uncertainty from the simulated sample to be much smaller than the data statistical uncertainty. A summary of the anticipated resource requirements can be seen in table  7.
Acknowledgements We thank the  EIC Silicon Consortium  for cost estimate methodologies concerning silicon tracking systems, technical discussions, and comments. We acknowledge the important prior work of projects eRD16, eRD18, and eRD25 concerning research and development of MAPS silicon tracking technologies. We thank the  EIC LGAD Consortium  for technical discussions and acknowledge the prior work of project  eRD112. We acknowledge support from the  Office of Nuclear Physics in the Office of Science in the Department of Energy , the  National Science Foundation , and the  Los Alamos National Laboratory Laboratory Directed Research and Development (LDRD)   20200022DR.
The paper provides then some new solutions and compares them. Among these, the auction-based mechanism Nobel  [3]  is based on energy trading at a local level and is based on the stock exchange model, while PowerMatcher  [5]  aims to balance demand and supply by the interaction of specific agents, whose name is SD-matchers. Finally, the solution proposed in  [6]  is a negotiation-based mechanism in which prosumers and generating companies (Gencos) may sell energy and bargain the price with the buyers. It is displayed how the energy cost is affected by this mechanism, and also the effects of adopting learning strategies for buyers. It has to be said, however, that the previously cited papers are centered on market mechanisms based on bidding systems for prosumers. Also worth mentioning is the work in  [10]  which used the same Cardiff dataset to evaluate new decentralized mechanisms designed to optimize energy exchanges in local energy communities.
Results for non-cooperative game This section has the purpose of evaluating the game defined in Section 3, showing empirically whether the existence of a NE always occurs or not. As it will be seen, this is not the case if the functions used are the original ones from the NRG-X-Change mechanism or the ones from  [7]. Conversely, using the functions introduced in Section 5 always guarantees the existence of a NE, as proven in the previous sections. The experimental evaluation has been made by simulating the game with a Python script. Real data from a grid from Cardiff, UK, have been used. The grid has 184 users, and 40 of them are capable of producing energy. Additional detail about the grid can be obtained from  [35]. 2 The experiment has been run by simulating the game according to Algorithm 1.
Results for cooperative game In this section, the impact of the formation of coalitions in a previously non-cooperative game will be analyzed, in terms of economic profits and energy self-consumption. The simulations focus on the case when, in a non-cooperative game, two users decide to form a coalition. The simulations have been coded in a script in Python language, using the same data described in Section 7. 1. The procedure has been based on Algorithm 1, by creating coalitions of two users inside the selfish game. This is how the simulations have been run. 1. A community 𝑈 = {𝑈 1 , … , 𝑈 𝑁 } is generated, exactly in the same fashion as Step 1 in Algorithm 1; that is, 𝑈 is a subset of the community with 184 users. In the cases considered for the experiments, 𝑁 is either 10 or 20. 2. The procedure described in Algorithm 1 is then carried out and, for each user, their energy cost and their amount of energy self-consumption are noted.
Setting up the datasets for ChimeraTE Each ChimeraTE Mode requires different input datasets. To run Mode 1 (genome-guided), gene and TE annotations, along with a genome fasta file are necessary. We took advantage of available pairedend RNA-seq datasets from ovaries of four wild-type strains of D. melanogaster, for which high-quality genome assemblies were also available  (52). We performed gene and TE annotation in the new assemblies using D. melanogaster's genome (dm6) from Flybase r6. 46 as a reference, and obtained ~17,357 genes, of which only ~64 were partially annotated (Sup. Table  1 ). Regarding TE annotation, we found ~10. 29% of TE content in the four wild-type strains, similar to our previous estimations for these strains  (52). In total, 128 TE families in the four genomes were uncovered, comprising the mean of ~20,754 TE insertions (standard deviation = 892).
Genes generating chimeric transcripts Chimeric transcripts have been found in several species, being associated with genes holding different functions  (12, 31, 32). In order to investigate whether genes generating chimeric transcripts in D. melanogaster have enriched biological processes, we have performed gene ontology enrichment analysis with a dataset of 566 genes, corresponding to all genes detected with Mode 1 (506 genes) and genes detected only with Mode 2, but confirmed with manual genomic curation (60 genes). We found 16 enriched ontology terms corresponding to 287 (50. 7%) genes, associated with different functions, mainly transcription regulation and organ/tissue development (Fig. 8 ). More specifically, there are genes associated with tissue development and differentiation, such as imaginal disc-derived wing and leg morphogenesis, compound eye development, R3/R4 cell fate and regulation of organ growth.
FUNDING This work was supported by  Agence Nationale de la Recherche  [Exhyb  ANR-14-CE19-0016-01  to C. V],  Fondation pour la Recherche Médicale  [ DEP20131128536  to C. V. ];  Idex Lyon fellowship  to  D. S. O. ,  Campus France Eiffel  [ P769649C  to D. S. O. ],  TIGER  [ H2020-MSCA-IF-2014-658726  to R. R. ];  National Council for Scientific and Technological Development  [ 308020/2021-9  to C. M. A. C. ]; and  São Paulo Research Foundation  [ 2020/06238-2  to C. M. A. C].