Print

Print


Hi,

The instructions are slightly wrong, as was my previous email -
thanks for pointing that out.

Running a single b0calc with the --xyz turned on produces a
single nifti file containing three separate 3D volumes all packed
together as a 4D image.  So running three b0calc lines, as it
says in the docs, gives you three files, each containing three
3D images, for a total of 9 3D images.  I mistaken said yesterday
that you would get 9 from a single run - sorry about that.

So the docs are correct up until the fslmerge line which is wrong.
The fslmerge line should be:
   fslmerge -t b0 b0z b0y b0x

It sounds like b0calc is running correctly on your smaller images.
The problem with the larger images is that you are using the 32bit
version of FSL!  This has an inbuilt 2GB limit, as all 32bit code does.
You need to be running on a 64 bit machine, with a 64 bit OS and
the 64 bit version of FSL.  Without this you cannot get past the 2GB
limit, regardless of how much memory or swap you have available!

For you interest, the memory required is due to the zero padded
volumes which require 1GB each, and so 2GB per complex volume.
As there needs to be at least three of these in memory at any time
to do the calculations, you are easily over the 2GB limit.

All the best,
	Mark




On 16 Apr 2010, at 13:33, Juha Pajula wrote:

> Hi!
>
> If the output is as you said they you have wrong instructions at  
> POSSUM homepage: http://www.fmrib.ox.ac.uk/fsl/possum/input.html#b0field
>
> Also the results looks to be wrong. There is only three volumes in  
> the file:
>
> bash-3.2$ fslsize IJ_b0x.nii.gz
> dim1           128
> dim2           128
> dim3           128
> dim4           3
> pixdim1        2.0000000000
> pixdim2        2.0000000000
> pixdim3        2.0000000000
> pixdim4        1.0000000000
>
> The used FSL war pre-build fsl-4.1.4-centos5_32.tar
>
>
>
> Mark Jenkinson wrote:
>> Dear Juha,
>> The output image should be a 4D image with 9 volumes, each
>> containing the relevant information.  This will all be contained
>> in one nii.gz file.  Can you check that this is the case?  Either
>> check with fslview or with fslsize (or fslhd).  You need to look
>> at the dim4 value from output in the latter.
>> OK, so I guess that the memory requirements are indeed
>> the problem.  It is possible that some of the third party
>> libraries might have an inbuilt 32bit limit.  Can you tell me which
>> version you downloaded (e.g. was it a binary version and
>> what was the name of the downloaded file or option you
>> selected).  With the memory that you have available it should
>> certainly be possible to get it to work, especially if it has managed
>> to get to the kernel multiplication stage.
>> All the best,
>>    Mark
>> On 15 Apr 2010, at 14:41, Juha Pajula wrote:
>>> Hi,
>>>
>>> I tried now with 128x128x128 image and now the program runs in few  
>>> minutes through without eny errors. It takes now even more memory  
>>> from sge as earlier, so probably the memory was running out.
>>>
>>> Even this problen looks to be solved, it won't still do what I  
>>> want. There is only one .nii.gz file in the output even if I have  
>>> the --xyz flag in use.
>>>
>>> I need those outputs from --xyz to merge the B0 inhomogeneities  
>>> for POSSUM.
>>>
>>> Any ideas where the problem is now?
>>>
>>> Mark Jenkinson wrote:
>>>> Hi,
>>>> What happens if you try to run it on a smaller image?
>>>> Say, just crop out a 128x128x128 portion of your existing
>>>> image and see what happens.
>>>> I'm quite puzzled by what you've found so far.
>>>> All the best,
>>>>   Mark
>>>> On 14 Apr 2010, at 17:20, Juha Pajula wrote:
>>>>> Hi
>>>>>
>>>>> The results are exactly same without --xyz flag.
>>>>>
>>>>> The exit signal from sge is 137 and by some search in web this  
>>>>> looks to mean that the used program, in this case b0calc, calls  
>>>>> abort by itself.
>>>>>
>>>>> According to sge logs the memory or swap is nor running out.
>>>>>
>>>>>
>>>>>
>>>>> Mark Jenkinson wrote:
>>>>>> Hi,
>>>>>> That's unusual, as this machine seems to have plenty of
>>>>>> memory and it seems to have passed through the
>>>>>> difficult stages of creating the FFTs.  Can you try it without
>>>>>> the --xyz option and see if that works?
>>>>>> All the best,
>>>>>>  Mark
>>>>>> On 13 Apr 2010, at 19:06, Juha Pajula wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> Last machine I used was our deparment computing cluster. The  
>>>>>>> used node had 32 gb of RAM and 10gb of swap. The cluster is  
>>>>>>> running with Redhat Enterprise Linux operating system and the  
>>>>>>> used FSL is version 4.1.4.
>>>>>>>
>>>>>>> The image has 256x256x256 pixels with 1 mm cubic size.
>>>>>>>
>>>>>>> The outputs from the program are following:
>>>>>>> Normal output from the grid engine:
>>>>>>> ---
>>>>>>> Calculating Bz field
>>>>>>> Calculating kernel
>>>>>>> zero pad
>>>>>>> Forward FFT
>>>>>>> Forward FFT
>>>>>>> Kernel multiplication
>>>>>>> ---
>>>>>>>
>>>>>>> Error output from the grid engine:
>>>>>>> ---
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> Image Exception : #99 :: Out of memory
>>>>>>> terminate called after throwing an instance of  
>>>>>>> 'RBD_COMMON::BaseException'
>>>>>>> #SPOOL PATH#/spool/outolintu16/job_scripts/38441: line 1:   
>>>>>>> 8013 Aborted                 b0calc -i #PATH#/JH645/ 
>>>>>>> JH_anat_kaannetty_atmask -o #PATH#/b0/JH_b0/JH_b0x --b0x=1 -- 
>>>>>>> b0y=0 --b0=0 --xyz --verbose
>>>>>>> ---
>>>>>>>
>>>>>>> I removed the paths from the error report, so don't care about  
>>>>>>> #SPOOL PATH# and #PATH#.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mark Jenkinson kirjoitti:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sounds like you are running out of memory for this.
>>>>>>>> What are the dimensions of your input image?
>>>>>>>> That is, how many voxels in each direction?
>>>>>>>>
>>>>>>>> And do you get any output from the command at all?
>>>>>>>>
>>>>>>>> It would also be useful to know how much RAM and swap
>>>>>>>> your machine has, and what type of machine and OS it is.
>>>>>>>>
>>>>>>>> All the best,
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13 Apr 2010, at 15:43, Juha Pajula wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> I am trying to create my own B0 inhomogeneities file for  
>>>>>>>>> POSSUM with b0calc and fslmerge. I have followed the  
>>>>>>>>> instructions from POSSUM homepage but I can't get the  
>>>>>>>>> results out while b0calc gives me an error:
>>>>>>>>>
>>>>>>>>> Image Exception : #99 :: Out of memory
>>>>>>>>>
>>>>>>>>> The used command is like the example at POSSUM homepage:
>>>>>>>>>
>>>>>>>>> b0calc -i JH_anat_atmask -o outputut/b0/JH_b0x --b0x=1 -- 
>>>>>>>>> b0y=0 --b0=0 --xyz --verbose
>>>>>>>>>
>>>>>>>>> I have tried to run this with separeted desktop computer as  
>>>>>>>>> well as our department computing cluster via N1 Grid Engine.  
>>>>>>>>> Both give the same result.
>>>>>>>>>
>>>>>>>>> The file JH_anat_atmask is in Analyze 7.5 format (with .hdr  
>>>>>>>>> and .img files)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can you help me to solve the problem?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>>
>>>>>>>>> Juha Pajula,
>>>>>>>>> Research Assistant,
>>>>>>>>> Methods and Models for Biological Signals and Images group  
>>>>>>>>> of Signal
>>>>>>>>> Processing department in Tampere University of Technology
>>>>>>>>>
>>>>>>>>> email: [log in to unmask]
>>>>>>>>> mobile: +358405426242
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>