Configure efficient pipelines

Here we focus on several important aspects which can be helpful while configuring a process list. In order to construct more efficient pipelines one needs to be familiar with Method pattern and method order, Re-slicing, and Sections.

Method pattern and method order

An HTTomo pipeline consists of multiple methods ordered sequentially and is executed in the given serial order (meaning that there is no branching in HTTomo pipelines). Behind the scenes HTTomo will take care of providing the input data for each method, and passing the output data of each method to the next method.

Different methods require data to be provided in different orientations (ie, the direction of slicing an array). In order to satisfy those requirements, the notion of a method having a pattern was introduced in HTTomo, i.e., every method has a pattern associated with it. So far HTTomo supports three types of patterns: projection, sinogram, and all.

Note

Transitioning between methods that change the pattern from projection to sinogram or vice versa will trigger a costly Re-slicing operation. Methods with pattern all inherit the pattern of the previous method.

In order to minimise the amount of reslice operations it is best to group methods together based on the pattern. For example, putting methods that work with projections in one group, and methods that work with sinograms in another group. It may not always be possible to group the methods in such way, especially with longer pipelines. However, it’s useful to keep this in mind if one seeks the most computationally efficient pipeline.

The pattern of any supported method can be found in Library files.

Note

Currently, HTTomo loaders use the projection pattern by default, therefore it’s best for efficiency purposes that the first method after the loader has the projection pattern. It is also recommended to place Centre of Rotation (CoR) methods right after the loader.

Library files

In order for HTTomo to execute a method it requires certain information about the method, such as its pattern, and (if it’s a GPU method) the amount of GPU memory required per-slice. HTTomo uses a package called httomo-backends to get this information.

See the httomo-backends documentation for more details on how it provides the required information through “library files” and “supporting functions”.

Grouping CPU/GPU methods

There are different implementations of methods in Supported libraries, and can be classified into three categories:

• cpu methods. These are traditional CPU implementations in Python or other compiled languages. The exposed TomoPy functions are mostly pure CPU.

• gpu methods. These are methods that use GPU devices and require an input array in CPU memory (e.g. Numpy ndarray).

• gpu_cupy methods. These are a special group of methods, mostly from the HTTomolibgpu library, that are executed on GPU devices using the CuPy API. The main difference between gpu_cupy methods and gpu methods is that gpu_cupy methods require CuPy arrays as input instead of Numpy arrays. The CuPy arrays are then kept in GPU memory across any consecutive gpu_cupy methods until they are requested back on the CPU. This approach allows more flexibility with the sequences of GPU methods, as they can be chained together for more efficient processing.

Note

If GPUs are available to the user, it is recommended to use gpu_cupy or gpu methods in process lists. The methods themselves are usually optimised for performance and HTTomo will take care of chaining the methods together to avoid unnecessary CPU-GPU data transfers.

The implementation of any supported method can be found in Library files.

Minimise writing to disk

HTTomo does not require Saving intermediate files by default. If the result of a method is not needed as a separate file, then there is no reason for it to be written to disk. This is because saving intermediate files can significantly slow down the execution time.