Duke-UNC Brain Imaging and Analysis Center
BIAC Forums | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Support Forums
 Analysis Software Support
 resting_pipeline-beta

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
Check here to subscribe to this topic.
   

T O P I C    R E V I E W
petty Posted - Mar 30 2012 : 2:07:27 PM
Hey Guys, I added something to the final step of the resting_pipeline.

There's now a generation of a graphml format file, which contains the zr_values and r_values from all the connections, as well as the time course and spacial location of the ROIs' centroids.

To make that happen there are a couple of new flags.

You may need them if not using the default AAL label file.

--corrtext is a tab delimited text file with the ROI value ( 1,2...n ) and the Name of the region:
1 DLPFC_R
2 DLPFC_L
3 FFG_R
4 FFG_L

examples can be seen in the text files located here:
/usr/local/packages/biacpython/data/

--refacpoint is the anterior commissure point in the brain in X,Y,Z coordinates. This is for a conversion and storage of the ROI centroid

If you are using the default, then you don't have to worry about those.

This graphml creation happens in the final step of the pipeline ... so if you wanted to give it a try, then the easiest thing to do is re-run the final stage.

This file is the kind of thing used to create networkx gaph theory graphs and i'm also working on a viewer function so that you can easily view results as a connectome, while being able to actually see your region names and timecourses.

more info can be seen on the wiki:
http://wiki.biac.duke.edu/biac:analysis:resting_pipeline#step_7

for now to call the newer version its just:
/usr/local/packages/biacpython/bin/resting_pipeline-beta.py

There will be a follow-up post about the viewer
15   L A T E S T    R E P L I E S    (Newest First)
syam.gadde Posted - Feb 19 2016 : 11:56:04 AM
It seems there is some re-meaning (i.e. adding back the mean) after WM/CSF regression, and then some rescaling of the data, all in step4 and step6. However, as far as step7/correlation is concerned, if two regions are linearly-correlated in both runs individually, I think that will be reflected in the concatenated runs too, even without explicitly demeaning the inputs, assuming similar variance in the two runs. However I am not a statistician and you could certainly demean the inputs yourself before sending them to step 7 if you wanted to be safe.
jlh125 Posted - Feb 19 2016 : 11:36:55 AM
Just a quick clarification (specifically related to combining multiple runs), are the resting state run de-meaned? (and if so, when in the script?)
syam.gadde Posted - Feb 16 2016 : 6:40:30 PM
I wasn't saying you should be worried about it, just be aware. I don't think you'll miss the two or so volumes that it might remove, given the length of your runs.
jlh125 Posted - Feb 16 2016 : 5:24:14 PM
quote:
Originally posted by syam.gadde

In this case, the suggestion was to concatenate the two runs after most of the pre-processing (including time-based filtering), but just before the parcellation and correlation, so each input would have been detrended individually.

Just don't be surprised if it sacrifices the volumes at the "splice" point, depending on the metric you use for scrubbing, as the two .par files (from mcflirt) are based on different reference volumes in each run, and so there may be a discontinuity at the concatenation. FD and "motion" metrics will be affected most by the discontinuity, DVARS may not notice it.



That is what I thought might happen. That wouldn't be ideal, but might be acceptable for some pilot analyses. Any alternative suggestions?
syam.gadde Posted - Feb 16 2016 : 4:52:15 PM
In this case, the suggestion was to concatenate the two runs after most of the pre-processing (including time-based filtering), but just before the parcellation and correlation, so each input would have been detrended individually.

Just don't be surprised if it sacrifices the volumes at the "splice" point, depending on the metric you use for scrubbing, as the two .par files (from mcflirt) are based on different reference volumes in each run, and so there may be a discontinuity at the concatenation. FD and "motion" metrics will be affected most by the discontinuity, DVARS may not notice it.
Jeff_Browndyke Posted - Feb 16 2016 : 4:22:44 PM
I'm not certain how the BIAC resting pipeline handles data, but I don't believe simply concatenating resting state runs is advisable as it would cause problems for any linear detrending correction.
jlh125 Posted - Feb 16 2016 : 4:10:06 PM
I wondered how best to use this script if you had multiple resting state runs from the same subject? Our group had two ~4 mins scans per subject. Is it reasonable to just combine the two resting state NIFTI files before Step 7 of the script (and simply concatenate the .par files output from step 2 for scrubbing)? Would that be reasonable?
syam.gadde Posted - Oct 16 2014 : 2:38:17 PM
--corrlabel specifies the image for the atlas. Defaults are:

--corrlabel /usr/local/packages/MATLAB/WFU_PickAtlas_3.0.1/wfu_pickatlas/MNI_atlas_templates/aal_MNI_V4.nii

--corrtext /usr/local/packages/MATLAB/WFU_PickAtlas_3.0.1/wfu_pickatlas/MNI_atlas_templates/aal_MNI_V4.txt

simon Posted - Oct 16 2014 : 2:26:35 PM
How do a use a different atlas than the default in step 7? i see 3 flags for the labels (corrlabel, corrtext, corrts), but not for the actual atlas itself.
morey Posted - Mar 03 2014 : 4:12:46 PM
My question relates to the correlation coefficients of functional connectivity in the resting state pipeline. For example each of the correlation coefficients in the 116 x 116 matrix represents the connectivity strength between nodes. Each subjects cross correlation matrix can be used to contrast between subject groups using randomise. The correlation coefficient can be positive or negative, but a negative correlation value also suggests a strong functional connection if it is close to -1.

When randomise permutes group assignment and computes the group means to generate a distribution of means, these means may not accurately reflect connectivity strengths because the negative and positive correlations would cancel out. One solution might be to take the absolute values of the correlation coefficients prior to permutation.

I noted that there is a normalized matrix but this also has negative values. I am concerned that permuting is not appropriate when numbers of opposite sign but the same magnitude signify comparable connectivity strengths. Is this a legitimate concern?
petty Posted - Jan 22 2013 : 6:54:13 PM
I ran this dataset interactively ( as you ), with 10G of ram. Not sure what your threshold was .. so you'll probably want to run it over. But it does just sound like more memory needed. Somethings don't report their usage correctly, so you can't always go by what was reported with qacct.

"01/22/2013 06:49:44 PM will "scrub" these volumes due to DVARS > 53.4295: [0, 1, 2, 3, 4, 155, 156, 157, 158, 159, 160, 161, 162] "
ch186 Posted - Jan 22 2013 : 5:56:34 PM
I requested 6GB and still got the error. Using "qaact -j" the max was 3.55GB.
syam.gadde Posted - Jan 22 2013 : 4:33:09 PM
The most likely explanation is running out of memory, assuming you haven't already requested more memory as described here:

http://wiki.biac.duke.edu/biac:cluster:submit#job_restrictions

If that assumption is wrong, let us know.
ch186 Posted - Jan 22 2013 : 4:27:06 PM
I am getting a memory error on the DVARS step of the pipeline. Any idea what is causing this?

01/22/2013 04:05:59 PM calculating DVARS for: /mnt/BIAC/munin.dhe.duke.edu/Morey/Lab/TBIPTSD/scrubbing/12947/output_test/filt_12947_rest_st_mcfr_brain_norm_wmcsf.nii.gz
Traceback (most recent call last):
File "/usr/local/bin/resting_pipeline.py", line 1292, in <module>
pipeline = RestPipe()
File "/usr/local/bin/resting_pipeline.py", line 111, in __init__
self.step7()
File "/usr/local/bin/resting_pipeline.py", line 941, in step7
self.step7b()
File "/usr/local/bin/resting_pipeline.py", line 974, in step7b
timeseries = self.scrub_motion_volumes(timeseries)
File "/usr/local/bin/resting_pipeline.py", line 1112, in scrub_motion_volumes
work = work ** 2
File "/usr/lib/python2.6/site-packages/numpy-1.6.1-py2.6-linux-x86_64.egg/numpy/ma/core.py", line 3670, in __pow__
return power(self, other)
File "/usr/lib/python2.6/site-packages/numpy-1.6.1-py2.6-linux-x86_64.egg/numpy/ma/core.py", line 6012, in power
result = np.where(m, fa, umath.power(fa, fb)).view(basetype)
MemoryError
petty Posted - Jan 08 2013 : 11:18:56 AM
to add to that update and only be more specific, the only place where it really would've caused an effect is here:

DVARS calculation ... if you were calculating by a percentage ( ie: --dvarsthreshold=0.5% ), then the mean calculation could've been off, likely causing a higher number volumes to be rejected

BIAC Forums © 2000-2010 Brain Imaging and Analysis Center Go To Top Of Page
This page was generated in 0.35 seconds. Snitz Forums 2000