Preexisting expert options

[chrisgorgo]

When rerunning a hires dataset:

ERROR: there is a pre-existing expert options file and
you have specified an expert options file on the command-line.
If you want to use the file specified on the command-line,
you must run with -xopts-overwrite, or you may edit the 
existing file /root/src/fmriprep/work/workflow_enumerator/sid000080/t1w_preprocessing/Reconstruction/expert.opts (and not use the -expert option).

Standard error:

Return code: 1
Interface ReconAll failed to run.

https://neurostars.org/t/fmriprep-error-interface-reconallrpt-failed-to-run/331/12?u=chrisgorgolewski

[effigies]

This is at the weird convergence of nipype and recon-all's resume functions, and kind of highlights the problem that is FreeSurfer using the output directory as the state directory, and us permitting people to use externally-prepared FreeSurfer subject directories. The short story is that expert options can by default only be defined once, since they're then saved in the FreeSurfer state, so that running recon-all in the future keeps the same parameters. We currently set them in the -autorecon1 phase. Which is a problem if that phase breaks and needs to be restarted, because we can't distinguish that situation from an externally-prepared (if partial) subject directory.

I think the best thing to do here is to split our FreeSurfer pipeline into one extra stage, separating T1/T2 population (recon-all -i ... -T2 ...) from recon-all -autorecon1, and include the expert options in the initial step. This has the advantage that no attempt to set expert options occurs if the directory already exists, and it would be very difficult for this first step to fail and need to be re-run.

There is the weird corner case of someone running the population step manually, for whatever reason, so we perform -autorecon1 with -hires, but never get a chance to specify the expert options file. But maybe this is just overthinking it. We do say in the documentation that we will perform missing steps in the recon-all pipeline. We need to make a note of -hires processing in the docs, and maybe also note that letting FMRIPREP run a partial reconstruction can produce unexpected results?

The other corner case is somebody starts recon-all with hires processing, and wants to switch to --no-submm-recon, but there I think the answer is clearly "delete the subject directory and start over".

[mike21499]

Hi there

I get an error regarding the recon-all. ReconallRPT failed to run. Tested two subjects with version 0.4.2. Attached is the traceback file.
recon_traceback.txt

Do I read it correctly that the solution at the moment is to add the --no-submm-recon flag ?
many thanks, michael

[effigies]

Hi @mike21499 I'm not able to download that recon_traceback.txt. Could you post it as a gist?

[mike21499]

yes
here it is https://gist.github.com/mike21499/ebe7ef6910f8948bad6130b50657d59f

[effigies]

Thanks. It's not clear to me exactly which part failed. Can you also post your <outdir>/freesurfer/sub-01/scripts/recon-all.log?

You're certainly welcome to try running with --no-submm-recon, but you'll need to remove your existing reconstruction attempt (<outdir>/freesurfer/sub-01). (Unfortunately, since -hires has effects at the very beginning of the pipeline, there's no way to reuse your existing run. You could move it into another directory, rather than delete it, if you think you might want that data.)

[mike21499]

OK. the flag --no-submm-recon didn't resolve the problem (after deleting the output folder), it still crashes.
Here's the log:
https://gist.github.com/mike21499/a760c4629a06a1d8b8421fbd108833bd

many thanks for your efforts, michael

[effigies]

Yes, it doesn't look like you're using a sub-millimeter T1w image to start, so we would already not be trying to use the hi-resolution options. The source of the error is still not evident to me from that log. You can try posting a link to your log file to the FreeSurfer mailing list to see if they can find the issue.

Given that the entire pipeline ran (AFAICT), there are two possibilities I can see:

1. Our use of an external skull-stripping pipeline produced a mask that FreeSurfer could not use.
2. There's some issue with your data that FreeSurfer is unable to automatically correct for.

To check for (1), if it isn't evident in the report, you can overlay the brainmask (<outdir>/fmriprep/anat/sub-01_T1w_brainmask.nii.gz) on the preprocessed T1 (.../sub-01_T1w_preproc.nii.gz) in mricron or Freeview, and verify that gray matter hasn't been removed.

For (2), you'll get much better support from the FreeSurfer mailing list. We use it, but they wrote it. :-)

---

As a last-ditch test of whether there's an issue with our pipeline, you can run recon-all -s sub-01 -i <path_to_t1> -all in a new environment.

You can use the following Docker command to keep everything as similar as possible:

mkdir -p /data/freesurfer_test
docker run -it --rm -v <bids_dir>:/bids -v /data/freesurfer_test:/data/freesurfer_test --entry-point=/opt/freesurfer/bin/recon-all poldracklab/fmriprep:0.4.2 -i /bids/sub-01/anat/sub-01_T1w.nii.gz -openmp 6 -parallel -subjid sub-01 -sd /data/freesurfer_test

This will use FreeSurfer's skull-stripping. If this fails, then it's definitely a problem on their end.