dataesr/scientific-paragraphs-categorization huggingface dataset:
Computationally intensive tasks such as time-stepping and linear algebra operators which are used in every single iteration must be offloaded to compiled extensions. This optimization strategy can be considered as the computational equivalent of the Pareto principle, also known as the 80/20 rule 2. The goal is to optimize such that "80 percent of the runtime is spent in 20 percent of the source code"  (Meyers 2012). Here, Cython  (Behnel et al. 2011a)  and Pythran  (Guelton 2018 ) compilers comes in handy. An example on how we use Pythran to reach similar performance than with Fortran by writing only Python code is described in the companion paper on fluidfft  (Mohanan et al. 2018). The result of using such an approach is studied in the forthcoming sections by measuring the performance of fluidsim.
Target audiences fluidsim is designed to cater to the needs of three kinds of audience. • Users, who run simulations with already available solvers. To do this, one needs to have very basic skills in Python scripting. • Advanced users, who may extend fluidsim by developing customized solvers for new problems by taking advantage of built-in operators and time-stepping classes. In practice, one can easily implement such solvers by changing a few methods in base solver classes. To do this, one needs to have fairly good skills in Python and in particular object-oriented programming. • Developers, who develop the base classes, in particular, the operators and time stepping classes. One may also sometime need to write compiled extensions to improve runtime performance. To do this, desirable traits include good knowledge in Python, Numpy, Cython and Pythran.
This metapaper is intended as a short introduction to fluidsim and its implementation, written mainly from a user-perspective. Nevertheless, we also discuss how fluidsim can be customized and extended with minimal effort to promote code reuse. A more comprehensive and hands-on look at how to use fluidsim can be found in the tutorials 3  , both from a user's and a developer's perspective. In the latter half of the paper, we shall also inspect the performance of fluidsim in large computing clusters and compare fluidsim with three different pseudo-spectral CFD codes.
Implementation and architecture New features were added over the years to the package whenever demanded by research interests, thus making the code very user-centric and function-oriented. This aspect of code development is termed as YAGNI, one of the principles of agile programming software development method, which emphasizes not to spent a lot of time developing a functionality, because most likely you aren't gonna need it. Almost all functionalities in fluidsim are implemented as classes and its methods are designed to be modular and generic. This means that the user is free to use inheritance to modify certain parts to suit one's needs, and avoiding the risk of breaking a functioning code.
Package organization fluidsim is meant to serve as a framework for numerical solvers using different methods. For the present version of fluidsim there is support for finite difference and pseudo-spectral methods. An example of a finite difference solver is fluidsim. solvers. ad1d which solves the 1D advection equation. There are also solvers which do not rely on most of the base classes, such as fluidsim. base. basilisk which implements a 2D adaptive meshing solver based on the CFD code Basilisk. The collection of solvers using pseudo-spectral methods are more feature-rich in comparison. The code is organized into the following sub-packages: • fluidsim. base: contains all base classes and a solver for the trivial equation ∂ t û = 0. • fluidsim. operators: specialized linear algebra and numerical method operators (e.
g. , divergence, curl, variable transformations, dealiasing). • fluidsim. solvers: solvers and postprocessing modules for problems such as 1D advection, 2D and 3D Navier-Stokes equations (incompressible and under the Boussinesq approximation, with and without density stratification and system rotation), one-layer shallow water and Föppl-von Kármán equations. • fluidsim. util: utilities to load and modify an existing simulation, to test, and to benchmark a solver. Subpackages base and operators form the backbone of this package, and are not meant to be used by the user explicitly. In practice, one can make an entirely new solver for a new problem using this framework by simply writing one or two importable files containing three classes: • an InfoSolver class 4  , containing the information on which classes will be used for the different tasks in the solver (time stepping, state, operators, output, etc.
Profiling It is straightforward to perform profiling with the help of the cProfile module, available in the Python standard library. For fluidsim, this module has been conveniently packaged into a command line utility, fluidsim-profile. Here, we have analyzed both 2D and 3D Navier-Stokes solvers in Beskow, and plotted the results in Fig. 2  and Fig. 3  respectively. Functions which consume less than 2% of the total time are displayed within a single category, other. In Fig. 2    pure Python functions, i. e. functions not built using Cython and Pythran. Cython extensions are responsible for interfacing with FFT operators and also for the timestep algorithm. Pythran extensions are used to translate most of the linear algebra operations into optimized, statically compiled extensions. We also see that only 1.
3% of the time is not spent in the main six functions (category other in the figure). With 8 processes deployed in parallel, time spent in pure Python function increases to 1. 1% of the total time. These results show that during the optimization process, we have to focus on a very small number of functions. From Fig. 3  it can be shown that, for the 3D Navier-Stokes solver for all cases majority UP JORS software Latex paper template version 0. 1 of time is attributed to FFT calls. The overall time spent in pure Python function range from 0. 001% for 512 3 grid points and 2 processes to 0. 46% for 128 3 grid points and 8 processes. This percentage tends to increase with the number of processes used since the real calculation done in compiled extensions take less time. This percentage is also higher for the coarser resolution for the same reason.
CFD pseudo-spectral code comparisons As a general CFD framework, fluidsim could be compared to OpenFOAM (a CFD framework based on finite-volume methods). However, in contrast to OpenFOAM, the current version of fluidsim is highly specialized in pseudo-spectral Fourier methods and it is not adapted for industrial CFD. In this subsection, we compare fluidsim with three other open-source CFD pseudospectral codes 10  : • Dedalus  (Burns et al. n. d. )  is "a flexible framework for spectrally solving differential equations". It is very versatile and the user describes the problem to be solved symbolically. This approach is very different than the one of fluidsim, where the equations are described with simple Numpy code. There is no equivalent of the fluidsim concept of a "solver", i. e. a class corresponding to a set of equations with specialized outputs (with the corresponding plotting methods).
To run a simulation with Dedalus, one has to describe the problem using mathematical equations. This can be very convenient because it is very versatile and it is not necessary to understand how Dedalus works to define a new problem. However, this approach has also drawbacks: -Even for very standard problems, one needs to describe the problem in the launching script. -There is a potentially long initialization phase during which Dedalus processes the user input and prepares the "solver". -Even when a user knows how to define a problem symbolically, it is not simple to understand how the problem is solved by Dedalus and how to interact with the program with Python. -Since solvers are not implemented out-of-the-box in Dedalus, specialized forcing scheme or outputs are absent. For example, the user has to implement the computation, saving and plotting of standard outputs like energy spectra.
• SpectralDNS  (Mortensen & Langtangen 2016 ) is a "high-performance pseudospectral Navier-Stokes DNS solver for triply periodic domains. The most notable feature of this solver is that it is written entirely in Python using Numpy, MPI for Python (mpi4py) and pyFFTW. " Therefore, SpectralDNS is technically very similar to fluidsim. Some differences are that SpectralDNS has no object oriented API, and that the user has to define output and forcing in the launching script 11 , which are thus usually much longer than for fluidsim. Moreover, the parallel Fourier transforms are done using the Python package mpiFFT4py, which is only able to use the FFTW library and not other libraries as with fluidfft  (Mohanan et al. 2018 ). • NS3D is a highly efficient pseudo-spectral Fortran code. It has been written in the laboratory LadHyX and used for several studies involving simulations (in 3D and in 2D) of the Navier-Stokes equations under the Boussinesq approximation with stratification and system rotation  (Deloncle et al.
2008). It is in particular specialized in stability studies  (Billant et al. 2010 ). NS3D has been highly optimized and it is very efficient for sequential and parallel simulations (using MPI and OpenMP). However, the parallelization is limited to 1D decomposition for the FFT  (Mohanan et al. 2018). Another weakness compared to fluidsim is that NS3D uses simple binary files instead of HDF5 and NetCDF4 files for fluidsim. Therefore, visualization programs like Paraview or Visit cannot load NS3D data. As with many Fortran codes, Bash and Matlab are used for launching and postprocessing, respectively. In terms of user experience, this can be a drawback compared to the coherent framework fluidsim for which the user works only with Python. In contrast to the framework fluidsim for which it is easy to define a new solver for a new set of equations, NS3D is specialized in solving the Navier-Stokes equations under the Boussinesq approximation.
Also note that in several cases, the upper bound of time step is not first limited by the stability of the time scheme, rather by other needs (to resolve the fastest wave, accuracy, etc. ), so these benchmarks are representative of elapsed time for accurate real-life simulations. Bi-dimensional simulations. We first compare the elapsed times for two resolutions (512 2 and 1024 2 ) over a bi-dimensional space. The results are summarized in Table  2. The results are consistent for the two resolutions. fluidsim is the fastest code for these cases. Dedalus is more than one order of magnitude slower but as discussed earlier, the time stepping method is different. Also note that Dedalus has more been optimized for bounded domains with Chebyshev methods. The two other codes SpectralDNS and NS3D have similar performance: slightly slower than fluidsim and much faster than Dedalus.
Surprisingly, the Fortran code NS3D is slower (47%) than the Python code fluidsim. This can be explained by the fact that there is no specialized numerical scheme for the 2D case in NS3D, so that more FFTs have to be performed compared to SpectralDNS and fluidsim. This highlights the importance of implementing a well-adapted algorithm for a class of problems, which is much easier with a highly modular code as fluidsim than with a specialized code as NS3D. Tri-dimensional simulations. We now compare the elapsed times for ten RK4 time steps for a tri-dimensional case with a resolution 128 3. Dedalus is slow and does not seem to be adapted for this case so we do not give exact elapsed time for this code. SpectralDNS is slightly slower (11. 55 s) than the two other codes (9. 45 s for fluidsim and 9.
52 s for NS3D). This difference is mainly explained by the slower FFTs for SpectralDNS. Fig. 6  presents a more detailed comparison between NS3D (blue bars) and fluidsim (yellow bars). The total elapsed times is mainly spent in five tasks: FFTs, Runge-Kutta 4, curl, vector product and "projection". The times spent to perform these tasks are compared for the two codes. We see that FFTs in NS3D are very fast: the FFT execution is 0. 55 s longer for fluidsim (nearly 9% longer). This difference is especially significant for sequential run for which there is no communication cost involved in the FFT computation, thus making it the least favorable case for fluidsim. Indeed, MPI communications are input-output bounded tasks which are not faster in Fortran than in Python. This difference can partially be explained by the fact that in NS3D, all FFTs are inplace (so the input can be erased during the transform).
On one hand, this choice is good for performance and for a lower memory consumption. On the other hand, since the same variables are used to store the fields in real and in Fourier spaces, it makes the code harder to write, to understand and to modify. Since memory consumption in clusters is much less of a problem than in the past and that code simplicity is highly important for a framework like fluidsim, we choose to use out-of-place FFTs in fluidsim. Another factor is that the flag FFTW PATIENT is used in NS3D which leads to very long initialization and sometimes faster FFTs. Since we did not see significant speed-up by using this flag in fluidsim and that we also care about initialization time, this flag is not used and we prefer to use the flag FFTW MEASURE, which usually leads to similar performance.
Time stepping in NS3D is significantly slower than in fluidsim (0. 34 s 20 % slower). We did not find a performance issue in NS3D. The linear operators are slightly faster in fluidsim than in the Fortran code NS3D. This is because this corresponds to Pythran functions written with explicit loops (see  Mohanan et al. 2018). Although the FFTs are a little bit faster for NS3D, the total time is slightly smaller (less than 1% of the total time) for fluidsim for this case. These examples do not prove that fluidsim is always faster than NS3D or is as fast as any very well optimized Fortran codes. However, they do demonstrate that our very high-level and modular Python code is very efficient and is not slower than a well-optimized Fortran code.
Quality control fluidsim also packages unittests to go alongside the related modules. Throughout the development process it is made sure that all tests pass on priority to ensure that new changes to package does not damage existing functionality. It is also important to quantify the efficacy of the tests, and this is done by calculating the code coverage. Code coverage is the ratio of the number of lines tested by unittests over the total number of lines in the whole package. For the present version of fluidsim the code coverage is valued at approximately 60%. For fluidsim, the code coverage results are displayed at Codecov. We also try to follow a consistent code style as recomended by PEP (Python enhancement proposals) 8 and 257. This is also inspected using lint checkers such as flake8 and pylint among the developers.
Dependencies • Minimum: fluiddyn, Numpy, h5netcdf, fluidfft (and FFT libraries, see  Mohanan et al. 2018 ). • Optional: Scipy, mpi4py, Cython and Pythran, pulp. (3) Reuse potential fluidsim can be used in research and teaching to run numerical simulations with existing solvers. Its simplicity of use and its plotting capacities make it particularly adapted for teaching. fluidsim is used at LEGI and at KTH for studies on geophysical turbulence (see for example  Lindborg & Mohanan 2017). Since it is easy to modify any characteristics of the existing solvers or to build new solvers, fluidsim is a good tool to carry out other types of simulations for academic studies. The qualities and advantages of fluidsim (integration with the Python ecosystem and the FluidDyn project, documentation, reliability -thanks to unittests and continuous integration -, versatility, efficiency and scalability) make us think that fluidsim can become a true collaborative code.
Introduction For a long time, policy implementation studies have demonstrated that street-level organisations and frontline workers are central to the shaping of welfare policies. Through their practice, they contribute to the essence of politics, by determining who gets what and how  (Brodkin & Marston, 2013). In this context, frontline workers are CONTACT Clémence Ledoux clemence. ledoux@univ-nantes. fr Part of this research has been developed within the ANR Project PROFAM (Travailler entre PROfession et FAMille), supported by the French National Research Agency (ANR-17-CE26-0019). We are very grateful to the reviewer of Policy and Society, and Rossella Ciccia and Emanuela Lombardo for their stimulating comments on a previous version of this text. We also warmly thank Joanne Walker for English language advice.
Ethical guidelines and consent Within the scope of this mission, parents or legal guards who voluntarily referred to the Minister of the Interior through a freephone, asked the CPDSI's structure for help. The notion of referral caused several explicit acceptations: semi-structured interviews with parents, semi-structured interviews with radicalized minors, inter-parental collective interviews, inter-youth collective interviews, sharing of videos and information. During these different data collection spheres, parents deliberately took part in various types of recording: log files, screenshots, recordings of conservations from their private computers. An informed consent was signed by each one of them. Radicalized adults (18 or more) were also reported to authorities by their parents or spouse who asked for them to be taken charge of.
Indeed, they must distinguish what appertains to real engagement in this ideology, to a sort of conformism, identity uneasiness, search of protection (within the group) or a provocation, to elaborate an adapted professional position. They will measure out the emotional reassurance so that the "paranoid perspective" weakens, the proposition of a substitution group and the guidance in filling the radical group's loss, a religious alternative discourse and cognitive dissonances to provoke doubts on the ideology, according to each individual. Hence the NOORAPPLI 3D software is divided into 3 main chapters separating the three dimensions, with a final chapter about the assessment of the cognitive change's positive or negative evolution caused by these three dimensions. Each chapter is composed of several items.
Assessment of the end of the others' dehumanisation process (tables 39 to 43) In order to do so, NOORAPPLI 3D will again help professionals to verify the individual's perception of Christians (table  39 ), Jews (table  40 ), atheists (table  41 ), but also Muslims (table  42 ) and Salafism (table  43 ). EXAMPLE FOR THE ITEM "Perception of Christians"  Once these items are completed, the software processes the answers and provides a pie chart picturing the subject's state. Hence NOORAPPLI 3D helps to indicate which aspects that were not developed sufficiently, to adapt the disengagement/deradicalization program, to rectify it according to the first results at the halfway point and to take the best decisions to avoid recidivism. There follows the example of a young male of 16 years and a half, we named X, who was sentenced to 12 months in prison for participating to a terrorist initiative when he returned to France after spending three months in the Iraq-Syria zone.
d) Quotation resulting in a majority of +2 (in red): these answers mean that the individual's radicalization process is reinforced, as well as his double dehumanisation (of himself and future victims). It raises a question about his dangerousness level for himself and society. The follow-up needs to be implemented or adapted and reinforced. If the software finds too various results that spread on one item's columns, going from -2 to +2, it shows the professional that the quoted individual used a dissimulation strategy (takya) at some point. In the aforementioned example, the software displays a "pie chart" picturing X's actual state of mind (schema 5): EXAMPLE OF A FINAL SCORE CALCULATED BY NOORAPPLI 3D SOFTWARE Schema 5: Final score calculated by NOORAPPLI 3D software as a pie chart This pie chart first displays that their preliminary investigation is completed, thanks to the gathered elements from their colleagues of youth detention centres, X's parents, his girlfriend, mother of his child and from X himself (1,43% of unknown answers).
Acknowledgements The authors would like to thank the organizers of the 2017 CEMRACS for the opportunity to study at CIRM. This work was partially funded in the scope of the research project " Advanced techniques for nonlinear pricing and risk management of derivatives " under the aegis of the  Europlace Institute of Finance , with the support of  AXA Research Fund. Finally, we would like to thank the all funding sources that supported us during CEMRACS, in particular  University Paris Diderot.
We use these histograms as probabilistic locators of changes in slope (Fig. 3 ). The change point representations of the ATS3 and CO 2 time series are composed of a set of n specified change points X i = (x i , y i )|i = 1,. , n. We denote the vector of m time series observations o at time t O l = (t l , o l )|l = 1,. , m, and the scalar residual term J between observations and the linear interpolation between change points f y : J (X i ) = R T C -1 R; r l = f y (t l ) -o l l , ( 1 ) where R is the vector of residuals at each data point with components r l , and C is the covariance matrix of the residuals. The ATS3 series contains 1412 data points and the WD CO 2 series contains 320, each of which is considered in the residuals. We fix x 0 = t 0 and x n = t l , i. e. , the x values of the first and last change points are fixed to the first and last x values of the observation vector, with the y values allowed to vary.
7 ka. The corresponding CO 2 mode reaches its maximum at around 11. 15 ka. Visually, we might question why the CO 2 change point is deemed to most probably occur at 11. 15 ka, when a kink in the series appears to occur closer to 11. 5 ka. It is important to note that two minor spikes in probability appear to fit the rapid rise that occurs close to 11. 5 ka, and that the downward spike at the end of this rise indeed indicates that a small number of accepted iterations do indeed fit a change point here. Since the resolution of the WAIS Divide dataset decreases considerably after the Holocene onset, and only three points account for the majority of the rapid rise that occurs before the Holocene onset, most of the weight is given to the obvious line beginning at the ACR end. Adding an additional point should allow us to fit this slightly better; the CO 2 series is slightly better fit with nine points according to the individual BIC values, and there is more probability around the rapid rise in the nine-point fit, though the peak at 11.
The considerable difference at T1 between our result and that of  Parrenin et al. (2013)  is most likely due to the much higher resolution of the WD CO 2 time series. It is also possible that the result of  Parrenin et al. (2013)  was limited to a local probability maximum of this change point in the CO 2 series. The addition of the WD paleotemperature record and removal of the Vostok record from ATS3, the updated atmospheric CO 2 dataset, and our more generalized methodology are all, in part, responsible for the differences in computed time delays (the Supplement). This testifies to the importance of data resolution, methodological development, and chronological accuracy in the determination of leads and lags.