I have basically posted this exact question once before. My afni_proc.py script kept dying during one of the warping stages (applying warp using 3dNwarpApply) giving me a Fatal Signal 6 (SIGABRT) received and a memory corruption message.
We figured out it was due to a large distance between the anatomical and functional datasets. The problem was solved by running @AlignCenters on the functional and anatomical datasets using TT_N27 as the base.
I recently got some data from another laband I basically get identical error messages and linear warping warns me about the data sets beeing far appart. I have tried to allign the centers using @AlignCenters and I use the -ginormous_move option. This still fails me. What should be my next move?
Fatal Signal 6 (SIGABRT) received
3dNwarpApply
Bottom of Debug Stack
** AFNI version = AFNI_16.0.05 Compile date = Feb 10 2016
** [[Precompiled binary linux_openmp_64: Feb 10 2016]]
** Program Death **
** If you report this crash to the AFNI message board,
** please copy the error messages EXACTLY, and give
** the command line you used to run the program, and
** any other information needed to repeat the problem.
** You may later be asked to upload data to help debug.
I suspect the affine alignment is not working properly for this, and the transformation is still too far off. You might try changing the cost function for the affine alignment to another like lpc+ZZ, lpa or nmi. Also switch the “-ginormous_move” to “-giant_move” since you are using @AlignCenters separately. You can try align_epi_anat.py separately to experiment with the options and see if you are getting a reasonable alignment between your anat and EPI data.
I initially used giant move but also tried ginormous.
Okey, I will try different settings on monday. But if I only do affine warping it does not fail, it completes with minor cropping of cerebellum. This is not fixed by init_xform center like it was last time (my old post)…
How come that their scanner places these volumes so far appart? Is it common?
The various master_xxx options control the output in align_epi_anat.py. The datasets usually don’t start off too far apart from the template usually, so it is a little weird. There are a few transformations going on here, so you may want to consider each of these separately to see where things are breaking down for you - epi to anat (align_epi_anat.py), anat to template affine (@auto_tlrc), anat to template nonlinear (auto_warp.py/3dQwarp). Take a look on Monday and if you have trouble, report back.
Just to make sure: Is it the “align” block or the “tlrc” block that is failing? Since you wrote that the “affine alignment” probably is not working properly (might be confusing affine alignment and the affine warping?). Or is it the align part that is troublesome but it is noticed when 3dNwarpApply tries to apply the warping to the “broken” alignment?
When you run @Align_Centers, what are you
aligning them to? I suggest aligning to the
template center. That will avoid origins being
off between the anat and template, too, rather
than just the anat and EPI.
Hi again, so I ran a couple of different settings. First of all I tested running with just linear warping and that works, even without running the 3dAlignCenters function prior to the analysis script.
Then I tried a couple of different cost functions and non-linear warping by running 5 different afni_proc sricpts with these settings:
-align_opts_aea
-giant_move
-cost lpa \
-align_opts_aea
-giant_move
-cost lpc+ZZ \
-align_opts_aea
-giant_move
-cost lpc+ \
-align_opts_aea
-giant_move
-cost mi \
-align_opts_aea
-giant_move
-resample off \
All of these still result in the same error:
3dNwarpApply -source TEST_sT1W_3D_TFE_SENSE_4_1_shft+orig -master anat_final.AB123_risk_Regress+tlrc -ainterp wsinc5 -nwarp anat.un.aff.qw_WARP.nii anat.un.aff.Xat.1D TEST_sT1W_3D_TFE_SENSE_4_1_shft_al_keep_mat.aff12.1D -prefix anat_w_skull_warped
++ 3dNwarpApply: AFNI version=AFNI_16.0.05 (Feb 10 2016) [64-bit]
++ Authored by: Zhark the Warped
*** Error in `3dNwarpApply': malloc(): memory corruption: 0x000000000{SOME NUMBER} ***
Fatal Signal 6 (SIGABRT) received
3dNwarpApply
Bottom of Debug Stack
** AFNI version = AFNI_16.0.05 Compile date = Feb 10 2016
** [[Precompiled binary linux_openmp_64: Feb 10 2016]]
** Program Death **
** If you report this crash to the AFNI message board,
** please copy the error messages EXACTLY, and give
** the command line you used to run the program, and
** any other information needed to repeat the problem.
** You may later be asked to upload data to help debug.
So now I don’t know what to do. You mentioned doing it stepise:
I’m not that used to running these functions by themselves, I usually use afni_proc. Are there some specific settings I should try?
I would try it at the individual scripts myself calling align_epi_anat.py, @auto_tlrc, and auto_warp.py or 3dQwarp. If you’re not comfortable doing that, you can simplify your afni_proc.py to only do the tlrc transformation as an affine transformation (skipping the nonlinear part for now), or reducing the problem down to only the align block and no tlrc block. The latter would stay in original subject space, so you should be able to tell if the anat and epi data are aligned.
I ran all the steps individually and everything seemed sucessfull.
My collaborator sent me their script which I used as a template. It might have been some formating error on that one (even though it did not seem that way - You usually get errors about row endings in that case). When I ran dos2unix on it, it seems to work…
This might have been a combination of error which made it hard to trouble shoot. My initial idea, to run @Align_Centers like last time, would probably have solved it directly if not the script was “tainted”. Do you think this is a possible explanation?
I used one of my older scripts (with the same proc-settings) and it worked. I started to look some more into it.
Without @Align_Centers prior to afni_proc the analysis fails at the anat_w_skull warping
It does seem to matter if I give @Align_Centers the input files as .nii or as BRIK and HEAD. For example when first doing
3dcopy data.nii .
I get the data as data+tlrc.BRIK and data+tlrc.HEAD. I then use this as inputting @Align_Centers and then I run the analysis.
During the analysis auto_warp.py also seem to run @Align_Centers since the output says:
Preforming center alignment with @Align_Centers
When I use the .BRIK and .HEAD format from 3dcopy it says distance between centers is 0.00000 mm and it finishes in 12/137 itterations.
When I instead put the raw data in .nii format as input to the @Align_Centers function prior to the afni_proc the same section in the afni_proc output says:
Center distance is 0.00000024 mm
And it needs all 137 itteratins and extra itterations making it 275/274 itterations.
The script still finishes though without error but there is one extra difference. The part where it crashed before (3dNapply_Warp for anat_w_scull) takes much longer in the latter (.nii) case and gives a:
++ Warping .[R]…Z
Where the other case (.BRIK/HEAD) only gives a
++Warping .Z
The output in the latter case (anat.final / anat_w_scull / epi.volreg) is totally messed up. The warping has failed but the script did not crash.
Why this difference between .nii and the output of 3dcopy .nii as inputs?
So. To fix my script I had to add:
#!/bin/bash
datapath=/data/study1
T1=$datapath/T1.nii
fmri=$datapath/epi.nii
3dcopy $T1 newT1
3dcopy $fmri newfmri
@Align_Centers -base ~/abin/TT_N27+tlrc. -dsets newT1 -child newfmri
T1=T1_shft+orig.
fmri=epi_shft+orig.
#use these as input in afni_proc
This is all very confusing. Why would it matter if I use data.nii or the output of 3dcopy data.nii outputfile (outputfile+orig.HEAD/BRIK) as input to @Align_Centers? Also, I think I did try this as a first trouble shooting and that did not work that time…
Glad this worked out. I think I know why this didn’t work properly for NIFTI data. For oblique data, the origins (and consequently the centers) are effectively not shifted because there are two attributes in the header that define the origin, and only one gets adjusted. That’s something we can try to fix in a future version.
Hi, I edited my previous post. I’m trying to reproduce the .nii error but I’m not successful at this moment.
As I mentioned in the previous post: Is it possible that the script I used as a template (the other lab’s script), that was sent by mail and proabably landed at a windows computer at some point, had some formatting errors? Even tough it did not complain about line-endings?
I ran two identical scripts, one with +orig. as input to @Align_Centers and one with .nii as input. I did not manage to get the .nii way to fail. I did however see that the costs of the warpin levels wary and I can see some small differencies here and there in the ouput. So yes, it is not the same thing to use +orig* data and .nii data. Sometimes it fails, sometimes it don’t. It’s wierd.
I doubt there were formatting errors if you didn’t see any error messages. Are things working out now, or are there continuing issues? If you’re still having problems, I think it would be best to upload some data.
But I guess it is “solved” but I’m not happy about it. I would like to be able to reproduce the error so that I can fully understand it. Beacause now I can run it without fail with both +orig.* and .nii files, even though they give slighly different results (in warping costs etc).
I have run a lot of permutatons of the settings and I’m still not a 100 % on what is going on. But yes, I guess the problem is gone. Feel free to try the data once if you like. Should I mail it to you?
But if I manually copy the raw data into the folder. Then run @Align_Centers on these raw .nii files and then use the shft.nii as input to the script below, it does suddenly not work… Can you see what is wrong with the method below? If I manually copy the raw data into the folder, run 3dcopy on them and Align the +orig. files and use the same script as below (ofc change the input names to +orig.) it works again!. So I have 1 script where .nii works and one where it does not. The scripts are in principal identical.. But it seems like you’re fine if you always go for +orig.BRIK/HEAD files.
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.