| T O P I C R E V I E W |
| rkozink |
Posted - May 23 2006 : 3:32:45 PM
I am getting the following error on golgi when trying to run bxh_eventstats on a single run.
Error allocating -1989897216 bytes
child /usr/local/bin/bxh_brainmask with signal 11, without coredump
Each run has 496 .img files (12.5 min run with TR=1.5) and was normalized to a voxel size of 0.875x0.875x0.875. I found that if I normalized the data to a voxel size of 3.5x3.5x3.5 then I could successfully run bxh_eventstats. However, this resolution is not ideal for our analysis. I tried a 2x2x2 and still received the error.
Rachel |
| 4 L A T E S T R E P L I E S (Newest First) |
| syam.gadde |
Posted - Aug 09 2006 : 09:15:57 AM
We discussed this problem offline, and Rachel was using 256x256x68 functional images to match anatomical images. It turns out this was not necessary for her particular analysis, so going back to 64x64x34 sufficed to resolve this particular issue. |
| rkozink |
Posted - Aug 07 2006 : 3:49:13 PM
Syam,
I am still having problems with memory. I am using the newest version of bxh_eventstats and specifying a memorylimit 32. I am only interested in averaging, so I have added in the no correlate option to my option file as well. Any more suggestions?
Thanks
Rachel |
| syam.gadde |
Posted - Jun 01 2006 : 5:41:06 PM
bxh_eventstats now supports the "memorylimit" option. Putting the following line:memorylimit 64 in your options file will force it to read at most 64MB of the input image voxels at a time. The program will of course take up more than 64MB of memory while running, but this can be used to drastically reduce the memory requirements of bxh_eventstats if you are running out of memory.
The cost of this is multiple passes to read the data (though it will do its best to be smart and read only the portions it needs). You may want to experiment with the number specified above -- smaller numbers will allow you to analyze larger datasets, but larger numbers will make it finish faster. |
| syam.gadde |
Posted - May 23 2006 : 4:46:34 PM
This also hit us in another project. eventstats is running out of memory. You not only have a large number of timepoints, but a high resolution data set. One possible solution is to have a 64-bit version of eventstats (which should be able to address a larger memory space). However, this will require the recompilation of many other dependent libraries, and will take a while. Another possibility is to reduce the amount of memory eventstats uses, perhaps by only reading portions of the data as needed.
Neither of these, obviously, are things you have any control over. So all I can suggest for now is to use lower resolution data and/or splitting up the timeseries into smaller subsets(?). |
