Oh all right then ....

If you look in $FSLDIR/src/fdt

you'll find a bunch of files called old_bedpostX*

if you copy these into $FSLDIR/bin

and rename them to remove the old_

they will work as before, but do the new crossing fibre tractography.

Note that these all have X rather than x at the end, so you should be  
able to run bedpostx to get the SGE friendly one or bedpostX to get  
the old slightly-hacked-together one, unless you are on a Mac in  
which case you will have to delete bedpostx from $FSLDIR/bin as mac  
terminals are not case sensitive.

These files won't work with the GUI, but should otherwise do the same  
job.

Don't expect me to smile while writing support emails for them though :)

T





On 30 Aug 2007, at 13:22, Susan Chacko wrote:

> If I understand this correctly, the proposed plan is that we would  
> have
> to run SGE if we wanted to run bedpost in parallel?
>
> Can I put in a request to retain the older method of parallelizing
> bedpost as well?  We manage a large cluster which uses PBS as its  
> batch
> system, and the older method of parallelizing bedpost works fine with
> PBS. If bedpost parallelized _only_ with SGE, it would not work for
> us at all.
>
> Also want to confirm that in my tests, the older method of  
> parallelizing bedpost
> does not work with bedpostx in FSL 4.0.0. I see only 1 xfibres  
> process, no
> matter how many processors I specify.
>
> Susan Chacko
> ---------------------------------------------------------------------- 
> ------------
> Susan Chacko
> Computational Biologist, Helix Systems
> Center for Information Technology
> 12B/2N207                                               Ph:  
> 301-435-2982
> National Institutes of Health                           Fax:  
> 301-402-2190
> Bethesda, MD 20814                                      Email:  
> [log in to unmask]
>
>
> On Aug 29, 2007, at 10:15 AM, Tim Behrens wrote:
>
>> I sent this this morning, but it hasn't come through so am  
>> resending..
>> ..........
>>
>> OK - On liaising with people here - I realise that the  
>> parallelisation for bedpostx might have changed a bit from that  
>> fro bedpost.
>>
>> Dave/Steve - correct me if this is wrong.
>>
>> There has been a big effort to make all of FSL SGE friendly. As  
>> far as I understand SGE is a system that is much cleverer at  
>> managing multi-processor resources than the old bedpost script was  
>> and, thanks to Dave Flitney, Bedpostx now seemlessly parallelises  
>> itself if SGE is installed on your system. Installing SGE on a  
>> single multi-processor system is apparently very easy indeed.
>>
>> I thought that, in the mean time, the old way of parallelising  
>> bedpost would work for bedpostx, but I now am not completely sure  
>> this is happening right (for example I think you should have seen  
>> 4 copies of xfibres running on your top, instead of just one).
>>
>> We will look into this, but we are running the FSL course next  
>> week, so things are very busy.
>>
>> When we get back from the FSL course, we will post detailed  
>> instructions for setting up SGE and this will then be the  
>> supported way of setting up multi-processor bedpostx jobs. I think  
>> it will be very easy to set up, and it will do a much cleverer job  
>> of parallelising than my old script did.
>>
>>
>> Cheers
>>
>> T
>>
>>
>> On 27 Aug 2007, at 21:37, Matt Glasser wrote:
>>
>>> That’s what should happen if you kill bedpost.  Sounds like your  
>>> parallelization is working properly.
>>>
>>>
>>>
>>> Peace,
>>>
>>>
>>>
>>> Matt.
>>>
>>>
>>>
>>> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]]  
>>> On Behalf Of Dianne Patterson
>>> Sent: Monday, August 27, 2007 4:22 PM
>>> To: [log in to unmask]
>>> Subject: Re: [FSL] new bedpost questions
>>>
>>>
>>>
>>> top exists on OSX as well...thankyou...
>>> I see 4 copies of sh using 0% cpu
>>> and then I see one copy of xfibres using 99% cpu.
>>>
>>> Both xfibres and the 4 copies of sh disappear if I kill bedpost.
>>> I see this behavior whether I use rsh or ssh...in the fsl.sh script
>>>
>>> Thoughts?
>>>
>>> Thankyou,
>>>
>>> Dianne
>>>
>>> On 8/27/07, Matt Glasser <[log in to unmask]> wrote:
>>>
>>> If you're using a linux install, you would just type "top" which  
>>> would list which processes are running and you could see if the  
>>> correct number of cores were being used.  I'm sure the mac has  
>>> something analogous to top that lets you see what processes are  
>>> using the CPU.  If you have 4 processors, you should have four  
>>> xfibers processes.
>>>
>>>
>>>
>>> Peace,
>>>
>>>
>>>
>>> Matt.
>>>
>>>
>>>
>>> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]]  
>>> On Behalf Of Dianne Patterson
>>> Sent: Monday, August 27, 2007 3:03 PM
>>> To: [log in to unmask]
>>> Subject: Re: [FSL] new bedpost questions
>>>
>>>
>>>
>>> Hi All,
>>> I hope the course is going well.
>>>
>>> I can now run bedpost in 5 hours instead of 13 hours.  This is  
>>> fine with me, but I wonder whether I can determine what actually  
>>> worked for me.  I have done 2 things:
>>> 1) reduced the number of iterations as Tim describes below AND
>>> 2) parallelized to use all 4 of my processors on the mac (also  
>>> described below)
>>>
>>> Is there any EASY way to determine whether parallelizing is  
>>> working?  I suspect the improvement I see may simply be due to  
>>> the reduced number of iterations, and that my attempt to  
>>> parallelize has had no effect...short of undoing the  
>>> parallelization additions, and rerunning bedpostx, can I tell  
>>> whether bedpost thinks it is running  in parallel?
>>> ====================
>>> 1:
>>>
>>> I have modified bedpostx_single_slice.sh
>>>
>>> On 8/21/07, Tim Behrens <[log in to unmask] > wrote:
>>>
>>>
>>> The file that calls xfibres is now called
>>> $FSLDIR/bin/bedpostx_single_slice.sh as Tim describes below:
>>>
>>> The relevant portion of that script now reads as follows:
>>>
>>> ${FSLDIR}/bin/xfibres\
>>>  --data=$subjdir/data_slice_$slicezp\
>>>  --mask=$subjdir/nodif_brain_mask_slice_$slicezp\
>>>  -b $subjdir/bvals -r $subjdir/bvecs\
>>>  --forcedir --logdir=$subjdir.bedpostX/diff_slices/data_slice_ 
>>> $slicezp\
>>>  --fudge=$fudge --nj=1250 --bi=$bi --se=25 --upe=24 --nfibres= 
>>> $nfibres > $subjdir.bedpostX/logs/log$slicezp  && echo Done
>>> ==============================================
>>> 2:
>>>
>>> I have also modified /usr/local/fsl/etc/fslconf/fsl.sh to call  
>>> 127.0.0.1 four times AND to use rsh (which exists on the machine  
>>> and I figured might be faster than ssh since it would not be  
>>> encrypted) AND to define and export FSLDIR:
>>>
>>> # The following variables are used for running code in parallel  
>>> across
>>> #  several machines ( i.e. for FDT )
>>>
>>> FSLLOCKDIR=
>>> FSLMACHINELIST=127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1
>>> FSLREMOTECALL=rsh
>>>
>>> export FSLLOCKDIR FSLMACHINELIST FSLREMOTECALL
>>>
>>> # Set up development variables (not for the faint-hearted)
>>>
>>> FSLCONFDIR=$FSLDIR/config
>>> FSLMACHTYPE=`$FSLDIR/etc/fslconf/fslmachtype.sh`
>>>
>>> export FSLCONFDIR FSLMACHTYPE
>>>
>>>
>>> ###################################################
>>> ### Add other global environment variables here ###
>>> ###      or change the definitions above        ###
>>> ###################################################
>>>
>>>
>>> # USER VARIABLES HERE
>>> FSLDIR=/usr/local/fsl
>>> export FSLDIR
>>>
>>> ###################################################
>>> ####    DO NOT ADD ANYTHING BELOW THIS LINE    ####
>>> ###################################################
>>>
>>>
>>>
>>>
>>> -- 
>>> Dianne Patterson, Ph.D.
>>> [log in to unmask]
>>> ERP Lab
>>> University of Arizona
>>> 621-3256 (Office)
>>>
>>>
>>>
>>>
>>> -- 
>>> Dianne Patterson, Ph.D.
>>> [log in to unmask]
>>> ERP Lab
>>> University of Arizona
>>> 621-3256 (Office)
>>>
>>>
>>