I was able to get it from the ftp, but I was not able to replicate the error. The last 70 or so time points of this data set are all 0s. I don't think this was the problem, but it might have been. In any event, it will mess up everything else unless you've used time point exclusion files. You can remove them using, eg, mri_convert CM_f.nii.gz --ndrop 70 CM_f.short.nii.gz you'd have to make sure the number you are dropping is correct.
On 4/17/19 4:35 PM, Mcnorgan, Christopher wrote:
External Email - Use Caution
Hi Doug,
After some false starts, I may have uploaded CM_f.nii.gz to the /transfer/incoming folder (my ftp client reports the upload was complete, but the directory listing afterwards shows 0 files). In the event that my ftp client lied to me about the transfer completing successfully, I have also uploaded the file to my google drive where I’ll let it remain for the next few days if you want to get it from there instead: https://drive.google.com/open?id=1urPlFg3NU56RxtZslgLzk-pXef3Csye1
Thanks, Chris
*From:*"Mcnorgan, Christopher" <cpmcnorg@buffalo.edu mailto:cpmcnorg@buffalo.edu> *Subject:**[Freesurfer] Followup on the mystery of the missing mcprextreg file* *Date:*April 16, 2019 at 5:55:28 PM EDT *To:*Freesurfer Mailing List <freesurfer@nmr.mgh.harvard.edu mailto:freesurfer@nmr.mgh.harvard.edu>
External Email - Use Caution
Hi Doug,
For some reason I’m having a problem replying to this list with my reply to your reply. To recap: some of my functional runs are missing the mcprextreg file, and so the GLM with the motion correction parameters is failing.
You had asked whether a mc-subjectname-bold.log file exists for these data. These log files do exist, and I’ve tried a couple times to send the log files (1MB attachment rejected). I’m including a google drive link to one of the log files in the hopes that your offer still stands to get to the bottom of why these files are reliably not being created for some runs, while created for other runs collected during the same session: https://drive.google.com/open?id=17GLikK1mzY5uL52TyqlGK0Sa5N5Fy1KY
We’ve been acutely aware of how many data frames are in each 4D volume because the scanner has been incorrectly writing that all volumes are 256 frames, though our self-paced experiment terminates earlier to that. We accidentally found the fix to be to open up the header using fsledithd, which then zero-pads the missing data frames until we have 256. However this is the case for all runs, so that doesn’t explain why only some runs are failing.
Thanks, Chris
/**********************************************
- Chris McNorgan
- Assistant Professor
- Department of Psychology
- University at Buffalo,
- The State University of New York
- http://ccnlab.buffalo.edu/
- Office: 716.645.0236
- Lab: 716.645.0222
**********************************************/
*From:*"Greve, Douglas N.,Ph.D." <DGREVE@mgh.harvard.edu mailto:DGREVE@mgh.harvard.edu> *Subject:**Re: [Freesurfer] Followup on the mystery of the missing mcprextreg file* *Date:*April 16, 2019 at 6:03:01 PM EDT *To:*"freesurfer@nmr.mgh.harvard.edu mailto:freesurfer@nmr.mgh.harvard.edu" <freesurfer@nmr.mgh.harvard.edu mailto:freesurfer@nmr.mgh.harvard.edu>
Can you upload the functional volume to ftp://surfer.nmr.mgh.harvard.edu/transfer/incoming Let me know when it is there and what the file name is
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer