Hello,
I’m trying to use the shard-recon package for my DWI data. The process seems to finish running, but fails while trying to save the output. This is the relevant output with the debug flag:
…
dwirecon: [INFO] Transpose projection - regularisers
dwirecon: CG: #iterations: 4
dwirecon: CG: estimated error: 3.26593581e-05
dwirecon: [INFO] creating image “recon.mif”…
dwirecon: [DEBUG] sanitising image information…
dwirecon: [DEBUG] creating empty file “recon.mif”
dwirecon: [INFO] file “recon.mif” already exists - removing
dwirecon: [DEBUG] resizing file “recon.mif” to 99536900
dwirecon: [DEBUG] sanitising image information…
dwirecon: [INFO] image “recon.mif” created with dimensions 96x96x60x3x15, voxel spacing 2.3958300000000001x2.3958300000000001x2.3999999999999999x1xnan, datatype Float32LE
dwirecon: [DEBUG] memory-mapping file “recon.mif”…
dwirecon: [DEBUG] “recon.mif” appears to reside on a networked filesystem - using delayed write-back
dwirecon: [DEBUG] file “recon.mif” held in RAM at 0x7fd02f27a010, size 99532800
dwirecon: [DEBUG] image “recon.mif” loaded
dwirecon: [DEBUG] image “recon.mif” initialised with strides = [ 45 4320 414720 15 1 ], start = 0, using direct IO
terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc
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.
Hi - sorry for being late to reply. Colin had already nudged me offline and we managed to identify the source of this segfault as a bug in dwirecon that arises only when no basis functions (option -rf) are provided. This issue does not occur when run through the main command dwimotioncorrect. I will push a fix to GitHub that sets the defaults correctly or throws a warning.