Unusually long runtime for fMRIPost-AROMA

Summary of what happened:

Dear fMRIPost-AROMA experts,

I have been running fMRIPost-AROMA across several datasets. While it worked well and usually only took a couple hours for most sites, it took an usually long amount of time to run for one particular site and generated a large volume of interim files (10 TB for around 100 participants). As such, the job could not finish for any participants from this site. The primary difference for this site is that it contains two task runs per session (only one session per participant). fMRIprep using version 25.2.5 ran successfully for all sites. I have included the relevant output log.

Many thanks in advance for your time and help with this.

Best,

Connie

Command used (and if a helper script was used, a link to the helper script or the command generated):

apptainer run -B "${fmriprepdir}":"${fmriprepdir}" --cleanenv /gpfs1/home/a/r/arazi/software/fmripost-aroma_0.0.12.simg ${fmriprepdir} ${fmriprepdir}/Postfmri_AROMA/ participant --participant-label "${subject}" --derivatives fmriprep=${fmriprepdir} --denoising-method orthaggr --error-on-warnings -w ${workdir}/${SLURM_JOB_ID}_${SLURM_ARRAY_TASK_ID} --skip_bids_validation --low-mem

Version:

0.0.12

Environment (Docker, Singularity / Apptainer, custom installation):

Apptainer

Data formatted according to a validatable standard? Please provide the output of the validator:

PASTE VALIDATOR OUTPUT HERE

Relevant log outputs (up to 20 lines):


Run1_output_Log.txt (68.8 KB)

	 <!-- Below this line, provide any other information that might be meaningful. This could be screenshots, troubleshooting steps you have tried, or information about your operating system, etc. -->

It looks like fMRIPost-AROMA is collecting both MNI152NLin6Asym and MNI152NLin2009cAsym outputs, so it is effectively processing the same runs twice. If you use a filter file to limit it to just MNI152NLin6Asym, then that should cut the processing time and working directory storage in half.