oesteban
commented
4 years ago @effigies, could we exclude N3 from the freesurfer workflow, since we are running N4 ourselves?
Closed eds-slim closed 11 months ago
oesteban
commented
4 years ago @effigies, could we exclude N3 from the freesurfer workflow, since we are running N4 ourselves?
effigies
commented
4 years ago You'll need to check whether nu.mgz is aligned to orig.mgz. It takes talairach.xfm as an input: https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllTableStableV6.0
eds-slim
commented
4 years ago Thanks for taking this up! Is there anything I can test further or otherwise contribute from my side?
eds-slim
commented
4 years ago @oesteban @effigies: I looked into the issue a bit further and tried to run mri_convert on the offending orig.mgz outside the container, this works without error.
As far as I can tell, the local and containerized versions of mri_convert are the same
mri_convert --version
mri_convert.bin --version
stable6-bash-4.2$ singularity shell --userns $WORK/containers/fmriprep/sandbox
Singularity sandbox:~> mri_convert --version
mri_convert.bin --version
stable6I do note that the bc version in the container is 1.06.95, which is older than my local verison 1.07.1. Could this be contributing to the problem?
Thanks for further input to resolve this.
eds-slim
commented
4 years ago The same error
mri_convert orig.mgz ./tmp.mri_nu_correct.mni.6097/nu0.mnc -odt float
mri_convert.bin orig.mgz ./tmp.mri_nu_correct.mni.6097/nu0.mnc -odt float
/opt/freesurfer/bin/mri_convert: line 3: 6272 Segmentation fault mri_convert.bin "$@"
ERROR: converting to mincoccurs with the latest smriprep version 2019-09-09-76bc290c67e9, i.e. smriprep v0+unknown.
eds-slim
commented
4 years ago After further scrutiny I have been able to use the -nocache option to volume_stats as described here to get the freesurfer recon-all command to execute a little bit further.
It now crashes out with a segmentation fault on spline_smooth. I will raise this issue with the N3 people and report back when I get a response. The alternative suggested by @oesteban, i.e. to skip N3 altogether, would be even more appealing. How could that be achieved?
effigies
commented
4 years ago Sorry, I'm still just not understanding why this is happening. I don't see any reason that N3 should fail after N4 runs.
Is the issue that we're inducing negative numbers in the image with N4 correction? What do these images look like?
If you're able to share the original T1w image, I could see if I can reproduce this.
BlackHoleExelion
commented
2 years ago @eds-slim Hello, did you find a solution? I got exactly the same issue right now.
kincsesbalint
commented
11 months ago I face a similar issue. I could run a few weeks back recon-all (freesurfer6.0) from Singularity on our server. Trying the same container with the same subject, it exits with the error above. Checking the fs log files from the previous successful run and the current one, no difference (until the line where the error is mentioned). However, when I check the log files in the individual folder/mri/mri_nu_correct.mni.log) there are some differences:
from the successful run:
current, bad run:
It seems that the mri_nu_correct.mni called with different arguments.
kincsesbalint
commented
11 months ago It seems that we have had some update on our server and there was some issue with mounting the tmp folder in the container. It seems that freesurfer could not write there, so in the next step it could not find data. Sorry for the noise.
effigies
commented
11 months ago No worries, glad you figured it out. Closing this as there's nothing actionable. A new issue can be opened if it resurfaces.
Hi, when using fmriprep version v1.5.0rc1 in singularity version 3.4.2-rc-1 I receive an error in recon-all
Specifically, there appears to be an segmentation fault in
mri_convertI get the same error, when I run this command isolated through singularity:
Interestingly, no error occurs when i change
-odt floatto-odt ucharor-odt short. The seg fault does occur for-odt int.Any ideas? Thanks.