dataesr/scientific-paragraphs-categorization huggingface dataset:
At the same time, given the GPU accelerations, FlowPM is 4-20x faster than the corresponding python FastPM simulation depending on the resolution and compute distribution. However the main advantage of FlowPM is the differentiability of the simulation and natural interfacing with deep learning frameworks. Built entirely in TensorFlow, the simulations are differentiable with respect to every component. This allows for development of novel analytic methods such as simulations based inference and reconstruction of cosmological fields, that were hitherto intractable due to the multi-million dimensionality of these problems. We demonstrate with two examples, providing the logical code-snippets, how FlowPM makes the latter straightforward by using TensorFlow Estimator API to do optimization in 128 3 dimensional space.
It is also able to naturally interface with machine learning frameworks as a part of the forward model in this reconstruction. Lastly, due to its speed, it is able to achieve comparable accuracy to FastPM based reconstruction in 5 times lower wall-clock time, and 640 times lower computing time. FlowPM is open-source and publicly available on our Github repo at https://github. com/modichirag/flowpm. We provide example code to do forward PM evolution with single-grid and multi-grid force computation. We also provide code for the reconstruction with both the examples demonstrated in the pa-per. We hope that this will encourage the community to use this novel tool and develop scientific methods to tackle the next generation of cosmological surveys.
Acknowledgements We would like to thank  Mustafa Mustafa  and  Wahid Bhimji  at  NERSC  and  Thiru Palanisamy at Google  for the support in developing this. We would also like to acknowledge the gracious donation of TPU compute time from Google which was instrumental in developing and testing FlowPM for SIMD Mesh implementation. This material is based upon work supported by the  National Science Foundation  under Grant Numbers  1814370  and  NSF   1839217 , and by  NASA  under Grant Number  80NSSC18K1274. This research used resources of the  National Energy Research Scientific Computing Center (NERSC) , a  U. S. Department of Energy Office of Science User Facility  operated under Contract No. DE-AC02-05CH11231.
The success of metaheuristic optimization methods has led to the development of a large variety of algorithm paradigms. However, no algorithm clearly dominates all its competitors on all problems. Instead, the underlying variety of landscapes of optimization problems calls for a variety of algorithms to solve them efficiently. It is thus of prior importance to have access to mature and flexible software frameworks which allow for an efficient exploration of the algorithm design space. Such frameworks should be flexible enough to accommodate any kind of metaheuristics, and open enough to connect with higherlevel optimization, monitoring and evaluation softwares. This article summarizes the features of the Paradiseo framework, a comprehensive C++ free software which targets the development of modular metaheuristics.
In this article, we summarize our efforts towards this goal, in the guise of the Paradiseo project. The Paradiseo framework is a 22 years old effort which aims at developing a flexible architecture for the generic design of metaheuristics for hard optimization problems. It is implemented in C++, a very mature object-oriented programming language,which is probably one of the fastest, if not the fastest, object-oriented programming platforms on the market  [19, 30, 28]. It is also highly portable and benefits from very extensive tooling as well as an active community. Paradiseo is released as a free and opensource software, under the LGPL-v2 and CeCILL licenses (depending on the module). Its development is open and the source code is freely available on the Inria 1 and Github 2 code repositories.
History The "Evolving Objects" (EOlib, then simply EO) framework was started in 1999 by the Geneura team at the University of Granada, headed by Juan Julián Merelo. The development team was then reinforced by Maarten Keijzer, who designed the current modular architecture, and Marc Schoenauer  [21]. Later came Jeroen Eggermont, who, among other things, did a lot of work on genetic programming, Olivier König, who did a lot of useful additions and cleaning of the code, and Jochen Küpper. The Inria Dolphin team, headed by El-Ghazali Talbi, did a lot of contributions starting from around 2003, on their own module collection called Paradiseo. Thomas Legrand worked on particle swarm optimization, the regretted Sébastien Cahon and Nouredine Melab worked on parallelization modules  [7, 6, 4, 5]. Arnaud Liefooghe and Jérémie Humeau worked a lot on the multi-objective module  [24]  and on the local search one along with Sébastien Verel  [18].
In the same team, C. FC. 3  and Jean-Charles Boisson made significant contributions. The (then) EO project was taken over by Johann Dreo, who worked with the help of Caner Candan on adding the EDO module. Johann and Benjamin Bouvier have also designed a MPI parallelization module, while Alexandre Quemy also worked on parallelization code. In 2012, the two projects (EO and Paradiseo) were merged into a single one by Johann Dreo, Sébastien Verel and Arnaud Liefooghe, who have been acting as maintainers ever since. In 2020, automated algorithm selection design and binding toward the IOHprofiler validation tool were added by Johann Dreo. Along the life of the project, several spin-off software have been developed, among which a port of the EO module in Java  [1] , another one in ActiveX 4  ; GUIDE, a graphical user interface for assembling algorithms  [10]   5  , and EASEA, a high-level declarative language for evolutionary algorithm specification  [9] , which later became independent  [26]  of the specific library.
Related Frameworks The 1998's version of the hitch-hiker's guide to evolutionary computation (frequently asked question in the comp. ai. genetic Usenet newsgroup 6  ) already Y Y N Y Y Y Y N Y N DEAP Python 2020 LGPLv3 45 9 Y N N N Y Y N Y N Y N CIlib Scala 2021 Apachev2 17 4 Y N N N N N N N N ? N HeuristicLab C# 2021 GPLv3 20 150 Y N Y Y Y Y N Y ~Y N Clojush Clojure 2020 EPLv1 17 19 Y N N N N N N N N N N lists 57 software packages related to the implementation of evolutionary algorithms (among which EOlib, the ancestor of Paradiseo). Most of those software are now unmaintained or impossible to find. There has been, however, a constant flow of new frameworks, library or solvers every year, for decades. We were able to find at least 47 of them readily available on the web 7. Among those projects, only 8 met all the following criteria:   1 , where the number of lines of code was computed with the cloc tool 9.
Note that for HeuristicLab, the code for the GUI modules was excluded from the count. The GPGPU module of Paradiseo  [27]  is not counted either, as it is not maintained anymore. The number of contributors has been retrieved from the code repository's commit histories, which underestimates the number of people involved in the case of Paradiseo; the extracted number is however kept, for fairness in comparison with the other frameworks, that might face a similar bias. Among the software close in features to Paradiseo, ECF has not been updated in 4 years. ECJ, jMetal edu/pub/doc/EC/FAQ/www/Q20. htm 7 Paradiseo, jMetal, ECF, OpenBeagle, Jenetics, ECJ, DEAP, CIlib, GP. NET, DGPF, JGAP, Watchmaker, Gen-Pro, GAlib, HeuristicLab, PyBrain, JCLEC, GPE, JGAlib, pycma, PyEvolve, GPLAB, Clojush, µGP, pySTEP, Pyvolution, PISA, EvoJ, Galapagos, branecloud, JAGA, PMDGP, GPC++, PonyGE, Platypus, DCTG-GP, Desdeo, PonyGE2, EvoGrad, HyperSpark, Nevergrad, Pagmo2, LEAP, Operon, EMILI, pso-de-framework, MOACO.
For instance, an eoSelectOne exposes the interface to pick a solution within a population: const EOT& operator()( const eoPop<EOT>&). Generic type: Almost all the operators in Paradiseo are defined over a EOT template holding the encoding of a solution to the optimization problem. This allows for two crucial features: (i) the user can provide her own data structure, without major redesign, and (ii) any operator deep in the call tree may have access to any specific interface of the encoding  [32]. This was one of the earliest decisions taken, and was already presented in  [21]. Factory: As many operators are abstracted through their interfaces, Paradiseo provides ways to manage them as collections or high-level aggregates, so that the user does not have to manage the details. For instance, Paradiseo provides classical stopping criterion collections or on-the-fly instantiation (see also  Section 4.
Multi-Objective Optimization -MOEO The MOEO module adds the necessary features to handle multi-objective optimization  [8, 35] : Selection: Operators which combine the ones above in order to guide the population towards Paretooptimal solutions. Archive: Secondary population which maintains non-dominated solutions. Performance metrics: Quality indicators computed over populations or archives to measure solution quality in multi-objective optimization. More information about the Paradiseo-MOEO module, and how to design multi-objective local search and evolutionary algorithms in Paradiseo are detailed in  [24].
In that case, an algorithm instance is a combination of parameterized operators, with varying functions and/or parameters  11. Of course, considering the whole footprint of Paradiseo would allow for far larger design space. It is also worth noting that the hybridization of two algorithms in Paradiseo is as simple as encapsulating operators with a similar interface. For instance, it is straightforward to use a local search algorithm implemented with MO as a variation operator of an evolutionary algorithm implemented with EO, then ending up with a so-called memetic algorithm. Moreover, this modular architecture facilitates a fair comparison of algorithms in practical use cases, where wall-clock performance is of prior importance; e. g. , for applications involving interactions with a human. In such a case, having a common code base helps conducting more unbiased studies.
Fast Computations Paradiseo is one of the few optimization frameworks written in C++, a compiled programming language known for its runtime speed. Moreover, its design is thought to directly plug components at compile time rather than relying exclusively on dynamically-run conditional expressions. A typical rationale in black-box optimization is to state that the efficiency of the algorithm computations is not a concern, because in real cases the objective function dominates the runtime. While this is true in essence, this argument forgets that, during the design phase of algorithms, practitioners most often do not use complex objective functions, but synthetic ones, which are very fast to compute. In that case, fast computation means fast design iterations. For example, a CMA-ES algorithm implemented with Paradiseo is 10 times faster than its heavily optimized counterpart implemented with Python/Numpy, when solving a standard synthetic benchmark.
Those measures are obtained using the reference implementation of CMA-ES available in the pycma package 12 , solving the Black-Box Optimization Benchmark (BBOB  [15] ) of the COmparing Continuous Optimizers (COCO 13 ) platform  [16]. The Paradiseo implementation 14 used the independent implementation of BBOB available on the IOHexperimenter 15 platform  [13]. Both benchmarks are implemented in C/C++. Running algorithms on the whole benchmark, on a single Intel Core i5-7300HQ at 2. 50GHz with a Crucial P1 solid- In addition, the Symmetric Multiprocessing module (SMP) allows to wrap any operator called within a loop transparently to fully make use of CPU cores. The master-worker model has been shown to scale (near) linearly with the number of cores, while having a low communication overhead.
Conclusions This article provides a high-level overview of the Paradiseo framework, a C++ free software which targets the development of modular metaheuristics. The main feature of Paradiseo is its ability to help practitioners to focus on creating solvers while thinking at a higher level of abstraction, thanks to: Utility features: Paradiseo provides a large set engineering features, which very often lack in proofof-concept frameworks: several fine-grained parallelization options, convenient interface features (command line argument parsing, state management, useful logs, etc. ). Having robust implementation of such features is often overlooked by users focusing on the algorithmic part. Component-based architecture: The concept of operator is at the core of the design of Paradiseo. It allows for the composition of algorithms, without the overhead of a dynamically loading plugins or the rigidity of a monolithic structure.
Solvers being assembled as a selection of components are also lightweight, as it is not necessary to build and carry all the framework's code within the executable binaries. Modular algorithm models: Paradiseo provides several modules targeting different algorithm paradigms -probably one of the largest footprints among active frameworks. Practitioners can easily design new algorithms which differ in some operators, hybridize algorithms, or even add new algorithm templates using existing operators. Algorithm design: Paradiseo focuses on providing a very large design space to the practitioner. Thanks to its fast computations, large-scale design experiments can be addressed. Combined with its features dedicated to automation, Paradiseo algorithm designers who want to test a new operator can easily focus on small code changes and rapidly check their efficiency and how they interact with other operators in a given paradigm.
Problem solvers can sort out algorithm instances that work best. As future works, we plan to improve the algorithm design automation features, merge more state-of-theart modular designs, and enhance the overall user experience. One of the main impediments to a more widespread use of the framework is that the learning curve for getting started is too steep. Solving this problem is the main objective of PyParadiseo, a module currently under development, that will expose interfaces to Paradiseo in Python, to facilitate the interoperability with external solvers, statistics program or machine learning frameworks.
Acknowledgments During 22 years, Paradiseo has been developed by more than 50 people, with the support of the following institutions: Inria,  University of Lille, University of the Littoral Opal Coast, Thales, École Polytechnique, University of Granada, Vrije Universiteit Amsterdam, Leiden University ,  French National Centre for Scientific Research (CNRS) ,  French National Agency for Research (ANR) ,  Fritz Haber Institute  of the  Max Planck Society, Center for Free-Electron Laser Science, University of Angers, French National Institute of Applied Sciences, Free University of Brussels, Pasteur Institute.
12 Version 3. 0. 0 of https://github. com/CMA-ES/pycma 13 Version 2. 3. 2 of https://github. com/numbbo/coco state disk, takes approximately 10 minutes with pycma/COCO, and only 1 minute with the Par- adiseo/IOH implementation. 14 Version 640fa31 of https://github. com/nojhan/ paradiseo 15 Version 2395af4 of https://github. com/nojhan/ IOHexperimenter.
Purpose: Patient-specific dosimetry in MRT relies on quantitative imaging, pharmacokinetic assessment and absorbed dose calculation. The DosiTest project was initiated to evaluate the uncertainties associated with each step of the clinical dosimetry workflow through a virtual multicentric clinical trial. This work presents the generation of simulated clinical SPECT datasets based on GATE Monte Carlo modelling with its corresponding experimental CT image, which can subsequently be processed by commercial image workstations. Methods: This study considers a therapy cycle of 6. 85 GBq 177 Lu-labelled DOTATATE derived from an IAEA-Coordinated Research Project (E23005) on "Dosimetry in Radiopharmaceutical therapy for personalised patient treatment". Patient images were acquired on a GE Infinia-Hawkeye 4 gamma camera using a medium energy (ME) collimator.
The global accuracy of clinical dosimetry relies on the accuracy of each of these steps  [2]. This is challenging, as some steps cannot be validated experimentally. Significant heterogeneities can be observed in current clinical dosimetry practice, at least in part related to the implementation of widely differing dosimetry protocols. The DosiTest project  [3, 4]  was initiated to evaluate the uncertainties associated with each step of the clinical dosimetry workflow and to propose standardised approaches to clinical dosimetry in MRT. The aim is to create a 'virtual' multicentric clinical dosimetry trial by circulating virtual patient datasets to the different participating centres and allowing them to process these datasets according to their dosimetric approach as if they were patients locally enrolled in their own nuclear medicine department.
Then, by obtaining the absorbed dose results along with a range of intermediate results from each centre, the heterogeneity in the clinical procedures implemented in different centres can be assessed and the uncertainties associated to each step of the dosimetric workflow evaluated. To take account of this heterogeneity and to allow each centre to perform dosimetry according to their local protocol, it is important to generate image data according to their own requirements in terms of acquisition settings, image format, time sampling, etc. Furthermore, the resulting datasets (planar, or SPECT/CT projections) should be processed in the clinical workstations installed in each nuclear medicine facility. An essential asset for the development of such an approach is the implementation of Monte Carlo modelling to generate clinical images based on a virtual, fully characterised patient.
This project (IAEA CRP project E23005 on "Dosimetry in Radiopharmaceutical therapy for personalised patient treatment") involves the circulation, within several medical physics departments, of SPECT/CT images obtained from a clinical situation of 177 Lu-labelled DOTATATE (Lutathera®) therapy. This experimental dataset was used as the base for generating simulated SPECT/CT. This work focuses on the generation of SPECT/CT images of a patient undergoing Lutathera® treatment. Tomographic projections with a GE Infinia Hawkeye SPECT/CT gamma camera were generated using GATE Monte Carlo simulation. These simulated projections were integrated in a SPECT/CT DICOM header file to enable commercial image workstations to access the simulated dataset as if they were real patient datasets. These images will then be circulated to different clinical centres to perform dosimetry thus allowing to determine the heterogeneity of the applied clinical procedures.
Patient model 2. 3. 1. CRP patient The third therapy cycle for a patient in Tygerberg Hospital, South Africa was considered with an injected activity of 6. 85 ± 0. 34 GBq Lutathera®. Acquisition setup and parameters were presented earlier. The reconstructed SPECT along with corresponding CT were imported into OpenDose3D  [14] , a specific clinical dosimetry module based on 3D Slicer  [15, 16]  to assess activity in various volumes of interest. Experimental calibration factor (4. 53 ± 0. 22 cps/MBq) were entered in the software. The segmentation of different volumes of interest (VOIs) was performed in OpenDose3D using the 3DSlicer Segment Editor tool. VOIs including the lungs, bones, left and right kidneys, spleen, liver and the remainder of the body were defined and segmented on the CT while a tumour present in the liver was segmented on the SPECT image.
From CRP patient to digital patient model The segmented and labelled patient CT maps were used to define the geometry of each volume of interest along with its composition. Each VOI composition was set according to the NIST material database (available as Supplementary material) and average densities was derived from the patient CT (Table  1 ). The modelled patient geometry is therefore a 3D matrix of size 256 × 256 × 40 (565. 5 × 565. 5 × 400 mm 3 ). When the virtual gamma camera following auto-contouring motion approaches the patient model as close as possible, the gamma camera head may collide with the patient geometry in the GATE environment. To prevent this "virtual" collision (as overlapping volumes are not allowed in GATE geometry description), we developed a specific approach that allows non-circular orbit modelling.
This work is currently under review  [18]  and will only be briefly presented here. A tessellated description of the patient geometry was introduced. This allows the extraction of the volumes of interest (VOI) in fine triangular meshes thereby eliminating the air surrounding the patient responsible for potential virtual collisions. The labelled map was used to further extract mesh surfaces individually for each VOI with a dedicated python script. All the individual meshes were then refined and simplified in the open source 3D image software Blender  [19] , and stereolithography (. stl) files were exported for each volume. These mesh surfaces were imported in GATE, and materials were added to each volume in conjunction with the patient CT information. Tessellated or mesh-based patient models were therefore generated for each time point from their respective voxelised labelled CT image.
Comparison metrics (projections) To validate the simulated SPECT projections against experimental SPECT projections, several criteria were considered: -Flattened profiles: For the comparison of the slices of 2D SPECT projections, flattened 1D profiles on the x-axis were created (for each projection) using a python script by summing all the counts along the y-axis. -Gamma Index: Gamma Index was used as a comparison metric to compare images as it accounts for both difference in counts (Dose Difference or DD criteria) and spatial difference (Distance to Agreement or DTA)  [23, 24]. Gamma index pass rate (GIPR), a pass/fail criterion specifies a percentage of gamma less than 1 (indicating the points lying within the given DD/DTA acceptance criteria)  [25].
Reconstruction Every clinical workstation uses DICOM (Digital Imaging and Communications in Medicine) files consisting of a raw image i. e. a 3D matrix representing the image and a header file with a standardised series of tags containing information relating to the patient demographics, acquisition parameters, image dimensions, matrix size, colour space, and a host of additional information. The raw image or the pixel intensity data (single or multiple image frames) is attributed to a tag called 'Pixel Data' (7FE0, 0010) in the DICOM file  [26, 27]. Simulated SPECT projections are raw images that are generated in interfile/projection format (. raw or. hdr/. sin extension). These simulated projections were inserted in the 'Pixel Data' tag of the patient DICOM file and the header information regarding patient and acquisition parameters were kept intact.
Comparison of simulated and experimental patient images These modelled SPECT projections were compared against the experimental patient projections. As illustrated in Fig. 4 , the simulated projections qualitatively look already very similar to the experimental images. Flattened 1D profiles were made to compare these images at different gamma camera positions (Fig. 5 ). The simulated projections were normalised with the sensitivity ratio derived from the calibration images. These profiles highlight the accurate positioning and alignment of the patient and gamma camera with respect to the centre of rotation between simulations and experiments. Comparison of this dataset was performed using a gamma index considering 2% -1 pixel criteria. Gamma index passing rate was 95. 5% with an average gamma of 0.