Hi all,
I am trying to run UKF Tractography on my DTI data, and am encountering problems that seem to be related to memory use.
Note: this always worked with the same data and parameters on a previous release of Slicer (4.10.2), so it would appear something has changed in the new release?
OS: Windows 10
Slicer version: 5.0.3
System details: Precision workstation, i9-9940X 14 core CPU, 128GB RAM, M.2 SSD, RTX2080
Input data: DTI data with 1 B0 and 64 directions, 220x220x156 voxels, 1mm³ resolution
Behavior:
UKF Tractography runs, using significant resources (over 35 GB of RAM) for a few hours (see image below).
Upon completion, the created fiber bundle file is empty. However, there are no reported errors (UKF Tractography completes “without errors”).
Blue= memory use (GB), Pink = CPU use (%)
When I resample my data to 1.2mm isotropic voxels, the tractography runs fine (see figure below for resource use).
Similarly, it runs fine if I significantly crop my data (by excluding some background, brainstem and cerebellum).
In both these cases, memory used by UKF is reduced to <32GB.
Blue= memory use (GB), Pink = CPU use (%)
I noticed this has been an issue in the past for some users (see UKF tractography fails for large scans (~1.5mm iso)), and that the suggested fix was to add more physical/virtual memory to ensure the process is not running out of resources. However, we definitely have 128GB available, so this does not seem to be the issue in our case.
I have noted, that compared to the previous version we used (Slicer 4.10.2), the memory usage of UKF tractography has more than doubled for processing of the same data.
Could this be related to the switch from VTK 8.2 to VTK 9 in Slicer 5 / Some internal format change? e.g. from integer to floating point?
Apart from what has caused that increased memory usage, from what I can tell, it appears as though when memory use of the UKF Tractography process exceeds 32GB, then no output file is created / the process crashes. Can this be some internal limitation? Some maximum size of something specified somewhere? Explicitly or given by some variable’s format?
Interestingly, the UKF tractography process completes “without errors”, so maybe the UFK-extension is actually fine and the problem occurs just in the very final stage when the resulting tract file is assembled and written out?
Is this something that is known/has been reported before? I am happy to provide a sample dataset to replicate this issue if this would help.
Thanks in advanced for your support!