Duke-UNC Brain Imaging and Analysis Center
BIAC Forums | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Support Forums
 Analysis Software Support
 FSL - cope1 report log errors

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
Bethany Posted - May 30 2008 : 3:08:33 PM
I have a question about my FSL third level analysis for RiskTime.01. The highest-level report log (the one in the top-level output directory looks fine, and the program did produce data for the contrast (though data that didn't look like what I would have expected based on previous analyses).

However, when I go down one level into the cope1.feat directory and look a the report log there, I get something that looks like this:

Progress Report / Log
Started at Fri May 30 13:36:09 EDT 2008

Higher-level stats

cat ../design.lcon | awk '{ print  }' > design.lcon
/usr/local/fsl/bin/flame --cope=filtered_func_data --vc=var_filtered_func_data --dvc=tdof_filtered_func_data --mask=mask --ld=stats --dm=design.mat --cs=design.grp --tc=design.con  --ols --nj=10000 --bi=500 --se=1 --fm --zlt=100000 --zut=100000
DOF cannot be zero or negative!
DOF cannot be zero or negative!
DOF cannot be zero or negative!
DOF cannot be zero or negative!
DOF cannot be zero or negative!
DOF cannot be zero or negative!
DOF cannot be zero or negative!


The same message (DOF cannot be zero or negative!) repeats for many pages. Then it switches to:

DOF cannot be zero or negative!
DOF cannot be zero or negative!
DOF cannot be zero or negative!
Log directory is: stats
Setting up:
ntptsing=23.000000 

No f contrasts
nevs=1
ntpts=23
ngs=1
nvoxels=221619
Running:
nmaskvoxels=601
njumps = 10000
burnin = 500
sampleevery = 1
nsamples = 9500

Metropolis Hasting Sampling
Number of voxels=601
Percentage done:
 1
stdtr domain error

ndtri domain error

stdtr domain error

ndtri domain error

stdtr domain error

ndtri domain error

stdtr domain error

ndtri domain error

stdtr domain error

ndtri domain error

stdtr domain error

ndtri domain error


Then it keeps counting up the percentage done from 1 to 100 with these same error messages repeated every time, after which it finishes off with the post-stats looking normal.

I don't know what's happening. Is this supposed to be happening? Like I said, it does output a contrast, but none of my older third-levels have log files that contain these sorts of error messages and I can't shake the feeling that so many pages of errors must mean something is wrong.

The second-levels logs all normal (both the top directory report and the report for the individual cope I checked).

Any ideas what's going on?
5   L A T E S T    R E P L I E S    (Newest First)
Bethany Posted - May 30 2008 : 11:39:56 PM
I shouldn't be using empty EVs at any point, no. Unless I totally screwed something up somewhere and haven't noticed, which is certainly not impossible.

I got the third levels to run without errors using fslmaths, but got the same (weird) results. Phooey. I'm going to try essentially re-running my original analysis from last year. If that doesn't come out essentially the same, I'll know there's something screwy going on.

Thanks again!
dvsmith Posted - May 30 2008 : 4:24:16 PM

Are you using empty EVs at any point? I've seen weird things happen when using empty EVs. Sometimes if you just re-run the offending analysis, it will correct itself. (strange... I know)
josh.bizzell Posted - May 30 2008 : 3:50:46 PM
I'm not sure what causes the NaN's in the 2nd level copes.... I was under the assumption that FSL doesn't create NaN values. Maybe someone else knows more.

Yes, you should run fslmaths on the offending subjects' copes with NaN values. Unless you can figure out why the NaNs are being created in the first place (which would be optimal).

- Josh
Bethany Posted - May 30 2008 : 3:48:31 PM
Yep, that's exactly what mine look like. Thank you!

Does the fact that I have all these NaNs suggest I'm doing something wrong at a lower level of analysis, or is it just FSL moving in mysterious ways?

Am I right in thinking that it's the second-level cope.nii.gz files I need to use fslmaths on?

Thanks again!
josh.bizzell Posted - May 30 2008 : 3:19:10 PM
I've seen this error before in 3rd level analyses, and it was because of NaN values in one of the copes that was input into the 3rd level.

I detected this by loading the "filtered_func_data" from that 3rd level cope's folder into showsrs2 and found black dots in subjects that were NaN (not a number), usually around the edge of the brain.

If this is the case, you can use fslmaths to convert NaN values to zero with the "-nan" flag.

-Josh

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