Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Use new DerivativesDataSink from NiWorkflows 1.2.0 #2114

Merged
merged 9 commits into from
May 7, 2020

Conversation

oesteban
Copy link
Member

This PR integrates the new API that will be released with 1.2.0.

References: nipreps/niworkflows#507

Changes proposed in this pull request

Documentation that should be reviewed

@auto-comment
Copy link

auto-comment bot commented Apr 30, 2020

Thank your for raising your pull request.

Some of the fMRIPRep maintainers will review your changes as soon as time permits.
I'm attaching below a Review Checklist for the reviewers, to check off during the
review.

PR Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work.

Please check what applies in the following aspects of the PR:

Code documentation

  • New functions and modules are documented following the guidelines.
  • Existing code required amendments in documentation and has been updated.
  • Sufficient inline comments ensure readability by other contributors in the long term.

Documentation site

  • The modifications to fMRIPrep in this PR do not require extra documentation. This is a common situation when a bug fix that does not change the code base substantially is submitted.
  • This PR requires documentation. The corresponding documentation will be submitted as an additional PR in the future.
  • This PR requires extra documentation, and will be included within this PR. Please check the boxes that apply best:
    • An existing feature is substantially modified, changing the interface and/or logic of a module.
    • A new feature is being added, therefore full documentation of it will be included
    • This PR addresses an error in existing documentation.
  • Yes, all expected sections of documentation were generated by the CI build, and look as expected

Tests

  • The new functionalities in this PR are covered by the existing tests
  • New test batteries have been included with this PR

Data

  • This PR does not require any additional data to be uploaded to OSF.
  • This PR requires additional data for tests.

Dependencies: smriprep

  • This PR does not require any update on smriprep; or
  • smriprep has correctly been pinned.

Dependencies: niworkflows

  • This PR does not require any update on niworkflows; or
  • niworkflows has correctly been pinned.

Dependencies: sdcflows

  • This PR does not require any update on sdcflows; or
  • sdcflows has correctly been pinned.

Dependencies: Nipype

  • This PR does not require any update on nipype; or
  • nipype has correctly been pinned.

Dependencies: other

  • This PR does not require any update on other dependencies; or
  • other dependencies have correctly been pinned.

Reports generated within CI tests

  • Yes, I have checked the reports of ds005 and they are not modified or the changes are as expected
  • Yes, I have checked the reports of ds054 and they are not modified or the changes are as expected
  • Yes, I have checked the reports of ds010 and they are not modified or the changes are as expected

@oesteban oesteban force-pushed the enh/new-datasinks branch 3 times, most recently from 45ccd1c to 83d4754 Compare May 2, 2020 16:46
Copy link
Member Author

@oesteban oesteban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the PR is working locally and I have high expectations that it'll work on Circle. I've left a few comments to make your reviews a bit easier, hope that helps.

@@ -9,69 +9,69 @@ fmriprep/logs/CITATION.md
fmriprep/logs/CITATION.tex
fmriprep/sub-01
fmriprep/sub-01/func
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-01_AROMAnoiseICs.csv
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-01_desc-confounds_regressors.json
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pybids sanitizes the zero padding, and I'm fine with it - others?

fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-02_space-T1w_desc-brain_mask.nii.gz
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-02_space-T1w_desc-preproc_bold.json
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-02_space-T1w_desc-preproc_bold.nii.gz
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-1_AROMAnoiseICs.csv
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is pretty nonstandard (even w.r.t. any current draft). Should we fix this in a separate PR, now that the implementation will be flexible enough to just update the inputs to the datasink?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do a separate PR, because we need to talk through the consequences with interested users.

fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-1_desc-confounds_regressors.json
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-1_desc-confounds_regressors.tsv
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-1_desc-MELODIC_mixing.tsv
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-1_space-fsaverage5_hemi-L_bold.func.gii
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've also added this as a default pattern:

  • hemi-X.func.gii -> hemi-X_bold.func.gii

The reason is that the suffix was being missed. In case you're wondering why I didn't add a _T1w suffix to the .surf.gii of anatomical derivatives, the reason is that .surf.gii only contains geometrical information, so there's no concept of modality expressed by the suffix. One less theoretical reason is that finding _T1w.surf.gii implies the surface was extracted from a T1w and, for instance FLAIR or T2w were not used. Agreed this is not a super-solid argument, but I believe should be enough to feel comfortable with the new naming as regards GIFTIs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mgxd @effigies, just double-checking you did not oversee this one, as it could be controversial.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. Yeah, maybe let's not do this until we finalize derivatives, to minimize the number of times we change derivatives.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default pattern is already written in niworkflows (which means, rolling back requires one more PR cycle). In addition, the new pattern would be more regular so hopefully more likely to be in line with the finalized derivatives.

If the reason to roll back is just practical (i.e., the reason to introduce this change is not counterargued), I'd rather keep it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with this. It looks like it's not covered explicitly anywhere in the derivatives draft, so we should make a point to argue for it.

fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-2_desc-confounds_regressors.json
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-2_desc-confounds_regressors.tsv
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-2_desc-MELODIC_mixing.tsv
fmriprep/sub-01/func/sub-01_task-mixedgamblestask_run-2_space-fsaverage5_hemi-L_bold.func.gii
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly to the AROMA noise components, we might want to update this and generate space-fsaverage_den-10k here (for a future PR).

@@ -50,7 +50,6 @@ single reference template (see `Longitudinal processing`_).
('T1w', {}),
('fsnative', {})
]),
reportlets_dir='.',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reportlets can now be written out directly to <output>/fmriprep/sub-xx/figures/

@@ -256,60 +256,133 @@ def init_func_derivatives_wf(

fs_outputs = spaces.cached.get_fs_spaces()
if freesurfer and fs_outputs:
from niworkflows.interfaces.surf import GiftiNameSource
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't removed this for backwards compatibility, but the new Path2BIDS should simplify its logic (no need anymore for building up the new pattern).

])

return workflow


def init_bold_preproc_report_wf(mem_gb, reportlets_dir, name='bold_preproc_report_wf'):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is a bit out of scope. This workflow is not used anywhere (I wrote it when there were plans to show a before/after reportlet without/with preprocessing. This will potentially be used at some point, and I thought it was more findable here in the outputs module.

setup.cfg Outdated Show resolved Hide resolved
setup.cfg Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
@oesteban oesteban marked this pull request as ready for review May 3, 2020 14:28
Copy link
Member

@effigies effigies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ran out of time to finish this before the meeting. Let's also revert the unnecessary setup.* changes here, and that will make sure we test the latest commit over at niworkflows.

Will finish review this afternoon.

@@ -826,7 +826,7 @@ def init_func_preproc_wf(bold_file):
# Fill-in datasinks of reportlets seen so far
for node in workflow.list_node_names():
if node.split('.')[-1].startswith('ds_report'):
workflow.get_node(node).inputs.base_directory = reportlets_dir
workflow.get_node(node).inputs.base_directory = output_dir
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will also put HTML snippets in figures/, right?

Copy link
Member

@effigies effigies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One additional comment.

fmriprep/workflows/bold/outputs.py Show resolved Hide resolved
@oesteban oesteban force-pushed the enh/new-datasinks branch 2 times, most recently from 48bd94e to a86d1ef Compare May 7, 2020 17:08
@oesteban oesteban force-pushed the enh/new-datasinks branch from a86d1ef to 7aa3453 Compare May 7, 2020 17:10
@oesteban
Copy link
Member Author

oesteban commented May 7, 2020

This is looking good. Can we just merge now? Last call for last minute reviews?

@effigies
Copy link
Member

effigies commented May 7, 2020

Let's do it.

@oesteban
Copy link
Member Author

oesteban commented May 7, 2020

Okay -
brace yourselves

(sorry, couldn't hold it)

@oesteban oesteban merged commit 3712c39 into nipreps:master May 7, 2020
@oesteban oesteban deleted the enh/new-datasinks branch May 7, 2020 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants