improper handling of dwi by file manager

[shen4brains]

file manager detects *dwi.nii.gz filenames fine but then places dwi files in /unclassified directory and no processing of dwi is performed

for an example, see here: /liberatrix/mcintosh_lab/kshen/ukbb_test/camCAN/sub-CC222797

here is the code block it should not enter: https://github.com/McIntosh-Lab-RRI/tvb-ukbb/blob/8a23e5a741a9188067be8ca3ebfea4736d25a2e0/bb_pipeline_tools/bb_file_manager.py#L546

[noahfl]

fix DWI issue with ADNI3 branch

[noahfl]

@shen4brains I isolated the part of the file manager that handles DWI for quicker and easier debugging. The fileConfig it generates after processing is as follows:

{'dwi': 'dMRI/raw/dwi.nii.gz', 'dwi_bvec': 'dMRI/raw/dwi.bvec', 'dwi_bval': 'dMRI/raw/dwi.bval'}

looking in my subject's dMRI/raw directory, it seems like it put those files in the fileConfig correctly into that directory.

I'm sitll looking at why the files are also being to unclassified but it does seem like the rest of the file manager is processing these correctly, at least for me

[noahfl]

The reason it also copies them into /unclassified is that there's a whole code block the first author wrapped in a try-catch statement. If anything at all goes wrong in that statement, it writes all files still in the list the file manager passes in to /unclassified. *dwi* specific processing happens before that code block but the code block throws an error because it doesn't find the AP/PA directions that the original pipeline is looking for. I added a quick little if-statement at the end that ensures that the *dwi* files don't also go into /unclassified because of whatever happens in the try-catch block. Issue fixed with https://github.com/McIntosh-Lab-RRI/tvb-ukbb/commit/b1234c28e030c90d90c13aa0c373dc94843228a7