-
Notifications
You must be signed in to change notification settings - Fork 533
[ENH] Issue 3345: Adding FreeSurfer longitudinal interfaces #3529
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
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #3529 +/- ##
==========================================
- Coverage 63.20% 63.19% -0.02%
==========================================
Files 308 308
Lines 40770 40792 +22
Branches 5480 5645 +165
==========================================
+ Hits 25770 25779 +9
Misses 14000 14000
- Partials 1000 1013 +13
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very good. I like your proposal for separating the base and long interfaces from the main one, which avoids overcharging the main interface which is already quite complex.
I was wondering whether you had tested a complete Nipype
workflow for FS longitudinal composed of all three tasks? I have made a suggestion which could improve composition.
|
||
>>> from nipype.interfaces.freesurfer.longitudinal import LongReconAll | ||
>>> longrecon = LongReconAll() | ||
>>> longrecon.inputs.long_id = ("ses-1","sub-template") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a workflow construction perspective, providing long_id
as tuple might make composition from all
, base
and then long
interfaces more difficult.
In pydra-freesurfer, I have split it as longitudinal_timepoint_id
and longitudinal_template_id
and required the latter be specified if the former is. This way they are both exposed as separate input to the interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that's a very good point. I can separate those out. I tend to run each step separately, but I will make that change and test out a full workflow with all three steps when I can...should definitely make sure that works with this setup.
Update on this: I was able to successfully run a nipype workflow with all longitudinal steps. (Not sure if I should document the relevant pieces of that somewhere). I think I can remove the [WIP], not sure if I need to update anything else or if anybody else has comments, perhaps @0rC0? I know you had worked on this previously as well... |
That's great.
One suggestion would be to post a working snippet here with like all 3 instances of |
This is hopefully enough to help people get started and should be close enough to what I actually ran...
|
.zenodo.json
Outdated
}, | ||
{ | ||
"affiliation": "Department of Neurosurgery, Medical College of Wisconsin", | ||
"name": "Espana, Lezlie", | ||
"orcid": "0000-0002-6466-4653" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest to modify the zenodo file within its own commit. Also, I believe you should keep Satra as last author.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh of course, my mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this initial proposal. This first iteration looks very good and your snippet shows very well how it can be all composed.
I have a few suggestions wrt to namings, constraints and some typos.
Co-authored-by: Ghislain Vaillant <ghisvail@users.noreply.github.com>
Co-authored-by: Ghislain Vaillant <ghisvail@users.noreply.github.com>
Co-authored-by: Ghislain Vaillant <ghisvail@users.noreply.github.com>
My suggestions did not include updates to the doctests, so they will likely fail. Could you update them please? You will also need to refresh the test suite generated automatically from the specs. |
Yes, working on that now. :) |
I don't know that we can take out the subject_id from the input spec...We're inheriting from the ReconAll spec which has a default subject_id of "recon-all" so I think we need to override it. Unless there's another way to negate that? Edit: Unless we turn off the "usedefault" in the original spec of course. Was just trying not to mess too much with the original. |
I will have a look at it next week.
If we can't, then that may be a sign Base and Long specs should be merged into the main ReconAll with some appropriate |
Please merge master to fix the tests. |
It looks very good to me. At the beginning of the new year I can do some more tests. |
Hi! Any chance we can get this reviewed? |
@ghisvail Were you reviewing this? Or would you like me to? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last suggestion to improve the robustness of the interface.
The rest looks good to me. Nice work 👏
@@ -927,6 +930,29 @@ class ReconAllInputSpec(CommandLineInputSpec): | |||
) | |||
flags = InputMultiPath(traits.Str, argstr="%s", desc="additional parameters") | |||
|
|||
# Longitudinal runs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might need to introduce additional constraints to avoid using cross-sectional specific arguments with base and long modes.
I am thinking of the T1_files
, T2_file
and FLAIR_file
parameters at least. These should probably get a requirement on subject_id
, which would achieve what we want thanks to your xor
constraints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That didn't cross my mind but excellent thought. I've add some requires and will test some variations next week to make sure that works as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to be merged. I have highlighted a few formatting nuggets which black
might complain about.
Co-authored-by: Ghislain Vaillant <ghisvail@users.noreply.github.com>
@effigies I don't have the privileges to merge this PR. Could you take care of it? 🙏 |
Looks like CI is broken; apologies. @ghisvail If you have time to look into this, it would be appreciated. Otherwise I'll get to it this week. |
It looks like issues with CI started to surface on the last two merged PRs. CI complains that jobs no longer find Perhaps we could refactor CI to not use a dedicated venv? Maybe there are good reasons for it, I have just never seen it done in practice with GHA since each job is executed in a separate throwaway container anyway. It might also make things considerably simpler, as I find the current flow of CI scripts quite hard to follow. Let me know what you think. |
Been a bit, but I got CI working (except CircleCI...) so hopefully any red checks you see are actionable. |
Summary
Adds FreeSurfer longitudinal interfaces per issue #3345.
List of changes proposed in this PR (pull-request)