Skip to content

Error viewing crashes from other machines with nipype_display_crash #1184

Closed
@jpellman

Description

@jpellman

Hi Nipype,

I frequently receive the following error when viewing crash files created on another computer:

Traceback (most recent call last):
File "/usr/local/bin/miniconda/envs/cpac039/bin/nipype_display_crash", line 86, in
False False
debug, args.directory)
File "/usr/local/bin/miniconda/envs/cpac039/bin/nipype_display_crash", line 17, in display_crash_files
crash_data = loadcrash(crashfile)
File "/usr/local/bin/miniconda/envs/cpac039/lib/python2.7/site-packages/nipype/utils/filemanip.py", line 383, in loadcrash
return loadpkl(infile)
File "/usr/local/bin/miniconda/envs/cpac039/lib/python2.7/site-packages/nipype/utils/filemanip.py", line 404, in loadpkl
return cPickle.load(pkl_file)
File "/usr/local/bin/miniconda/envs/cpac039/lib/python2.7/site-packages/traits/has_traits.py", line 1442, in setstate
self.trait_set( trait_change_notify = trait_change_notify, **state )
File "/usr/local/bin/miniconda/envs/cpac039/lib/python2.7/site-packages/traits/has_traits.py", line 1541, in trait_set
setattr( self, name, value )
File "/usr/local/bin/miniconda/envs/cpac039/lib/python2.7/site-packages/nipype/interfaces/traits_extension.py", line 80, in validate
self.error( object, name, value )
File "/usr/local/bin/miniconda/envs/cpac039/lib/python2.7/site-packages/traits/trait_handlers.py", line 172, in error
value )
traits.trait_errors.TraitError: The 'in_file' trait of a FLIRTInputSpec instance must be an existing file name, but a value of '/home/ubuntu/Documents/working/resting_preproc_679_session_1/_scan_rest_1_rest/_csf_threshold_0.96/_gm_threshold_0.7/_wm_threshold_0.96/_compcor_ncomponents_5_selector_pc10.linear1.wm0.global0.motion1.quadratic1.gm0.compcor1.csf0/func_mni_fsl_warp_0/residual_warp.nii.gz' <type 'str'> was specified.

I've been able to get around this error in the past by temporarily recreating the directory structure along with a dummy file for the missing file on my own machine. This is a bit of a cumbersome workaround though, and I'm wondering if there's a way to avoid having to go through with it to view the crashes.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions