Which files am I supposed to look at?My original data file is 256x256x134 with 26 volumes.The merged files turned out 256x256x134 with 50 volumesThe mean files turned out 256x256x134 with 1 volumeThe dyads files turned out 256x256x134 with 3 volumesThe dyads_dispersion turned out 256x256x134 with 1 volume.Is that ok?
On Thu, Nov 4, 2010 at 1:44 PM, Saad Jbabdi <[log in to unmask]> wrote:
HiIf your output files look correct (e.g. the number of slices matches the data) then you should be fine.This is an unfortunate situation where the exit test has been run before the final merge of the different slices has finished.Sorry for that. We will try to make the exit test more robust in the future (if Dave agrees....).Cheers,Saad.
On 4 Nov 2010, at 17:36, shaza zaghlool wrote:
After running for 3.5 days, and bedpost went through every single slice and said all the slices were processed. I got this message:
For some reason the bedpostX process DOES NOT appear to have successfully completed. Please examine your results carefully. kill: 250: No such process.When I looked at my bedopostX directory I found:4 dyads files7 mean files6 merged filesmonitorlogsxfmscommandsHow do I examine my results?
On Tue, Nov 2, 2010 at 5:19 PM, Matt Glasser <[log in to unmask]> wrote:
You get no benefit for interpolating that data for tractography, get significant costs in execution time (probtrackx will also be 8x slower), and in validity of your analysis (see previous posts on the subject). I would run bedpostx on your original data.
Peace,
Matt.
From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of Stamatios Sotiropoulos
Sent: Tuesday, November 02, 2010 4:02 PMHi Shaza,
It seems that your data are interpolated at the scanner, that's why you get so small within-slice dimensions. Next time make sure you turn such interpolation off and acquire isotropic voxels.
Regarding execution time, a whole brain volume with 2x2x2 mm3 voxels takes about 15-25 hours, using a single CPU core. If your voxel volume is 8 times smaller, you should expect roughly 8 times more execution time.
Cheers,
Stam
----- Original Message -----
From: [log in to unmask]" href="mailto:[log in to unmask]" target="_blank">shaza zaghlool
To: [log in to unmask]" href="mailto:[log in to unmask]" target="_blank">[log in to unmask]
Sent: Tuesday, November 02, 2010 8:47 PM
Subject: Re: [FSL] running bedpost
The original resolution I had was 256x256x49x26 with anisotropic pixel dimensions: 1.09x1.09x3. I did Log Euclidean resampling to that to get the values I listed below.
On Tue, Nov 2, 2010 at 4:21 PM, Matt Glasser <[log in to unmask]> wrote:
That is quite high resolution, so it is not surprising that bedpostx is taking a long time. What are you scanning that gives you that high resolution, or did you interpolate your data (which is very bad)?
Peace,
Matt.
From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of shaza zaghlool
Sent: Tuesday, November 02, 2010 3:17 PMSubject: Re: [FSL] running bedpost
My data.nii.gz is a float32 image with dimensions 256x256x134x26. So # of directions is 26. Pixel dimension is 1.09 and is isotropic.
System hardware is
Memory: 4G
Quad CPU 2.5 @GHz
OS: UbuntuI used default parameters when running bedpost
On Tue, Nov 2, 2010 at 4:09 PM, Matt Glasser <[log in to unmask]> wrote:
What kind of dataset are you running on what kind of hardware (resolution, # of directions, # of CPUs).
Peace,
Matt.
From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf Of shaza zaghlool
Sent: Tuesday, November 02, 2010 3:04 PM
To: [log in to unmask]
Subject: [FSL] running bedpostIs it normal for bedpost to take over 2 days of running?
--Saad JbabdiUniversity of Oxford, FMRIB CentreJR Hospital, Headington, OX3 9DU, UK(+44)1865-222466 (fax 717)