Mathias Goncalves

Currently running into the following: ``` Node: nibabies_23_2_wf.single_subject_XXXXXX_XX_wf.infant_anat_wf.sphere_reg_wf.msm_sulc_wf.msmsulc Working directory: /wd/nibabies_23_2_wf/single_subject_XXXXXX_XX_wf/infant_anat_wf/sphere_reg_wf/msm_sulc_wf/msmsulc Node inputs: args = config_file = /opt/conda/envs/nibabies/lib/python3.10/site-packages/smriprep/data/msm/MSMSulcStrainFinalconf environ = {} in_data = in_mesh = ['/wd/nibabies_23_2_wf/single_subject_XXXXXX_XX_wf/infant_anat_wf/sphere_reg_wf/msm_sulc_wf/apply_surface_affine/mapflow/_apply_surface_affine0/lh.sphere_converted_xformed.surf.gii', '/wd/nibabies_23_2_wf/single_subject_XXXXXX_XX_wf/infant_anat_wf/sphere_reg_wf/msm_sulc_wf/apply_surface_affine/mapflow/_apply_surface_affine1/rh.sphere_converted_xformed.surf.gii'] in_register = in_weight...

Update: The BCP CI output file `sub-01_ses-1mo_run-001_desc-aseg_dseg.nii.gz` is missing labels for accumbens (left - 28, right - 58), which is expected for CIFTI output.

Update: `metric`/`metric_weight` will likely need to be converted to list of lists. https://github.com/nipreps/nibabies/blob/0c07d6335eba1a136899006659ef18192c316723/nibabies/data/within_subject_t1t2.json#L7-L8

pinging @ericfeczko

what is the default Smoothing FWHM used in the dcan pipeline? 2?

From [`MNIInfant` docs](http://nist.mni.mcgill.ca/infant-atlases-0-4-5-years/): > NOTE that these templates are smaller then standard MNI-152 template, so if you use them to perform registration in stereotaxic space it will be different coordinate...

another troublesome interface: [`sdcflows.interfaces.bspline.Coefficients2Warp`](https://github.com/nipreps/sdcflows/blob/17feeb3056448067ff7a1f80a7717f7a5b1194a0/sdcflows/interfaces/bspline.py#L223) memory_profiler ``` Line # Mem usage Increment Occurences Line Contents ============================================================ 11 57.5 MiB 57.5 MiB 1 @profile 12 def coeff(): 13 57.5 MiB 0.0 MiB...

Fully on board with this - we need to regularly exercise each workflow branch to avoid introducing problems on patches. I like the fmriprep approach as it is a relatively...

hey @tsalo - awesome! `docker/fit-apply` merge is imminent, so definitely that one

@mwaskom looks like there is no default value for `fieldcoeff_file` - thus it doesn't get extracted for the `outputs` dict unless explicitly specified since it's left `Undefined`