Welcome Colin!
Given that the SHARD recon is an external project and not yet a part of the MRtrix3 software, it may be more appropriate to post over on the relevant issue list, as there’s a chance that it may be a problem specific to the contents of that project and not of the MRtrix3 back-end against which it is built.
Nevertheless, a couple of suggestions:
-
Run
top
in another terminal and monitor the RAM usage. If it approaches 100% prior to termination of the command, then your system does not possess sufficient RAM to process your data. -
A
std::bad_alloc
can unfortunately mask the source of the problem if it is not as simple as insufficient RAM. The instructions here explain how to better isolate the source of the problem; however the runtime would be exceptionally long if running in debug mode. -
This:
dwirecon: [DEBUG] “recon.mif” appears to reside on a networked filesystem - using delayed write-back
means that your system is having to allocate sufficient RAM to store the entire output image in order to then dump it in one go to the output filesystem, essentially doubling the RAM requirements (since it’s storing the generated results and the results to be written to file in RAM side-by-side). Changing the output image location to a local file system, such that the output image can be memory-mapped, may bypass the RAM limitation.
Cheers
Rob