Qsiprep 0.22.0: unusal output directory structure with --recon-only

Summary of what happened:

I’m attempting to get structural connectivity matrices for some DTI data. I ran a first pass using qsiprep 0.21.4 for preprocessing, and qsiprep 0.19.1 for reconstruction (see Qsiprep –recon-only: dsi_studio_gqi works but mrtrix_singleshell_ss3t_ACT-hsvs fails)[Qsiprep --recon-only: dsi_studio_gqi works but mrtrix_singleshell_ss3t_ACT-hsvs fails - #5 by Steven), both using singularity containers. Unfortunately, I had set the output resolution to 2mm isotropic (voxel dimensions of original dwi are 0.95x0.95x2.5), and I’ve seen recommendations that it be closer to 1mm (e.g., 1.25mm). So I’m looking at re-running the full analysis (preprocessing and reconstruction) at a finer resolution.

The newly released qsiprep 0.22.0 has some new features and improvements that I would like to take advantage of: it provides the sift2 mu constant that I originally had to fish out of the working directory (Qsiprep recon: have sift2 structural connectivity matrices been normalized by mu?), and, according to the release notes, a fix for the freesurfer ingression’s impact on HSVS processing (don’t know if this problem was present in version 0.19.1). With 0.22.0, preprocessing seems to run fine. However, after running qsiprep --recon-only the output is split across three directories in the derivatives output: qsirecon-anat/ and qsirecon-MRtrix3_fork-SS3T_act-HSVS/, along with the expected qsirecon/ directory. The latter just contains some log information, whereas a lot of the expected outputs are in the other two directories. I suspect the qsirecon-anat/ and qsirecon-MRtrix3_fork-SS3T_act-HSVS/ were destined to be merged into the expected qsirecon directory, but not sure.

I also run into (still) the dreaded error recon_plot error that seems to plague all singularity-based runs. I’ve tried the --writable-tmpfs approach suggested in ODF reports, but I haven’t gotten that to work. So at the moment, I’m running with --skip-odf-reports, and hope to maybe work out the reports later, with --reports-only option. Unfortunately, qsiprep throws an error on this report run because it can’t find any files to work with in the expected qsirecon directory.

I realize 0.22.0 is the initial release, and perhaps I should treat it as a sort of beta version. (Or, as in the old days, an even number version that signals an unstable branch, not to be used in production.)

So: should I give up on 0.22.0? Or can I use 0.22.0 for preprocessing, but then drop back down to 0.19.1 for the reconstruction? And has anyone else been able to use the --write-tmpfs option to succeed with the generation of the ODF reports within singularity?

Thanks so much!

  • Daniel

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

PASTE CODE HERE
singularity run \
      --writable-tmpfs \
      --cleanenv \
      --env TEMPLATEFLOW_HOME=/opt/templateflow \
      --bind "${TEMPLATEFLOW_HOME:-$HOME/.cache/templateflow}:/opt/templateflow" \
      --bind "${FREESURFER_LICENSE}":/license.txt:ro \
      --bind "${inpt_bids_dir}":/bids:ro \
      --bind "${inpt_dwis_dir}":/dwis:ro \
      --bind "${inpt_free_dir}":/free:ro \
      --bind "${outp_dir}":/outp \
      --bind "${outp_temp_dir}:/tmp" \
      --bind "${outp_work_dir}:/work" \
      --bind /tmp/.X11-unix/:/tmp.X11-unix \
      "${QSIPREP_SINGULARITY_IMAGE}" \
      /bids  /outp  participant \
      --verbose \
      --verbose \
      --recon-only \
      --stop-on-first-crash \
      --skip-odf-reports \
      --work-dir             /work \
      --recon-input          /dwis \
      --recon-spec           mrtrix_singleshell_ss3t_ACT-hsvs \
      --mem-mb               20000 \
      --nthreads             8 \
      --omp-nthreads         7 \
      --fs-license-file      /license.txt \
      --freesurfer-input     /free \
      --participant-label    "${subj}"

Version:

0.22.0

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

Singularity

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):

...
240729-01:56:58,753 nipype.workflow IMPORTANT:
         QSIPrep finished successfully!
240729-01:56:58,780 nipype.workflow IMPORTANT:
         Works derived from this QSIPrep execution should include the boilerplate text found in <OUTPUT_PATH>/logs/CITATION.md.

Screenshots / relevant information:


Hi @silophophe,

The splitting is intentional.

Best,
Steven