Skip to content

FIX: Allow max_shnot to be set (auto mode) #2940

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

Merged
merged 2 commits into from
Jun 11, 2019
Merged

Conversation

garikoitz
Copy link
Contributor

@garikoitz garikoitz commented May 31, 2019

For further information and why it can be left unset see http://community.mrtrix.org/t/lmax-for-dwi2response-and-dwi2fod/1099/4

cc / @oesteban

Summary

Fixes # .

List of changes proposed in this PR (pull-request)

Acknowledgment

  • (Mandatory) I acknowledge that this contribution will be available under the Apache 2 license.

@codecov-io
Copy link

codecov-io commented Jun 1, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@460c1bb). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##             master    #2940   +/-   ##
=========================================
  Coverage          ?   67.59%           
=========================================
  Files             ?      344           
  Lines             ?    43747           
  Branches          ?     5456           
=========================================
  Hits              ?    29572           
  Misses            ?    13466           
  Partials          ?      709
Flag Coverage Δ
#smoketests 50.37% <ø> (?)
#unittests 65.03% <ø> (?)
Impacted Files Coverage Δ
nipype/interfaces/mrtrix3/preprocess.py 79.64% <ø> (ø)

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 460c1bb...68952d4. Read the comment docs.

@oesteban
Copy link
Contributor

oesteban commented Jun 3, 2019

@satra, @effigies, @mgxd anything against merging this one?

@effigies
Copy link
Member

effigies commented Jun 3, 2019

The idea of setting the defaults is for provenance and to encode behavior so that the same interface invocation should get basically the same behavior, even if the underlying software changes its default in a future version. Is there some invocation that actually gets default behavior?

@oesteban
Copy link
Contributor

oesteban commented Jun 4, 2019

I don't know the original default behavior* but at some point, the default has become some sort of "auto" mode, triggered when the flag is not present. Therefore, after this PR the interface will actually implement their default.

* I think it would crash if none given, and I defined 8 as a typically used value.

@effigies
Copy link
Member

effigies commented Jun 4, 2019

Yes. To put a finer point on my questions:

  1. Is it possible to pass a non-blank value that is equivalent to leaving it blank?
  2. If so, does it make sense to set that to the default, so that the interface can maintain consistent behavior in case the default changes again?

We have interfaces that go both ways on question 2, but I thought the preference was to use usedefault when the defaults correspond to specific arguments, for the reasons I mentioned above.

Not trying to hold this up. Feel free to merge, if the answer to either question is no.

@oesteban
Copy link
Contributor

oesteban commented Jun 5, 2019

  1. Is it possible to pass a non-blank value that is equivalent to leaving it blank?

I think that is not possible, after interpreting this: https://mrtrix.readthedocs.io/en/latest/concepts/sh_basis_lmax.html

For any command or script operating on data in the spherical harmonic basis, it should be possible to manually set the maximum harmonic degree of the output using the -lmax command-line option. If this is not provided, then an appropriate value will be determined automatically.

I haven't found better documentation elsewhere.

  1. If so, does it make sense to set that to the default, so that the interface can maintain consistent behavior in case the default changes again?

I don't think this is the case.

@oesteban oesteban merged commit 7fbc7cb into nipy:master Jun 11, 2019
@effigies effigies added this to the 1.2.1 milestone Aug 16, 2019
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.

4 participants