dataesr/scientific-paragraphs-categorization huggingface dataset:
A yellow frame shows that computation is currently ongoing. A green frame indicates that computation is finished. Furthermore, when moving a window, all downstream windows also move. This gives the user an impression of connections between graph nodes. This intuitive way of interacting with image data allows users to learn image processing, analysis and relationships between operations efficiently because it keeps technical implementation details out of sight. For every processed image, the CLIJ-assistant can backtrack which original images, subsequent operations and corresponding parameters were involved in forming the image. Thus, it is not necessary to store intermediate results of various parameter configurations in the computer memory. The original image, the graph structure and the parameters of operations are sufficient to recompute a result.
Finally, feature extraction and quantitative analysis follow to determine spatio-temporal properties of the imaged objects using descriptive statistics of pixel, region and topological properties. To facilitate accessibility and application of those steps, a search-bar and auto-completion of commands in the script editor were introduced in the recent years in Fiji. These tools allow the user to read in the graphical user-interface what certain operations do and how they can be applied to images. However, neither the search bar nor the auto-completion suggest what to do next. The user still needs to know the right terms to search for and thus, requires substantial knowledge of image analysis terminology. In order to overcome this limitation, we implemented an expert system in the CLIJ-assistant.
Code generation for automation, documentation and knowledge exchange The well-known Macro Recorder is one of the key features of ImageJ  [3]. If the recorder is shown on screen while the user applies operations to images, it records code in ImageJ's Macro programming language, which corresponds to the actions of the user. World-wide, a large number of users self-taught the principles of programming image analysis procedures by observing what is recorded in ImageJ. Also, the recording of object-oriented programming languages, such as JavaScript and Java, is available. Advanced programming skills are typically necessary to make these recorded scripts executable. Fiji  [4]  additionally introduced more advanced scripting languages such as Groovy, Jython, Clojure and Beanshell. However, macro recording capabilities for those scripting languages were not implemented.
While the macro recorder contributed substantially to knowledge-transfer on how to use ImageJ Macro for automation of quantitative image analysis, adoption of the more modern and capable languages still has potential. To approach this aspect, we implemented code generation capabilities in the CLIJ-assistant using an IDFG as starting point. After an IDFG has been set up, configured and optimized, the graph can be exported in various programming languages. As the user chooses the language to export the IDFG to after setting it up, it is also possible to compare scripts in multiple languages as shown in Figure  3. The exported scripts allow the user to go beyond ImageJ and Fiji, because they also offer programming languages applicable in other platforms. Currently supported languages are ImageJ Macro, Icy  [5]  Javascript, Matlab (Mathworks, United States MA), Fiji Groovy, ImageJ JavaScript, and Fiji Jython.
Furthermore, a Java-plugin generator for Fiji, shown in Supplementary Figure  S5 , an Icy protocol generator, shown in Supplementary Figure  S6 , and script export for QuPath  [19]  Groovy, shown in Supplementary Figure  S7 , are available for testing. Support for Python  [20]  and C++ are under development and prototypes can be tested as well. Even though the set of implemented GPUaccelerated image processing functions available in Python and C++ are limited yet, we encourage early adopters to explore these technologies and provide feedback to guide further development. Through the introduced Python compatibility, the multi-dimensional image data explorer napari  [21]  and Jupyter notebooks  [22]  can be utilized as shown in Supplementary Figures S8 and S9, respectively. Interoperability is ensured with Python and C++ on a low code-level.
In order to implement IDFG operations as similar as possible in ImageJ, in Python and in C++, the underlying GPU-accelerated OpenCL code is identical. Maintenance of the native code base is done as part of the clEsperanto 2 project. Fostering reproducibility of image analysis procedures by clear documentation, human-readable protocols of the IDFG can be exported as shown in Supplementary Figure  S10. These protocols can be used to communicate the applied image processing workflow with scientists who are used to other platforms and to people without coding experience. Hence, we see this feature as a potential supplementary methods section generator. ImageJ Macro Markdown notebooks  [23]  can be generated from an IDFG as well. These notebooks present a hybrid between human-readable protocols and macro executable code,  as shown in Supplementary Figure  S11.
Discussion We have presented an overview of CLIJ-assistant, a userfriendly tool for designing GPU-accelerated image analysis workflows in ImageJ. Across multiple sample types and imaging technologies, our approach enables visualization and quantification of tissue and cellular behaviors with an interactive and configurable toolkit. The necessary user actions towards a well-suited image analysis workflow are facilitated using automatic suggestions by an expert system, pre-selection of suitable subsequent operations and automatic parameter optimization. While workflow design does not involve programming skills, it is possible to export workflows in various programming languages and to deploy them to other platforms. This approach bridges communities such as biologists and computer scientists, and users of different image analysis platforms.
With this mechanism custom plugins on the Java class path can be discovered and offered to the user in right-click menus, the search bar and in the auto-completion of the script editor. Secondly, ImageJ's Macro Extensions are used to drive the macro-compatibility. The underlying architecture suggests using arrays of objects as parameter lists. This approach was chosen because it paves the path towards compatibility with QuPath and Icy. Furthermore, passing arrays of objects allows passing of one image over to two CLIJ plugins: The first plugin receives the image as output image; the second plugin receives it as input. In that way, plugins can be chained together in a fashion similar to the mechanism used in ITK. Thus, CLIJ operations have a state. They are not just functions that are executed once.
Therefore, the re-implementation of filters for the Python and C++ side might appear like a lot of effort. However, there are substantial benefits to the community: Programmers used to ImageJ's scripting languages can copy over code snippets to Python driven Jupyter notebooks, and Python programmers can provide code snippets from their workflows to users of ImageJ, Icy or QuPath. This approach bridges communities and facilitates knowledge exchange. Most importantly, it allows workflow designers to focus on the scientific question rather than technical implementation details of analysis procedures. Furthermore, as increased efforts are required for automated testing and deployment of the Python, Java and C++ environments of clEsperanto, the project has the chance to achieve high quality implementations of image processing operations.
The user-interface of the CLIJ-assistant is under development, and this preprint serves as a base for discussion between the user and developer communities. Thus, the interface may change in the future. We want to highlight that if users generate code using CLIJ-assistant employing CLIJ2 operations to process their images in ImageJ, Fiji, Icy or Matlab, these workflows will continue to work even if the CLIJ-assistant changes. This is also true for generated Java-based Fiji-plugins as long as they are limited to CLIJ2 operations. A strong delimitation between CLIJ2 operations and the presented IDFG user interface ensures that. CLIJx operations may also be subject to change, as the x in CLIJx stands for 'experimental'. Nevertheless we would emphasize that user feedback on these operations is guiding us towards the next generation of CLIJ and allows us to make decisions on which CLIJx functionality should be included in future releases.
Acknowledgements We would like to thank everybody who helped motivating, developing and testing CLIJ-assistant and the colleagues who supported us in performing the experiments of which we re-used data for demonstrating the potential of the CLIJ-assistant. In particular thanks go to  Armin Lühr  ( TU Dortmund ),  Barbara Treutlein  ( D-BSSE ,  ETH-Zürich ),  Benjamin Pavie  ( VIB Leuven ),  Bert Nitzsche  ( PoL TU Dresden ),  Bradley Lowekamp (NIAID Washington) ,  Bram van den Broek  ( Netherlands Cancer Institute Amsterdam ),  Bruno C. Vellutini  ( MPI CBG Dresden ),  Christian Tischer  ( EMBL Heidelberg), Cläre von Neubeck (University Hospital Essen ),  Curtis Rueden  ( University of Madison ),  Deborah Schmidt  ( CSBD/MPI CBG Dresden ),  Elke Beyreuther  ( OncoRay Dresden ),  Florian Jug  ( CSBD/MPI Dresden ),  Gayathri Nadar  ( MPI CBG Dresden ),  Irene Seijo Barandiaran (MPI CBG Dresden) ,  Johannes Girstmair  ( MPI CBG Dresden ),  Johannes Müller  ( OncoRay Dresden ),  Kisha Sivanathan  ( Harvard Medical School Boston ),  Liane Stolz-Kieslich  ( DKTK Dresden ),  Malte Gotz  ( OncoRay Dresden ),  Marion Louveaux  ( Institut Pasteur Paris ),  Matthias Arzt (CSBD/MPI CBG Dresden ),  Mechthild Krause  ( OncoRay, University Hospital Carl Gustav Carus, Dresden ),  Noreen Walker  ( MPI CBG Dresden ),  Pete Bankhead  ( University of Edinburgh ),  Romain Guiet  ( EPFL Lausanne ),  Sebastian Munck  ( VIB Leuven ),  Stein Rørvik ,  Stéphane Dallongeville  ( Institut Pasteur ) and  Tanner Fadero (U Chapel Hill) Furthermore , the constant support by the  Image Science  and the  NEUBIAS communities  is acknowledged.
We introduce ssNMRlib, a comprehensive suite of pulse sequences and jython scripts for user-friendly solid-state NMR data acquisition, parameter optimization and storage on Bruker spectrometers. ssNMRlib allows the straightforward setup of even highly complex multi-dimensional solid-state NMR experiments with a few clicks, from an intuitive graphical interface directly from the Bruker Topspin acquisition software. ssNMRlib allows the setup of experiments in a magneticfield independent manner, and thus facilitates the workflow it in a multi-spectrometer setting with a centralized library. Safety checks furthermore assist the user in experiment setup. Currently hosting more than 140 1D to 4D experiments, primarily for biomolecular solid-state NMR, the library can be easily customized and new experiments are readily added as new templates.
In all cases where selective pulses are used, e. g. in CO-CA INEPT transfers or homonuclear 13 C decoupling in indirect 60 dimensions, the pulse power levels are calculated directly within the pulse sequences using the desired excitation band width (in ppm), i. e. at each B 0 field strength the correct power level is calculated. The user does not need to take care of the powerlevel calibration of any shaped-pulse. An important further consideration when designing NMRlib is the possibility to add new experiments to the library, which then are accessible as a button that performs the setup of the experiment. To include a novel experiment to ssNMRlib, buttons 65 are available which create the template and setup scripts from an experiment that has been collected. The newly created setup routine is available as a button in the ssNMRlib browser window (see below).
Implementation of ssNMRlib NMRlib is an add-on in the Bruker Topspin software, and has been tested currently on Topspin 3. 2 to 3. 6 and Topspin 4, on Linux host computers. ssNMRlib is part of the NMRlib library, and is installed at the same time as NMRlib. The NMRlib GUI window is launched directly from a button within the Topspin software (see Figure  2A ). NMRlib comprises a set of jython scripts, pulse sequences, selective-pulse and ramp shapes, and acquisition lists (vdlist, vclist etc), which can be saved either locally on one spectrometer, or on a centrally mounted disk (which may be on one spectrometer), to which all spectrometers access. The latter is very useful to ensure that a whole facility uses the same experiments. The individual experiments (pulse programs, one jython script for acquisition, one for processing parameters and one for the security check) are organized in a directory tree structure and buttons in the GUI windows allow navigating through these directories.
The organization of the experiments can be fully customized, and new experiments can be added to any location within the file structure. The library also contains all the shape files for selective pulses, amplitude ramps etc, and decoupling sequences used by ssNMRlib, as well as a file required for safety checks (see below). On each spectrometer, the files with the correct routing need to be available, e. g. for 1 H, 13 C or 15 N detection experiments. The principal elements of the prosol table (power levels of the different channels) need to be up to date. These latter instrument-specific files, together with the general, non-instrument-specific scripts and the pulse sequence contain everything needed to run ssNMRlib on a given instrument. Part of the current ssNMRlib experiment file tree is shown in Figure  1B.
Example screenshots of the NMRlib windows are shown in Figure  2A. Currently, the library is organized to have in the top level branches (buttons) for setup experiments (KBr, adamantane), a main branch containing 1 H-, 13 C-or 15 N-detected experiments, as well as buttons leading to scripts, including those that allow adding/removing templates to/from the library, saving acquisition parameters or retrieving them from a previous session. In addition, the NMRlib window also contains an "Editor" button to navigate directly to the folder structure that contains the underlying scripts and pulse sequences pertaining to a given NMRlib window ("pp" (pulse sequences),"py" (jython scripts), "vc" and "vd" (lists)). Furthermore, a "Save" button allows saving an experiment in order to create a template from an experiment that has been acquired (see section 2.
4). The tasks performed by a typical script in ssNMRlib which sets up an experiment are shown in the script opens a GUI window that summarizes the most important parameters (Figure  2 , center). The user may manually modify parameters at this step. Of course, all parameters can also be changed at any point in the AcquPars tab in Topspin. Another added value of the ssNMRlib software is that all the parameters of an experiment are automatically checked to insure the probe safety before launching an experiment.
g. if one interrupts a measurements session and continues at a later time point, starting with the previously optimized acquisition parameters. Once all the required transfers and pulses have been optimized, clicking a button for a specific experiment (e. g. a 2D, 3D or 4D correlation experiment) executes a script that automatically reads the optimized parameters used in all the transfer steps, calculates power levels and shapes, and sets up the particular experiment. These steps are described in the following sections.
1 H is decoupled with composite pulse decoupling (swfTPPM  (Thakur et al. , 2006)  or WALTZ-16  (Shaka et al. , 1983) ). During 1 H acquisition, composite-pulse decoupling is applied to 15 N and/or 13 C as appropriate (generally using the WALTZ-16 scheme  (Shaka et al. , 1983) ). As described above, all required band-selective decoupling pulses are calculated and set within the pulse sequence, and the correct shape(s) are called by ssNMRlib's python setup routines. The decoupling field strengths γ • B 1 /(2π) can be specified in kHz by the user, and the setup script proposes values and sets the duration of the unit element pulse accordingly. -For the majority of the assignment experiments, we have versions with additional deuterium decoupling. These experiments may be used with probes equipped for a 2 H channel.
g. CP elements, decoupling or hard pulses. The safety check is performed automatically by ssNMRlib whenever the user clicks on a button to load an experiment. In addition, a "Security" button in Topspin, right next to the button to launch NMRlib, as well as a button in the ssNMRlib window (see Figure  2 ), can be clicked at any time to control the user modified parameters. The safety checks in ssNMRlib access a table (which can be modified by the user) that lists the accepted durations and power levels (in kHz) for a given element. This table comes with ssNMRlib. In the linux console from which Topspin was started, all the parameters that have been verified are listed, including whether they are within the limits of the probe (Figure  9 ). In case a parameter exceeds the specified power limits, a popup window warns the user, and the warning is written in the linux terminal.
Additional useful macros for processing and experiment setup NMRlib comes with a number of additional useful macros and scripts for various tasks, including saving and reading acquisition parameters, processing (e. g. phasing 3D or 4D experiments or summing spectra or time-domain data) or plotting (in Matplotlib format). These tools are described in the following sections. 2. 5. 1 Store and retrieve acquisition parameters and pulse sequences ssNMRlib contains many useful tools for optimizing parameters, keeping the parameters in memory, and using the optimized parameters of all the required pulse sequence blocks when setting up a complex experiment. ssNMRlib allows writing all the present parameters in a user-friendly text file, the "recap file". The file saves all currently stored parameters, along with the date/time of their creation, which allows the user to see which parameters have been recently optimized.
Processing macros General processing tools are part of NMRlib and have been introduced before  (Favier and Brutscher, 2019). As ssNMRlib is part of this library, all previously proposed tools are also available for solid-state NMR experiments. Tools are available to add two multi-dimensional spectra (in time-or frequency domain), to phase multi-dimensional (3D, 4D) spectra, or to remove (i. e. set to zero) corrupt FIDs from a multi-dimensional data set, which may arise for example as a consequence of arching in ssNMR experiments using python package (numpy  Van Der Walt et al. (2011) , nmrglue  Helmus and Jaroniec (2013) , matplotlib  Hunter (2007) ). Another macro allows to correct FIDs for magnetic-field drift (i. e. shearing of the spectrum), which shall be https://doi. org/10. 5194/mr-2020-25.
Conclusions and perspectives We have presented herein ssNMRlib, a comprehensive library of pulse sequences and setup scripts which markedly facilitate solid-state NMR data acquisition, security checks, tracking of parameters and data handling. We developed the library in a multi-spectrometer facility, and the fact that pulse sequences are all centralized contributes greatly to keeping data acquisition simple and reproducible. While the current ssNMRlib version has its focus on pulse programs for biomolecular applications, the library can be extended in a straightforward manner to any kind of NMR data acquisition. We are currently implementing more experiments, such as C-and R-type  (Levitt, 2002)  sequences, as well as 31 P and 19 F experiments. We foresee in future versions of ssNMRlib the use of the WaveMaker library, which allows to create shape files (ramps, selective pulses, decoupling sequences) directly from within the pulse sequence on the fly.
Acknowledgements. This work used the NMR and isotope labeling platforms of the Grenoble Instruct center (ISBG;  UMS 3518 CNRS-CEA-UJF-EMBL ) with support from  FRISBI  ( ANR-10-INSB-05-02 ) and  GRAL  ( ANR-10-LABX-49-01 ) within the  Grenoble Partnership for Structural Biology  (PSB). P. S. acknowledges support from the  European Research Council  ( ERC-StG-311318 -ProtDyn2Function ). We.
We develop and describe such a self-consistent modeling framework, called MINOT (modeling the intracluster medium (non-)thermal content and observable prediction tools) and make this tool available to the community. MINOT models the intracluster diffuse components of a cluster (thermal and nonthermal) as spherically symmetric. It therefore focuses on CRs associated with radio halos. The spectral properties of the cluster CRs are also modeled using various possible approaches. All the thermodynamic properties of a cluster can be computed self-consistently, and the particle physics interactions at play are processed using a framework based on the Naima software. The multiwavelength observables (spectra, profiles, flux, and images) are computed based on the relevant physical process, according to the cluster location (sky and redshift), and based on the sampling defined by the user.
With a standard personal computer, the computing time for most cases is far shorter than one second and it can reach about one second for the most complex models. This makes MINOT suitable for instance for Monte Carlo analyses. We describe the implementation of MINOT and how to use it. We also discuss the different assumptions and approximations that are involved and provide various examples regarding the production of output products at different wavelengths. As an illustration, we model the clusters Abell 1795, Abell 2142, and Abell 2255 and compare the MINOT predictions to literature data. While MINOT was originally build to simulate and model data in the γ-ray band, it can be used to model the cluster thermal and nonthermal physical processes for a wide variety of datasets in the radio, millimeter, X-ray, and γ-ray bands, as well as the neutrino emission.
This software is called MINOT, modeling the intracluster medium (non-)thermal content and observable prediction tools. It is based on the Python language and is available at the following url: https://github. com/remi-adam/minot. MINOT includes various parameterizations for the radial profiles and spectral properties of the different cluster components. The code does not aim at computing the CR production rate from microphysics considerations (e. g. , turbulence, shocks, or diffusion), but instead directly models the spatial and spectral distributions of the CRs and the thermal gas. The predictions for associated observables are available in the radio (synchrotron), millimeter (tSZ effect), X-ray (thermal Bremsstrahlung), γ-ray (inverse Compton and hadronic processes), and also for neutrino emissions (hadronic processes).
This includes surface brightness profiles or maps, spectra, and integrated flux computed with different options. For γ-rays, CR electrons (CRe), and neutrinos from hadronic origin, MINOT includes the latest description of the hadronic interactions in the ICM, based on the Naima software  (Zabalza 2015). The thermal modeling uses the XSPEC software for X-ray predictions  (Arnaud 1996) , and it includes an accurate description of the tSZ signal up to high plasma temperatures. This article is organized as follows. In Section 2 we provide a general overview of the code and discuss the different interfaces. Section 3 discusses the physical modeling of the cluster components. The physical processes related to particle interactions are detailed in Section 4. In Section 5 we discuss the prediction of observables in the relevant energy bands.