Skip to content

ENH: use neurodocker 0.4.1 + apt install afni #2707

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Oct 31, 2018

Conversation

kaczmarj
Copy link
Collaborator

Summary

This PR proposes updates to Dockerfile generation.

References #2706 (comment)

List of changes proposed in this PR (pull-request)

  • upgrade to neurodocker 0.4.1
  • install afni from neurodebian
  • minor refactoring in neurodocker generate commands.

Acknowledgment

  • (Mandatory) I acknowledge that this contribution will be available under the Apache 2 license.

@effigies
Copy link
Member

This seems to be broken by #2691...

@effigies
Copy link
Member

@kaczmarj Is there a trivial way to trigger a new docker build? I want to make sure that things aren't only passing on master because we're reusing the old images.

@effigies
Copy link
Member

Built from scratch on rel/1.1.3 locally and no issues. Will try your branch now.

@effigies
Copy link
Member

Yeah, that fails. Looks like you're changing the Matlab and/or SPM installs, and our doc parsing is failing for these versions. How about we push this off to 1.1.4? Or possibly restore the old Matlab/SPM.

@kaczmarj
Copy link
Collaborator Author

@effigies - i think the issue is with the matlab compiler runtime installation. i'm fine pushing this to the next release, but i'll fix it soon.

@effigies effigies added this to the 1.1.4 milestone Sep 20, 2018
@codecov-io
Copy link

codecov-io commented Oct 10, 2018

Codecov Report

Merging #2707 into master will increase coverage by 0.42%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2707      +/-   ##
==========================================
+ Coverage   67.44%   67.87%   +0.42%     
==========================================
  Files         340      340              
  Lines       43170    44002     +832     
  Branches     5352     5430      +78     
==========================================
+ Hits        29116    29865     +749     
- Misses      13356    13433      +77     
- Partials      698      704       +6
Flag Coverage Δ
#smoketests 50.55% <ø> (-0.01%) ⬇️
#unittests 65.31% <ø> (+0.49%) ⬆️
Impacted Files Coverage Δ
nipype/testing/utils.py 89.65% <0%> (-1.73%) ⬇️
nipype/interfaces/afni/base.py 66.93% <0%> (-1.62%) ⬇️
nipype/interfaces/bru2nii.py 73.68% <0%> (-0.39%) ⬇️
nipype/interfaces/io.py 54.44% <0%> (-0.16%) ⬇️
nipype/utils/filemanip.py 79.95% <0%> (+0.44%) ⬆️
nipype/interfaces/afni/preprocess.py 83.36% <0%> (+1.87%) ⬆️
nipype/interfaces/afni/utils.py 86.09% <0%> (+4.34%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d83b06d...23e6357. Read the comment docs.

@effigies
Copy link
Member

Want to merge master? Circle seems to have done okay on Oscar's coverage update.

@kaczmarj
Copy link
Collaborator Author

The following command is failing.

flameo \
--copefile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/copemerge/mapflow/_copemerge0/cope1_merged.nii.gz \
--covsplitfile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/l2model/design.grp \
--designfile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/l2model/design.mat \
--dofvarcopefile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/gendofvolume/dof_file.nii.gz \
--ld=stats \
--maskfile=/work/output/fmri_fsl_reuse/Linear/level1flow/featpreproc/_subject_id_s1/_fwhm_5.0/dilatemask/mapflow/_dilatemask0/f3_dtype_mcf_bet_thresh_dil.nii.gz \
--runmode=fe \
--tcontrastsfile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/l2model/design.con \
--varcopefile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/varcopemerge/mapflow/_varcopemerge0/varcope1_merged.nii.gz

One can run the following to reproduce

/usr/bin/run_examples.sh fmri_fsl_reuse Linear /data/examples/ level1_workflow

@kaczmarj
Copy link
Collaborator Author

This is the specific error:

flameo --copefile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/copemerge/mapflow/_copemerge0/cope1_merged.nii.gz --covsplitfile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/l2model/design.grp --designfile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/l2model/design.mat --dofvarcopefile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/gendofvolume/dof_file.nii.gz --ld=stats --maskfile=/work/output/fmri_fsl_reuse/Linear/level1flow/featpreproc/_subject_id_s1/_fwhm_5.0/dilatemask/mapflow/_dilatemask0/f3_dtype_mcf_bet_thresh_dil.nii.gz --runmode=fe --tcontrastsfile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/l2model/design.con --varcopefile=/work/output/fmri_fsl_reuse/Linear/level1flow/fixedfx/_subject_id_s1/_fwhm_5.0/varcopemerge/mapflow/_varcopemerge0/varcope1_merged.nii.gz
Standard output:
Log directory is: stats
Setting up:
ntptsing=4.000000 

evs_group=1.000000 

Standard error:
terminate called after throwing an instance of 'RBD_COMMON::BaseException'
Aborted (core dumped)
Return code: 134

@effigies
Copy link
Member

Neurodebian's FSL doesn't look to have been updated (correct @yarikoptic?). I wonder if there's a library bug that the new builds are hitting.

@effigies
Copy link
Member

Looks like the build is fixed on master. Unclear why.

@effigies
Copy link
Member

Ah, I see. Master is able to reuse the old base images, because of the compare_dockerfiles check. PRs from most users won't be able to do so. So fresh builds are still failing, we're just not doing them on master.

@effigies
Copy link
Member

I reproduced the issue. Adding --verbose --debug=2 gives practically no more output. I see a couple options:

  1. Try non-Neurodebian FSL to verify that the issue persists. (Possibly upgrade versions?)
  2. Ping the FSL mailing list.

Any other thoughts?

@kaczmarj
Copy link
Collaborator Author

@effigies - i will see if using a neurodebian snapshot from a few months ago will solve the issue http://snapshot.debian.org/

@effigies
Copy link
Member

@kaczmarj Any luck here? Is there something I can do to help this along?

@effigies
Copy link
Member

@kaczmarj Any chance we can figure this one out this week? Tests are still failing for all new PRs, and it would be nice to have this fixed before the next release.

This was referenced Oct 24, 2018
@kaczmarj
Copy link
Collaborator Author

@effigies - i'm working on this now

@effigies
Copy link
Member

Thanks. Sorry to pester.

@effigies
Copy link
Member

Did some of my own tests on #2763. Even installing directly from FSL, flameo crashes for both 5.0.9 and 5.0.11. Perhaps it's a libc issue?

IDK. Is there any chance of just fixing the broken aspects of the current Dockerfile? Or is this a minimal update already?

@kaczmarj
Copy link
Collaborator Author

@effigies - this is a minimal update already. i tried to update the original (neurodocker 0.3.2) dockerfile to use the non-neurodebian fsl to no avail.

# neurodocker version 0.4.1-22-g7c44e01
NEURODOCKER_IMAGE="kaczmarj/neurodocker:master@sha256:858632a7533cac100f70932749b4cfc77fc40f667f41fca208f406215cff8a27"
# neurodebian:stretch-non-free pulled on September 19, 2018
BASE_IMAGE="neurodebian:stretch-non-free@sha256:7cd978427d7ad215834fee221d0536ed7825b3cddebc481eba2d792dfc2f7332"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kaczmarj What if we revert the BASE_IMAGE? If that helps, I think that would be decent evidence that it's a library version issue.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@effigies - i don't think that will help. the apt-get update calls will update to the latest neurodebian stretch sources. i tried using neurodebian snapshots from september 17, 2017 and from january 1, 2017, but both ran into the same flameo error. i'm going to try to use the nipype base image on dockerhub with the current nipype source code now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@effigies - i used nipype's base image on dockerhub (i.e., nipype/nipype:base) and still got the flameo error. is it possible that nipype's code is causing this? could one of the inputs to flameo be corrupted / malformed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it works on master, still, with the same inputs. There's something new in the build.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kaczmarj Is there any chance of using a Debian snapshot from earlier, as well? If it's a libc update or similar that's causing the issue, that wouldn't be resolved by using a neurodebian snapshot.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, i'll try that now. i'm experimenting with updating packages in the current nipype py36 docker image and see if that will reproduce the error.

@kaczmarj
Copy link
Collaborator Author

kaczmarj commented Oct 30, 2018

@effigies - i've narrowed down the issue to the SPM12 matlab r2010a installation in neurodocker 0.4.1. unfortunately i don't have time to dig into it right this minute, but i will this evening / tomorrow morning.

matlab has a lot of old shared libraries, so they might be interfering in some way...

@miykael
Copy link
Collaborator

miykael commented Oct 30, 2018

@kaczmarj, I remember that I had some library issues when I switched the tutorial from spm-dev to spm-r7219. I think you showed me this, but the solution in my case was to first look through the miniconda libraries before going into the ones from MATLAB, see here.

The libraries for Matlab compiler runtime 2010a are being found before the system libraries, and flameo was linking to one of matlab's libraries. This commit prepends the system libraries to LD_LIBRARY_PATH so that flameo (and other binaries) do not link to Matlab's libraries.
@kaczmarj
Copy link
Collaborator Author

thanks @miykael - this indeed was the issue. the most recent circleci build should pass now (it did on my computer).

@effigies
Copy link
Member

Sweet! Here we go.

@effigies effigies merged commit 988a648 into nipy:master Oct 31, 2018
@kaczmarj kaczmarj deleted the enh/neurodocker branch October 31, 2018 15:45
@kaczmarj
Copy link
Collaborator Author

Wahoo!

And as an added bonus, it takes about 9 minutes to build both the base docker image and the main (py36) image. according to @miykael, the matlab compiler runtime file for matlab 2010a is much smaller than that for 2018b, so using 2010a decreases the spm/mcr installation significantly. that and afni being installed from neurodebian.

@miykael
Copy link
Collaborator

miykael commented Oct 31, 2018

Exactly. Switching to SPM-r7219 decreases MATLAB by a few GB and even SPM by a fe 100MB. And afni (and ants) from neuredebian has a similar reduction effect. Like this I was able to get the tutorial from 12GB to 6GB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants