I was running xfibres as downloaded from the binary distribution, and
it did not seem to be threaded.  The workflow I was trying to help
along was bedpostx/probtrackx.

I believe that fsl_sub could possibly be modified so that instead of
submitting jobs to a remote cluster, it instead ran jobs using GNU
Parallel, which would start them on processors on the local machine.
I haven't looked at it closely or hard yet, but that seems like it
would be a useful extension to fsl_sub.  As I mentioned, I thought I
had seen a version where that had been done, but I cannot find it now.
If anyone does find it and can send it or a link to it, I'd appreciate
it.

I saw that Neurodebian has gone the other way and is advocating
installing a scheduler on the local machine.  That's not really an
option for me because I need this to run with the least modification
possible on lab workstations, small servers, biggish servers, and on
our cluster.

I think the GNU Parallel mechanism would work well for portability, as
it is pretty portable and can be installed by a user in their home
directory if they are on a shared machine on which they are not an
administrator.

Unfortunately, our only cluster is quite large, and queue times for
individual jobs can be quite long, so I think it unsuitable in its
current state.

Thanks for the reply.  We may be looking at SLURM soon, and that might
change things.

-- bennet


On Sun, Jul 23, 2017 at 10:49 PM, RICHARDS, JOHN
<[log in to unmask]> wrote:
> 1--If you mean, are the compiled programs done to access the multiple processors with multi-thread libraries?  I think the answer is yes on this.  For example I run a FSL FLIRT on a computer node that I know uses 4 of the cores, and it says it is using multiple cores.  This runs a program in a single p;rocess that may use several cores.
>
> 2--If you mean parallel processing of different processes, then several of the routines are designed to call fsl_sub such that the individual processes, often different subjects, are processed in parallel on the different "cores" or "threads" or "nodes".  The fsl_sub was set up for SGE, could be done on Condor and I have seen SLURM implementations.  For this you would need to be using a cluster and modify the fsl_sub routine according to the cluster software.  I have used this on SGE and OGE, and briefly on Condor.  I am now using SLURM and have not been using the multi-process procedures and so have not implemented the SLURM procedures in the fsl_sub.
>
> 3--If you run one of the FSL procedures that "might" use the fsl_sub, and you don't have the underlying cluster system in place, it will do the procedures serially (rather than in parallel) perhaps using multithread processors each time the serial procedure is used.
>
> John
>
>
> ***********************************************
> John E. Richards
> Carolina Distinguished Professor
> Department of Psychology
> University of South Carolina
> Columbia, SC  29208
> Dept Phone: 803 777 2079
> Fax: 803 777 9558
> Email: [log in to unmask]
> HTTP: jerlab.psych.sc.edu
> *************************************************
>
>
> -----Original Message-----
> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of Bennet Fauber
> Sent: Sunday, July 23, 2017 1:11 PM
> To: [log in to unmask]
> Subject: [FSL] FSL parallel without using a cluster?
>
> Perhaps I am missing something stunningly obvious, but I'm not seeing a way to get FSL to use multiple cores on the same machine.
>
> From what I can see fsl_sub is set up for SGE and Condor, but I don't see an obvious way to simply use it with multiple cores.  Because of the number of users and scheduler policies, queue wait times make using any mechanism that submits another job impracticable.  There is mention in fsl_sub of OMP_NUM_THREADS, but  I searched the source distribution for OMP_NUM_THREADS, but I don't find it in any file but fsl_sub, so I don't think the FSL binary programs are OMP enabled.
>
> I have access to machines with 4-56 cores on which I can run FSL, and I'd like to be able to set the number of cores that it can use.  Some machines are set up to use cgroups, and the number of processors will vary from session to session, so ideally it would be possible to set a variable indicating the number of available processors.  That would also help for shared but unscheduled machines.
>
> I am very unfamiliar with the actual FSL programs themselves; I just help out when I can with Linux.
>
> Thanks,  -- bennet