dataesr/scientific-paragraphs-categorization huggingface dataset:
A nonsmooth numerical model for Drucker-Prager flows In this section, we present our continuum dilatable Drucker-Prager plastic fluid model for granular flows, along with the nonsmooth numerical discretisation used to robustly and efficiently simulate true-scale collapses. The numerical model is based on the original reformulation of the Drucker-Prager rheology as a conic constraint introduced in  Daviet & Bertails-Descoubes (2016a,b) , and implemented in the open-source Sand6 software. In order to assess the physical relevance of this model in the context of transient granular flows, we numerically reproduce a classical avalanche experiment in two and three dimensions, and analyse the role of the Drucker-Prager friction coefficient in regards to the usual experimental avalanche and stop friction coefficients.
2008) , i. e. features having optimal contrasts to be tracked (enhanced by the presence of multicoloured materials as shown in figure  2 ). We interpolate feature velocities on a mesh to produce the velocity fields using the opyf python package. The reader may refer to Annex 1 of  Rousseau & Ancey (2020)  for details on the velocimetry procedure. H 0 L 0 H f H f L f h (x) Figure  4  illustrates the methodological data used to compare experiments and simulations in this article: the upper left column shows snapshots of the recorded experimental collapse for the initial and some intermediate state, coloured with the velocity magnitude as measured by velocimetry, while the upper right column shows the corresponding snapshots of the simulation, where the background medium and velocity are displayed by the Material Points quantities.
In parallel with these efforts, it is of paramount importance to promote software development as a valuable research activity, and research software as a key enabler for Open Science/Open Research, recognizing in the careers of academics their contributions to high quality software development. This was stated in the November 2018 Paris Call on Software Source Code  17  , and clearly put forward in the agreement on reforming research assessment published on July 20, 2022  18. This is still a challenge today 1  : Promoting software development is not an easy task, due to the many kinds of software projects and the broad varieties of expertise involved  19. Designing, coding, debugging, maintaining, documenting, testing, support, and management, are activities that require specific skills, ranging from scientific and technical knowledge, to community building and management, to writing and maintaining documentation that facilitates the use and appropriation of software.
Defining research software A key preliminary step in this endeavour is to define precisely which software falls in the scope of the award. As a first step, we focus on research software. This is software designed, maintained, and/or used by scientists and/or research institutions. It is developed to meet a specific need of science, hence it results from research work and/or enables scientific work, which is notably valued by publications before/on/around/with the software. We acknowledge the broad variety of forms that software can take: standalone and/or in interaction within an ecosystem, a platform, middleware, or a library, module or plugin of another software. Furthermore, to be eligible for an Open Science award, research software should be licensed as free and open source software, typically under one of the licenses approved by the Open Source Initiative 5.
For example, the Covid-sim C++ source code was deemed sound and correct as a simulator despite not being received well by software engineers  26. Non-professional software developers may also become expert developers in their research area. To take this diversity of practices into account, it is crucial to refrain from looking at research software only through the software engineering lens. Promoting good software engineering practices is important as they are necessary skills for producing good quality code, but this must not be a hard requirement for the award. Taking into account software diversity: Maturity. Some research software have been developed for decades, while others are very new, for example a prototype written during a PhD thesis. Some software have institutional support and significant resources for their development, others are supported by a large international community, while the remaining ones are maitained by a few, or just one, individuals without any particular help.
Some other projects, despite being more recent, are made available without a license. The submission process, which requires selecting an open source license, incites the software development team to take into account that important aspect. It may be the case that the software itself is open-source, but requires a proprietary platform to be executed (think e. g. of Matlab scripts), or that some parts of the software may not be open-source (e. g. in an industrial context). Generally speaking, while it is essential that the scientific output should be as open as possible, it was decided to have the largest definition as possible of openness, i. e. even within closed ecosystems, to promote reproducibility and enable others to build upon such research. Awarding community. Software is often not developed by a single person, and the prize wishes to also recognize the role of the community behind the software.
Data and software availability Underlying data Recherche Data Gouv Dataverse: Données anonymes concernant les candidatures au premier prix science ouverte du logiciel libre de la recherche, https://doi. org/10. 57745/HN6O85 For each of the 129 submissions, this dataset includes metadata on the start date of development, programming language(s), license(s), and scientific domain. Personal information was removed. Data are available under the terms of the Etalab Open License 2. 0.
Acknowledgements We thank all the applicants to the award, the committee members of the 2022 award ( François Elie ,  Stéfane Fermigier ,  Christine Gaspin ,  Martin Grandjean ,  Alexis Kauffmann ,  Daniel Le Berre  (chair),  Lucas Nussbaum ,  Guillaume Plique ,  Viviane Pons , and  Stéphane Popinet ), and  Sandrine Blazy  who will be the chair of the 2023 committee. We thank the members of the " Collège Codes sources et logiciels du Comité pour la Science Ouverte " ( Florent Chuffart ,  Mélanie Clément-Fontaine ,  Ludovic Courtès ,  Sébastien Gérard ,  Mathieu Giraud ,  Timothée Giraud ,  Jean-Yves Jeannas ,  Nicolas Jullien ,  Daniel Le Berre ,  Violaine Louvet ,  Camille Maumet ,  Clémentine Maurice ,  Grégory Miura ,  Raphaël Monat ,  Sophie Renaudin ,  Nicolas Rougier ,  François Sabot ,  Sylvie Tonda-Goldstein , and  Samuel Thibault ).
All these solutions are given in a uniform way in one table. Together with the exact coordinates for the Platonic and Archimedean polyhedra we used (also in the appendix) these solutions can be easily verified by the reader; for the coordinates of Catalan solids we refer to www. dmccooey. com/polyhedra/. For the reader's convenience, we also provide our source code written in the programming language R and the software Maple: www. github. com/Vog0/RupertProblem.
Explicit results In this section we collect the explicit results of our work. We prove Rupert's property for a tenth Archimedean solid, show that most Catalan and Johnson solids are Rupert, improve on almost all known Nieuwland numbers and estimate the Rupertness of all point symmetric Platonic and Archimedean polyhedra. The solutions described below in Theorem 2 and 3 as well as in §4. 2 are found using the probabilistic and numerical algorithms from the previous section in the programming language R and then verified with rigorous bounds in Maple.
Icosidodecahedron all permutations of (0, 0, ±Φ) and all even permutations of (± 1 2 , ± Φ 2 , ± Φ 2 2 ) 14. Truncated dodecahedron all even permutations of (0, ±1/Φ, ±(2 + Φ)), (± 1 Φ , ±Φ, ±2Φ) and (±Φ, ±2, ±(Φ + 1)) 15. Truncated icosahedron all odd permutations of (0, ±1, ±3Φ), (±1, ±(2 + Φ), ±2Φ) and (±Φ, ±2, ±(2Φ + 1)) 16. Rhombicosidodecahedron all even permutations of (±1, ±1, ±Φ 3 ), (±Φ 2 , ±Φ, ±2Φ) and (±(2 + Φ), 0, ±Φ 2 ) 17. Truncated icosidodecahedron all even permutations of (± 1 Φ , ± 1 Φ , ±(3 + Φ)), (± 2 Φ , ±Φ, ±(1 + 2Φ)), (± 1 Φ , ±Φ 2 , ±(-1 + 3Φ)), (±(2Φ -1), ±2, ±(2 + Φ)) and (±Φ, ±3, ±2Φ) 18. Snub dodecahedron all even permutations of (2α, 2, 2β), (α + β Φ + Φ, -αΦ + β + 1 Φ , α Φ + βΦ -1), (α + β Φ -Φ, αΦ -β + 1 Φ , α Φ + βΦ + 1), (-α Φ + βΦ + 1, -α + β Φ -Φ, αΦ + β -1 Φ ), (-α Φ + βΦ -1, α -β Φ -Φ, αΦ + β + 1 Φ ) with an odd number of sign changes of the coordinates, where ξ = 3 Φ 2 + 1 2 Φ -5 27 + 3 Φ 2 -1 2 Φ -5 27 , α = ξ -1/ξ and β = ξΦ + Φ 2 + Φ/ξ Table  4 : Used coordinates of all Platonic and Archimedean solids, as used in the Maple Package geom3d (for verification), except Snub Cube and Snub Dodecahedron, which are not needed for our results.
Φ = ( √ 5 + 1)/2 ≈ 1. 62 is the golden ratio. Finally, Table  4  incorporates the exact coordinates we used for the Platonic and Archimedean solids. The coordinates for Catalan and Johnson solids can be found at www. github. com/Vog0/RupertProblem and are taken, as mentioned, from the website www. dmccooey. com/polyhedra. The first link also contains the source code in R and Maple we used to find and then verify solutions.
Acknowledgments We would like to thank  Alin Bostan  for his careful reading of the first version of this manuscript,  Herwig Hauser  for his support and  Mohab Safey El Din  for his help and expertise on algorithms for semi-algebraic sets. The second author was financially supported by the  DOC fellowship  of the  ÖAW  ( 26101 ), the  WTZ  collaboration project of the  OeAD  ( FR 09/2021 ) and the  DeRerumNatura  project  ANR-19-CE40-0018.
e. , genotypes A or C, favors the hypothesis of genotype A as the initial partner. Indeed, A/G recombinants are rather frequent in nucleotide databases, perhaps more frequent than they should be with regard to the rarity of genotype G. Furthermore, a significant proportion of the A/G recombinant removes, as expected, the immunologically problematic HBe region of genotype G in the recombined progeny, and a certain number of them (GeneBank accessions HM484898, HM484906, and HM48492) are compatible with the formation of genotype I (Figure  3 )  [30]. The final molecular event that led to the generation of the new genotype I must be, therefore, a recombination between this putative ancestral A/G recombinant with a representative genotype C (Figure  3 ). This recombination event removed, for the second time, the HBe region to replace the genotype A version with the more efficient genotype C version.
Genetic Variations Observed on HBV Genotype I Genome Full sequences (n = 121, Table  S1 ) retrieved in the database were investigated for the presence of clinically relevant susceptible sequence variations affecting the pre-core region, the basal core promoter, the negative regulatory element, the pre-S region, the major hydrophilic region, or the reverse transcriptase domain of the polymerase gene  [49, 50]. All significant variations are summarized in Table  2. The examination of the table indicates that the currently available strains of genotype I are, in general, mildly mutated when compared with what we know about the genotype B and C also present in the same region. It is known that relevant genetic variations tend to accumulate in each patient with time and with the progression of liver disease  [51] [52] [53].
The unique diffraction geometry of ESRF beamline ID06-LVP offers continuous static 2D or azimuthally resolving data collections over all accessible solid angles available to the tooling geometry. The system is built around a rotating custom-built Pilatus3 CdTe 900k-W detector from Dectris, in a configuration equivalent to three butted 300k devices. As a non-standard geometry, here the method of alignment, correction and subsequent integration for any data collected over all solid angles accessible, or over any azimuthal range contained therein, are provided and illustrated by parameterizing and extending existing pyFAI routines. At 1 integrated intervals, and typical distances (2. 0 m), the system covers an area of near 2. 5 m 2 (100 Mpx square equivalent), to 0. 65 A ˚resolution, at 53 keV from a total dataset of some 312 Mpx.
In early testing, this was achieved by step-scanning a scintillation counter in a composite chord of linear translation and a rotation stage to recover a 2-orthogonal incidence angle. This was advantageous in terms of ultimate resolution as gauge volumes provided by the receiving and detector slit-pairs were, generally, significantly smaller than sample diameters at interesting wavelength and 2 combinations. This situation provided a good level of background rejection from the multitude of potential scatterers that compose a large-volume assembly (e. g. Guignard & Crichton, 2014; Bernal et al. , 2014; Crichton et al. , 2016). Such a setup, at long distance, also has high inherent resolution, but with the evident downside that such resolutions require sampling at compatible rates. Data collections were, therefore, time-consuming (hours) and the whole system tedious to align in spite of the robustness of the basic unit and its simplicity (no more complicated than a KF-40 vacuum tube with two sets of vacuum-compatible JJ X-ray slits at either end, with coaxial Tl:NaI scintillator detector).
Thus, with a suitable total exposure time selected and an internal 10 Hz frame rate, full solid-angle data collection could be collected in a, motor-compatible, minute and required only a TTL trigger to initiate. This negated any requirement for a continuous collection mechanism with synchronized motors and integration into ESRF data collection policies. A typical data collection, viz. at 1 image revolution À1 , consisted of some 512 lines (mod 32) of azimuthal information and was significantly better resolving than other similar devices. Related data collection strategies were also being conducted elsewhere with 1D detection that also claimed increased resolution over flatplate equivalents for diamond-anvil-cell collections  (Fisch et al. , 2015). This was not without its drawbacks; prime here was the data being native in (, 2) pixel (px) space, i.
e. polar, rather than in Cartesian (2, 2)-equivalent px. They also did not extend to 0 2, so no unique solution can be found for beam-centre and distance calibration by typical methods (there is no ellipse to fit). Indeed, despite these 2D data being instantly inspected, they were not directly fittable with most diffraction-based analyses as a 2D dataset, as this still requires pixel-to-2 integration, which suffers from the same issue. Versions 16 et seq of Fit2D  (Hammersley, 2016)  incorporated new developments to deal with these issues. These included polar-specific calibration routines that could estimate distance independent from beam centre, and correct for beam and rotation axis offsets, in addition to the usual tilt and rotation corrections shared with conventional flat-plate Cartesian collections.
We cannot simply stack adjacent 2D images to produce a time (etc. ) series output of the 2D result: we must integrate to 1D patterns first. This is trivial, but it changes the workflow and necessitates an efficient, live, monitoring tool. The beamline provides this through wipow (of VF-N). Considering solid-angle data, at low scattering angles each static frame shares azimuthal contributions from the adjacent 15, or more, frames, but at highest angles from potentially only the next frames. Clearly, then, tilt and offset corrections are required before bi-dimensional intensity estimation per (2, ) bin. When the native single image increased from only 1D binning (1539 px Â 512 lines) without necessity for intermediate frame integration and correction to 900k px Â 360 frames (with significantly higher bit depth) requiring correction before binning, a much more significant computational task is required to produce a fittable dataset.
On the other hand, for static time-series collections, given that native Dectris images are Cartesian irrespective of the detector orientation in space, it remains a planar detector and can be integrated directly with standard 2D software; e. g. Fit2D, pyFAI  (Ashiotis et al. , 2015) , Dioptas (Prescher & Prakapenka, 2015), etc. However, the results obtained will not be The image on the left, with open tooling and the bottom anvil in the reset position (fully extended at about À 1. 5 mm from the centre), shows the view upstream of the primary and wedge cut-outs, here with a carbide second-compression stage in 6/8 geometry. The maximum extent of the solid angle visible is limited by the anvil gap and the cut-out half-angle (13. 5 ) and ! rotation, to a maximum of $ 22 , in the horizontal plane.
, as any tilts, or rots, will be defined about the beam centre, or point of normal incidence, rather than about the rotation centre. As bidimensional binning and integration (regrouping) will take minutes to complete, an on-the-fly precis of the current solidangle dataset is readily available by accumulating near-beamheight regions of interest from adjacent frames in order to construct a direct polar image for inspection, or through integrating a region of interest over all the original images. This is of particular interest to stress-strain deformation experiments, which, due to practicalities in data collection rates, simply have no time for inspecting full integrations.
Data correction A Jupyter Notebook-based Python script (see example in Section S1 of the supporting information) has been prepared around the pyfai-multigeometry module, with necessary input from single. geometry_refinement at initial stages and follows the general goniometer calibration scheme illustrated by  Kieffer et al. (2020). Using the frame collected about 270 , an initial assessment of fit parameters and control points are made at all azimuthal positions, with the = 270 data returned for inspection (Fig. 4 ). A first round of refinement is then made at an assumed fixed orthogonal detector location through refinement of distance and beam centre only (Fig. 5 ) using the static calibration as initial. At this stage it is clear that there is a periodic behaviour in the distance returned, that is cyclic and is in phase with the estimation of the poni2 parameter.
A constrained refinement of all expressions and terms results in a root mean square value of 2 Â 10 À9 to 8 Â 10 À10 for a reduced dataset (five decades improved over initial calibrations), as shown in Fig. 6. This information, together with the detector geometry, is sufficient to describe the location of idealized standard reference material (SRM) peak locations on the detector at any position, to further improve control point collection (with or without further extraction for problematic frames) and for final unconstrained refinement of all parameters over all frames. From the output, it is clear that there is significant correlation and periodic behaviour, and that we are at the limit of pixelation in the results, e. g. in the envelope depicted by poni2 and rot1, Fig. 5 , that correlate with variation in distance estimates per.
Sequencing was performed with a MiSeq sequencer (Illumina), according to the manufacturer's protocols. Raw sequence data in FASTQ format were analyzed using the following variant callers and as previously described  16, 53  : BWA v-0. 7. 12 (read alignment); Picard-tools (marking duplicates); samtools v-1. 2; v-1. 139 (BAM file creation); GATK HaplotypeCaller v-3. 4-46 GRVC v-1. 1; snpEff v-4. 0 (variant calling). Run quality control included %DP_100X (>95%), %DP_200X (>90%), number of reads per sample and % reads q30 forward and reverse (>85%), read quality mean (>30) and percentage of mapped reads (>75%). A minimum of ten reads was required for variant calling. Results were analyzed after alignment of the reads using two dedicated pipelines, SOPHiA DDM (Sophia Genetics) and an in-house software GRIO-Dx.
Events on genomic regions reported to be prone to recurrent artifact  59  (chr6 < 58 Mb, chr7 > 61 Mb and chr2 > 50 Mb) were also filtered, and those where manual inspection demonstrated noise or sparsity in the array. To find common genomic lesions on a focal and arm level, Infinium OmniExpress arrays were initially processed with Illumina Genome Studio v2. 0. 4. Following this, LRR data were extracted for all probes and array annotation was obtained from Illumina (InfiniumOmniExpress-24v1-3_A1). LRR data were then smoothed and segmentation called using the CBS algorithm from the DNACopy 61,62 v1. 60. 0 package in R. A minimum number of five probes was required to call a segment, and segments were analyzed using GenomicRanges 63 v1. 38. 0. Definitions of amplification, gain, loss and deletion events were as outlined in ref.
Targeted single-cell genotyping analysis Data preprocessing. For each cell, the FASTQ file containing both targeted gDNA and cDNA-derived sequencing reads was aligned to the human reference genome (GRCh37/hg19) using Burrows-Wheeler Aligner (BWA v0. 7. 17) and STAR  67  (v2. 6. 1d). Custom perl scripts were used to demultiplex the gDNA and mRNA reads in the BAM file into separate SAM files based on targeted-sequencing primer coordinates (https://github. com/albarmeira/TARGET-seq). Next, Samtools 68 (v1. 9) was used to concatenate the BAM header to the resulting SAM files before reconverting the SAM file to BAM format, which was subsequently sorted by genomic coordinates and indexed. Both gDNA and mRNA reads were tagged with the cell's unique identifier using Picard (v2. 3. 0) 'AddOrReplaceReadGroups' and duplicate reads were subsequently marked using Picard 'MarkDuplicates'.
Then, SCITE was used (git revision 2016b31, downloaded from https://github. com/cbg-ethz/SCITE. git; ref. 73) to sample 1,000 mutation trees from the posterior for every single-cell genotype matrix corresponding to a particular patient, where all possible mutation trees are equally likely a priori. For patients in which several disease time points were available, all time points were merged for SCITE analysis. As parameters for every SCITE run '-fd 0. 01' (corresponding to the allelic dropout (ADO) rate of reference allele in our adapted SCITE model), '-ad 0. 01' (corresponding to the ADO of the alternate allele), a chain length (-l) of 1e6 and a thinning interval of 1 while marginalizing out cell attachments (-p 1 -s) were used. To summarize the posterior tree sample distribution, the number of times a particular sample matched each tree was computed.
Computational validation of TP53 bi-allelic status from single-cell targeted genotyping datasets To further validate the bi-allelic status of TP53 mutations in our dataset, the patterns of ADO in TARGET-seq single-cell genotyping data from patients carrying at least two different TP53 mutations were investigated (n = 6; Extended Data Fig. 1j ). To test the hypothesis that the observed TP53-WT/TP53homozygous (TP53-WT/HOM; or (0,2)) cells are the result of a chromosomal loss (and therefore, in different alleles), the following null hypothesis (H 0 ) was formulated: observed TP53-WT/HOM cells are double ADO events. Under H 0 , every TP53-WT/HOM cell (0,2), TP53-HOM/ WT cell (2,0), TP53-HOM/HOM (2,2) as well as an unknown number of TP53-WT/WT (0,0) are the result of a TP53-HET/HET (1,1) cell undergoing ADO at both sites.