Which applications are actually using the “runs” structure- i.e.-
in which applications there is a difference between the outputs when computed over:
…task-sometask1…
…task-sometask2…
and when computed over:
…task-sometask_run-1…
…task-sometask_run-2…
?
If we look at the spec we will find the following definitions of session and run:
Session - a logical grouping of neuroimaging and behavioural data consistent across subjects. Session can
(but doesn’t have to) be synonymous to a visit in a longitudinal study. In general, subjects will stay in the
scanner during one session. However, for example, if a subject has to leave the scanner room and then be
re-positioned on the scanner bed, the set of MRI acquisitions will still be considered as a session and match
sessions acquired in other subjects. Similarly in situations where different type of data is obtained over
several visits (for example fMRI on one day followed by DWI the day after) those can be grouped in one
session. Defining multiple sessions is appropriate when several identical or similar data acquisitions are
planned and performed on all -or most- subjects, often in the case of some intervention between sessions
(e.g., training).
Run - an uninterrupted repetition of data acquisition that has the same acquisition parameters and task
(however events can change from run to run due to different subject response or randomized nature of the
stimuli). Run is a synonym of a data acquisition.
This gives quite a bit of flexibility and different apps can take advantage of the session group ping. FMRIPREP for example currently does not treat multiple _bold files across sessions differently from multiple runs. Everything gets registered to a subject specific T1w template (constructed from all sessions and runs). However in the future two improvements might take advantage of sessions: using session specific bold templates as intermediate coregistration targets and ability to run multiple instances of FMRIPREP for each session separately (https://github.com/poldracklab/fmriprep/issues/1175).