Hi,
Yes, definitely you want 64-bit, with as many CPUs and RAM as you can
afford (at least 2GB RAM). Actually, I don't think that having an
expensive graphics card is particularly important for FSL, someone
can correct me if I'm wrong; RAM is more important.
Either an Apple or a Linux desktop machine would be equally fine -
the choice between them probably would depend on non-FSL factors, as
FSL runs equally well on either. So I would also take into account
things like: which you will get better local IT support for, and
which better suits your other needs, like do you want Office to run
on it (Apple good for that), etc.
If you're happy with 2 CPUs then the dual iMacs are good value, if
you want higher specs then the Mac Pros are nice, but probably out of
your $2k range. I don't know about Linux box prices in the states but
you can probably get slightly more bang for your buck with a Linux box.
The PowerPC with 4.5GB of ram, even though Apple aren't selling these
any more, would be a very nice machine. According to http://
www.fmrib.ox.ac.uk/fsl/feeds/doc/timings.html if the PowerPC has
2.5GHz G5 chips it is only 30% slower than the latest fastest Apple
intel machines, and with that much RAM would be nice, particularly if
it's free!
Hope this helps? Cheers, Steve.
On 1 Feb 2007, at 21:50, Dianne Patterson wrote:
> Hi All,
>
> So, if you all had the opportunity to build/buy a machine primarily
> to run fsl, what would you choose?
>
> I'm picking up that a good video card is important (like a high end
> g-force),
> that 64 bit is important (but is linux better than Mac OS X?, and
> if so, which 64 bit linux is most efficient)...
> I may be able to get a quad core PowerPC running Mac OSX with 4.5
> GB of ram donated...which seems like it could be a nice choice!?
> Thoughts?
>
> Obviously lots of ram lots of storage...2-4 cpus...
> windows/cygwin is not a great option.....
>
> Any other thoughts, details...I'm thinking in the $2000 range...
>
> Thankyou very much for any of your thoughts and experiences,
>
> Dianne
>
> On 2/1/07, Tim Behrens <[log in to unmask]> wrote:
> My guess is the same as Saad's, but I also don't have any direct
> experience.
>
> T
>
> On 1 Feb 2007, at 18:13, Saad Jbabdi wrote:
>
>> hi,
>> my guess is that it is not a good idea to interpolate upsampled data.
>> If you do this, the value in each voxel will slightly change,
>> because of the interpolation, compared to the original signal.
>> now if you do this for each volume, corresponding to each gradient
>> direction, the signal in each voxel will go slightly up, or
>> slightly down, for each direction volume, and this might miss up
>> with your orientation information and anisotropy values.
>> having said that, I don't know if it does change things that much..
>>
>> cheers,
>> saad
>>
>>
>>
>> On 1 Feb 2007, at 17:19, Hedok Lee wrote:
>>
>>> Dear FSLers.
>>>
>>> I also have a dataset which has been upsampled. Has anyone tried
>>> downsampling a data set (like sinc interpolation) and run bedpost?
>>>
>>> thanks in advance,
>>>
>>> Hedok
>>>
>>>
>>> Andreas Bartsch wrote:
>>>> Yeah, probably Tim is right. I noticed the resolution but it is
>>>> true that this is unlikely to reflect the "real sampling". On
>>>> the other hand, depending on your system you may in fact have
>>>> acquired the data at 256x256? But you better check on it as this
>>>> is a indeed a fairly big data set to process...
>>>> Andreas
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: FSL - FMRIB's Software Library [ mailto:[log in to unmask]]
>>>> Im Auftrag von Tim Behrens
>>>> Gesendet: Donnerstag, 1. Februar 2007 18:11
>>>> An: [log in to unmask]
>>>> Betreff: Re: [FSL] AW: [FSL] bedpost running time
>>>>
>>>> Your sacnner has upsampled the resolution of your image to <1mm
>>>> in- plane. This is what is causing it to be slow, and it will
>>>> also cause huge problems at later stages.
>>>>
>>>> You should turn this feature off on your scanner, so that your
>>>> data is analysed at the resolution that it is acquired. Then
>>>> everything will run much faster.
>>>>
>>>> cheers
>>>>
>>>> T
>>>>
>>>> On 1 Feb 2007, at 17:07, Andreas Bartsch wrote:
>>>>
>>>>
>>>>> Hi,
>>>>> Be patient. On cygwin such a data set make take 36 hours or so.
>>>>> Cheers-
>>>>> Andreas
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: FSL - FMRIB's Software Library
>>>>> [ mailto:[log in to unmask]] Im Auftrag von [log in to unmask]
>>>>> Gesendet: Donnerstag, 1. Februar 2007 17:33
>>>>> An: [log in to unmask]
>>>>> Betreff: [FSL] bedpost running time
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm fairly new to FSL. I'm trying to run bedpost. I have a
>>>>> data set with
>>>>> 34 volumes, 32 diffusion weighted, and 2 withouth the
>>>>> weighting. It has
>>>>> 56 slices, and 56 slices. It has been running for over 18
>>>>> hours now, and so far it's only analyzing the 10th slice.
>>>>> Should I be concerned that it's taking so long? I got images
>>>>> that looked ok when I ran DTI fit.
>>>>> when I ran the datacheck, everything was fine. I'm running it
>>>>> on windows XP with 2GHz pentium processor, with 2GB of ram.
>>>>> The bedpost_datacheck output is below. Any ideas anyone? Or
>>>>> is it just a large dataset?
>>>>>
>>>>> data_type INT16
>>>>> dim1 256
>>>>> dim2 256
>>>>> dim3 56
>>>>> dim4 34
>>>>> datatype 4
>>>>> pixdim1 0.8280000091
>>>>> pixdim2 0.8280000091
>>>>> pixdim3 2.2000000477
>>>>> pixdim4 1.0000000000
>>>>> cal_max 4095.0000
>>>>> cal_min 0.0000
>>>>> file_type NIFTI-1+
>>>>>
>>>>> /home/mark/Kelly/UBC_3T_DTI_32dir_data/BEDPOST/nodif
>>>>> data_type INT16
>>>>> dim1 256
>>>>> dim2 256
>>>>> dim3 56
>>>>> dim4 1
>>>>> datatype 4
>>>>> pixdim1 0.8299999833
>>>>> pixdim2 0.8299999833
>>>>> pixdim3 2.2000000477
>>>>> pixdim4 3.0000000000
>>>>> cal_max 4095.0000
>>>>> cal_min 0.0000
>>>>> file_type NIFTI-1+
>>>>>
>>>>> /home/mark/Kelly/UBC_3T_DTI_32dir_data/BEDPOST/nodif_brain_mask
>>>>> data_type INT16
>>>>> dim1 256
>>>>> dim2 256
>>>>> dim3 56
>>>>> dim4 1
>>>>> datatype 4
>>>>> pixdim1 0.8299999833
>>>>> pixdim2 0.8299999833
>>>>> pixdim3 2.2000000477
>>>>> pixdim4 3.0000000000
>>>>> cal_max 1.0000
>>>>> cal_min 0.0000
>>>>> file_type NIFTI-1+
>>>>>
>>>>> num lines in /home/mark/Kelly/UBC_3T_DTI_32dir_data/BEDPOST/bvals
>>>>> 1
>>>>> num words in /home/mark/Kelly/UBC_3T_DTI_32dir_data/BEDPOST/bvals
>>>>> 34
>>>>> num lines in /home/mark/Kelly/UBC_3T_DTI_32dir_data/BEDPOST/
>>>>> bvecs
>>>>> 3
>>>>> num words in /home/mark/Kelly/UBC_3T_DTI_32dir_data/BEDPOST/bvecs
>>>>> 102
>>>>>
>>>>> thanks
>>>>>
>>>>> ~Kelly
>>>>>
>>
>> ---------------------------------------------------------------------
>> ------
>> Saad Jbabdi,
>> Postdoctoral Research Assistant,
>> Oxford University FMRIB Centre
>>
>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>> +44 (0) 1865 222545 (fax 222717)
>> [log in to unmask] http://www.fmrib.ox.ac.uk/~saad
>> ---------------------------------------------------------------------
>> ------
>>
>>
>>
>>
>
>
>
>
> --
> Dianne Patterson, Ph.D.
> [log in to unmask]
> ERP Lab
> University of Arizona
> 621-3256 (Office)
------------------------------------------------------------------------
---
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------
---
|
