I am using MRtrix in a Windows Linux Subsystem. I managed to perform full brain tracography with 20M streamlines. Then I ran tcksift, but after ~3600 iterations seemed to be stuck and was not showing any CPU activity. I killed the process and ran tcksift again. Around 400 iterations the same thing happened, no cpu usage. Then I shifted to my MinGW Windows installation (on the same machine), and that finished within a couple of hours.
The funny thing is that the .tck file was not produced at all half way through tcksift, I can only see it when the full process is finished. No indication that the process is working on a temporary folder either.
Does any of this make sense. Anyone knows if the WSL installation may not work properly. Note, I just updated MRtrix last night to make sure everything is up to date. Also note, I need to run in WSL because there is an entire linux echosystem there, and I can make use of scripts using FSL, ANTs, nipype, etc.
I can’t comment much myself on the Windows Linux Subsystem; it’s definitely a promising concept, but since we can’t get it working with QT to support mrview, we haven’t really tested it much.
If I had to take a wild guess, I’d say there’s an outside chance that it may be a buggy condition variable implementation, leading to thread hanging. @jdtournier and myself have had tremendous fun in the past trying to prevent multi-threading lockups on Windows… If your MRtrix3 code is newer than 30 May 2016, it should have what we thought was the fix; but the WLS implementation may well have additional issues over and above MSYS2. You could try running tcksift in WLS with -nthreads 0 and see if it (eventually) completes?
The funny thing is that the .tck file was not produced at all half way through tcksift, I can only see it when the full process is finished. No indication that the process is working on a temporary folder either.
This is the expected behaviour; tcksift will only generate an output track file if the process completes. Writing intermediary results at each iteration to disk would simply be too slow. Temporary directories are really only used by the MRtrix3 Python scripts, not the binaries.