dataesr/scientific-paragraphs-categorization huggingface dataset:
Albiol et al. [18]  proposed a new type of densitometric radiographic images (a technique that combines two radiographs that were produced with two different tube voltages). They replaced one of the radiographs with a simulated one, thanks to the use of a contour sensor (e. g. Microsoft Kinnect) and gVirtualXray (see Figure  1c ). It is also possible to integrate further simulation models to take into account the patient's physiology such as the respiration during the CT scan acquisition. In this case, reconstructed slices will exhibit motion artefacts  [19]. Andreozzi et al. [20]  used gVirtualXray to generate noise free X-ray radiographs. Noise is added as a post-process to study real-time edge-aware denoising in fluoroscopic devices. Corbi integrated gVirtualXray with other relevant software packages, such as Geant4, into a Docker container that is used online to teach particle physics and X-ray imaging to undergraduate students in engineering  [21].
Another motivation, from an educational point of view, is that exposure parameters have an influence not only on image quality but also on the radiation dose the patient receives. Using anthropomorphic phantoms with realistic clinical parameters to develop a virtual software is important to recognise the effect those parameters have on image quality in terms of contrast and noise from the absorption and scattering of the X-ray photons. To benchmark X-ray projections simulated on GPU with gVirtualXray against ground truth images of clinically realistic phantoms: • A suitable digital anthropomorphic phantom must be chosen. It will be used to compare i) an X-ray projection using gVirtualXray with ii) an image simulated using a state-of-the-art MC simulation tool. MC simulation is considered the gold standard method in particle physics.
MC methods are based on step-by-step transportation and tracking of particles. The open-source software GATE v9. 0  [5]  based on the Geant4 v10. 7 toolkit  [22]  has been used in this study. Option 4 of the electromagnetic standard library was selected, following the recommendation from the Geant4 medical simulation benchmarking group  [23]. Simulation parameters for both simulations must be equivalent. • A suitable anthropomorphic phantom used in clinical routine must be selected. It corresponds to some kind of mannequin that can be scanned. The virtual anatomy is extracted by segmentation and isosurfacing of the CT scan of the phantom. It is used to produce another two simulated radiographs. They will be compared with digitally reconstructed radio-graphs (DRRs) computed from the original CT scan of the anthropomorphic phantom.
DRRs are radiographic images produced directly from 3D CT data. They have been used in several medical imaging applications for decades, such as the verification of computer-designed radiotherapy treatments  [24] , 2D/3D image registration  [25]  and more recently the creation of training data for training tumour-tracking algorithms  [26]. They are often computed using a ray-casting algorithm and tend to ignore scattering although it can be taken into account  [27]. The main difference between the simulations performed using gVirtualXray and DRRs is in the data representation of the scanned patient: surface meshes vs. voxels. Simulation parameters for the radiographs and corresponding DRRs must be equivalent. • A CT data acquisition will be simulated. The anthropomorphic phantom data will be used as a CT scan of the phantom is available.
Overview of the simulation model In clinical routine, an anti-scatter grid is commonly used in radiography. It is a device placed between the patient and the detector. Such devices use a grid pattern designed to stop scattered photons and let through the photons that travel along a straight line from the source to the detector. CT scanners in medicine make use of a helical scanning geometry where the patient couch is continuously translated during the data acquisition  [28]. It allows the beam to be collimated to a fan-beam geometry rather than a large rectangular area. It significantly reduces the amount of scattered radiation compared to cone-beam computed tomography (CBCT), which requires a 2D area detector with many more rows of pixels. Scatter in CT does occur and causes inaccuracies in the measurement of attenuation values which can lead to artefacts such as cupping, streaks, increased image noise, uniformity issues.
The overall process is summarised in Figure  8. A CT scan acquisition is simulated. It consists of generating a series of X-ray projections around the virtual phantom at successive angles. We use the Core Imaging Library (CIL) 7   to reconstruct the CT volumes from the projections  [38]. It is a Python toolkit that provides many popular algorithms, including FBP and FDK. Slices of the reconstructed CT volume are then compared with the corresponding slices of the original CT volume.
Notebook 4: Registration of simulated radiographs onto real radiographs Registration is the process of matching a moving dataset (called source) to a fixed dataset (called target). The source is somehow transformed (e. g. moved and/or deformed) so that it closely matches the target. Figure  9  illustrates the framework that is used to perform the registration. Our approach relies on fast X-ray image generation and robust global optimisation algorithms. The source (blue trace in Figure  9 ) is the surface model of the Lungman; and the target (red trace in Figure  9 ) is a real radiograph (see "ground truth" in Figure  14a ). The virtual patient must match the location and orientation of the patient in  header) that must be estimated by mathematical optimisation. Optimisation algorithms choose different combinations of parameters until a stopping criterion is met (green trace in Figure  9 ).
The corresponding diagonal profiles in Figure  13  indicate that the amplitude of Hounsfield Units is well recovered. The height of peaks and the depth of dips are accurate. We can see that the simulated data lacks photonic noise and that void was used instead of air. As we used µ air = 0, the HU values are equal to -1000 in the synthetic data whereas it should be slightly higher. In this test, a virtual Lungman phantom is registered so that its simulated radiograph closely matches a real digital radiograph taken with a clinical X-ray machine by GE Healthcare (Chicago, Illinois, USA). The position and orientation of the virtual Lungman phantom are first registered as an optimisation problem to minimise the differences between the real radiograph and the simulated one.
Any delay longer than one second will be considered unacceptable by the user. It is important that images are accurate too. When scattering can be ignored, we demonstrated that gVirtualXray provides a suitable alternative to Monte Carlo simulations and DRRs computed from CT volumes. For thicker patients with more of scatter, such deterministic simulations may be too simplistic and may not be appropriate. To date, high-resolution and relatively noise-free images cannot be generated fast enough with Monte Carlo methods for real-time or high-throughput data applications. Another advantage is the use of surface meshes instead of voxel data: character animation used in video games can be deployed to change the virtual patient's pose, which is not feasible with DRRs computed directly from CT volumes.
The direct simulation of X-ray images from real CT volumes is not recommended with gVirtualXray. Indeed, each voxel would need to be converted into 12 triangles and the voxels sorted by HU value. A DRR software dedicated to voxelised data, such as Plastimatch, is likely to provide better computational performance. Today's GPUs are designed to render millions of triangles to provide real-time video games with a high level of realism. This property of GPUs makes it possible to use volumetric meshes made of tetrahedrons. VR applications with soft tissue deformations and cutting may benefit from this method. Note that this approach is also of interest in material science to simulate an object under load.
Conclusion Until now, core components of gVirtualXray were evaluated by comparing its simulated images with corresponding images simulated with GATE, but only using a simplistic test object  [9]. This new paper benchmarked gVirtualXray with clinically realistic phantoms. Accurate images that would take days using GATE can be generated in milliseconds with gVirtualXray for high-throughput data (e. g. real-time VR, image registration, and training/testing data generation for ML) when scattering can be ignored. Simulated projections can also be fed to a reconstruction algorithm to produce CT volumes. The use of surface models enables the combination of X-ray simulation with real-time soft-tissue deformation  [44, 9]  and character animation  [45] , which is hardly possible with DRRs computed directly from CT volumes.
1 http://www. opengatecollaboration. org/ (accessed: 27 February 2023) 2 https://geant4. web. cern. ch/ (accessed: 27 February 2023) 3 https://sourceforge. net/projects/gvirtualxray/ (accessed: 27 February 2023) 4 https://pypi. org/project/gVXR/ (accessed: 27 February 2023).
Materials and Methods A wireless wearable (glove) sensor system was used for collecting thousands of gripforce data per sensor location and individual user in real time. The glove system does not provide haptic user feedback, and the sensors therein were positioned to fit the cylindrical shape of the control handles of a robotic system designed for bi-manual intervention in transluminal endoscopic surgery. Task simulations may solicit either the dominant, the non-dominant, or both hands at the same time depending on the complexity of the task. Here, grip-force data recorded from the dominant and non-dominant hands of an expert and a novice tested in ten successive sessions, performed without breaks between sessions, of a four-step pick-and-drop task were generated. All sensors of the glove system were carefully calibrated, as explained in further detail below in Section 2.
The master interfaces are statically balanced and all joints exhibit low friction, which means that only minimal forces are required to produce movement in any direction. The controller of the robot master system runs on a DELL Precision T5810 model computer equipped with an Intel Xeon CPU E5-1620 with 16 Gigabytes memory (RAM) under real-time Linux. The real-time Linux mapping control software communicates with the master interface and the slave system. Joint positions of the master interfaces are obtained from encoders read at 1 kHz by the central controller of the master CPU, which maps the positions individually to the corresponding joints of the slave systems to compute reference positions. The master CPU sends these reference positions to the drivers controlling the slave motors at 1 kHz.
The relation between force and voltage is linear within the range of output voltages measured in the experiments here for variations within the range of [0; 1500] mV. Careful calibration of all sensors was performed prior to the experiments to ensure that all sensors provided similar calibration curves. The relationship between force (g) and tension (mV) here is shown graphically in the Results section. Regulated 3. 3 V was provided to the sensors from the Arduino. Power was provided using a 4. 2 V Li-Po battery enabling use of the glove system without any cable connections. The battery voltage level was controlled during the whole duration of the experiments with the Arduino electronic prototyping platform and displayed continuously via the user interface. The glove system was connected to a computer for data storage via Bluetooth-enabled wireless communication at a rate of 115,200 bits per second (bps).
The spatiotemporal grip-force profiles for expert and novice described under 3. 3 in the Results section were drawn from a functionally relevant subset of three sensors (red circles) in the dominant hand, translating optimal grip-force deployment by the pinky (S7), and minimized gross grip-force deployment by the ring and middle fingers (S5, S6) characteristic of expertise in controlling the master-slave system of the surgical robot. The data from ten of the twelve sensors (S2, S3, S5, S6, S7, S8, S9, S10, S11, S12) in the dominant and non-dominant hands of the two users were fed into the variability (standard deviations) and neural network analyses (SOM). Sensors S4 and S1 produced too little significant output and were not taken into account.
Manipulation of one instrument is required to perform this task here. Given the limited degrees of freedom for hand and finger movements, the user is bound to perform the task with each hand in rather the same way. The locally deployed grip forces will vary depending on how skilled a user has become in performing the task. Here, grip-force data collected from two users with distinct levels of task skill (expert vs. novice) were analyzed. The hand preference profiles of these two users were different. The expert user has been practicing on the system since its manufacture and become a highly proficient user, with years of user experience and more than 100 h of training in this specific task. This expert is proficient in using the system with his dominant (left) hand, and has only a moderate preference for using his left hand in everyday manual tasks.
Statistical Analyses The variability in the novice and the expert data for each hand across the ten sessions was statistically assessed for all sensors that produced meaningful output. The goal of this exercise is to bring to the fore skill-specific differences in grip-force variability across sensors and sessions. This was achieved by computing and plotting the variance in the data in terms of standard deviations from the mean, which express the squared differences between the observations and the group mean divided by the number of data points for each group of observations. The statistical analyses (2-Way ANOVA) between the raw grip-force data from a functionally relevant subset (Table  2 ) of three of the twelve sensors (S5, S6, S7) for the expert and the novice from their first and last task sessions with the dominant hand was performed using the MATLAB toolbox.
Sensor Finger Grip-Force Control S5 middle gross grip-force deployment S6 ring non-specific grip-force support S7 pinky precision grip control These same selected data were then submitted to spatiotemporal analysis in terms of Average peak amplitudes in milliVolts (AmV) for successive temporal windows of a fixed size of 2000 msec each in the given individual sessions. With one signal recorded every 20 msec and 100 signals per time window of 2000 msec, we have AmV = mVtotal/100, which is the total sum of mV recorded in a given time window divided by the total number of signals in that time window. Since expert and novice had different hand-use preferences in everyday life, as explained above in Section 2. 4, the differences shown for the dominant hand are likely to best reflect specific characteristics relating to the skill level in this task here.
Skill-Specific Grip-Force Variability The numerical range of observations (in mV) was determined for each sensor across sessions (ten per hand), for expert and novice performing with the dominant and nondominant hand. The results of this descriptive analysis are shown above (Figure  7 ). The variability in grip forces deployed by the novice and the expert by the dominant and the non-dominant hands was then analyzed on the basis of the raw data from each individual session. Temporal variability in biosensor data expresses the evolution of the amount of functional "noise" in the living system under study, and was determined here in terms of standard deviations (STD) from the mean (not standard errors of the mean as shown in Figure  7 ). STD express the squared differences between observations (measurements) and the group mean (for a given individual session here), divided by the number of data points in the group.
Individual temporal grip-force profiles from sensors S5, S6, and S7 were submitted to spatiotemporal analysis. This was achieved by computing the Average peak amplitudes in milliVolts (AmV) for fixed successive temporal windows of 2000 millliseconds (msec) from a given individual session, as explained in 2. 5 above. These profiles, comparing the first and the last individual sessions of the expert and the novice, are shown below (Figure  10 ). Statistical comparison (2-Way ANOVA) between the original raw data of the expert and novice from their first and last task sessions reveal significant interactions between 'expertise' (two factor levels) and 'session' (two factor levels) for all three sensors considered here (S5, S6, S7). For sensor S5 on the middle finger (gross grip-force deployment), the mean (m) grip forces and their standard errors (sem) from the first session yield m = 241 mV and sem = 4.
MIMIC: The components MIMIC can be considered as a hyper model consisting of 3 main components, as shown in Fig. 2  in its central part. These components solve the problems classically encountered when coupling different and multiple dynamic systems, from desynchronization to feedback integration. The first component schedules the simulations according to the temporalities of the connected models. The Cycle Synchronizer (CS) executes the connected models and starts the interaction process between the involved models. This component prioritizes multiple interacting models based on users' preferences. The second component, the Interaction System States Server (ISS), serves the communication protocols used to create the MIMIC state variables (variables used for interactions). Finally, the third component, the Interaction State and Data Recorder (ISDR), ensures the integrity of the interaction and the state variables of the coupling interface connecting the interacting models.
This operation creates a state variable that can be understood by any other model involved in the interaction. The definition and translation of the ISS state variables are the responsibility of the users, based on their knowledge of the interacting models and the desired observations. State variables are of 3 types: (a) state variables considered as output copies of the connected models, (b) state variables specific to the internal operations of MIMIC, and (c) state variables defined by the users to encode the interaction between models and MIMIC. Interaction State and Data Recorder (ISDR) In this component, in addition to interaction-relevant states, data collected from connected models and internal data resulting from computations within the interface are recorded and stored at each event (when any model is executed) processed in the schedule.
The storage of state variables and data from the coupling model interface makes stop-and-go simulation available. In a broader sense, storing interaction state and data allows users to access a simulation from a previous date in the scheduler, rerun it, and simulate different scenarios by dynamically adjusting the simulation parameters. The results of the interaction simulation are accessible directly from MIMIC, without going through the associated models. The results are adaptable, independent of the simulation itself, and can be read backward and forward (to the last event of the simulation). To illustrate the MIMIC framework, a simple attack case is considered below.
The user's layer or how the users communicate with MIMIC Interactions in MIMIC are generated from the users' instructions, covering the following 2 aspects: (a) the interaction code itself written by the user and so-called UIM (user interaction model) and (b) the control of the simulation, the so-called UC (user simulation control). In both cases, the instructions are processed through the "User-MIMIC communication" component. Indeed, we want the kernel being untouched and safe from external process to guarantee the platform integrity. In MIMIC, we consider the UIM and UC as pseudo-models. This offers numerous interests. It keeps the architecture consistent as a whole; the state variables of the interaction can be kept and made available easily; it gives the potential to build a hierarchical embedding of applications; the user can define active observers (acting as controllers operating according to results gained in the interaction code).
User interaction model (UIM) Users write in Julia language, the code describing the interaction between the models, using the pseudo-model's state variables and pseudo-model's calls. However, using Julia to encode the UIM is not a requirement: (a) The interaction code can also be an "external" model, belonging to the model layer. This method leads to a higher level of complexity and lower performance since requesting to be wrapped in a pseudo-model. (b) Next, if the level of coupling is weak, operating only on the inputs and outputs of the models, forming a "shared coupling" as defined in  [23] , then the user is not requested to provide any UIM. The simulation starts directly from the initial schedule and runs from the explicit cycle input and output definitions described for the pseudo-model generation.
Development and dissemination This framework is primarily aimed at scientists and engineers in the agricultural and environmental sectors looking to estimate P&D effects on plants on long term to assess possible resilience of plants. We intend that this implementation be a user-friendly tool, with an open access code for further development. The modular structure of the architecture should provide the flexibility to adjust and refine the interactions. Finally, its parameterization is easy to understand and is adapted to users who are not specialists in software development. The tool was developed in Julia, an open-source high-level dynamic programming language  [52]. It offers the advantage of calling scripts written in other languages popular in the plant science modeling community (MATLAB, R, etc.
), and Julia remains close to them in its syntax. This choice is also Table  2. The case study tasks list and the schedule after 10 simulation steps. (A) List of events submitted to the scheduler. (B) The events agenda of the scheduled tasks. On both lists, parameters are the following, from left to right: name of model (Model3 stands here for the human model), step size for the model, last time executed, next time to be executed, and status in the schedule. In the user layer, translating variables from one model to another using variable manipulation with ISS or/and arithmetic operation is straightforward, even in Julia. The code is written in a file using a notepad, with a ". jl" extension or through a code editor. In the YAML file, the name of the functions and the path to the code are listed.
The advantage of YAML over other file formats is its simplicity to be read. Writing instructions for this file type is simple and understandable for users of all professional backgrounds. Access to the source code is free via GitHub: https://github. com/ Houssem-Triki/MIMIC. The kernel code can be found there including the case study. The tool is coded as a package that can be downloaded using the Julia REPL command line. Users will find the templates for the YAML input files. These documents can be edited using notepad software or any code editor. The Git provides documentation on MIMIC and the case study example, for which a template sheet data file is provided for the fruiting data, allowing users to test different tree production and harvesting situations.
Parameters of the coupling MIMIC's parameters used in the study case are shown in Table  4. The step time of the simulation will be determined from the parameters that are entered into the time data field of MIMIC's model parameters. For more details, each model and, thus, each pseudo-model are characterized by the simulation's step time (in cycles), the simulation's start time (start simulation), and the simulation's end time. Users need to specify the models' state variables (CBB, coffee, and human) that are relevant to the interaction in MIMIC in the "variables data" field.