GENIUS Viz

From RealityGrid

[edit] Segmentation of the patient specific systems

A graphical-editing tool has been developed to reconstruct the patient specific vascular structure of the medical data acquired and some outlines are provided here. It is assumed that the medical data is organized in a set of slices, each one stored in a file that comprises the intensity of every pixel of the corresponding image. By specifying the directory where all the files are located, the tool reads and visualizes the data of a user-selected slice. The user can rapidly scan and display all the slices, depending on the size of the data set, and select a particular pixel through a mouse event. If the pixel is properly chosen, belongs to the vascular structure and the constrast between the latter and the rest of the brain is high enough, a cluster-based algorithm which assumes that the voxel covered by the selected pixel and slice as seed, accurately reconstructs the entire vascular network based on a simple thresholds-based approach. A key point is that, during the segmentation, the entire data set is not stored in main memory but a hierarchical data organization permits to avoid memory consumption associated with the majority of the non vascular structure. Then, the inlet and outlet boundaries must be set up. Mouse and keybord events permit to quickly create, translate, rotate and modify triangles that will be useful to define inlet and outlet fluid lattice sites, as explained shortly. If the manipulated triangles cut the arteries and vessels, by picking any of the inner fluid sites confined by those boundaries another cluster method performs a recursive search through the connected fluid sites and automatically define the information needed for HemeLB (see HemeLB Deployment) of every fluid, inlet and outlet site and exclude the outer regions. An important feature is that the intersections needed to stop the recursive search through the lattice at the boundary triangles is accelerated by a ray tracing approch which keeps the computational complexity roughly independent by the total number of triangles. However, we are trying to develop a method which is well-suited to automatically cut all the outlets without the need to graphically maniputate the corresponding triangles. At this point, the reconstructed system can be outputted on a file which HemeLB uses as input configuration file.

[edit] Approaches to HemeLB output rendering

The rendering of time-dependent flow fields of large systems is a challenging problem. Approaches based on the very limited capabilities of graphics hardware cannot handle large and complex data sets. Current state-of-the-art ray tracer softwares can interactively visualize iso-surfaces or perform the volume rendering of large stationary systems. However, the high performance is drastically reduced when dealing with dynamic situations due to large preprocessing times and low IO bandwidth. The latter affects either the input reading executed by the graphical tool prior to its preprocessing stage or the output phase of the simulator. Assuming that the flow field simulation is performed by a certain number of processors, its global reconstruction from the corresponding sub-domains needed before its output takes a significant time. Furthermore, the transmission of a large file between the machine which simulates the flow field and the local workstation dedicated to its rendering can require several seconds. To sum up, the elapsed time between the flow field simulation and its visualization can be easily of the order of a minute. This classic approach is unacceptable and we have investigated an alternative technique to rapidly produce the iso-surface and the volume rendering of large and complex non stationary flow fields. Specifically, we have incorporated a ray tracer into the core of HemeLB. thus it can directly perform the rendering by means of the same set of processors that handle the fluid flow simulation: each processor ray trace its specific sub-domain and the final image is recovered communicating each partial sub-image to a particular processor. The output is represented by the data of the coloured pixels only. In this way, any preprocessing and large IO operation is avoided and the entire flow field reconstruction is not needed. However, some communications are needed to assemble the final image for each desidered time step. High bandwidth networks can transmit it to a local workstation at such a speed to eventually follow interactive rates achieved by HemeLB. At this point the time evolution of large flow field can be displayed in real time. Steering and checkpoint capabilities have been incorporated in order to modify the parameters associated to the perspective, visualization frequency, etc., thus to interactively display simulation results during their computation.

[edit] HemeLB's ray tracer performance

The parallelization of the ray tracer is in progress. However, some preliminary single-site and cross-site benchmarks have been conducted on LONI machines obtaining the volume rendering of the velocity intensity flow field of a cerebral patient-specific system of about 4.69M fluid lattice sites. The cross-site runs were performed on two machines using half of the total number of processors (PEs) in each one. The timing results in frames per second (FPS) associated with a full 512x512 screen projection of the volume rendering are reported in the following table:

PEs	Single-site	Cross-site
16	44.96	40.49
32	120.0	132.4
64	351.1	550.4

The elapsed times considered is that associated with the time needed to obain the colours of the non-white pixels (which would be ready to be displayed if the machine had a graphical system). It is stressed that the previous cross-site benchmarks are preliminary and not very reliable: the elapsed times of the benchmarks were too short, the resolution of the function that returns the elapsed time is too low compared to that associated with a single time step rendering and the compiler optimizations used was relatively low on those machines ("-O3"). However, the timing results are not far from the definitive ones. We can see that cross-site runs exhibit a very similar performance with respect to the single-site ones. Superlinear speedup and very high performance is attained in any case presented.