dataesr/scientific-paragraphs-categorization huggingface dataset:
A likely explanation is that the climate-carbon feedback on land is underestimated in Pathfinder, as suggested by the γ metric seen in Sect. 4. 2. Alternatively (or concurrently), the absence of loss of sink capacity caused by land cover change  (Gasser and Ciais, 2013; Gasser et al. , 2020)  can explain the overestimation of the land sink under high CO 2. The Pathfinder model's estimates of both sinks nonetheless remain well within the CMIP6 models' uncertainty ranges. Our SLR emulator gives estimates (Table  4 ) that are always on the lower end of the range reported in the AR6  (Fox-Kemper et al. , 2021, Table 9. 9). This can be explained by the fact that our individual SLR rate estimates are on the lower end of their respective constraints (see  Sect. 3. 5. 3). This discrepancy also highlights potential structural limitations in the SLR module (e.
Acknowledgements. We thank  Andrew H. MacDougall  for sharing permafrost simulations made with  UVic , and  Côme Cheritel  for the first version of Figs. 1234. Financial support. Development of Pathfinder was supported by the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement no. 820829  ( CONSTRAIN  project) and by the  Austrian Science Fund (FWF)  under grant agreement no. P31796-N29  ( ERM  project). Review statement. This paper was edited by  Marko Scholze  and reviewed by  Ian Enting  and one anonymous referee.
% to 20 % by Pathfinder across SSP scenarios. This is consistent with the upward adjustment of the ocean carbon sink stemming from our Bayesian calibration. To compare the land carbon storage with CMIP6 models, because our land carbon module does not include land use change processes, we correct the value reported by complex models by the cumulative land use change emissions of each scenario (Riahi et al. , 2017;  Gidden et al. , 2019). While the land carbon storage of Pathfinder is well in line under ssp126 (a scehttps://doi. org/10. 5194/gmd-15-8831-2022Geosci. Model Dev. , 15, 8831-8868, 2022.
Our approach matches heuristics for simple inputs while being significantly faster than the best Integer Linear Program (ILP) solver-based approach for complex inputs. We also show how ML can be used to continuously improve the search for the long tail of workloads. Our approach is shipping in two production systems: Google's Pixel 6 phone and TPUv4. It achieves up to two orders of magnitude allocation time speed-up on real ML workloads compared to a highlytuned production ILP approach that it replaces and enables important real-world models that could not otherwise be supported.
These heuristics are fast but cannot solve workloads with complex allocation behavior that are close to the memory limit. (2) Solver-based approaches: Past work has used SAT or ILP solvers to encode the bin packing problem. One example of this type of strategy is Checkmate  [30] , which uses the solver for optimal rematerialization of buffers. These approaches can handle the more complex workloads that heuristics cannot solve but are often too slow to run online. We investigated this problem during the development of Pixel 6. The compiler for the ML accelerator in Pixel 6's custom Tensor System on Chip (SoC)  [4]  originally relied on a memory allocation approach that used two strategies: 1) A heuristic similar to previously deployed and published greedy approaches  [2, 38] , which is fast but does not solve the most complex models, and 2) An ILP solver-based approach that is used if the heuristic fails.
Target Platforms The problem we investigate is universal to almost all production ML compilers. In this paper, we look at two very different scenarios. Our focus is on the ML accelerator in Pixel 6, but we also integrated our approach into the TPUv4 compiler that targets data center ML workloads. Both accelerators have very different hardware designs (Figure  2 ), deployment scenarios, and use different compiler stacks. Pixel 6 Tensor SoC (Inference): Google's custom Tensor SoC contains a proprietary tensor processing unit. The accelerator consist of a 2D array of processing elements (PEs). Each PE contains a scratchpad memory, as well as a number of SIMD units. Each of the SIMD units contains a local register file and a number of compute lanes. TelaMalloc manages the scratchpad memories within the PEs (all PEs execute the same code and thus have identical memory allocations).
Product Requirements & Motivation We will now describe our motivation, and how the goals and requirements between the two accelerators fundamentally differ. Pixel 6: Android apps can target the Tensor SoC's ML accelerator via NNAPI  [5] , an API that can be called from anywhere in the program. NNAPI invokes the compiler, which may happen at load time but also elsewhere in the program (e. g. , an app may download a model or programmatically generate NNAPI calls). The compiler runs on the phone's CPU, takes the model and any settings provided by the application or system, and maps it to a schedule of operators with associated buffers. It then invokes the memory allocator to pack a chosen subset of memory buffers into PE memory. As long as a suitable packing can be found, the size or layout of this packing does not matter since the accelerator is uniform and not shared.
This would require all model/app developers to share their source code with a central repository, which is often infeasible. Caching compilation results on-device does not solve this problem since the prohibitively long compilation time still occurs after every app or configuration change and is user-visible (note that some models take minutes to compile; this is too long for a user to wait for an app). Finally, running compilation at installation time is infeasible as well, since the model is generated by arbitrary code (e. g. , the application may download the model at run time, after it has been installed  [5] ). While only a subset of models take prohibitively long to compile, some of them are important and could not run without TelaMalloc. Enabling this long tail is thus our primary motivation.
TPUv4: We integrated TelaMalloc into the open-source XLA compiler  [37] , which is used for TPUv4. Compilation in data centers can tolerate moderate memory allocation delays, but the XLA compiler is also used as a JIT compiler for JAX  [15]  and TensorFlow (where compilation is time-sensitive). To allocate buffers in SRAM, XLA repacks buffers many times in its inner loop, so speedups in repacking can add up to substantial savings. There are also autotuners that run the compiler many times to optimize a model  [52]. Most importantly, XLA uses its allocator to opportunistically put as many access-intensive buffers as possible into SRAM while heuristically maximizing their utility. Corresponding kernels fetch data from there instead of HBM, executing faster. TelaMalloc succeeds at packing more buffers into the same memory within the time limit, resulting in end-to-end program speedups without substantially increasing compilation time (Section 7.
𝑀 is the maximum memory size. Note that variables 2-3 and constraints 2-4 implement a logical OR preventing any two buffers from overlapping. and end time are fixed, we can statically determine which buffers overlap in the time dimension. For each of these overlapping pairs (OverlappingBuffers), we add constraints (2-4) to encode that they must not overlap in the space dimension. For two buffers 𝑖 and 𝑗, this can be written as (pos 𝑖 + size 𝑖 < pos 𝑗 ) OR (pos 𝑗 + size 𝑗 < pos 𝑖 ). We encode logical OR in standard ILP fashion as boolean variables 𝐵 𝑖,𝑗 and B𝑖,𝑗 , as well as two equations, one for each side of the OR (𝐵 𝑖,𝑗 selects which branch can be false). This approach has similarities to other solver-based approaches that divide up resources, such as CheckMate  [30]  and bin packing algorithms for cluster scheduling such as TetriSched  [60].
EVALUATION We evaluate TelaMalloc's performance compared to the state-ofthe-art ILP-based solution. TelaMalloc runs on-device for Pixel 6 and on server CPUs for XLA. We therefore evaluate TelaMalloc both on Pixel 6 devices as well as a 6-core Intel Xeon E5-1650 CPU running at 3. 60GHz with 64 GB of DRAM and Linux kernel version 5. 17. 11. We use a mix of microbenchmarks and real-world models to cover a representative set of workloads. To scale our evaluation, we collected a set of on-device allocator inputs that we can run on regular servers or desktops. These traces are identical to those running on actual Pixel 6 hardware and we validated that allocation speedups observed on a desktop CPU translate to on-device speedups (Figure  12 ). Unless otherwise noted, we give each model 110% of the minimum required memory.
This degree of overlap does not occur in practice, but it shows fundamental limitations of our (and other solver-based) approaches when there are many overlapping blocks. We also collected a pprof [6] profile from a representative run, to understand where time is spent. We found that upwards of 87% of time is spent in the solver and 9% in TelaMalloc's block selection Table  2 : Heuristic execution time (on workstation) and its minimum required amount of memory compared to the theoretical minimum achieved by the ILP solver. The heuristic runs much faster than solver-based approches (Figure  12 ). heuristics. This shows that we are mostly solver-bound and are not introducing unexpected overheads in the rest of the allocator. Furthermore, TelaMalloc's code and memory overheads are negligible compared to the ILP solver, which is complex and large.
We explore this on our dataset of 1,192 input configurations. As before, we run configurations in a distributed dataflow pipeline (backtrack counts are timing-independent). We use a model only trained on the benchmarks in Figure  13 , demonstrating its ability to generalize. Note  that this experiment uses a new/experimental version of TelaMalloc and is thus not directly comparable to the other experiments. Out of our 1,192 inputs, 117 were models where TelaMalloc backtracked more than 1,000 times, which indicates corner cases where TelaMalloc alone does not perform well. Out of these 117 benchmarks, ML improved 102. This includes 56 inputs that timed out and now succeed, and 34 inputs where the number of backtracks was reduced by 10× or more. Some inputs also got worse ś the most important case is when backtracking skips the important part of the search space and therefore terminates without finding a solution (4 out of 1,192 cases) or increases backtracks by more than 10× (9 cases).
TPUv4 Workloads We integrated TelaMalloc into XLA's TPUv4 compiler. Recall that the benefit in this case is not only the allocation speed but also the ability to opportunistically pack more buffers into SRAM (Section 2. 3). The TelaMalloc-based repacking step is used in the inner loop of the SRAM allocation algorithm where it runs up to 50 times. XLA is also used by TensorFlow and JAX as a JIT compiler. Compile times are thus important as well. Figure  18  shows the performance improvement of the compiled programs that use TelaMalloc as the repacker as opposed to the bestfit algorithm, using Tensorflow/XLA. Note that this shows actual program speedup rather than allocator speedup presented in the previous sections. TelaMalloc achieved up to 7% better performance than the best-fit algorithm.
Those elements are the semi-unbounded size of reservoir and foundation-rock domains, dam-water interactions, wave absorption at the reservoir boundaries, water compressibility, dam-foundation rock interaction, and spatial variations in ground movement at the dam-rock interface. However, finite element calculations of arch dams undertaken in professional practice generally neglect these variables. Four-constructed arch dams in the USA (Deadwood Dam in Idaho, Monticello Dam in California, Morrow Point Dam in Colorado, and Hoover Dam in Nevada) were investigated to study the relevance of the ignored variables cited. The acquired data assured that the calculations without these parameters led to unacceptably erroneous predictions of earthquake-induced stresses. Analyses neglect spatial changes in ground movement and fail to recognize the areas of the dam that are expected to be stressed, and harmed.
Liu & Chen (2013) discussed numerically two models of the earthquake, the massless foundation and the viscous-spring conditions. The viscous-spring boundary subroutine is implemented in the finite element software ANSYS. The viscous-spring boundary and the wave input model were modelled for the seismic analysis of the Longtan gravity dam-foundation system. The obtained results demonstrate that the magnitude of the dam's dynamic reactions was less than the massless foundation model by 4%-38%. The structural dynamic reactions are overstated to some degree using the standard massless model. The radiation damping influence of infinite foundation has a major influence on the structure's dynamic responses and is highly vital to be taken into consideration. Pan et al. (2015)  provided an approximate incremental dynamic analysis (IDA) for the earthquake-resistant design of the Dagangshan arch dam, in China.
Pasbani  Khiavi et al. (2021)  examined the responses to achieve the optimal body stiffness using probabilistic and uncertainty methods after evaluating the effect of Young Modulus of both the body concrete and the foundation as strength parameters for concrete arch dams. The dam-reservoir-foundation system's finite element analysis was completed using ANSYS software, and the Monte Carlo method, a new method for parametric study and sensitivity analysis, was used for uncertainty analysis. The dam's safety status can be investigated using the design criteria, and the best state for the model in terms of structural strength can be chosen. However, in order to properly select the modulus of elasticity of the dam body concrete, the simultaneous effect of the stiffness of the foundation must be considered and the optimal value chosen.
As strong-motion accelerograph datasets became commonly available in the 1970s, they became widely used as the principal theoretical tool in earthquake engineering  (Trifunac & Todorovska 2008). To evaluate the modal response, the acceleration will be multiplied by the modal mass of each mode. The spectral modal analysis consists of determining the modal mass of the studied system. Successive steps should be followed to obtain the results. The most common type of analysis is quasi-static analysis, where the load is applied at a very slow rate so that the acceleration is negligible. After that, the eigenmodes of the structure is defined, by searching for a normal mode of vibration of an oscillating system. Then, by selecting useful modes, the corresponded modal responses will be estimated. To study the response of the modes, the modes should be selected with a modal mass greater than 5% of the total vibrated mass.
In order to check that all the dimensions will be secure, the stresses should be verified before modelling the proposed medium dam. Referring to Equations (  1 ) and (  2 ), in addition to Figure  2 , the stresses of the proposed medium dam can be calculated as following: P ¼ 10 Â 25 Â 25 2 À 300 ¼ 125 kN=m P av ¼ 125 Â 1 þ 4:75 2 x 40:865 ¼ 132:2kN=m ¼ 0:132 MPa s ¼ 0:132 Â 0:132 Â 40:865 4:75 ¼ 1:137MPa , 8 Mpa: The stresses exerted by the water on the proposed medium arch dam is acceptable, and the dam can resist it. The forces exerted on the dam are were the upstream pressure, the sediment pressure, the weight of the dam, and the seismic load that was represented by a pseudo-static force in the first study. Advance Design (2022) finite element analysis software developed for the civil engineering domain, provides a complete platform from structure simulation to post-processing results, and structure modification.
It covers a full variety of features specialized in sophisticated CAD models, meshes generation, analysis, validation, and improvement of concrete, metal, and wood constructions, resulting from post-processing and production of high-quality outputs. Advance Design uses the main worldwide standards (Eurocode, North America…). In this case, this software was used to calculate the stresses of the dam consider first the pseudo-static force applied to the dam. Although, the frequencies and modes of the dam. The analysis in the Advance Simulation model is established in four operational modes: Models, Analyse, Design, and Report. The properties of each component were specified in Advance Design. Those properties are represented in Table  1. Usually, different parts were produced in the graphical area.
The option of drawing an arch on Advance Design does not exist. The model was drawn in 3D model parts as areal elements using AutoCAD software, and then the model was imported as shown in Figures  3  and 4  In the pseudo-static case, the forces was added with values in two directions, horizontal and vertical. The exerted forces on the model were as follows; upstream pressure 'Q 1 ' with maximum value, sediment force 'G 1 ' value was 33. 3 kN, the hydrodynamic force 'F' equal to 328. 49 kN/m. Once all the loads were defined, the combinations were performed, and then the finite element model was analysed. During the analysis of the second   case, the response spectrum, the added forces were removed (Weight of dam, sediment, and water pressure). Only the hydrodynamic force was added. The model's consistency and integrity should be checked with the verification tool.
Following the evaluation of the model, the program generates the analysis model. This model performed a numerical process that is automatically executed. The mesh is an essential operation for the calculation of the finite element structure. The finite element meshing was accomplished using global mesh settings. The mesh parameters were specified for each element. These parameters were defined using a detailed method. This operation subdivided the structural elements into several sub-elements to refine the results of the calculation. In Advance Design, two types of mesh are available: Grid and Delaunay. In this case, the second type was used, due to its ability to build meshes for space-discretized solvers, angle guarantee, and quick development of triangulation techniques. The elements used were triangles and quadrangles (T3-Q4).
The size of each element was defined by default as 0. 5 m. In the end, the total node number was 3314 nodes. (Figure  5 ). To calculate the stresses for this arch dam, it was divided into two parts, the consoles and the arches. The calculated stresses, in the x direction, were considered for the arch part. While, the calculated stresses, in the y direction, were considered for the console part of the dam. Some parameters should be defined, to find the frequencies of the dam in a full reservoir state. Using the manual data of the used software (Advance Design 2022) and the recommendation of Eurocode  (EN 1998 (EN -1: 2004)) , the parameters values were chosen as follows: the acceleration a gr ¼ 2. 5 m/s 2 , the importance coefficient γ i ¼ 1, the topographic coefficient S T ¼ 1. 2, and finally the depreciation correction η ¼ 5%: a g ¼ a gr Â g i ¼ 2:5 Â 1 ¼ 2:5m=S 2 (20) Advance Design permits arranging analysis in several computation stages, and computing them gradually (enable properties adjustments for each step).
Video recording of feeding events Field observations were performed in the five bays from May to September 2016, from December 2016 to May 2017, in February, April and June 2018, and from June to October 2019. Three snorkelers prospected a bay daily either from 7:00 to 12:00, or 11:00 to 14:00 or 14:00 to 19:00 to ensure data collected were evenly distributed across daylight hours. Once a turtle was spotted, the snorkelers video-recorded its behaviours with GoPro Hero 4 Silver cameras, using the focal sampling technique  (Altmann, 1974) , at a minimal distance of 4 meters. The bays being highly frequented, most turtles are used to human presence and their behaviour usually seems unaffected by the presence of snorkelers. Nevertheless, if snorkelers' presence appeared to stress a turtle (which displayed a change in behaviour, location or direction), they moved away.
Video recording of feeding events 172 Field observations were performed in the five bays from May to September 2016, from 173 December 2016 to May 2017, in February, April and June 2018, and from June to October 174 2019. Three snorkelers prospected a bay daily either from 7:00 to 12:00, or 11:00 to 14:00 or 175 14:00 to 19:00 to ensure data collected were evenly distributed across daylight hours. Once a 176 turtle was spotted, the snorkelers video-recorded its behaviours with GoPro Hero 4 Silver 177 cameras, using the focal sampling technique  (Altmann, 1974) , at a minimal distance of 4 178 meters. The bays being highly frequented, most turtles are used to human presence and their 179 behaviour usually seems unaffected by the presence of snorkelers. Nevertheless, if snorkelers' 180 presence appeared to stress a turtle (which displayed a change in behaviour, location or 181 direction), they moved away.
Acknowledgements This study was carried out within the framework of the  Plan National d'Actions Tortues Marines de Martinique (PNATMM). The protocol of this study was approved by the  Conseil National de la Protection de la Nature  and the  French Ministry for Ecology  (permit numbers:  2013154-0037  and  201710-0005 ) and followed the recommendations of the Police Prefecture of  Martinique. This work was supported by the  Fonds Européen de Développement Régional (FEDER)  and  Direction de l'Environnement, de l'Aménagement et du Logement (DEAL) Martinique (European Union ,  Conventions 2012/DEAL/0010/4-4/31882 & 2014/DEAL/0008/4-4/32947 & 2017/164894 ),  Office De l'Eau (ODE) Martinique  ( Conventions 014-03-2015  and  180126 ),  Centre National de la Recherche Scientifique (CNRS, Subvention Mission pour l'Interdisciplinarité) ,  European Regional Development Fund (Convention CNRS-EDF-juillet 2013) and  Fondation de France  ( Subvention Fondation Ars Cuttoli Paul Appell ).
Introduction Almost twenty years after the completion of the sequencing of the genomes of Saccharomyces cerevisiae, Drosophila melanogaster and Homo sapiens, precise gene annotation still remains challenging. Initiatives such as the Human Proteome Project (HPP)  (Omenn et al. , 2021)  or ProteomicsDB  (Lautenbacher et al. , 2021)  aim at defining the ensemble of proteins actually expressed in human or other organisms using mass spectrometry (MS) based approaches. These projects have reached impressive milestones but they are centered around the protein database that are used to mine the experimental MS data in order to identify expressed proteins  (Brunet et al. , 2020). So far, these databases mainly comprise genes annotated in UniProt  (Bateman et al. , 2021). However, recent studies have suggested that hundreds of small yet to be annotated proteins, might be expressed across the kingdom of life  (Fabre et al.
, 2021). These proteins, called alternative proteins (AltProts, or short open reading frame (ORF) encoding polypeptides (SEPs) or microproteins), have failed to be annotated notably due to the short length of their open reading frame (less than 100 codons), alternative start codon (other than AUG) or the enforced rule establishing that messenger RNAs (mRNAs) are monocystronic  (Brunet et al. , 2020). Almost two decades of pioneering work have highlighted that AltProts can be produced from ORFs on long non-coding RNA (lncRNA-ORF) or the different regions of mRNAs, within the 5' or 3' untranslated regions or alternative frames in canonical coding sequences (called uORFs, dORFs and intORFs, respectively)  (Plaza et al. , 2017a). Database such as OpenProt  (Brunet et al. , 2019) , sORFs. org (Olexiouk et al.