bids-apps / MRtrix3_connectome

Generate subject connectomes from raw BIDS data & perform inter-subject connection density normalisation, using the MRtrix3 software package.
http://www.mrtrix.org/
Apache License 2.0
48 stars 26 forks source link

preproc - Fieldmaps #117

Closed lizannea closed 1 year ago

lizannea commented 1 year ago

Dear experts,

I am trying to run the preprocessing MRtrix3_connectome pipeline on one subject, which gave me the following error message: image

It stops with the field maps.

To see if it was due to the induced amount of fmaps (Diffaltpe, magnitude 1, magnitude 2, phasediff), I re-ran the script on the same participant after moved the magnitude 1, magnitude 2 and phasediff (intended for DWI and functional) files temporally to a different location. Which didn’t change the error message. image

--debug files: command.txt cwd.txt log.txt

Would you have any suggestions how to solve this?

Thank you!

@civier @DavidjWhite33

lizannea commented 1 year ago

To add to my previous post, I tried to run the container on one participant from two different datasets (ARLA, Fonterra) with the debug flag on. In all cases I received the same error massages (see below for the terminal contents as a text file for each).

ARLA: MRtrix_connectome:0.5.0: Arla_MRtrix3_connectome_0.5.0.txt command.txt cwd.txt

MRtrix_connectome:0.5.3: ARLA_MRtrix3_connectome_0.5.3.txt command.txt cwd.txt

Fonterra: MRtrix_connectome version 0.5.0: Fonterra_MRtrix3_connectome_0.5.0.txt command.txt cwd.txt

MRtrix_connectome version 0.5.3: Fonterra_MRtrix3_connectome_0.5.3.txt command.txt cwd.txt

Do you have any suggestions how to solve this or what the next step could be? I have shared data from a test subject with you through CloudStor in case that would be helpful.

Thank you so much,

Lizanne

@civier @DavidjWhite33

Lestropie commented 1 year ago

Hi Lizaanne,

  1. The App is not capable of making use of dual-gradient-echo field maps. This is a long-outstanding limitation with MRtrix3's dwifslpreproc, which is a more appropriate location for that functionality; MRtrix3_connectome should ideally just be capturing those data if present and passing them to dwifslpreproc. https://github.com/MRtrix3/mrtrix3/issues/1758 I did try to lay down some code for this at some point, but I don't recall how far I got. I also have a feeling that that code was never pushed and resides on a system in which one of the HDDs just died...

  2. Looks like over and above that the code structure is not quite correct. I expect #118 to at least prevent the unhandled exception at that location. But even if you use this code, I still expect a subsequent failure to occur for your data due to point 1.

Rob

lizannea commented 1 year ago

Hi Rob,

Thank you for your response and flagging the issue with my code structure.

Lizanne

Lestropie commented 1 year ago

Issue was with my code structure :upside_down_face:

Is it possible to run the updated code in #118 on your data and confirm that it at least progresses past the reported unhanded exception?

lizannea commented 1 year ago

Hi Rob,

When running the updated python code, I unfortunately still received the unhandled Python exception.

I was wondering what your recommendation is about up and down sampling when using multiple datasets. The studies have different resolutions and one is isometric. I have included an overview of the included studies. We want to using different connectome MRtrix tools.

What would be the ideal resolution and should we bring the different studies to the same resolution?

Thank you so much,

Lizanne

image

Lestropie commented 1 year ago

@lizannea For the sake of connectome construction, there's no need to convert all data to a common spatial resolution, since there's no central template to which all data are warped for spatial correspondence. Native resolution is typically best. There's an argument for resampling Study 3 to eg. 1.9 x 1.9 x 1.5 mm to try to recover some resolution in I-S axis by interpolating DWI data rather than FODs; but hard to know for sure, and I wouldn't convert to 2mm just for consistency with other data.

Lestropie commented 1 year ago

@lizannea I made some sample data and the change in #118 resolved the issue in the case where IntendedFor is a list and one of the DWIs appears in that list. So not sure why the error persisted in your case; is it possible that you were not running the version with the updated code?