Hi!
I tried b0calc with 64 bits FSL and it works now fine. Does this 2GB
limit affect also the whole POSSUM too? Is it possible to face a memory
problem with possum simulatios if I have high resolution and too many
volumes defined in the simulation parameters?
Then a little question about your example slice profile for POSSUM:
How the frequenises have been normalized? The freq axis does not go from
-pi/2 to pi/2 in the default profile, but -1.2470665 to 1.2470665. Where
these values comes from?
Mark Jenkinson wrote:
> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
|