gistfile1.txt

Case 1
SubjectSource ->['4D.nii']->Spm.Realign->'4D.nii'->FSL.Smooth->'4D.nii'

in contrast to:
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->FSL.Smooth->'4D.nii'

Case 2
SubjectSource ->['4D.nii']->Spm.Realign->'4D.nii'->SPM.Smooth->'4D.nii'->FSL.Bet

even thou SPM.Smooth also accept lists
in contrast to:
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->SPM.Smooth->['4D.nii']->FSL.Bet

so this is a more general problem of how to connect nodes that accept multiple inputs to nodes that don't.

• interactively, this is not an issue. traits will complain and the user will know after a few attempts that spm is giving a list and that bet will only take a single file. i think that's a good thing.
• in the context of the pipeline, one would use iterfield (currently) or mapnode (after our change) to define nodes that work over a list of inputs.

so case 1:
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->mapnode(FSL.Smooth)->['4D.nii']
and case 2:
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->SPM.Smooth->['4D.nii']->mapnode(FSL.Bet)->['4D.nii']

actually, i think the bigger problem may be subjectsource. for a given subject, you can have say one structural scan and one functional scan. so should subjectsource return a str for the structural and a list for the functional? or should we provide a mechanism for the user to specify? or should it always return lists?

I don't agree this is a better way to do it from the user point of view. I understand it seams cleaner from our (developers) point of view, but iterfields/mapnode should be necessary only in cases of iterating over MULTIPLE values. This is just unnecessarily overcomplicated.

About exceptions user would get in the interactive mode. This would be just annoying - why would I need give a list if it will also work on single elements? What we need to do is to automatically generate traits constraints in the documentation so it would be clear for the user what to use.

internally for something like spm Realign, one would need to support (at the end of the day):

Any(List(List(File(exists=True, type='3d'))), List(File(exists=True, type=['3d','4d'])), File(exists=True, type='4d'))

the only addition here is the last one (for user simplicity).

alright. let's go with user simplicity for now and we'll see how things evolve. but this will require us to solve the multipath trait issue