Hi,
I’ve setup MRtrix (0.3.15-285-g68589079) on a Centos 6 cluster (Rocks 6.2 & SGE). I need to control multi-threading with some defaults so that MRtrix doesn’t spawn as many threads as it sees cores on whichever compute node it’s running on (this bogs down the whole node when it does).
I’ve created /etc/mrtrix.conf on my head and compute nodes, and it has “NumberOfThreads: 0” to disable multi-threading by default. This is a very good start, assuming I’m correct to think that setting NumberOfThreads here to 0 will disable multi-threading by default?
But when users run a job in a parallel environment with multiple cores, I’d like to automatically set the default multi-threading in MRtrix to match the number of cores they’ve been assigned. I do this for other applications, e.g. by setting an environment var to the number of assigned cores when the job is launched.
Is there a way to do this? I haven’t found something in the documentation. I could hack it to change NumberOfThreads in the user’s ~/mrtrix.conf file when they’re job is launched, but this isn’t a great solution.
I know that otherwise we’ll just rely on users to use the -nthreads option to MRtrix commands.
Thanks for any ideas.
-M
Setting the number of threads via an environment variable is not currently supported, but it would be trivial to add - we’d just need to add a suitable one-liner at this point in the code. I think this would be a worthwhile addition, I’ll give that a shot tomorrow when I have a minute.
What would you like this variable to be called? Would something like MRTRIX_NTHREADS be OK?
Thanks for the quick reply. MRTRIX_NTHREADS sounds good, or maybe MRTRIX_DEFAULT_NTHREADS maybe for clarity? But whatever you think is most in keeping with MRtrix style would presumably be best. I figure this would take precedence over settings in /etc/mrtrix.conf and ~/mrtrix.conf, but be overridden by the -nthreads command argument?
Yes, agree that MRTRIX_DEFAULT_NTHREADS is probably more explicit. And yes, I’d go for the order of precedence you suggest, that’s what I had in mind too.
OK, I just pushed the required modifications to the nthread_from_env branch on GitHub, feel free to give it a try - pull request is also open here. I haven’t tested these changes myself (need to go to bed!), so would appreciate someone giving it a test run 
. I ended up going for the MRTRIX_NTHREADS name, since I figure the ‘default’ really should be that specified in the config file. Not a great reason, but hey, it’s also shorter…
To give it a try:
git fetch
git checkout nthread_from_env
./build
and to revert to the master branch:
git checkout master
./build
OK, don’t bother with the above - I’ve just merged these changes to master. Just issue a regular git pull && ./build, and you should be good to go. At that point, this should work as expected:
export MRTRIX_NTHREADS=4
mrconvert ... # or whatever MRtrix command you're interested in
Now we just need to document this somewhere…
1 Like
Thanks very much! Haven’t had time to try it yet, but will when the next users needs the latest mrtrix build.
. I ended up going for the