MRG: TOPUP update

[satra]

• allows specifying different phase encode directions for individual volumes
• simplifies output naming
• clarifies mandatory requirements
• update workflows that depend on these interfaces

[satra]

@arnaudbore - could you test this branch out? it seems to be fine with the things i am running.

[arnaudbore]

Hi Satra, I still have the error message. I'm working with the master I guess. How can I be sure of the version that I'm using ?

Arnaud

[satra]

assuming you have no local changes in the nipype repo you can do this:

git remote add satra https://github.com/satra/nipype.git
git fetch satra
git checkout -b fix/eddy satra/fix/eddy

[arnaudbore]

I'm sorry satra it doesn't work well. I still have the error message Look what I'm doing:

git clone https://github.com/nipy/nipype.git
cd nipype
git remote add satra https://github.com/satra/nipype.git
git fetch satra
git checkout -b fix/eddy satra/fix/eddy
and finally sudo python2.7 setup.py install

I looked into /usr/local/lib/python2.7/dist-packages/nipype and the files that you changed were actually changed so I think I've done it right but I'm not familiar with git so maybe I'm forgetting something...

Thank you for your help.

[oesteban]

Hi there,

I'm able to help with this by now. What is the status of this right now?, referring to this initial guidelines:

allows specifying different phase encode directions for individual volumes
simplifies output naming
clarifies mandatory requirements
todo:
test for encoding file
update workflows that depend on these interfaces

[arnaudbore]

Hi,

When I run the topup function with a specific output name it raises an error but different from what we had so far so I think satra fixed the output naming. If I use a differect dirrectory than the current one for the output it still raises me an error because it's looking for the output file in the current directory.

Thank you
Arnaud

[satra]

@oesteban and @arnaudbore - this request is ready for a good review. since topup takes a long time to run, it would be nice to have a minimal regression test for this. anyone has a low resolution dataset to test this with?

[oesteban]

Yes, we could (with permission of @ecaruyer) include a low-res version of Phantomas / paper (ISMRM14), to test topup and also any other dwi-derived interface/workflow.

I've used it in this paper (ISBI14), so the test is almost written already (that paper is actually the reason why I implemented that scaffold of an interface for topup).

[ecaruyer]

Hi all,

Sure, the tool is here to be shared! If you could simply somewhere keep a ref to the phantomas project home on github https://github.com/ecaruyer/phantomas or on my website http://www.emmanuelcaruyer.com/phantomas.php

[satra]

@oesteban - i'll merge this and open a different pr for regression tests for nipype.

[oesteban]

Sounds good :)

[oesteban]

I wrote an example that uses TOPUP here: https://github.com/oesteban/nipype/blob/enh/NewEPIArtifactCorrections/examples/dmri_preprocessing.py

And it works nicely as regards TOPUP (motion correction is not very good due to FLIRT limitations, though)