Hmm - interesting. It does look like some slices are being processed  
by more than one processor.
I'm not sure why this is happening. This is how the parralelisation  
works:

each cpu runs a program called bedpost_proc that does this:

for every possible slice
	if no other cpu has claimed the slice,
	  	write a test file telling your cpu identity, and claiming the slice.
		wait 10seconds
		if no other cpu has tried to write the same file (i.e. if the file  
is the same as when you wrote it)
	  		start running the slice.
		endif
	endif
end


we thought this would be quite safe (and it has been on systems we  
have tried on), so I am not quite sure what has happened.

I guess you have two options.

1) (The purist one) watch carefully what logfiles are appearing, and  
what cpus are processing which slices, and try to figure out what is  
going on
(The log files are called ${subjdir}.bedpost/logs/.0001 etc)

2) The hack: put the following line before the avwmerge in bedpost  
(line 255):
rm -rf ${subjdir}.bedpost/diff_slices/data_slice_*+

which will delete every slice with a + after it....

Sorry I haven't figured it out..

T


On 14 Mar 2007, at 00:15, Stein, Jason (NIH/NIMH) [F] wrote:

> Thanks very much!  When I look in ${subjdir}.bedpost/diff_slices, I  
> see
> the following:
>
> data_slice_0000   data_slice_0019+  data_slice_0039   data_slice_0058
> data_slice_0001   data_slice_0020   data_slice_0040   data_slice_0059
> data_slice_0002   data_slice_0021   data_slice_0041   data_slice_0060
> data_slice_0002+  data_slice_0022   data_slice_0042   data_slice_0061
> data_slice_0003   data_slice_0023   data_slice_0042+  data_slice_0062
> data_slice_0004   data_slice_0024   data_slice_0043   data_slice_0063
> data_slice_0005   data_slice_0025   data_slice_0044   data_slice_0064
> data_slice_0006   data_slice_0026   data_slice_0044+  data_slice_0065
> data_slice_0007   data_slice_0027   data_slice_0045   data_slice_0066
> data_slice_0008   data_slice_0028   data_slice_0046   data_slice_0067
> data_slice_0009   data_slice_0029   data_slice_0047   data_slice_0068
> data_slice_0010   data_slice_0030   data_slice_0048   data_slice_0069
> data_slice_0011   data_slice_0031   data_slice_0049   data_slice_0070
> data_slice_0012   data_slice_0032   data_slice_0050   data_slice_0071
> data_slice_0013   data_slice_0033   data_slice_0051   data_slice_0072
> data_slice_0014   data_slice_0034   data_slice_0052   data_slice_0073
> data_slice_0015   data_slice_0035   data_slice_0053   data_slice_0074
> data_slice_0016   data_slice_0036   data_slice_0054   data_slice_0075
> data_slice_0017   data_slice_0037   data_slice_0055   data_slice_0076
> data_slice_0018   data_slice_0038   data_slice_0056   data_slice_0077
> data_slice_0019   data_slice_0038+  data_slice_0057
>
> And as you can see there are directories with a "+" after them.   
> When I
> look at those slices with and without the + sign (like  
> data_slice_0002 =
> slice 2 and data_slice_0002+ = slice 3) in the mean_fsamples.nii.gz  
> they
> look exactly the same, and when I import those slices into matlab and
> subtract them, they are completely zero, so are equal.  Also, the  
> number
> of slices with the "+" sign is equal to how many extra slices I  
> have in
> my data.
>
> Is it ok to remove those folders files with a "+" sign after them and
> then merge the images?  Does this happen because some of my CPUs are
> calculating the same slice?  In general, is the parallelization set up
> so that one slice is calculated on each CPU?
>
> Thanks again for your help,
> Jason
>
> -----Original Message-----
> From: Tim Behrens [mailto:[log in to unmask]]
> Sent: Monday, March 12, 2007 5:49 PM
> Subject: Re: Number of Slices Produced from Parallelized Bedpost
>
> Sorry - I missed a crucial part....
>> comment out line 270     #rm -rf ${subjdir}.bedpost/diff_slices
>>
>
> Now rerun bedpost!!
>
>
>> Then, when it's finished
>>
>> type
>>
>> ${FSLDIR}/bin/imglob -oneperimage ${subjdir}.bedpost/diff_slices/
>> data_slice_*/th_samples
>
> .....
>
> cheers
>
> T