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?
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
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
-toption is not specified), but certain features could be disabled with flags. For example:--ignore_fieldmaps--ignore_sbrefsIf 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.