DCM Batch

[dankessler]

A DCMBatch processor is in the works. So far, it's mostly been designed by @dankessler and coded by @shijiaguo.

Here is how it works:

dcm_batch.m

Inputs:

• VOI path templates
• SPM.mat templates (first level specifications)
• Subject List
• SubjDir path template
• Permissibility matrices for driving inputs (a), fixed connectivity (b), and modulatory (c) connectivity.

Results

A DCM model for each subject, for each possible combination of DCM wiring matrices.

This script would first call...

---

permutation.m

Inputs:

permissibility matrices a, b, c (supplied by the batch caller)

Returns

cell array of all possibly a, b, and c permutations as restricted by the permissibility matrices

Next up it calls

---

dcm_job_config

Inputs:

• one set of connectivity matrices (a, b, and c)
• full path name of where to place the dcm.mat job object
• full path to an SPM.mat job to extract time series of inputs from
• full paths to VOIs (as a cell array)

Given these inputs, and using code borrowed largely from a template dcm_batch script, it will...

Returns

Stores a dcm.mat job with all options specified
A full path to this dcm.mat job

Next, it calls

---

dcm_do_job

Inputs

• Cell array of paths to dcm.mat jobs

Results

For each of these jobs, it will just simply call the dcm_job spm function, which will do the model, creating the result where specified.

---

At present, we have written permutation and dcm_job_config, which are arguably the trickiest of the scripts. @dankessler is planning to undertake scripting of the dcm_batch and dcm_do_job routines.

Future developments would include a possible VOI generator (at present, you would have to have already done your extractions). We're not sure if it'd be better to include the VOI generator as part of this script, or as a separate project, maybe with a bridge.

The scope of the present project will not include SecondLevel analysis, but since this script will now where all of your jobs are being stored, using it to invoke model selection and parameter estimating, etc, would save the user some serious gui clicking time.

Thoughts? Especially any from @sripada who developed the original concept with @dankessler?

[sripada]

Looking good @dankessler and @shijiaguo!

On the VOI generation issue: There are a number of different schemes for generating a VOI, and we need to be able to accomodate the following:

1. Each subject gets the same spherical VOI centered at a single MNI coordinate.
2. Each subject gets a different spherical VOI. Maybe this is a sphere located at the subject's peak within some larger mask.
3. Each subject gets an activation cluster-based VOI whose shape and location will vary by subjects.

Maybe 1&2 can be built into the script, with the user specifying whether it will be 1 or 2, radius of sphere, coordinates if 1, mask to search in if 2, etc... BTW, I've got some code that will take a mask and a t map, and will a subject's peak within the mask. Let me know if you need it. Or SPM8 might do this for you.

But to accommodate more customized schemes like in 3, the script should be written to accept an VOIDirectory variable which points to a folder where there will be an VOI per subject. Its the user's job to populate that folder using whatever tools they want.

[dankessler]

Thanks for the thoughts @sripada

I'm sitting here with @shijiaguo now and we're thinking through how to do this.

2 & 3 don't really seem substantially different, if I understand you correctly. Principally, they both

1. Identify a region based on a mask and an activation pattern
2. Do something with that region
   • For 2, that something is to identify the peak, then construct a sphere around it.
   • For 3, that something is simply to return the whole region as a VOI

1 is more unique and pretty simple to specify.

It may be easier to, at this stage in development, sidestep the issue of VOI creation and write it to work based on preextracted VOIs. We can later incorporate an extraction routine into the batch so that it's a one shot operation for the user.

VOI extraction could conceivably have a lot of configurable options, customizations, features, etc, so it may make more sense to develop a somewhat more comprehensive VOI extraction toolbox and point to that, rather than trying to package it within DCM.

The beauty of the single repo is that if we add a VOI extraction toolbox, we can rewrite DCMbatch to take advantage of it, and don't have to worry about dependency issues across multiple repos.

After my thinking above, I think the VOI identification makes sense to take up as a separate development issue (which could be developed by @shijiaguo, or somebody else). Once the VOI extraction toolbox is built (should be pretty straightforward to get something rudimentary working) we can integrate it into DCMbatch. For now, we just write dcmbatch to expect already extracted VOIs.

I think a lot of your comments will be handy in guiding the VOI toolbox if we go that route.

[dankessler]

I've opened up a new issue #21 to track discussion of a VOI extraction toolbox.