Hi,
The 2GB limit will apply to all processes, including POSSUM.
However, for small simulations you can probably get it to work.
The slice profile is simply truncated at a convenient point where
the amplitude is less than 0.3% of the maximum - since it needs
to be truncated at some arbitrary point. The frequency
difference is normalised as a percentage of the Larmor frequency.
All the best,
Mark
On 26 Apr 2010, at 16:05, Juha Pajula wrote:
> 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
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
|