NITRC CONN : functional connectivity toolbox Forum: help

RE: including a parametric modulator

Shivali Verma — Wed, 28 Oct 2026 7:37:10 GMT

Hi Alfonso,
I followed the suggested approach of adding the parametric modulators as weighted conditions in CONN.
I am now trying to understand whether it is valid to contrast the original Encoding condition with the Encoding condition weighted by the parametric modulator to investigate whether connectivity is associated with the behavioural ratings.
More specifically, I would like to understand whether this contrast would identify connectivity effects related to the continuous behavioural ratings over and above the general Encoding-related effects, or whether a different contrast would be more appropriate.
I would really appreciate your advice on how best to approach this analysis.
Best, Shivali

MION HRF implementation for NHP task-based functional connectivity.

Brent Stewart — Mon, 19 Oct 2026 18:25:48 GMT

Hi. I'm using CONN to analyze task-based functional connectivity from macaque scans that used MION contrast agent. I believe I got it to work, but I hope people more familiar with the inner workings of CONN could provide feedback on if my methods are sound. I used modified spm_hrf code to implement the MION HRF, which produces the desired MION-HRF-convolved condition time series (for use as confounds during denoising). However, the MION HRF is a negative deflection, so after conn_process.m produces HRF-convolved condition time series, all temporal weights assigned to conditions would be negative, meaning no data points would be included in analyses because CONN only looks for positive temporal weights. 1) I therefore edited conn_process.m to look for negative weights: From line 600: % BOLD HRF % idx1=find(x>0); idx2=[0;find(diff(idx1)>1);length(idx1)]; % crop to within-condition samples % MION HRF idx1=find(x<0); idx2=[0;find(diff(idx1)>1);length(idx1)]; % crop to within-condition samples 2) And I inverted the MION HRF-convolved time series when temporal weights variables are defined: From (new) line 622, see the additional "*-1" in uncommented lines: % BOLD HRF % tweights{1}=cat(1,tweights{1},x(idx(:)));                       % HRF  %.*xw(idx(:))) % tweights{2}=cat(1,tweights{2},conn_hanning(length(idx)));       % HANNING %.*xw(idx(:))); % tweights{3}=cat(1,tweights{3},xw(idx(:)));                      % HRF.*MODUL (note: this option is now obsolete; tbd) % tweights{4}=cat(1,tweights{4},idx(:));                          % IDX % tweights{5}=cat(1,tweights{5},(1:numel(idx))');                 % JDX % MION HRF tweights{1}=cat(1,tweights{1},(x(idx(:))*-1));                    % HRF  %.*xw(idx(:))) tweights{2}=cat(1,tweights{2},conn_hanning(length(idx)));         % HANNING %.*xw(idx(:))); tweights{3}=cat(1,tweights{3},(xw(idx(:))*-1));                   % HRF.*MODUL (note: this option is now obsolete; tbd) tweights{4}=cat(1,tweights{4},idx(:));                            % IDX tweights{5}=cat(1,tweights{5},(1:numel(idx))');                   % JDX This appears to have worked, but any feedback on potential errors or unintended consequences from this protocol would be greatly appreciated!

Surface-based projects: which space should subject-specific surface ROIs be in?

Yagmur Yildirim — Mon, 19 Oct 2026 11:56:35 GMT

Dear CONN developers,
I’m writing to share an issue I ran into with CONN’s surface-based pipeline, in case it is useful for the documentation. I have since moved my analysis outside CONN, so I’m not asking for troubleshooting, only for clarification of the intended workflow.
I used CONN (25b) with SPM (25.01.02), MATLAB on Linux, to preprocess and denoise surface-based resting-state data from 40 subjects with two sessions each, using longitudinal FreeSurfer reconstructions. My analysis required time series from small subject-specific surface ROIs: functional-localizer patches of 69-106 vertices and Wang atlas labels. All of them are FreeSurfer <code>.mgz</code> files defined on each subject’s native surface (123,674 vertices per hemisphere).
When I added these files as ROIs, I could not obtain usable time series. The functional outputs (<code>*.surf.nii</code>) are [42 × 83 × 94 × 210] volumes with no spatial transform that I could use to relate native-surface ROIs to them. The sampling used for surface ROIs also appeared far too sparse for ROIs of this size, on the order of 1,000 points across the surface. CONN’s own atlas ROIs extracted without problems.
The volume size may explain this. 42 × 83 × 94 = 327,684, which is exactly twice the 163,842 vertices of one fsaverage hemisphere. I therefore suspect that CONN’s surface data lives in fsaverage space and that surface ROIs are expected there, not on a subject’s native surface. If so, native-surface ROIs would be incompatible with the stored data by design.
Is this the intended workflow? If so, it would help users if the surface-analysis documentation stated which space and format ROI files must use, and whether subject-specific native-surface ROIs are supported. Such ROIs are common in visual neuroscience, for example with retinotopic atlases and functional localizers, so support for them would be a valuable feature.
The manual and tutorials present surface-based analysis as supported, which is why I expected this to work. 
Thank you for the toolbox and for your time.
Best regards,
Yagmur

RE: Does CONN work with remote submission (through parallel server)?

cramos — Fri, 16 Oct 2026 22:06:04 GMT

Hi Alfonso!
That would be great, and I'd be happy to help test and debug! As you mentioned, I do think it would be the most generally useful to work with parallel server since that eliminates users being stuck waiting for a compute node to become available. Depending on what they are requesting (e.g. quantity of nodes, duration of the runs, etc.) wait times can range anywhere between a couple of hours to well over a day, all the while they would have to be sitting on the initial compute node hoping the nested job launches and completes before getting kicked off. That is to say, the ssh method is risky and not ideal. 
That's a great point about the file systems and one I hadn't considered. The compute machines each have their own file systems (with one of them, "/work", being connected across all compute machines for easy sharing and backup). The rest are unique to each individual compute cluster, but the naming conventions (i.e. "/home1", "/work", and "/scratch") are uniform across all the systems for convenience. Each of those is accessible from the login nodes or compute nodes of their respective machine. Data transfers are typically done with command-line tools like rsync and scp, but managing data from a local machine can also be done either using an sftp client or the browser-based data management tool, Globus. Each cluster's “/scratch" file system is where we direct all users to stage their computation and IO because those spaces have no user quota limits on how much data they can store and the hardware of each “/scratch" is best equipped to handle the load. To balance this, purges are run at semi-regular intervals to clear out old, untouched data, so it is strongly recommended that copies of inputs and final results be kept and offloaded to other storage locations to avoid potential loss. 
The vast majority of user workflows are to first transfer necessary data to the machine, then connect to a login node via ssh to build and stage jobs, then finally submit jobs with sbatch to whichever partition they choose. We also have a few browser-based portals for job submissions and those are primarily for a convenient method to launch interactive jobs that require a GUI or some other visual element, which are done through VNC and DCV. That’s how the CONN users here have been connecting thus far and they’ve just run the computation on the same node in the interactive job, rather than offloading the computation to another or multiple other nodes. All jobs are strictly submitted through login nodes though, where even the portals are also doing so under the hood. Our cluster configurations for submitting remotely with Parallel Server do the same. 
Let me know if that answers your question or what other info you might need. 
Thank you!
-Chris

RE: Only 1 mean file for 1 subject with 2 sessions

Alfonso Nieto-Castanon — Wed, 14 Oct 2026 18:10:06 GMT

Hi Mary & Shayla
I have now uploaded these changes to CONN's development version (this can be downloaded from github.com/alfnie/conn; see or https://web.conn-toolbox.org/resources/conn-development for details). When entering multiple anatomical files per subject CONN will now automatically force functional preprocessing steps to run separately across runs in order to accommodate possible anatomical differences between runs (so you should be able to run the standard pipelines normally wihtout having to do anything differently). If you have a chance to try out the new functionality please let me know if everything works correctly and/or if you run into any issues.
Best
Alfonso
Originally posted by Mary Newsome:
<blockquote>
Thank you, Alfonso! I see how having one mean would make sense when all of the runs were collected at the same time and not expected to be different. I had an experience similar to that of Shayla's. For an intervention design, I think both of your ideas would help a lot. (The only thought I had about where to offer the option was what if in the rare occasion that the same T1 had to be used for both sessions for some reason (e.g., corrupted or accidentally not acquired), but then one could always copy the file and have it loaded in for each subject?) 
Also, thanks picking up on that error. Thankfully, we did catch that earlier.
All the best,
Mary
</blockquote>

RE: Does CONN work with remote submission (through parallel server)?

Alfonso Nieto-Castanon — Wed, 14 Oct 2026 11:09:15 GMT

Hi Chris,
You are right there are a few ways to make this work (e.g. as you suggest we could create a new profile that submits jobs from a compute-node through a ssh remote execution to a login node), but perhaps the way that would be most generally-useful to others in a similar situation as yours would be if I simply add an option to CONN to submit jobs using Matlab's own Parallel Server functionality, adding that option to the current list of compatible job schedulers, as this is becoming an increasingly common scenario. If you are up for it perhaps I could use your help to test/debug this? The only potential difficulty that I am thinking of is whether the compute-nodes in your system have access to the same shared storage as your users' computers (where a user's CONN project and data is stored) and/or whether that access may be through a different search path in the remote filesystem. Can you give me some details about how is the storage organized in your cluster, where exactly you would expect a user saves their data and CONN project (fMRI often requires large datasets, and many analyses require reading and writing considerable amounts of large files), and how that is accessed from both a user's local computer and a compute-node?
Thanks!
Alfonso
Originally posted by cramos:
<blockquote>
My name is Chris and I work for TACC (Texas Advanced Computing Center) where I maintain our installations of matlab through the Lmod module system on our HPC clusters. I am trying to help some of our users get set up with using CONN on our compute machines. The problem is that CONN assumes it's running on a head node and submits the job with slurm sbatch commands. We don't allow users to run matlab on the head nodes (login nodes) on any TACC machines since those are shared nodes and matlab is notoriously a bit of a memory hog, so instead we have the options to either run directly on the compute nodes (which are not shared on our systems) or submit slurm jobs remotely from their local computer's matlab shell/GUI via matlab's Paralllel Server.
Using CONN while running directly on a compute node is technically doable, but job submissions are disabled from the computes, so the workaround is to ssh to a login node from within the job to submit the subsequent CONN job. I believe that can be done by modifying the sbatch command CONN uses, but they are still left with having to wait in the queue until their initial job launches on the compute node to even start with CONN. Instead, we'd like for them to be able to stage their jobs locally so they don't have to wait in the queue, and then they can send off the CONN computation portion to our machines with a saved cluster configuation that we'll get them set up with ourselves. 
My issue is that I can't figure out a way to make CONN recognize and use the saved cluser configuration. Is there a way to make this work? 
Thanks in advance! 
-Chris 
</blockquote>

Does CONN work with remote submission (through parallel server)?

cramos — Tue, 13 Oct 2026 19:15:51 GMT

My name is Chris and I work for TACC (Texas Advanced Computing Center) where I maintain our installations of matlab through the Lmod module system on our HPC clusters. I am trying to help some of our users get set up with using CONN on our compute machines. The problem is that CONN assumes it's running on a head node and submits the job with slurm sbatch commands. We don't allow users to run matlab on the head nodes (login nodes) on any TACC machines since those are shared nodes and matlab is notoriously a bit of a memory hog, so instead we have the options to either run directly on the compute nodes (which are not shared on our systems) or submit slurm jobs remotely from their local computer's matlab shell/GUI via matlab's Paralllel Server.
Using CONN while running directly on a compute node is technically doable, but job submissions are disabled from the computes, so the workaround is to ssh to a login node from within the job to submit the subsequent CONN job. I believe that can be done by modifying the sbatch command CONN uses, but they are still left with having to wait in the queue until their initial job launches on the compute node to even start with CONN. Instead, we'd like for them to be able to stage their jobs locally so they don't have to wait in the queue, and then they can send off the CONN computation portion to our machines with a saved cluster configuation that we'll get them set up with ourselves. 
My issue is that I can't figure out a way to make CONN recognize and use the saved cluser configuration. Is there a way to make this work? 
Thanks in advance! 
-Chris

RE: Lesion mask integration

Alfonso Nieto-Castanon — Tue, 13 Oct 2026 9:24:11 GMT

Dear Samim
Comparing a single subject to another cohort is perfectly fine. You may do that within CONN using the standard GLM second-level analysis tools available. In the context of GLM a between-group comparison where one of the groups has only one subject is mathenatically exactly equivalent to your planned Crawford-Howell t-test, so you could run those analyses simply from the second-level results tab selecting the reference group and another group identifying a single subject and entering a [-1 1] between-subjects contrast. 
Hope this helps
Alfonso
Originally posted by Mohammad Samim Zaheer:
<blockquote>
<div>Dear Alfonso,</div>
<div> </div>
<div>Thank you for your detailed clarification. I understand that comparing a single subject to another cohort is not supported. However, if I want to export connectivity data for a specific ROI, such as the IFG, to perform a Crawford-Howell t-test outside of CONN, what steps should I follow?</div>
<div> </div>
<div>Is it possible to obtain this data? If so, could you advise on the appropriate extraction method and recommend which type of analysis I should use?</div>
<div> </div>
<div>For context, I have data from 10 GBM patients and 15 controls. I would like to compare each patient individually to the control group before conducting a group analysis.</div>
<div> </div>
<div>Thanks again for your help!</div>
<div>Samim</div>
</blockquote>

RE: Error in dimensions of ROI matrix

Francesc Xavier Aymerich — Tue, 13 Oct 2026 9:08:35 GMT

Dear Alfonso,
Thank you very much for fixing this bug. I will try to process again with your new version.
Xavier
 
Originally posted by Alfonso Nieto-Castanon:
<blockquote>
Dear Xavier
Thank you very much for reporting this issue. That was actually a bug in the code in the way it handled potentially-rectangular ROI-to-ROI connectivity matrices when exporting RRC matrices as .mtx.nii files. I have included a fix for this issue in the latest update to CONN development version (you may download the development version from github.com/alfnie/conn, or see https://web.conn-toolbox.org/resources/conn-development for details). If you could give that a try and let me know if you still run into any issues that would be great. 
Thank you again!
Alfonso
 
Originally posted by Francesc Xavier Aymerich:
<blockquote>
Dear users,
 
At the end of SBC_01 analysis (step 3/3: Preparing second-level ROI analyses) I received the following error message:
ERROR DESCRIPTION:   Error using assert input matrix must be square
Error in conn_mtx_write (line 21) assert(M==size(data,2),'input matrix must be square');  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error in conn_process (line 4854)  conn_mtx_write(outputfilename,Z,names,xyz,arrayfun(@(n)sprintf('Subject%03d',n),validsubjects,'uni',0));  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error in conn_process (line 86)  case 'analyses_gui_seedandroi',conn_disp(['CONN: RUNNING ANALYSIS STEP (ROI-to-ROI or seed-to-voxel analyses)']); conn_process([10,11,15],varargin{:});  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error in conn (line 10376)  conn_process('analyses_gui_seedandroi',CONN_x.Analysis); ispending=false;  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error in conn_menumanager (line 125)  feval(CONN_MM.MENU{n0}.callback{n1}{1},CONN_MM.MENU{n0}.callback{n1}{2:end});   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CONN25.b SPM25 + DAiSS DEM FieldMap MEEGtools Matlab v.2026a project: CONN25.b storage: 67.5Gb available
I have debugged this error and M and data have different dimensions but I don't know the reason.
Thanks in advance,
Xavier
</blockquote>
 
</blockquote>

RE: Lesion mask integration

Mohammad Samim Zaheer — Sun, 11 Oct 2026 15:09:08 GMT

<div>Dear Alfonso,</div>
<div> </div>
<div>Thank you for your detailed clarification. I understand that comparing a single subject to another cohort is not supported. However, if I want to export connectivity data for a specific ROI, such as the IFG, to perform a Crawford-Howell t-test outside of CONN, what steps should I follow?</div>
<div> </div>
<div>Is it possible to obtain this data? If so, could you advise on the appropriate extraction method and recommend which type of analysis I should use?</div>
<div> </div>
<div>For context, I have data from 10 GBM patients and 15 controls. I would like to compare each patient individually to the control group before conducting a group analysis.</div>
<div> </div>
<div>Thanks again for your help!</div>
<div>Samim</div>