dataesr/scientific-paragraphs-categorization huggingface dataset:
This rich and productive environment has made Python popular for scientific research. To complement this facility for exploratory work and rapid prototyping, NumPy has developed a culture of employing time-tested software engineering practices to improve collaboration and reduce error  [31]. This culture is not only adopted by leaders in the project but also enthusiastically taught to newcomers. The NumPy team was early in adopting distributed revision control and code review to improve collaboration on code, and continuous testing that runs an extensive battery of automated tests for every proposed change to NumPy. The project also has comprehensive, high-quality documentation, integrated with the source code  [32, 33, 34]. This culture of using best practices for producing reliable scientific software has been adopted by the ecosystem of libraries that build on NumPy.
For example, in a recent award given by the Royal Astronomical Society to Astropy, they state: The Astropy Project has provided hundreds of junior scientists with experience in professional-standard software development practices including use of version control, unit testing, code review and issue tracking procedures. This is a vital skill set for modern researchers that is often missing from formal university education in physics or astronomy. Community members explicitly work to address this lack of formal education through courses and workshops  [35, 36, 37]. The recent rapid growth of data science, machine learning, and artificial intelligence has further and dramatically boosted the usage of scientific Python. Examples of its significant application, such as the eht-imaging library, now exist in almost every discipline in the natural and social sciences.
Array proliferation and interoperability NumPy provides in-memory, multidimensional, homogeneously typed (i. e. , single pointer and strided) arrays on CPUs. It runs on machines ranging from embedded devices to the world's largest supercomputers, with performance approaching that of compiled languages. For most its existence, NumPy addressed the vast majority of array computation use cases. However, scientific data sets now routinely exceed the memory capacity of a single machine and may be stored on multiple machines or in the cloud. In addition, the recent need to accelerate deep learning and artificial intelligence applications has led to the emergence of specialized accelerator hardware, including graphics processing units (GPUs), tensor processing units (TPUs), and field-programmable gate arrays (FPGAs).
Due to its in-memory data model, NumPy is currently unable to utilize such storage and specialized hardware directly. However, both distributed data and the parallel execution of GPUs, TPUs, and FPGAs map well to the paradigm of array programming: a gap, therefore, existed between available modern hardware architectures and the tools necessary to leverage their computational power. The community's efforts to fill this gap led to a proliferation of new array implementations. For example, each deep learning framework created its own arrays; PyTorch  [38] , Tensorflow  [39] , Apache MXNet  [40] , and JAX arrays all have the capability to run on CPUs and GPUs, in a distributed fashion, utilizing lazy evaluation to allow for additional performance optimizations. SciPy and PyData/Sparse both provide sparse arrays-which typically contain few non-zero values and store only those in memory for efficiency.
In addition, there are projects that build on top of NumPy arrays as a data container and extend its capabilities. Distributed arrays are made possible that way by Dask, and labeled arrays-referring to dimensions of an array by name rather than by index for clarity, compare x[:, 1] vs. x. loc[:, 'time']-by xarray  [41]. Such libraries often mimic the NumPy API, because it lowers the barrier to entry for newcomers and provides the wider community with a stable array programming interface. This, in turn, prevents disruptive schisms like the divergence of Numeric and Numarray. But exploring new ways of working with arrays is experimental by nature and, in fact, several promising libraries-such as Theano and Caffe-have already ceased development. And each time that a user decides to try a new technology, they must change import statements and ensure that the new library implements all the parts of the NumPy API they currently use.
Ideally, operating on specialized arrays using NumPy functions or semantics would simply work, so that users could write code once, and would then benefit from switching between NumPy arrays, GPU arrays, distributed arrays, and so forth, as appropriate. To support array operations between external array objects, NumPy therefore added the capability to act as a central coordination mechanism with a well-specified API (Fig. 2 ). To facilitate this interoperability, NumPy provides "protocols" (or contracts of operation), that allow for specialized arrays to be passed to NumPy functions (Fig. 3 ). NumPy, in turn, dispatches operations to the originating library, as required. Over four hundred of the most popular NumPy functions are supported. The protocols are implemented by widely used libraries such as Dask, CuPy, xarray, and Py-Data/Sparse.
NumPy was initially developed by students, faculty, and researchers to provide an advanced, opensource array programming library for Python, which was free to use and unencumbered by license servers, dongles, and the like. There was a sense of building something consequential together, for the benefit of many others. Participating in such an endeavor, within a welcoming community of like-minded individuals, held a powerful attraction for many early contributors. These user-developers frequently had to write code from scratch to solve their own or their colleagues' problems-often in low-level languages that precede Python, like Fortran  [46]  and C. To them, the advantages of an interactive, high-level array library were evident. The design of this new tool was informed by other powerful interactive programming languages for scientific computing such as Basis  [47] , Yorick  [48] , R  [49] , and APL  [50] , as well as commercial languages and environments like IDL and MATLAB.
With this funding, the project was (and is) able to have sustained focus over multiple months to implement substantial new features and improvements. That said, it still depends heavily on contributions made by graduate students and researchers in their free time. NumPy is no longer just the foundational array library underlying the scientific Python ecosystem, but has also become the standard API for tensor computation and a central coordinating mechanism between array types and technologies in Python. Work continues to expand on and improve these interoperability features. Over the next decade, we will face several challenges. New devices will be developed, and existing specialized hardware will evolve, to meet diminishing returns on Moore's law. There will be more, and a wider variety of, data science practitioners, a significant proportion of whom will be using NumPy.
Methods We use Git for version control and GitHub as the public hosting service for our official upstream repository (https://github. com/numpy/numpy). We each work in our own copy (or fork) of the project and use the upstream repository as our integration point. To get new code into the upstream repository, we use GitHub's pull request (PR) mechanism. This allows us to review code before integrating it as well as to run a large number of tests on the modified code to ensure that the changes do not break expected behavior. We also use GitHub's issue tracking system to collect and triage problems and proposed improvements.
Library organization Broadly, the NumPy library consists of the following parts: the NumPy array data structure ndarray; the so-called universal functions; a set of library functions for manipulating arrays and doing scientific computation; infrastructure libraries for unit tests and Python package building; and the program f2py for wrapping Fortran code in Python  [55]. The ndarray and the universal functions are generally considered the core of the library. In the following, we give a brief summary of these components of the library. Core. The ndarray data structure and the universal functions make up the core of NumPy. The ndarray is the data structure at the heart of NumPy. The data structure stores regularly strided homogeneous data types inside a contiguous block memory, allowing for the efficient representation of ndimensional data.
Infrastructure libraries. NumPy provides utilities for writing tests and for building Python packages. The testing subpackage provides functions such as assert allclose(actual, desired) that may be used in test suites for code that uses NumPy arrays. NumPy provides the subpackage distutils which includes functions and classes to facilitate configura-tion, installation, and packaging of libraries depending on NumPy. These can be used, for example, when publishing to the PyPI website. F2PY. The program f2py is a tool for building NumPy-aware Python wrappers of Fortran functions. NumPy itself does not use any Fortran code; F2PY is part of NumPy for historical reasons.
Central role NumPy plays a central role in building and standardizing much of the scientific Python community infrastructure. NumPy's docstring standard is now widely adopted. We are also now using the NEP system as a way to help coordinate the larger scientific Python community. For example, in NEP 29, we recommend, along with leaders from various other projects, that all projects across the Scientific Python ecosystem adopt a common "time window-based" policy for support of Python and NumPy versions. This standard will simplify downstream project and release planning.
Wheels build system A Python wheel  [58]  is a standard file format for distributing Python libraries. In addition to Python code, a wheel may include compiled C extensions and other binary data. This is important, because many libraries, including NumPy, require a C compiler and other build tools to build the software from the source code, making it difficult for many users to install the software on their own. The introduction of wheels to the Python packaging system has made it much easier for users to install precompiled libraries. A GitHub repository containing scripts to build NumPy wheels has been configured so that a simple commit to the repository triggers an automated build system that creates NumPy wheels for several computer platforms, including Windows, Mac OSX and Linux. The wheels are uploaded to a public server and made available for anyone to use.
The default bit generator is a 64-bit implementation of the Permuted Congruential Generator  [62]  (PCG64). The three other bit generators are a 64bit version of the Philox generator  [63]  (Philox), Chris Doty-Humphrey's Small Fast Chaotic generator  [64]  (SFC64), and the 32-bit Mersenne Twister  [65]  (MT19937) which has been used in older versions of NumPy. 9 Bit generators provide functions, exposed both in Python and C, for generating random integer and floating point numbers. The Generator consumes one of the bit generators and produces variates from complicated distributions. Many improved methods for generating random variates from common distributions were implemented, including the Ziggurat method for normal, exponential and gamma variates  [67] , and Lemire's method for bounded random integer generation  [68].
Acknowledgments We thank  Ross Barnowski ,  Paul Dubois ,  Michael Eickenberg , and  Perry Greenfield , who suggested text and provided helpful feedback on the manuscript. We also thank the many members of the community who provided feedback, submitted bug reports, made improvements to the documentation, code, or website, promoted NumPy's use in their scientific fields, and built the vast ecosystem of tools and libraries around NumPy. We also gratefully acknowledge the Numeric and Numarray developers on whose work we built. Jim Hugunin wrote Numeric in 1995, while a graduate student at  MIT. Hugunin based his package on previous work by  Jim Fulton , then working at the  US Geological Survey , with input from many others. After he graduated,  Paul Dubois  at the  Lawrence Livermore National Laboratory  became the maintainer.
The six most stable participants at pre-tests (characterized by an individual coefficient of variation in the range 0. 33-2. 75%) were set at the same swinging frequency of 5. 34 rad/s , while the seventh participant (the most unstable, coefficient of variation 4. 50% ) was set at a different frequency ( 6. 28 rad/s ). This condition was used to test to what extent and under which interaction topology the introduction of one outlier would destabilize an otherwise homogeneous network. • Natural. Here, all the additional masses were removed, and the 7 participants performed the task at their own natural frequency, ranging from 5 rad/s to 6. 13 rad/s. Data processing. Each pendulum was equipped with a calibrated analog potentiometer to record its angular motion at f s = 200 Hz. The acquisition was performed using the Matlab software, recording the signals of the seven pendulums simultaneously.
The position time series were then smoothed out through a Moving Average filter with a time window of 10 samples ( t w = 0. 05 s ). The Hilbert transform method was applied on the filtered positions to extract the time series of the phases. Data analysis and relevant metrics. Denoting T as the number of samples in each trial and N as the number of players, we can define θ i (k) as the phase of the i-th pendulum at the k-th sampling instant, for all i = 1,. , N and k = 1,. , T. The following set of metrics were used to capture the relevant features of the human group interactions recorded in our experiments: • Individual frequencies and group frequency. At each time step, we computed the angular velocity of each player by applying finite differences (forward Euler method) to the extracted phases: with �t = 1/f s being the sampling time.
Acknowledgements B. B. , C. CO. , S. B. , and S. P. were supported by grant  H2020-FETPROACT-2018-01  "EnTimeMent". The authors wish to acknowledge support from the  Italian-French University VINCI  Program 2017 that supported the PhD Scholarship of C. C. P. D. was supported by the programme " STAR 2018 " funded by the  University of Naples Federico II  and  Compagnia di San Paolo ,  Istituto Banco di Napoli ,  Fondazione , project  ACROSS. M. d. B wishes to acknowledge support from the  Internationalization Program of the University of Naples Federico II, Italy supporting the International agreement between Naples and University of Montpellier, France.
The posterior distributions are sampled using an affine invariant Markov chain Monte Carlo ensemble sampler as implemented in the Python emcee package  (Foreman-Mackey et al. , 2013). While it is also possible to estimate the posterior distributions from numerically solving the forward problem, each forward model evaluation from t = 0 up to the point where V > 1 mm s -1 takes several tens of seconds on a single CPU. The practical reason for this is that the fault is critically stressed and hence requires small time step evaluations to ensure sufficient numerical accuracy and stability. 3 Analysis of fluid injection tests of  Cappa et al. (2019).
Indeed, when we perform the inversion of the dilatancy-slip data from the field experiment, we find median values of L = 4. 9 ± 1. 0 mm, H = 13. 0 ± 2. 5, and φ c -φ 0 = 0. 082 ± 0. 016 (Fig. 6 ). While these other values seem entirely reasonable, the inferred value of H is well above the estimated upper bound of √ 3/2φ c ≈ 2. 9. This suggests that the CNS model is unable to explain the relationship between fault slip and fault opening in this experiment. In the CNS model, dilatancy is envisioned to originate from grain sliding and rolling, neighbour swapping, and "jostling", which requires a volume increase of the gouge to accommodate. However, the model fault itself is mathematically planar, and so no dilatancy occurs due to geometric constraints. In the case of a macroscopically non-planar fault geometry (as is inevitable for tectonic faults;  Candela et al.
When the same inversion approach was applied to a decametric-scale field injection experiment, we found that the inferred parameters fell outside of the feasible range of values, highlighting the relevance of other mechanisms, such as fault structure and poro-elastic effects, in this scenario. The excellent agreement between the CNS model and the laboratory data allows us to interpret the dynamics of the fault in terms of volumetric deformation (porosity changes). By doing so, we circumvent the velocity dependence of the rate-and-state friction parameters a, b, and D c , which increases the predictive power of numerical models of natural faults. Adopting the CNS model expedites the extrapolation of laboratory results to nature and permits better assessment of the applicability of the model and accuracy of the parameter values.
Code and data availability. A Python script that reproduces the results and figures in this paper, along with the laboratory and field injection data, is available at https://doi. org/10. 6084/m9. figshare. 12613007  (van den Ende et al. , 2020). Author contributions. MPAvdE conceptualised the study and performed the analyses. MMS and FC provided the laboratory and field data. JPA supervised MPAvdE. All authors discussed and prepared the contents of the paper. Special issue statement. This article is part of the special issue "Thermo-hydro-mechanical-chemical (THMC) processes in natural and induced seismicity". It is a result of the 7th International Conference on Coupled THMC Processes, Utrecht, Netherlands, 3-5 July 2019.
Acknowledgements. The authors thank the topical editor  André Niemeijer  and two anonymous reviewers for their encouraging and constructive comments on the paper. Martijn P. A. van den Ende ,  Frédéric Cappa , and  Jean-Paul Ampuero  are supported by  French government  through the  UCA JEDI Investments  in the  Future  project managed by the  National Research Agency (ANR)  with the reference number  ANR-15-IDEX-01. Financial support. This research has been supported by the  Agence Nationale de la Recherche  (grant no. ANR-15-IDEX-01 ). Review statement. This paper was edited by  André R. Niemeijer  and reviewed by two anonymous referees.
The JT-60SA cryogenic system was commissioned in 2016 in closed loop, without the cryogenic users (superconducting magnets, current leads, thermal shields). The first plasma operation is expected in 2020. This paper updates the heat load profiles resulting from the cooling loop of TF magnets, and received by the refrigerator and its thermal damper. The heat load profiles are calculated through thermal-hydraulic simulations of the magnets and the associated cryo-distribution, also named as supercritical helium loops. This update was performed by taking into account new data from the TF magnets (measured pressure drops, updated heat loads coming from the plasma), as well as a more accurate thermal model of the TF magnet. Previous simulation had been performed using the Vincenta code in 2010 and were used for the cryogenic system acceptance tests.
The reliability and optimization of operation become challenging aspects to study with quick dynamic simulations. It requires simplified models for faster-than-real time calculations. Some methodologies have been developed and tested, for example for ITER TF and CS magnets based on Artificial Neural Network requiring training of the neural network on full sets of simulations with detailed models  [26]. Simcryogenics developed by CEA for the cryo-distribution and the cryoplant is addressing the critical requirement of dynamic simulations for control purposes with simplified models. Recent modelling work with Simcryogenics demonstrated the relevance of the thermal-hydraulic code developed by CEA for modelling the cryodistribution and the cable in conduit conductors (CICC), in order to evaluate the heat load profile to the cryoplant  [7].
Description of the Vincenta model A model of the loop 1 was performed using the Vincenta code V6. 0 in 2010  [5]. The Vincenta code is a thermal-hydraulic simulation code for superconducting magnets and their cryo-distribution. This code was used to model the dynamic behavior of the supercritical loop HELIOS (Helium Loop for hIgh LOads Smoothing) under pulsed heat loads  [6]. Since the comparison to experimental results gave very satisfying results  [6] , the Vincenta code was chosen to benchmark the model of the loop 1 performed using the Simcryogenics library  [7]. The results obtained using Vincenta in 2010 are considered in the present paper. Since 2010, CEA/dSBT has developed its own modelling tool Simcryogenics, which was chosen for the present modelling work. This tool is more flexible allowing the reduction of the calculation time (typically 10 min for the loop), the study of various dynamic scenarios including the refrigerator (e.
Description of the Simcryogenics models The loop1 was modelled using the Simcryogenics library for MATLAB/Simulink, as schematically shown in Fig. 2. 1-dimensional pipes, i. e. pipes consisting of volumes distributed along the flow direction, were used to model the supply line, return line, TF CICC as well as TF and CS structures. The two exchangers HX1 and HX2 were considered as perfect heat exchangers, i. e. the outlet temperature was independent of flow conditions and set equal to the bath temperature. These exchangers were immersed into the thermal damper V700, which is a 4. 3 K saturated helium bath. The schematic is similar to that presented in  [7]  even though the library had been updated in order to manage flow reversal  [12]. Equivalent parallel channels were only modelled once and then multiplied.
This Simcryogenics model was built using the data that were available in 2010 and will be referred to as SC1 model in the following sections. The second one was an updated SC1 model, which was dedicated to the study of the different modifications in terms of heat transfer coefficient, friction factor, materials properties and non-uniformly distributed heat load distribution on the TF CICC. This model was also modified in order to model the inter-turn thermal coupling, as defined in section 4. 6. In the following sections, the updated model will be referred to as SC2 model.
Dimensions & materials for the TF CICC The parameters used to model the TF CICC are shown in Table  2. On SC2 model, the wetted perimeter, the helium cross-section area as well as the type and masses of materials were updated according to  [4]. As for the modified SC2 model dedicated to the study of the inter-turn thermal coupling, the bundle and the jacket with its insulation were modelled as two distinct masses, as described in section 4. 6. On Simcryogenics, the material properties of copper, stainless steel and epoxy were calculated using data from NIST. An updated value of 100 was chosen for the RRR of copper based on the measurement that were performed on the CICC copper and NbTi strands, i. e. ranges of 70-90 and 148-233 respectively  [15].
Benchmark of Simcryogenics and Vincenta results Under similar assumptions, the Vincenta code and the Simcryogenics library give similar results  [7]. As an update of the Simcryogenics library was performed  [12] , it was necessary to verify that the results obtained with SC1 model were similar to those obtained with the Vincenta code using the same input parameters. As shown in Fig. 8 , both results were in good agreement. For the different curves, the maximum absolute relative difference ranged from 0. 6% to 7. 5%, while the mean absolute relative difference ranged from 0. 1% to 2. 3%.