[caret-users] FW: Problems during/after flattening

[Sandoval, Traci I]

I have uploaded the zip file, Traci.Sandoval.NPRLab.archive.tar.gz
the number of bytes it is trying to read is exactly 3 times the amount that is being read? Thank you for your help. 

Traci Sandoval
NPR Lab
University of Texas at Dallas 


-----Original Message-----
From: caret-users-bounces at brainvis.wustl.edu on behalf of Donna Dierker
Sent: Wed 7/16/2008 1:30 PM
To: Caret, SureFit, and SuMS software users
Subject: Re: [caret-users] FW: Problems during/after flattening
 
Hi Traci,

See inline replies below.

Donna

On 07/16/2008 12:11 PM, Sandoval, Traci I wrote:
>
> After I completed the flattening process and go to save all my files, 
> I receive an error when I try to save the bordercolor file, it says it 
> is open for writing and cannot save?
>
I can think of a few reasons why writing the bordercolor might fail:

* Caret doesn't like the filename for some reason.
* The file system is full.
* You don't have write permission to the current directory.

If you have ruled out the second and third reasons, then try a simple 
name with no special characters or spaces (e.g., test.bordercolor). We 
don't really save the flattening bordercolor, anyway; we use the 
registration bordercolor set here:

http://sumsdb.wustl.edu/sums/archivelist.do?archive_id=6057499
>
> Once I close everything and try to open the files again I receive the 
> following errors. I receive the bordercolor error everytime, but do 
> not always receive the reading files error.
>
> You have selected border files that require a border
> color file but no border color file is selected.
>
Again, you could open the 
ForSPHERICAL.REGISTRATION_Human.Class3.bordercolor in the dataset linked 
above, but its bordercolors won't match the pre-flattening border names; 
they will match the post-flattening border color names in the 
*fromFlattening*borderproj file.
>
> Error Human.121.L.SPHERE_aligned.071008.65070.coord: contains a 
> different number of nodes than Human.121.L.Raw.65070.coord
> Error .: Premature EOF reading zipped file. Tried to read
> 6690888bytes. Actually read 2230296.
>
This is a different, more serious problem. The filenames suggest both 
coords have 65070 nodes, but the error claims otherwise. The "Tried to 
read 6690888bytes" seems excessive for a coord file. The 2230296 number 
seems more reasonable. Was this imported from another format? If you 
could upload it here, I could have a look at it:

http://pulvinar.wustl.edu/cgi-bin/upload.cgi

Often, though, it helps to have the whole dataset (i.e., the spec files 
and all files listed in it, or the current working directory) archived 
in .zip or .tar.gz form.
>
> Thank you for your help.
>
> Traci Sandoval
>
> Research Assistant
>
> University of Texas at Dallas
>
> Center for Brain Health
>
> NPR Lab
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> caret-users mailing list
> caret-users at brainvis.wustl.edu
> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>   

_______________________________________________
caret-users mailing list
caret-users at brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4475 bytes
Desc: not available
Url : http://brainvis.wustl.edu/pipermail/caret-users/attachments/20080718/24497244/attachment.bin