jerdra / boonstim Goto Github PK

Nextflow is releasing a new version of the scripting language "DSL 2" which allows us to:

1. Define Nextflow processes as routines to use later
2. Allow the use of sub-workflows
3. Allow using "include" (similar to import in python)

The use of sub-workflows is especially important since it allows us to create substitute-able workflows when creating weight functions for optimization.

This issue should be done after the initial release, since the focus is currently on releasing a mentalizing network targeting pipeline first.

After #1, the next step is to generate a surface patch above the region of dense positive functional connectivity over DMPFC for each subject. This can be done in a similar manner to:

https://github.com/tigrlab/rtms_optimize/notebooks/python2/extract_surface_patch.ipynb

However the surface patch extraction routine should be able to take in any ribbon-constrained NIFTI file. Alternatively we could just use the weights across each node on the mesh, find the centroid spatial position then project from there.

There is a current on-going issue where Ciftify and fMRIPrep outputs (fully stored in cache) are not being fully transferred to the output directory. Only some of the top-level directories are being transferred, but not the complete output hierarchy.

Providing a script/mode of running a full end-to-end test (perhaps using a subject hosted on OSF) would be useful for facilitating end-to-end testing of BOONStim in terms of:

• Whether BOONStim will successfully run on a given system
• Performance metrics (run-time) on a given system

The standard pipeline at the moment is the ciftify/fmriprep route, however some acquisitions are better processed using HCP-Pipelines (HCP and potentially ABCD sequences).

The rest of the pipeline is agnostic to T1 processing and surface generation (as long as they're freesurfer compatible).

TO-DO:

• Build an HCP pipelines module that outputs the required cifti surfaces
• Wrap the fs2gifti and cifti_mesh workflows into a single workflow, HCP pipeliens doesn't need f2gifti
• Run HCP sequence data through the pipeline

Originally rtms optimization geometry routines were written in Python2 due to SimNIBS having only a python2 based API. With the release of SimNIBS 3 there is now Python3 compatibility.

As a result we want to port over the python library:
https://github.com/tigrlab/rtms_optimize/fieldopt

To python 3. With this, comes small changes to the SimNIBS python API (some functions need to be updated since they are deprecated etc..). In addition some Numpy-based routines should be updated as well (using "@" for matrix multiplication).

Set up continuous integration for testing of pipeline. The following functions should have unit-tests written for them:

• Ciftify/mri2mesh running
• Tetrahedral projection algorithm (tetrapro)
• Bayesian optimization (compare to densely sampled grid?)
• Surface patch generation
• Geometry library (geolib)

For automated targeting of the mentalizing network we need to define a weight landscape such that stimulation magnitude is maximized for regions in the DMPFC maximally functional connected to the mentalizing network.

To do this the following method is proposed:

1. Use the "Mentalizing Network" Neurosynth map
2. Map onto fs_LR_32k surface using connectome-workbench
3. Mask out DMPFC, and re-compute functional connectivity using average DMPFC-external mentalizing regions
4. Resample functional connectivity map into native mesh space (mri2mesh's surface)
5. Project into _T1fs_nu_conform.nii.gz volume space
6. Perform tetrahedral projection into SimNIBS mesh space using tetrapro python library

The end result should be a list of weights (functional connectivity) corresponding to each node.

For the fully-automated component of the pipeline we want to create a mesh surface using mri2mesh and a standardized surface (using ciftify). However these two surfaces need to be registered to one another in order to perform the surface --> volume ribbon projection from connectome workbench.

Initial Nextflow scripts for running ciftify/mri2mesh in parallel are up in the repo under: pipelines/bin/ciftify_meshing.nf

Next steps are to perform post surface/mesh generation registration steps into a well-organized folder.

The BASH script:
https://www.github.com/tigrlab/rtms_optimize/bin/register_fs_to_ciftify

Is a crude implementation of this. In this repo we want to use Nextflow + Singularity container support to run these steps.

qc_cortical_distance results are currently stored using UUIDs which differentiate runs, instead we should transform the UUIDs back into the proper entity set and save with a more descriptive filename

pipeline/ciftify_meshing.nf defines a Nextflow script that will automatically run both ciftify and mri2mesh in parallel after initial subject-specific T1 template generation (allows use of multiple T1s).

We'd like to set up the following features on nextflow for this script:

• Email delivery upon pipeline completion/failure
• Profiles for running on different clustering systems

Check the following links for how to:

https://www.nextflow.io/docs/latest/mail.html
https://www.nextflow.io/docs/latest/config.html#config-profiles

As with many standard BIDS pipelines it is very useful to have a single-subject QC page to examine the quality of the pipeline's output. The BOONStim QC page should contain the following elements;

• Link to fMRIPrep + Ciftify / HCPPipelines QC page
• Include images from optimization result
• Include distance measurements for scalp to cortex
• Provide instructions for debugging common issues (misplacement of centroid)

Some groovy code snippets are duplicated across config files. For example the snippet:

Closure get_partition;
if (partition instanceof Closure){
    get_partition = partition
}else{
    get_partition = { t -> partition }
}

Closure cacheDir;
if (params.cache_dir){
    cacheDir = { f ->
                    def d = new File("$params.cache_dir/$f")
                    d.mkdirs()
                    "$params.cache_dir/$f"
               }
}else{
    cacheDir = { f -> "" }
}

Is re-used in multiple config files. Originally thought to define all config specs in the main boonstim.nf.config file but the scope induced by includeConfig doesn't seem to carry over function definitions - they are local.

The solution here would be to create a groovy script containing function definitions that can be imported in each of the config files.

subject parameters (hair thickness, etc) and subject selection should work through separate mechanisms/arguments into the main pipeline

Post #8, #1. The final step is to wrap up the entire pipeline into a nextflow script.
This will require completion of #3, #2, #5 as well.

A clean python interface to work with the preprocessing steps of BOONStim would serve as a useful platform on which:

• comparison tests between optimization methdologies can be done using data projected into FEM space
• later use of outputs in analysis can be done

It's likely that this will require some re-organization of the BOONStim outputs and caching directories

Currently we have both Grid and Bayesian optimization modules using the automatically generate parameteric surface for sampling.

However providing an interface for running SimNIBS optimizations would be useful for comparison purposes and for cases in which SimNIBS continues to add more sophisticated optimization techniques.

Should write up some documentation on how to run and configure the pipeline to get things up and running. The following documentation is required for the main pipeline:

1. nextflow configuration file paths (container locations etc... for singularity)
2. required singularity containers (mri2mesh, rtms_bayesian, connectome workbench)
3. input data specification (BIDS)
4. output specification - where to find outputs, what does each output mean
5. how to work with outputs (gmsh simulation and mesh files, surfaces)
6. how to make custom weight functions on the surface (parcellation-based/FC-based/etc)

In addition documentation is needed for:

1. tetrahedral projection (tetrapro) - the methods used
2. geometry library (geolib) - description of each function and implementation
3. surface patch extraction - how a sampling surface is defined
4. objective function (FieldFunc) - reference documentation of methods and use

Implement parcellation workflows where users can specify a parcellation in fsaverage_LR32k or volume space with an ROI#/Label to automate selection of parcel for targeting