Open smeisler opened 11 months ago
Interesting. Seems to be the cohort/res combo. Can you share sub_reader403_wf/template_iterator_wf/select_xfm/_report/report.rst
?
Node: sub_reader403_wf (template_iterator_wf (select_xfm (utility)
==================================================================
Hierarchy : fmriprep_23_2_wf.sub_reader403_wf.template_iterator_wf.select_xfm
Exec ID : select_xfm.a0
Original Inputs
---------------
* anat2std_xfm : ['/om2/scratch/tmp/oozernov/READER_fitlins/sub-reader403/data/derivatives/fmriprep/sub-reader403/anat/sub-reader403_run-1_from-T1w_to-MNIPediatricAsym_mode-image_xfm.h5', '/om2/scratch/tmp/oozernov/READER_fitlins/sub-reader403/data/derivatives/fmriprep/sub-reader403/anat/sub-reader403_run-1_from-T1w_to-MNI152NLin2009cAsym_mode-image_xfm.h5', '/om2/scratch/tmp/oozernov/READER_fitlins/sub-reader403/data/derivatives/fmriprep/sub-reader403/anat/sub-reader403_run-1_from-T1w_to-MNI152NLin6Asym_mode-image_xfm.h5']
* key : MNIPediatricAsym:cohort-4
* keys : ['MNIPediatricAsym', 'MNI152NLin2009cAsym', 'MNI152NLin6Asym']
I see. So the issue is that we currently pass around template as if it's meaningful on its own, because resolutions are not considered distinct templates (you can register to 1 and resample to 2). But cohorts should be considered distinct templates, so we need to pass around cohort information.
Right now we pass template
and template_spec
out of register_template_wf
:
And this needs to be combined into {template}[:cohort-<cohort>]
. Either that can be done in that workflow or in the fit workflow
Another approach is to pass around template_spec
everywhere we pass around template
and decide what to do with the collection of keys.
One thing that seems clear to me is that we'll need to add cohort-<label>
to the transform file, so that we can distinguish pre-computed transforms.
That will require updates to the path patterns in niworkflows: https://github.com/nipreps/niworkflows/blob/a0af2636521580d84b6b4eb1c32b0cfc4e1bff85/niworkflows/data/nipreps.json#L154-L184
As well as adding the cohort to the how we look up precomputed transforms in:
Which is called here:
If any changes are needed to the last part, they'll need to be propagated to fMRIPrep here:
@smeisler Do you have any time or interest in working into this? Would you need help getting set up with a dev environment? I'm working on another issue today, so I would be glad of any effort you're able to put at this.
cc also @mgxd as this will affect nibabies significantly.
I can give it a shot. I shouldn't have trouble setting up a dev environment (changes will be happening in https://github.com/smeisler/smriprep/tree/fix/cohort_res) but will update here if I run into issues.
Actually before I do too much, I should make sure the dev environment was set up correctly. Steps I took:
smeisler/smriprep
smeisler/smriprep/fix/cohort_res
cd smriprep
, git checkout fix/cohort_res
conda
environement mamba create -n smriprep_dev pip
; mamba activate smriprep_dev
smriprep
in that environment from the cloned repo pip install -e .
Anything I'm missing? I realize it's not containerized, so there might be some oddities with software versions I have on my computer, but hopefully I can at least make the changes to the workflow.
You're going to need to work with niworkflows and you'll at least want to test with fmriprep, so I think you'll want to install all of these:
for REPO in nipreps/{fmriprep,smriprep,niworkflows}; do
git clone https://github.com/$REPO
done
mamba env create -f fmriprep/env.yml # Can use -n to override the default name of fmriprep
mamba env config vars set -n fmriprep FSLDIR=$CONDA_PREFIX # Make sure FSL tools can find each other
mamba activate fmriprep
pip install --no-deps -e ./fmriprep -e ./smriprep -e ./niworkflows
It's not hard to add additional repos after the fact.
You'll also need FreeSurfer, AFNI and Connectome Workbench installed in your PATH, but otherwise you should be good to go.
Edit: Note that I reordered one command. You want to set the environment variable before activating to make sure it gets loaded into your shell.
@smeisler Just checking in about how this is going for you.
Haven't had much time to work on this yet, hope to get to it tomorrow.
Hello @smeisler have you had any luck? I am facing the same issue but using MNIInfant:cohort-2. ValueError: 'MNIInfant:cohort-2' is not in list
Hi @effigies
I have the same issue: ValueError: 'MNIPediatricAsym:cohort-1' is not in list
. Has this issue been solved or can I use other versions released before fmriprep 23.2.1.
Best, Yunhong
Hi @effigies, hi @smeisler,
is there any progress on that issue or workaround? We have the same issues with ValueError: 'MNIPediatricAsym:cohort-6' is not in list
but would like to proceed with fmriprep 23.2 instead switching to an older version.
Thanks in advance,
Florian
If you use the :unstable tag, you can test the next version prior to release.
Hi @effigies, I tested the current : unstable version with MNIPediatricAsym: res-2:cohert-6 . Everything worked fine for me and did not produce any errors, so I'm looking forward to the 22.2.3 release.
Thanks for all the effort,
Florian
The release that will be included in will be 24.0.0.
What happened?
select_xfm
is failing onWhat command did you use?
What version of fMRIPrep are you running?
23.2.0a3
How are you running fMRIPrep?
Singularity
Is your data BIDS valid?
No
Are you reusing any previously computed results?
No
Please copy and paste any relevant log output.
Additional information / screenshots
BIDS Validator outputs below. I don't think any of these errors would be related to the present error.