PS - people shouldn't do this unless they have a specific reason to
want to. The best thing to do in general is to install SGE and run
with the new version. Instructions to follow.
T
On 30 Aug 2007, at 13:50, Tim Behrens wrote:
> 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)
>>>>
>>>>
>>>
|