3dGroupIncorr: Error or incompetence?


I have used InstaCorr and 3dGroupIncorr before and it has worked great. I now experience some similar problems between the two functions and suspect something is wrong. Or, I just forgot how to use it.

lsb_a -release
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.2 LTS
Release:	18.04
Codename:	bionic

afni -version
Precompiled binary linux_openmp_64: May 29 2021 (Version AFNI_21.1.09 'Domitian')

Opening afni inside a .results dirr.
Setting “anat_final” as underlay.
Clicking on Setup Icorr
Choose Dataset in the scond column: I choose errts.fanaticor and click Set. Then Set and Keep.
Terminal Output:

*+ WARNING: Forced switch from 'Original View' to 'Talairach View' [#1]
++ InstaCorr preparations:
 + Computing automask
malloc(1.5 billion bytes)readingrrts.sub116-1.fanaticor+tlrc. 1.5 billion bytes).....................................float scan.done
 + Automask from '/home/robka/BG_2021_rest/sub116-1.results/errts.sub116-1.fanaticor+tlrc.BRIK' has 304650 voxels
 + Extracting dataset time series: /home/robka/BG_2021_rest/sub116-1.results/errts.sub116-1.fanaticor+tlrc.BRIK
 + - Filtering 304650 dataset time series
 + bandpass: ntime=360 nFFT=360 dt=2 dFreq=0.00138889 Nyquist=0.25 passband indexes=7..72
 +   -- quadratic detrend
 +   -- FFTs
 + - Normalizing dataset time series
++ InstaCorr setup: 304650 voxels ready for work: 11.93 sec
 + ..... Use 'InstaCorr Set' to pick a seed voxel .....
 + ..... (Mouse-right-click menu in image viewer) .....
 + ..... (or Shift+Ctrl+left-click at seed point) .....
 + ..... (Shift+Ctrl+left-click-and-drag for fun) .....

By this stage I should be able to right click in one of the images, and take “InstaCorr set” and I should see correlations, like before. The button is click-able but nothing comes up when I press it or ctrl+shift+left-click.

I make a new directory, copy the anat_final to it
Then I run:
3dSetupGroupInCorr …/sub116-1/errts.sub116-1.fanaticor+tlrc. (only one file to test)
This gets me the files
I then open afni
afni -niml &
In the same terminal I run
3dGroupInCorr -setA Group.grpincorr.niml
The terminal gives me:

3dGroupInCorr -setA Group.grpincorr.niml ++ 3dGroupInCorr: AFNI version=AFNI_21.1.09 (May 29 2021) [64-bit]
++ Authored by: Cox, the Mad Correlator
++ GIC: data file Group.grpincorr.data found with 378,224,640 bytes of data
++ GIC: -setA opened, contains 1 datasets, 1050624 time series, 378,224,640 bytes
++ GIC: page faulting (reading) data into memory
 + setA:0123456789.0123456789.0123456789.0123456789.0123456789.!
++ GIC: total .data bytes input = 378,224,640 (about 378 million)
++ GIC: --- Be sure to start AFNI with the '-niml' command line option
 +      ---  [or press the NIML+PO button if you forgot '-niml']
++ Opening NIML socket 'tcp:localhost:53213' to AFNI. Connected!
++ 3dGroupInCorr stands ready to do thy bidding, O Master :-) !!
++ NIML connection opened from (tcp:host:53213,AFNI_GroupInCorr_NIML)
 + GIC: OpenMP thread count = 15

But when I right-click in the image, or shift+left-click nothing happens.
If I go to define overlay, and select GrpInCorr and then Setup GICor it gives me a pop-up:
*** AFNI: ****
isn’t connected!
Nothing happens in the terminal.

I tried this with no difference:
sudo ufw allow 53213/tcp

Do I forget a step in the AFNI-viewver or is somthing wrong? =)



The Bob is out today, so I will take a crack at this…

For reference, I am looking at the InstaCorr and GroupInCorr demos in the Bootcamp data:

curl -O https://afni.nimh.nih.gov/pub/dist/edu/data/CD.tgz
tar xvzf CD.tgz
cd CD
tcsh s2.cp.files . ~
cd ..

… with the relevant part of the unpacked directories being:
… where there is the “@RunVolGroupInCorr” script.

From your error message about ports, I think that the niml-talking functionality has not been actuated. Looking in the @RunVolGroupInCorr script, I see:

afni -niml -npb 0 -yesplugouts -layout DemoLayout
sleep 1
3dGroupInCorr -npb 0 -setA G1.grpincorr.niml -verb &

You do have “-niml” running; do you have another instance of AFNI and/or SUMA up, by any chance? If you do, there might be port number confusion. You can specify a port number for communication explicitly with both the AFNI GUI and 3dGroupInCorr with “-npb SOMETHING”—in the above, it is “-npb 0”.

Can you try 1) closing existing AFNI/SUMA instances, and 2) using “-npb NUMBER” with the same NUMBER for both the GUi and 3dGroupinCorr?
(The “sleep 1” might or might not be so useful; kind of depends on the system—gives AFNI a bit of time to setup before running 3dGroupInCorr in the demo script.)

Just some other AFNI/port functionality—
instead of closing existing AFNI/SUMA sessions that might be using a port, you should be able close just ones that might be using a particular port number, to make sure there is no crosstalk:

@Quiet_Talkers -npb_val NUMBER


I’m not quite out yet, but in a few moments.

I don’t see anything wrong with your GUI InstaCorr usage – after it says “ready for work”, it should work – and it does on my computer just now. So that is a mystery to me.

The GroupInCorr screen output also says it is ready (connected). The only thing I can think is that you are running 2 copies of AFNI – perhaps one is hidden away somewhere – and it connected to the wrong one. You could try the command “killall afni” to make sure that all copies of any program named “afni” are dead. Followed by “ps aux | grep afni” to see if there are any stray AFNIs running – you should see only something like

rwcox            72407   0.0  0.0  4268080    816 s001  R+   11:37AM   0:00.00 grep afni

as the output, which is the grep command itself with the string “afni” in it.

Will that kill any processing done by other users on the server? E.g. afni_proc?
Also, when you say that perhaps another instance is running, could that be by another user logged into the same machine?
Afni is installed for all users under /usr/local/abin.

Thanks for prompt replies!

Hi, Robin-

I just remembered “afni” has an option to find an available/free port, so you shouldn’t need to kill other ones (NB: I don’t think the quiet_talkers would kill an afni_proc.py job; I am not sure if it might get one of the headless AFNI instances running in the QC imaging-generation called by it, though… I would hope not one from a different user. But I am not certain.)

OK, so to find an available/free port, you can use one of these opts:

-available_npb: Find the first available block of port numbers, 
                   print it to stdout and quit
                   The value can be used to set the -npb option for
                   a new set of chatty AFNI/SUMA/etc group.
   -available_npb_quiet: Just print the block number to stdout and quit.

The latter is better for scripting, e.g.:


# get a portnum that is free
set portnum = `afni -available_npb_quiet`

# use portnum now
afni  -niml -npb ${portnum} ....

3dGroupInCorr -npb ${portnum} ....


Thanks Paul!

This got a bit messy and turned into two questions:

  1. InstaCorr:
    It works. The problem was something else, which is strange. When setting up Instacorr, and mask is checked an automask = on, it turns out it makes an inverted mask! I get voxels/correlations if I place the marker outside the brain. If I turn off auto-mask, then I get values in the brain (and they make sense, e.g. DMN). What could cause this? Basically there is nothing in the brain with auto-mask.

  2. 3dGroupInCorr
    I tried your commands but something seems off. The server is on a secure network, so the firewall is off and should allow traffic:

sudo ufw status verbose
Status: inactive

But when running your command I get that no ports are available (it should be larger than 0 and less than 23 (I think) so the returned port is not valid:

afni -available_npb

First available npb: 0

I also looked into existing AFNI sessions:

ps aux | grep afni
robka    35837  0.0  0.0  15984  1024 pts/2    S+   02:18   0:00 grep --color=auto afni

I guess it finds the grep command I did?

Then I try the whole afni-niml + 3dgroupIncorr again:
Once I start 3dGrouIncor I see in

sudo netstat -tcp | grep afni
tcp        0      0 localhost:53213         localhost:41928         ESTABLISHED 37770/afni          
tcp        0      0 localhost:53213         localhost:41928         ESTABLISHED 37770/afni          
tcp        0      0 localhost:53213         localhost:41928         ESTABLISHED 37770/afni          
tcp        0      0 localhost:53213         localhost:41928         ESTABLISHED 37770/afni 

Before I ran 3dGroupIncorr it was empty. So, that seems to work?
But I don’t get any information in the afni-viewer that it is connected…

I can’t say anything about the 3dGroupInCorr problems right now – it seems to be some network/security thing. Unless it is connecting to suma instead? However, unless you are superuser (root), you don’t have permission to kill jobs belonging to other users.

OK, one 3dGroupInCorr thought – try using the -NOshm option, which will avoid the default attempt to use shared memory instead of TCP/IP. If that doesn’t work, then I suggest trying to use the plugout_drive program and see if it can connect successfully to AFNI to “drive” it via a TCP/IP connection, in a similar but simpler way than 3dGroupInCorr.

afni -yesplugouts
Enter command: OPEN_WINDOW B

For the single-dataset InstaCorr problem, is it possible that you have a lot of large noise outside the brain? So that the automask algorithm is failing? (It looks for connected regions of high intensity stuff.) Try running 3dAutomask on the the same dataset and see what the resulting mask looks like overlaid on the input dataset. I’ve seen weird EPI data like that once or twice. Or since you are using errts, the scaling used in afni_proc.py could have created this as an artifact.

Just turn off masking in InstaCorr and mentally mask the dataset. Or read in the mask calculated by afni_proc.py (you DID use afni_proc.py, right?) instead of using the automask – usually the afni_proc.py mask is in dataset mask_epi_anat – and use that in InstaCorr.

Hi, Robin-

Re. InstaCorr—I have also seen that kind of thing happen with resting state, in particular: the data there is residuals, so of mean zero, and then if you have smaller noise in the brain than outside… it can be tricky to automask directly. If you need to mask the data (do you?) you can load in a separate dataset there, in that “Mask” row of the controller.

Re. ports—I think using port “number 0” is still OK. Actually, that is what the @RunVolGroupInCorr demo script in ~/AFNI_demos/AFNI_InstaCorrDemo.mini/vol/ has explicitly set (line 28ff):

afni -niml -npb 0 -yesplugouts -layout DemoLayout
sleep 1
3dGroupInCorr -npb 0 -setA G1.grpincorr.niml -verb &

How about if you try running the GroupInCorr demo from the Bootcamp on that machine? There is a Setup and a Run script. We know that should work, so that might provide a diagnostic.


Thanks Bob!

I am (g)root on the server and I think I used sudo killall afni.

The GroupIncorr issue:
I am sorry, this might have been incompetence… I just used one subject to create the GroupIncorr.niml/data files. Could that have been an issue? Bad data? We ran it now using 3 subjects and it work! Sorry!

The Instacorr Issue:
Yes! It was probably was the scaling! Is this a problem? Running InstaCorr on pb.volreg/pb.blur or even pb.scale works fine. The masks “masks out” the brain only when using the errts.fanaticor. Is should not be specific to this dataset, I tried with data from another study and the same thing happens for errts.fanaticor. And, I have used this before without problems but the new element here is the scaling block that we added since it was present in the recommended afni_proc.py resting state example. As long as we give our own afni_proc mask (mask_epi_anat - and yes we did run afni_proc =)), are we fine? Or does this indicate some other issue?

Hi Paul, thanks! Please see my latest post under Bob’s reply! Would be very interesting to see your thoughts (on another issue - that we can totally move to a new thread!)

Hi, Robin-

I am not sure about 1 vs 3 subj in 3dGroupInCorr-- but if a “group” is expected, it wouldn’t surprise me that somethign might fail. For example, what is the standard deviation of 1 value? (Sounds like a koan—what is the sound of one hand clapping?)

Re. Instacorr: the fact that errts is different (and weird) doesn’t surprise me—it is a residual dset, so that dset has mean of zero by default, and probably small fluctuations in the brain vs outside. I might expect scale to be a bit similar, but it has a nonzero mean, so that might make the difference. Anyways, for residuals, I would either not mask (which is perfectly acceptable) or use an externally generated mask (probably done by afni_proc.py already, too, yes?).

For the other question—that seems totally separate, and pretty long. Can we make that a separate thread?


Hi @Robin , I have encountered the same problem. Have you solved it? Could you give me some advice?

I have found one cause of this phenomenon. When I ran the 3dSetupGroupInCorr, I did not check the log info carefully. In fact, 3dSetupGroupInCorr received only one file instead of a file list. So the terminal says they have connected to each other while the GUI shows no connection issue.


Is the current problem just that afni and 3dGroupInCorr are not talking? In general, you should include the -npb option in any such commands, since if there are other programs using port blocks, they would not be otherwise available for the current ones.

Consider also first verifying which ports are available using either afni -available_npb or afni -available_npb_quiet. For example, _quiet could be run first to get an available block, which could then be passed using the -npb options in the respective programs.

  • rick