Use config.toml to determine settings when creating full results from minimal mode

[jbwexler]

What would you like to see added in fMRIPrep?

There are many use cases in which users would want to have a generic command that can get full results from minimal mode results, without having to look back at the original command and include the correct settings used (ie --use-syn-sdc or --ignore fmap-jacobian). Perhaps there could be a setting like --reuse-settings that would pull settings from config.toml.

Do you have any interest in helping implement the feature?

Maybe?

Additional information / screenshots

No response

[effigies]

Hmm. This is not actually in the output, it's put into the scratch directory. I think it makes more sense to put into $OUT/logs.

[mgxd]

isn't this already doable with --config-file <previous-config> --level full

[effigies]

I was thinking of testing that when I realized that we don't save the previous configs to the output directory.

[mgxd]

we do - it's in the subject's log folder / run-uuid / fmriprep.toml

[effigies]

Oh, cool. I would not have thought to look there. So we emit it multiple times if a job runs multiple subjects? I feel like under the top level log directory with timestamped (instead of or in addition to UUID) folders would be more readily accessible.

[jbwexler]

It's turned out to be surprisingly complicated to automate the expansion of something like sub-01/log/*/fmriprep.toml as an input in my workflow (using ReproMan). My best option is probably to add it to the command array after reproman run, but before the job starts. I wonder if others would find it useful to have an option for --config-file that looks in the default location for that subject?

[jbwexler]

Also, fmriprep.toml uses absolute paths and not all the paths can be overridden with command line arguments. For example, log_dir.

[jbwexler]

After some more testing, it seems that log_dir isn't an issue, as it gets determined by the fmriprep_dir. The problem is that the fmriprep_dir from the config file isn't getting overridden by the command line argument. Conversely, the notrack=false that is present in the config file doesn't get utilized, instead reverting to the default notrack=true.