Page status: 2007-06-18: Under construction!
This page describes and provides access to a table which shows the relationships between steps in recon-all, and files that are read, created, written or deleted at each step.
Applies to: Freesurfer version 3.0.5 2007-02-07
Chart is going to go here
xxx
Download Excel version
This version is more tractable to look at and print.
xxx
Data notes
- To avoid clutter, I have omitted columns for most log files
- Unlike my previous effort of this type, in this chart I've retained steps and files from right as well as left processing. I did this to more clearly see steps that involve both left and right.
Method
In brief, this chart builds on directory data gathered during a run of recon-all on the "bert" sample subject. Gathering this data entails two parts:
- A "directory survey" script (FWIW in python) recursively navigates the Freesurfer directories, capturing write, access and directory-mod date-time information for each file.
- Commands added to the recon-all script to run the directory survey script before and after each existing recon-all command. More precisely, in recon-all, commands at each step are invoked using a pattern that builds the command string in variable "cmd", and then runs it by invoking "$cmd". I manually searched for each such location, and inserted my own command to invoke "before" and "after" versions of the directory survey script.
Once the run is complete, the directory-survey data is slurped into a database, cleaned up, and then a cross-tab query organizes the data in Files-vs-steps form.
Wrinkles
- The main wrinkle is that using the file system's access/write/dir-mod date-time feature is a bit iffy. First, this only works on some systems -- on others not all the data-time values work, or they may have granularity too coarse to be useful (despite being reported in seconds). I found that this did work OK on Centos 4 (RHEL 4, or FC something). It did not work on Centos 4 with the files on Mac OS X server accessed via NFS. Don't know whether that's a Mac problem or an NFS problem.
- Even on a system where directory timestamps work acceptably well, it's obviously necessary to make sure the successive steps in the recon-all process do not occur within one second of each other, otherwise the available timestamp resolution will be unable to report a difference in times. For that reason, the directory-survey script incorporates a delay of at least two seconds.
- Backup jobs running in the middle of the proceedings can log extra reads that are nothing to do with recon-all :-).