✨ Re-assess `abcd-options` related nodeblock designs and boundaries

[Steve Giavasis]

Related problem

Related to #2029.

The nodeblocks that were developed in a rapid fashion for the harmonization with the DCAN ABCD pipeline are large and rigid, and also lack a clear documented purpose (although a purpose does indeed exist for each).

In addition, they create a range of outputs that are too specific for use only in other abcd-options related nodeblocks, and they also result in multiple versions of similar data in one pipeline (ex. multiple brain masks) which are unclear as to how they were produced or why.

The main problems caused by this:

• Users are unsure if and why they should select these pipeline options when considered, and what is unique about them (other than replicating the ABCD pipeline).
• Users and developers are unsure which brain masks are for what and why there are more than one.
• Pipeline connection errors continue to arise repeatedly during testing and development due to the overly-specific data labels.

Proposed feature

The abcd-options related nodeblocks should be re-assessed for the possibility of breaking them down into smaller functional blocks, or combining functionality from multiple nodeblocks into one.

These nodeblocks include:

• Anatomical preproc
  • brain_mask_freesurfer_abcd
  • brain_mask_acpc_freesurfer_abcd
  • freesurfer_abcd_preproc
  • correct_restore_brain_intensity_abcd
• Functional preproc
  • bold_mask_anatomical_based
• Registration
  • overwrite_transform_anat_to_template
  • transform_timeseries_to_T1template_abcd

The principles to keep in mind guiding this, while looking at each of the outputs:

• Does the output have a unique purpose or function? Is there a reason a user would select to create this data for its own sake? (If so, consider converting into its own nodeblock).
• Is the output specifically tied to a "later" nodeblock or very unique to other nodeblocks? (If so, consider putting all operations on this data in one nodeblock if possible and sensible).

For example:

• What does the output desc-ABCDpreproc_T1w mean? Why is it the preferential input for Freesurfer's recon-all? We may know as the C-PAC developers, but this is not clear to users.
• What about the output desc-restore-brain_T1w?
• For what reasons would a user select overwrite_transform_anat_to_template? etc.

Acceptance criteria

The acceptance criteria will have to take more shape as we define what needs to be changed.

But a more general set of acceptance criteria will look like:

• No more coupling of separate nodeblocks.
• Users can clearly understand what each of these nodeblocks are used for, and why they should want to select them.
• No redundant outputs, unless there is a reason for multiple - in which case the reason is clearly documented.

Alternatives

No response

Additional context

No response