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

[REF] Remove unused arguments and simplify CLI #163

Merged
merged 18 commits into from
Dec 4, 2018

Conversation

tsalo
Copy link
Member

@tsalo tsalo commented Nov 30, 2018

Ref. #161, #162.

Changes proposed in this pull request:

  • Change maximum number of iterations for tedica from 200 to 5000, to match how many we ran with mdp (see No convergence after 5000 steps #144).
  • Remove conv argument from tedica and workflow, to use FastICA's default tolerance.
  • Remove cost argument, to use FastICA's default (logcosh).
  • Change argument denoiseTEs to verbose, which will be expanded to toggle output of many intermediate and less-used files, as discussed in Reduce intermediate outputs #17.
  • Change default behavior from performing GSR to not performing GSR.
  • Remove arguments filecsdata and strict.
  • Add gscontrol argument to toggle minimum image regression (t1c) and global signal regression (gsr). One or more algorithms can be used, but the default is to use none.

@codecov
Copy link

codecov bot commented Nov 30, 2018

Codecov Report

Merging #163 into master will decrease coverage by 0.3%.
The diff coverage is 3.84%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #163      +/-   ##
==========================================
- Coverage   52.96%   52.65%   -0.31%     
==========================================
  Files          32       32              
  Lines        1903     1899       -4     
==========================================
- Hits         1008     1000       -8     
- Misses        895      899       +4
Impacted Files Coverage Δ
tedana/model/fit.py 28.81% <0%> (-0.25%) ⬇️
tedana/workflows/tedana.py 11.81% <0%> (-0.19%) ⬇️
tedana/decomposition/eigendecomp.py 11.11% <50%> (+0.3%) ⬆️
tedana/io.py 35.55% <0%> (-1.09%) ⬇️
tedana/utils.py 98.01% <0%> (-0.08%) ⬇️
tedana/tests/test_utils.py 100% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6e21c5d...54946f6. Read the comment docs.

@tsalo
Copy link
Member Author

tsalo commented Nov 30, 2018

CircleCI is failing because GSR is no longer being performed, which means that the files T1gs.nii, glsig.1D, tsoc_nogs.nii, and tsoc_orig.nii are no longer generated.

Also since T1c-GSR is no longer performed by default, the files betas_hik_OC_T1c.nii, dn_ts_OC_T1c.nii, hik_ts_OC_T1c.nii, meica_mix_T1c.1D, and sphis_hik.nii are no longer generated either.

@tsalo tsalo mentioned this pull request Nov 30, 2018
Copy link
Member

@emdupre emdupre left a comment

Choose a reason for hiding this comment

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

This is great ! There are a lot of big changes in here, and it even might make sense to split into two PRs. Overall I had some stylistic comments and a few questions on choices we're making. Thanks for starting this !

tedana/decomposition/eigendecomp.py Show resolved Hide resolved
default=False)
parser.add_argument('--strict',
dest='strict',
parser.add_argument('--gscontrol',
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 not sure why we have both gscontrol and global_denoise arguments. Could you explain what's the benefit, here ?

Copy link
Member Author

Choose a reason for hiding this comment

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

GSR (gscontrol_raw) and T1c-GSR (gscontrol_mmix) are both run by default on the data, rather than treated as competing alternatives to one another. Also, since GSR is run within the pipeline, while T1c-GSR (and someday GODEC, dGSR with rapidtide, etc.) is run after, as a sort of post-processing step.

That said, we can clean this up. Maybe we could allow multiple global denoising steps? E.g.,
--global_denoise gsr t1c if you want to run both.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I think I'd prefer that ! Since they're both aimed at the same outcome, it would make more sense to group them together, in my mind. WDYT ?

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 can do that, but I'm still a little wary of the argument name. Can you think of anything better that global_denoise, denoise, or ws_denoise?

Copy link
Member

Choose a reason for hiding this comment

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

I liked gs_control ! Since it's "controlling" global signal, through various means :)

Copy link
Member Author

Choose a reason for hiding this comment

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

That works, I think. The other methods we'd ultimately consider include rPCA, GODEC, dynamic GSR with rapidtide, aCompCor, and tCompCor. The only ones where gs_control (maybe gscontrol?) would seem kind of weird are aCompCor and tCompCor, but it's not too much of a stretch.

Copy link
Member

Choose a reason for hiding this comment

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

Also, if we're integrating into larger pipelines, many of those already do aCompCor and tCompCor !

Copy link
Member Author

Choose a reason for hiding this comment

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

That's true, and aCompCor actually can't be integrated into tedana without information we don't want to require, although I imagine that a number of denoising steps will need to go inside of tedana the same way that GSR and T1c-GSR are done.

Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest that we can cross that bridge once we fully integrate into some of the larger pipelines :)

tedana/model/fit.py Outdated Show resolved Hide resolved
tedana/decomposition/eigendecomp.py Outdated Show resolved Hide resolved
tedana/workflows/tedana.py Outdated Show resolved Hide resolved
tedana/workflows/tedana.py Show resolved Hide resolved
@emdupre
Copy link
Member

emdupre commented Dec 3, 2018

It looks like we're still adding new individual echo outputs:

> dn_ts_e1.nii
> dn_ts_e2.nii
> dn_ts_e3.nii
> dn_ts_e4.nii
> dn_ts_e5.nii

I thought we moved that to the binder-related PR ? Or is this an older CI output ?

@tsalo
Copy link
Member Author

tsalo commented Dec 3, 2018

That's from moving --denoiseTEs into --verbose. It's unrelated to the binder stuff.

@emdupre
Copy link
Member

emdupre commented Dec 3, 2018

Ah I see -- yeah I guess by using --verbose we are losing some granularity ! This is ok with me, and I suppose we can always revisit later :)

@emdupre
Copy link
Member

emdupre commented Dec 3, 2018

OK, I just want to review the generated artifacts and then I think this would be good to merge ! Do you mind if I squash and merge ?

@tsalo
Copy link
Member Author

tsalo commented Dec 3, 2018

There are a lot of mini-commits, so that's fine with me. To be honest, since we're working to make PRs contained and sort of single-effect changes, I'd love to switch to squash and merge generally. I always make so many commits to check the CI that I feel bad about merging normally.

@emdupre
Copy link
Member

emdupre commented Dec 4, 2018

OK, I checked the files and I think this looks good !

Only remaining issue: we need to update the expected outputs here. Since these will now differ by dataset, we should probably create a separate file for each dataset with the correct filenames -- this will actually be better in the long-run, since it means we'll test more options !

@tsalo
Copy link
Member Author

tsalo commented Dec 4, 2018

Okay, it should be good now.

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.

2 participants