search

bbfrederick / rapidtide

rapidtide - a suite of programs for doing time lag correlation analysis on fMRI data
Apache License 2.0
70 stars 14 forks source link

Generate citable reports within workflows #32

Open tsalo opened 3 years ago

tsalo commented 3 years ago

Is your feature request related to a problem? Please describe. There is a very large parameter space for rapidtide workflows. To improve transparency, it would be nice to generate citable reports. It's also great to be able to just copy the text over to your methods section, as is done with BIDS Apps like fMRIPrep (generally with a note like this about using it verbatim).

Describe the solution you'd like Two options that have worked for me in the past are:

  1. Make a formattable paragraph in the workflow script, then format the paragraph with the argument values as necessary. I've done this in NiMARE but it's not very scalable since you're adding a lot of text and you have to know what the paragraph should look like for every version of the parameters.
  2. Using logging to build reports based on individual functions that are called. We do this in tedana, and I prefer this approach, but it requires solid modularization.
    • For certain steps that may be run several times, this can require a bit of effort to prevent duplicate sentences in the report, but it's definitely doable.

Describe alternatives you've considered A more elegant solution is to leverage Nipype workflows like fMRIPrep does. Specifically, it uses a derived class called LiterateWorkflow that allows individual workflows to have "description" attributes that can be compiled and written to a file by a larger, wrapper workflow. However, short of breaking rapidtide up into individual mini-workflows and wrapping those in Nipype workflows, this isn't feasible here. (It's also hard to access parameters within these workflows, which makes writing specific descriptions harder.)

Additional context None.

bbfrederick commented 3 years ago

Hmm. Good idea, but I'll have to think how to implement it. Every single tunable parameter is recorded in the options file (which is a text dump of the options dictionary in this version, but defaults to json going forward. I could put in a routine to parse that and generate the text. That will probably have to wait for 2.0 (the dev version, 2.0 alpha is way ahead of master, but doesn't yet have this. I'll mull over how best to do this).

tsalo commented 3 years ago

It's definitely not an easy feature to add. Please let me know if I can help.