Fmriprep: [IDEA] Rename workflows

Created on 10 Jan 2017  Â·  7Comments  Â·  Source: nipreps/fmriprep

The current workflow names (ds005 and ds054) have historical justification, but they confuse new users.

I propose new naming scheme:
ds005 -> basic
ds054 -> basic_sbref_fmap

This way we can add basic_sbref in the future (when there are sbrefs but fieldmaps are not available or should not be used). WDYT?

Most helpful comment

Alternatively, we can completely scrap the concept of multiple workflows and deal with this with flags. This way there would be "one" workflow that adapts to the data (this is what already happens when the -t option is not specified), but certain features could be disabled with flags. For example:

--ignore_fieldmaps

--ignore_sbrefs

If we chose this option we will have to go do a little documentation rewriting. Basically, we would describe workflows not based on their names, but based on the input data available. This might be more intuitive for users.

All 7 comments

Hi,
BTW what do the names of other workflows mean ? (HPC, spiral)

Which other workflows are you referring to? Outside of fmriprep?

On Jan 11, 2017 6:56 AM, "mrahim" notifications@github.com wrote:

Hi,
BTW what do the names of other workflows mean ? (HPC, spiral)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/311#issuecomment-271889408,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOkp_tMKA7Op-a94GhuQuczxKhJO2AWks5rRO22gaJpZM4Lf_UT
.

I'm referring to these workflows when I type fmriprep -h

  -t {ds005,ds054,HPC,spiral}, --workflow-type {ds005,ds054,HPC,spiral}
                        workflow type, a monkeypatch while it is not 
                                                 automatically identified

Oh I see. Those were removed (actually never implemented as workflows). ds054 aka basic_sbref_fmap will support spiral and TOPUP fieldmaps.

Alternatively, we can completely scrap the concept of multiple workflows and deal with this with flags. This way there would be "one" workflow that adapts to the data (this is what already happens when the -t option is not specified), but certain features could be disabled with flags. For example:

--ignore_fieldmaps

--ignore_sbrefs

If we chose this option we will have to go do a little documentation rewriting. Basically, we would describe workflows not based on their names, but based on the input data available. This might be more intuitive for users.

I like that

Or even better --ignore {sbref, fieldmaps}. by @oesteban

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jsmentch picture jsmentch  Â·  3Comments

jawaltz picture jawaltz  Â·  4Comments

dkp picture dkp  Â·  3Comments

ptubiolo37 picture ptubiolo37  Â·  4Comments

effigies picture effigies  Â·  4Comments