A multipurpose numerical method for imaging studies and tomographic reconstruction

A multipurpose software, called Revolt, has been developed to fully exploit the imaging capabilities of Triple-GEM 2D cameras for X-rays and neutrons detection. Both tomographic inversion techniques and synthetic data production methods are based on the modeling of a transport matrix between the 2D spatially resolved signal on a detector and the 3D signal emission in the experimental space. The core task of the Revolt software is to provide a transport matrix between the two quantities via a numerical-geometrical approach. The method is based on the analytical evaluation of detector pixels Line Of Sight generated via a Monte Carlo method to include obstacle shading on the detector image. The Revolt implementation and validation are described in this work, which provides a solid base for future application of tomographic inversion techniques in the context of fusion plasma physics.


Introduction
The use of GEM (Gaseous Electron Multiplier) based pixelated detectors [1,2] for Soft X-ray (SXR) imaging is behind the development of a spatial analysis software for synthetic data generation and tomographic inversion techniques.The relation model between the volume emission in the experimental space, divided in 3D pixels called voxels, and the 2D signal on the detector pixels is a fundamental element for both purposes.
In the context of SXR camera experiments, the detector image can be represented as a vector  ∈ R  (with  detector pixel), which is obtained through the application of a linear operator  to the emission vector  ∈ R  (with  emitting voxel) representing local emission sources.The process of synthetic data generation involves the derivation of  from simulated emission , while the challenge of tomographic reconstruction centers around the retrieval of  from the relationship  •  = , exploiting optimization algorithms such as the Tikhonov Regularization method [3,4].
The Revolt software has been developed to compute the matrix , which entries take into account the solid angle fraction while considering the shading effect stemming from obstacles along each Line Of Sight (LoS) such as: pinhole apertures, vacuum chamber flanges and diagnostic ports, or various experimental support structures and mountings.In contrast to more powerful and comprehensive tools like GEANT4 [5], MCNP [6] or TRANSP [7] codes, Revolt aims to a lighter solution, focusing solely on geometrical LoS considerations, thus providing streamlined computation of the matrix  while maintaining adaptability for various particle detectors, including SXR, gamma, or neutron cameras.In the main case of interest, i.e.SXR radiation from fusion plasmas, this approximation is possible because a plasma in the temperature and density range of interest is optically thin in the SXR region of the spectrum [8], thus the radiation from any point in its interior will not be appreciably changed by any intervening plasma on the path to an externally located detector.

Revolt description
Revolt is a Monte-Carlo (MC) code, deriving from a previous work [9] for the evaluation of LoS of particle detectors, whose idea is to use a voxel approach combined with line of sight evaluation of geometrical obstacle surfaces, as sketched in figure 1(a).
The geometrical evaluation defines which voxels are seen by each pixel of the detector and how much every element volume contributes to the signal on the pixel as a weight over the total signal -1 -detected.The output of the routine is a matrix  :  pixel ×  voxel , which entries are the relative weights and are determined by 3 factors: • The solid angle subtended by the detector pixel surface: where  • n is the scalar product between the detector surface  and the voxel-to-detector line, and  2 the voxel-to-detector distance.
• The obstacles shade on the voxel, i.e. what portion of the voxel volume is visible by the detector, named .
The terms can be grouped in a single expression called Solide Angle FRACTion (SAFRACT) that reads:

Code implementation
The procedure, schematized in figure 1(b), and developed in C programming language, initiates by defining a world volume, partitioned into a voxel mesh-grid.User-defined parameters for detector position, dimensions, obstacle nature, and positions are specified in an input text file.After a preliminary check to ensure voxel centers fall within loose geometry boundaries and the detector's cone of view, in order to save computational time in the MC routine, the Monte Carlo routine begins.
For each pixel-voxel pair, a set of  vox point pairs is randomly extracted, with one point from the voxel volume and the other from the detector pixel, and the equation of the LoS that connect them is calculated.The choice of the number of iterations, i.e.,  vox , determines the accuracy of the results and is related to the spatial resolution required.Indeed, the distance between two neighbouring extracted points in a voxel is given by 3 √︁ / vox , where  is the voxel volume.Subsequently a geometrical analysis determines if every LoS found has intersections with any obstacle.For every line that does not meet any obstacle (depending on the nature of the latter, which can be a radiation-absorbing object or a collimator plane) an hit mark is saved.Eventually the pixel-voxel solid angle is calculated with the equation (2.1), where the ratio of the total hit marks -2 - hit over  vox is the H term of the equation:  =  hit / vox , and is proportional to the visible volume.Every voxel which contributes to the signal on the detector is then saved with the relative information, and the L matrix is updated.
The optical obstacles are built from geometrical solids and consist in: • cylindrical collimators: the LoS must pass through both bases of the cylinder.
• cylinders and blocks as simple radiation absorbing obstacles: those are defined by their 3d equations and evaluated by analytical intersection-equations.
• view-cone: the angle between the LoS and the axis of the cone must be inferior than the view-cone aperture.
• Polygons: complex shaped obstacles can be built defining convex polygons by their vertexes in the 3D space, and using them as faces of the objects, the user can impose if the LoSs must pass through any polygon, to simulate collimator faces, or not, to simulate obstacles of various nature.The intersection analysis is then made on every individual polygon [10].

Code validation
The Revolt code undergoes testing with several toy models to evaluate its capabilities, with two notable scenarios discussed here.The first test examines the impact of a rectangular collimator edge to study the ability to represent partially shaded pixels.
In the first simulation, the voxel and detector directly face each other, resulting in all LoS from the voxel to the detector being counted, thus the entire emitting area is colored in green in figure 2 on the left.In the second simulation, the voxel is shifted, making it only partially visible to the detector (as illustrated in figure 2 on the right).In this case, the LoSs originating from the green area are not blocked by the collimator, constituting 50% of the total LoSs.The red area LoS are entirely uncounted, representing a LoSs of 25% of the LoSs and emission points.The white area LoSs are counted if they terminate on the left side of the dashed-blue line on the detector, they constitute half of the LoSs generated from the white area, resulting in an additional 12.5% of the global emission points being visible.This implies that the expected SAFRACT for the partially visible model is 62.5% of the fully facing simulation.This result is verified to the second decimal number, with the direct facing layout yielding a SAFRACT of  direct = 0.387..and the partially visible layout producing  shaded = 0.240 =  direct × 62.5%.
In the second test Revolt output is validated with an MCNP [6] simulation using a collimated geometry depicted in figure 3(a).The geometrical setup built both in MCNP and Revolt is composed by a single-pixel detector, at coordinates (−22.8,−11.5, 0), observing through a pinhole configuration six sets of voxels arranged in toroidal shapes.With MCNP all the objects are assumed as completely absorbing materials, and the space is considered vacuum.The LoS are disturbed by a vertical cylinder of absorbing material centered in the origin and with a radius of 1.96 m, and 5 vertical collimating planes, inserted 30 cm after the pinhole, as shown in figure 3(a).The set of voxels are 6 horizontal slices of a cylindrical ring, centered in the origin, with internal and external radius respectively of 2.58 and 2.62 m and total height of 0.5 m.To facilitate the comparison, SAFRACT values are translated into the probability of a particle emitted within a specific ring of voxels reaching the detector.This is -3 - achieved by computing the ratio of obstacle-free LoSs for an emitting ring to the total evaluated LoSs.The simulations results, presented in figure 3(b), exhibit a good agreement between the two tools, with differences of less than 7% for every set of voxels studied.While some undershooting tendencies are noted, as is visible comparing the points with the bisector, they are considered non-critical for the immediate scope of this tool and will be addressed in future developments.

Figure 1 .
Figure 1.(a) Revolt voxel-LoS approach representation.(b) Work-flow of the algorithm, where the dashed-line boxes represents looped operations.

Figure 2 .Figure 3 .
Figure 2. Geometries to test the effect of the edge of the collimator on a voxel (dashed black line) adjacent to the collimator.The first simulation (left) is done with voxel and detector facing each other, the voxel is completely seen by the detector, thus completely colored in green.The second simulation (right) is done by shifting the detector so that only half of the volume is facing directly the detector.