There would be no benefit to running fmriprep twice for each task separately. FMRIPREP handles inconsistencies between participants and process all available data for each participant.
Only benefit would come from multiple instances of FMRIPREP on multiple compute nodes/machines for non overlapping sets of participants. In such case each instance should have separate working directory, but they should all write to the same output (although you can also consolidate outputs when they are done).
It is great to know that FMRIPREP will handle the data inconsistencies when it is executed once for all the sessions/tasks/ETC.
Just to clear things out, for anyone in the future: Would FMRIPREP also handle such inconsistencies if executed twice—once for each of the tasks or some subset of tasks (one situation that I think it would be desirable is when a study contains a number of tasks, say 4-5, but it is required to output subset of results faster than the rest e.g., when a conference submission deadline is approaching
In such case, after the first execution of FMRIPREP is done e.g., for task-1 and task-2 and the out-dir and work-dir are complete, what approach would you recommend for handling task-3, task-4, which haven’t been processed earlier?
(1) tell FMRIPREP to use new out-dir-2 and new work-dir-2 for the following preprocessing
(2) tell FMRIPREP to use the old out-dir (same as in the first execution) but use a new work-dir-2
(3) reuse both directories out-dir and work-dir (if it is known that no files will be overwritten, except for the HTML reports ETC).
To follow-up on this: is there a way to implement slice timing for 1 type of task but not others? For example we have short TRs for resting-state so slice timing is unlikely to be useful (1190ms), while for other tasks we have a longer TR where it is probably necessary (2.5s).