dataesr/scientific-paragraphs-categorization huggingface dataset:
Both the original gysela code and the scheduling of the task version presented here rely on a coarse-grain parallelism handling a full (r, θ) 2D plane by thread. To leverage finer-grain parallelism, the algorithm would enable processing one or two planes at a time which typically fits in cache, instead of one by thread that typically does not. A task based approach is needed to leverage this fine grain parallelism since it requires having one thread working on the rightmost part of the DAG of Figure  1  while the others work on the left part; i. e. the threads do not execute the same code anymore. The task version implemented here is therefore a promising first step towards a version of the code with better cache behavior that will be the focus of some future work. StarPU codes described and evaluated in this section leverage intra-node computing power.
Thus, a bottom up approach can limit the size of individuals kernels and allow independent optimizations of small kernels. This is a way to reduce the search space used for the auto-tuning process as well as modularizing the implementation. Optimizing individual loop nest can also be a viable strategy. Another point that BOAST handles is helping the programmer to deal with huge optimization space to search for auto-tuning. In the remaining of the section we will briefly present BOAST's syntax. BOAST is an Embedded Domain Specific Language (EDSL) written in Ruby. A more in-depth tutorial is available in Annex A, or in the BOAST wiki  3. The BOAST documentation  4  gives more details on its usage. Listing 1. BOAST, C and Fortran code for declaring variables An example of implementing a kernel in BOAST is shown in Listing 3.
Auto-tuning parameters The set of tunable parameters in the BOAST meta-program are of utmost importance in order to reach better performance out of the auto-tuning process. Hereafter, we will go through the main tunable parameters that we have defined in the advection kernel. This list can be extended if we find other opportunities that accelerate computations. • Targeted language. Within gysela, Fortran 90 is the most used language, but the C language is also employed. Therefore, it is worthwhile to evaluate the opportunity to generate and compile C or Fortran and link the resulting object file to the gysela executable. • Loop unroll. BOAST provides a way to parameterize the loop unrolling. Specific locations where we found that unrolling impacted significantly the execution time have been equipped with BOAST unrolling.
• Inlining. For the four subroutines that have been written into the meta-program, two alternatives have been used to inline inner-most subroutine calls. The first solution is to tell to the compiler through a directive to inline a given call (e. g. !DIR$ FORCEINLINE with INTEL Fortran). The second solution is to make use of the builtin feature of BOAST to produce this inlining. • Intrinsics. BOAST can produce INTEL intrinsics (see paragraph 4. 4. 1 that follows). We have written a version of the meta-program that generates directly a code close to an assembly code. We can use or this kind of explicit vectorization, or, as a backup solution, a higher level of expression. • Block size. As mentioned in Section 4. 2. 2 and Listing 3, loop tiling is hardwired in the meta-program. Auto-tuning process will go through the different values of the blocking parameter of the loop (that interacts with vectorization done by the compiler).
It is quite disappointing for our intrinsics version but it means that vectorization made by the compiler on the non-intrinsics version is quite competitive. The two parameters inlining and unroll have not a single value through all the machines, the auto-tuning process is helpful to extract the best choice. The compiler version has a major impact on performance and surprisingly depends also on the considered machine. The block size, which is the loop tiling parameter, is a complex parameter as its impact on the performances depends highly on the compiler used. Figure  10  shows the impact of the block size on the different platforms using the different compilers. First, GFortran does not optimize the code well and it is mandatory to help the compiler with hand-tailor loop tiling. But still GFortran is not as efficient as the other compilers to optimize the code and for which the loop tiling is far from critical.
Second, there are some correlation between the block size and the compiler, because the behavior of the block size is similar between platforms and for a given compiler. For GFortran the impact of the block size across the platforms can be modeled with (blocksize + 1 blocksize ) as shown in Figure  11. However for the other compilers, even if we could identify a general tendency, the previous model does not fit correctly, because the measurements are much more noisy (in the sense that the parameters which are not accounted for in the model have a non negligible impact). This noise could be explained by the fact that ICC, GCC and IFortran are able to perform more complex optimization and thus are less predictable. In this kind of situation, auto-tuning really makes sense because it is not possible to guess correctly which optimization to put into place in the code and how to tune it correctly to handle all architectures and compilers.
size has more than two possible values. Interpreting this Table , we learn that the less important parameters are unroll and inlining. We note the Fortran language brings a substantial benefit over C on all machines, and also the version with no-intrinsics wins the one with intrinsics. The two main parameters that we have to focus on are the compiler version and the block size for the vectorization, they both have a big impact on all considered machines. BOAST auto-tuning mechanism permits to select the best choice.
Integration in the full gysela code The BOAST version of the kernel offers great performance and performance portability. This improvement would although be of little interest if not used in the production runs of the gysela code. Integration in the full code does, however, have to take into account not only performance but other aspects also such as readability and usability. gysela is indeed the result of a collaboration between people coming from different scientific fields -mathematics, physics, computer science-and with various expertise levels concerning software development. The code can only keep evolving if it remains possible for all these people to use it and understand the semantic it implements. C FORTRAN q q q q q q q q q q q q q q q q q q q q q q q q q 0e+00 1e-04.
Impact of block size for the different platforms and compilers Figure  10. The impact of block size differs from a compiler to another but for a given compiler, the model for block size, is similar across the different platforms except for the Rheticus platform. Which means there are some correlation between the block size and the compiler / language. On the bright side, one should recall that the number of lines of the BOAST kernel is less than the original Fortran version (200 lines vs. 300). This does however not mean that it is simpler to understand but merely reflects the relative compactness of the Ruby-based BOAST DSL in comparison to the verbosity of Fortran. The BOAST version of the kernel does indeed add a layer of logic where potential optimizations are explicitly specified on top of the original kernel and thus buries the semantic deeper.
The drawback is that, if neither the programmer nor the compiler manages to use the vector units, you can only achieve a fraction of the peak performance. For instance, on the Knight Landing's architecture (called also KNL) that uses AVX-512, and possesses a peak theoretical performance of 3 TFlops/s (10 12 double precision floating point operation per second). If one is restricted to scalar computations the peak performance that can be achieved is less than 400 GFlops/s. As the Knight Landing architecture was one target of the project, one of the necessary improvements to BOAST was thus to add support for the AVX-512 instruction set. We extended the SSE and AVX/AVX2 support to also support AVX-512. BOAST proposes to generate intrinsic C instructions from BOAST vector code. The Ruby vector code can also be used for FORTRAN generation.
Measuring Energy Consumption BOAST gives the energy consumed by a kernel execution, if that information is available in the platform. Ultimately the energy data is read from the Intel RAPL energy counters available in several Intel CPUs. These counters give the energy consumed by the whole CPU, core and either memory or integrated graphics card, depending on the CPU model. Since Linux 3. 13 it is possible to read these counters from the powercap interface. When possible, BOAST uses powercap. With older Linux versions this interface is not available. In these cases, BOAST reads the values from the model-specific registers (MSR), which requires root permissions. Without these permissions it attempts to read the counters through the likwid daemon, which in turn needs root access but is often granted by the system administrator.
The energy data is returned in a dictionary along with the execution time. The energy consumed by the package, core, uncore and memory is given for each socket. This q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q qq q q q q q q q q qq q q q q q q q q qq q q q qq q q q q q q q qq q q q q q 0. 2 Listing 5. BOAST code to optimize for energy delay product information can be used in conjunction with execution time or GFlops/s to decide which kernel version should be used. For instance, instead of using only execution time one may select the most efficient kernel according to energy-delay-product, as shown in Listing 5. Each point in Figure  12  shows the average execution time and energy consumption for the package (CPU) for a combination of optimization parameters: vector pragmas, nontemporal vector pragmas, loop unrolling and number of threads.
Conclusion on BOAST use The BOAST tool allowed us to improve the performance of one main kernel of the gysela code. The portability of performance is effective on all the machines we have evaluated. Nevertheless, the code readability is impacted, the BOAST meta-program is quite complex compared to the original Fortran code. We have found a way to circumvent this issue in insulating the difficulties to a kernel generation mechanism well separated from the usual compilation process, and with a separate code directory. Only a HPC specialist is able to intervene on this part, but it does not bother usual developers and users that still have access to equivalent Fortran code. Main works that have been carried out to obtain this BOAST kernel are: 1) identify what are the parameters for the auto-tuning, 2) learn BOAST and write a BOAST program that generate the kernel and scan parameters, 3) port and benchmark the meta-program on 4 different machines, 4) integrate into gysela the best auto-tuned kernel while keeping a code base that is readable for standard developers and users.
This preliminary work is a first step that should prove to be more and more useful with the increased heterogeneity of hardware to come both with accelerators such as GPUs and with imbalance due to the thermal throttling of CPU cores for example. A future work that seems promising would be to describe the task graph at a finer grain in terms of data parallelism so that more threads can work on a given piece of data and thus improve the cache efficiency. Such an achievement requires a task-based description of the algorithm since some tasks can not be parallelized at a finer grain than a 2D plane and efficient use of CPU resources thus requires a parallel execution of fine and coarse grain tasks. On the other hand, we have evaluated a meta-programming approach that enables one to rely on the BOAST tool to make optimization choices at compile-time.
Tilt series were recorded using Serial EM software (bio3d. colorado. edu/SerialEM (27) ) at a nominal magnification of 64000× (2. 2 Å/pixel). The dose--symmetric recording scheme macro  (28) , was run within an angular range from -60° to + 60°, with a starting angle 0° and an angular increment of 2°. The electron dose was set to 1. 5 e-/A 2 for individual tilt images, corresponding to the total dose 91. 5 e-/A 2 for the complete tilt series. Contrast of tilt images recorded with imaging conditions used for 2D images (CTF first zero at 1. 9 nm) was not sufficient for fiducial--free alignment. A reliable alignment was achieved when the target defocus was set to -3. 5 µm, corresponding to the CTF first zero at 2. 4 nm. Since this value is relatively close to the signal of interest (P sampling range, see Results), CTF correction was performed for all tomographic data.
Generation of fiducial--free markers was done by patch tracking algorithm of IMOD package  (29). Tilt series alignment based on marker positions generated by IMOD, CTF correction and tomogram reconstruction were performed with customs scripts  (30, 31). The reconstructed volumes were denoised by filtering by 3D nonlinear anisotropic diffusion (k=1, 10 iterations)  (32). 5 nm tomographic slices through the reconstructed section volumes were generated in IMOD.
Generation of CTF--modulated projections and tomographic slices from the canonical NCP. generated from 1EQZ PDB map using pdb2em function of EMAN software package  (33)  with a resolution of 1 nm and pixel size 0. 025 nm. All following calculations were done with using custom scripts running under Matlab platform (MathWorks, Natick, USA). The nucleosome electron density map was rotated in space with all three rotational angles assigned to random numbers, and a projection of the complete volume was generated. CTF was applied to the projection image with defocus assigned as a random number within the defocus range of real 2D images of nucleosomes acquired at 200 kV (--1. 5 ± 0. 5 μm) and at 80 kV (900 nm). This procedure was repeated to generate a set of reference images (Supplementary Figure  S2 ).
7 µm, whereas defocus values for other tilt angles were generated as a list of random numbers within the aforementioned range. The generated tilt series were then aligned, CTF--corrected and reconstructed with the same scripts as used for the real tomogram reconstructions. Similarly, 5 nm thick tomographic slices were generated in IMOD. P--measurements and statistical analyses. Line profiles measurements were performed using the ImageJ software  (34). Shapiro--Wilk (SW) test was used to assess normality of P distance measurements distributions. All data samples were distributed normally with the exception of High--Salt solutions measurements. The two--sample t--test was used to assess difference between normally distributed data samples. The Kolmogorov--Smirnov test was used to assess difference between High Salt and other data samples.
Note that the measured P--values depend on the imaging conditions (voltage and underfocus values), as analysed in SI (Supplementary Figure  S8 ). CTF correction does not correct for this effect (3D data are CTF--corrected; for 2D data, we checked that CTF-correction does not change measured P--values, see Supplementary Figure  S1 ). Since imaging conditions differ for 2D and tomographic data acquisitions, it is not possible to directly compare, nor simply normalise, the 2D and 3D datasets. Yet, the ratio of the mean P--value of nuclear nucleosomes to that of the corresponding PDB reference is the same for the two datasets (1. 12 and 1. 13 respectively). This suggests that the different nuclear nucleosome populations are similar whatever the considered cell type.
Acknowledgements. We thank  J. J. Lacapère  and  L. Issop  ( Faculté X. Bichat, Paris ) and  A. M. Tassin  ( I2BC, Gif--sur--Yvette ) for providing HT29 and KE37 cells respectively. We thank  G. Pehau--Arnaudet  for his support at the federative FEG--cryo--electron microscope ( Institut Pasteur, Paris ) and  J. Dubochet  ( Univ. Lausanne ) for access and support at the  LAU (Uni. Lausanne, Switzerland). We thank  H. Gnaegi  ( Diatome ) for providing diamond knives for tomographic experiments and  M. Kunz  ( Univ. Frankfurt ) for help with tilt series reconstruction. This work was funded by the program  ANR--06--PCVI--0029. This work was supported by  "Investissements d'Avenir" LabEx PALM  ( ANR--10--LABX--0039--PALM ). M. Eltsov  and  D. Grewe  were supported by the  German Research Foundation (DFG)  grant  EL 861/1--1.
, 2008). In cryptophytes, starch is found in the periplast  (Deschamps et al. , 2006) , a compartment surrounding the plastid that corresponds to the cytosol of the ancient red alga that was engulfed through secondary endosymbiosis by a eukaryotic phagotroph. Starch synthases have a central role in starch synthesis since almost every glucose found in starch was initially deposited by an SS enzyme. SSs are retaining glycosyltransferases classified within the GT5 family in the Carbohydrate Active Enzyme (CAZy) database  (Lombard et al. , 2013). GT5 also includes the ADP-Glc utilizing bacterial glycogen synthases (GSs). Two very different types of GT5 SS are used for starch synthesis. Red algae and glaucophytes share a GT5 UDP-Glc utilizing glycogen/SS with many heterotrophic glycogen accumulating eukaryotic lineages.
RESULTS The crystal structures of three SSs were determined and refined. Crystallization was carried out in the presence of ADP and acarbose; these ligands are present in the final models. Acarbose, a glucosidase inhibitor used clinically for treating diabetes, was used as an acceptor mimic to obtain ternary complexes of both donor and acceptor  (O'Reilly et al. , 1999; Errey et al. , 2010). Crystallographic statistics and PDB accession codes on all the models are shown in Table  1. The model for CpGBSSI is of considerably lower crystallographic quality compared to the other two. The crystal of CLg1GBSS contains three crystallographically independent protein molecules in the asymmetric unit of which one (chain A) is bound to ADP and acarbose, one (chain B) is bound to ADP and glucose from the cryoprotectant and the third chain appears to be a mixture of the two, although ADP and acarbose were modeled in the electron density.
Phylogeny of the GBSS/SSI/SSII Group In plants, glaucophytes and green algae, enzymes of the SSIII/IV/V type have been fairly recently studied through phylogenetic analysis. These enzymes originate from a chlamydial gene encoding an enzyme secreted by these pathogens in the cytosol of the Archaeplastida common ancestor  (Ball et al. , 2013 (Ball et al. , , 2015)). Although a preliminary but incomplete analysis of the GBSSI/SSI/SSII group of enzymes has been performed, we now have investigated this issue in greater detail with a vastly expanded database that include the secondary eukaryotic algae (alveolates and cryptophytes) and a much larger sample of glaucophytes and red algae. GBSS and SSI/SSII enzymes from the lineages derived from plastid primary and secondary endosymbiosis, respectively the Archaeplastida (green and red algae, glaucophytes and plants) and the alveolates and cryptophytes, form a very robust monophyletic group among the bacterial GT5 ADP-Glc requiring glycosyl transferases (Figure  8  and Supplementary Figure  2 ).
We argue that if the few cyanobacteria (only two sequences in the databases) that harbor GBSSI had received the gene from a eukaryotic source, these bacterial sequences should have been found within either one of the three Archaeplastida groups or within a secondary endosymbiosis group such as the alveolates or cryptophytes. This is not the case. The phylogenetic position and monophyletic nature of cyanobacterial GBSSI at the base of the three Archaeplastida lineages, is, on the contrary, perfectly consistent with the gene coding this enzyme entering the ancestral eukaryotic host through primary endosymbiosis. Because of this, and in agreement with our previous biochemical characterization of cyanobacterial GBSS  (Deschamps et al. , 2007) , we propose that the cyanobacterial plastid ancestor was a starch and amylose accumulating cyanobacterium.
M. S. D. bonds 0. 006 Å 0. 012 Å 0. 009 Å R. M. S. D. angles 1. 2 • 1. 6 • 1. 5 • Ramachandran outliers (%) 0% 0. 4% 2. 2% PDB code 6GNF 6GNE 6GNG Numbers in brackets are for the high resolution shell. #Rmerge = hkl i|Ii(hkl)- < I(hkl) > |/ hkl i Ii(hkl). +Rwork = hkl|| Fobs|-| Fcalc||/ hkl|Fobs|. §Rfree = hkl|| Fobs|-| Fcalc||/ hkl|Fobs| calculated using a random set containing approximately between 1000 and 1500 (3% or 3647 for CLg1GBSS) of the reflections that were not included throughout structure refinement. per frame. Diffraction data was reduced with XDS (Kabsch, 2010) to a resolution limit of 2. 2 Å. A test set was created with 3% of the data. Data quality as well as final refinement statistics are reported in Table 1.
In this paper, we describe SAFlex (Structural Alphabet Flexibility), an extension of an existing structural alphabet (HMM-SA), to better explore increasing protein three dimensional structure information by encoding conformations of proteins in case of missing residues or uncertainties. An SA aims to reduce three dimensional conformations of proteins as well as their analysis and comparison complexity by simplifying any conformation in a series of structural letters. Our methodology presents several novelties. Firstly, it can account for the encoding uncertainty by providing a wide range of encoding options: the maximum a posteriori, the marginal posterior distribution, and the effective number of letters at each given position. Secondly, our new algorithm deals with the missing data in the protein structure files (concerning more than 75% of the proteins from the Protein Data Bank) in a rigorous probabilistic framework.
The growth and speed of macromolecular structure determination techniques (protein crystallography and NMR spectroscopy) results in a considerable increase to 3D structures in the Protein Data Bank (PDB,  [30, 31] ), which currently has more than 130,000 3D protein structures. More than half of PDB structures share at least 95% sequence identity. Even if this redundancy is considered valuable in investigating families of homologous sequences  [32, 33] , the dominant approach for data mining the PDB considers redundancy as non-informative  [34] , resulting in an artificial reduction in the variability of the structural space. Yet, protein redundancy analysis is crucial for protein flexibility insight. Proteins are highly flexible macromolecules and their 3D folding and dynamic properties are essential in many biological processes  [32, 34].
These missing parts often relate to the ends of the protein or loops that are the most flexible regions of proteins and involved in protein interactions and function. Thus the detection and modeling of these missing data could have a very appealing impact for protein structure analysis. However, they have not been explicitly modeled by different SA approaches. In this paper, we extend a previously published SA, HMM-SA  [3, 15, 40] , in SAFlex (Structural Alphabet Flexibility) to encode 3D conformations of proteins in case of missing residues or uncertainties with the aim to better explore increasing protein 3D structure information. HMM-SA was modeled using HMM, which provides a very precise description of protein structures, particularly loop regions  [41]  known to play important roles in protein function.