VrlWiki - User contributions [en]

Automatic Build System

2014-05-05T19:28:53Z

Tom Sgouros: /* The cron Job */

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

To add more tests to the nightly run, use the systest tools, found in '''/systest/bin''':

;systest-link
:Add a link to the '''/systest/bin''' directory. If it links to something executable, the system will run it every night. The script will run as the user (and group) of the file owner.
:Use it like this: ''/systest/bin/systest-link /systest/projects/vrl/vrl_critical.sh /systest/bin/vrl_crit''

;systest-rem
:Remove a link in the '''/systest/bin''' directory.

There is also a '''systest-req''' which stores metadata (i.e. documentation) about each of the links in '''/systest/bin''' and a '''systest-info''' which regurgitates it.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

The arguments are separated by spaces so there should be no spaces within the arguments.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-05T19:28:34Z

Tom Sgouros: /* The cron Job */

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

To add more tests to the nightly run, use the systest tools, found in '''/systest/bin''':

;systest-link
:Add a link to the '''/systest/bin''' directory. If it links to something executable, the system will run it every night. The script will run as the user (and group) of the file owner.
:Use it like this:

''/systest/bin/systest-link /systest/projects/vrl/vrl_critical.sh /systest/bin/vrl_crit''

;systest-rem
:Remove a link in the '''/systest/bin''' directory.

There is also a '''systest-req''' which stores metadata (i.e. documentation) about each of the links in '''/systest/bin''' and a '''systest-info''' which regurgitates it.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

The arguments are separated by spaces so there should be no spaces within the arguments.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-05T15:05:59Z

Tom Sgouros: /* The cron Job */

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

To add more tests to the nightly run, use the systest tools, found in '''/systest/bin''':

;systest-link
:Add a link to the '''/systest/bin''' directory. If it links to something executable, the system will run it every night. The script will run as the user (and group) of the file owner.
:Use it like this:

<code>/systest/bin/systest-link /systest/projects/vrl/vrl_critical.sh /systest/bin/vrl_crit</code>

;systest-rem
:Remove a link in the '''/systest/bin''' directory.

There is also a '''systest-req''' which stores metadata (i.e. documentation) about each of the links in '''/systest/bin''' and a '''systest-info''' which regurgitates it.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

The arguments are separated by spaces so there should be no spaces within the arguments.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-05T15:05:22Z

Tom Sgouros: /* The cron Job */

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

To add more tests to the nightly run, use the systest tools, found in '''/systest/bin''':

;systest-link
:Add a link to the '''/systest/bin''' directory. If it links to something executable, the system will run it every night. The script will run as the user (and group) of the file owner.
:Use it like this:

<code>/systest/bin/systest-link /systest/projects/vrl/vrl_critical.sh /systest/bin/vrl_crit</code>
;systest-rem
:Remove a link in the '''/systest/bin''' directory.

There is also a '''systest-req''' which stores metadata (i.e. documentation) about each of the links in '''/systest/bin''' and a '''systest-info''' which regurgitates it.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

The arguments are separated by spaces so there should be no spaces within the arguments.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-05T14:50:11Z

Tom Sgouros: added documentation about systest tools.

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

To add more tests to the nightly run, use the systest tools, found in '''/systest/bin''':

;systest-link
:Add a link to the '''/systest/bin''' directory. If it links to something executable, the system will run it every night. The script will run as the user (and group) of the file owner.
:Use it like this: <code>/systest/bin/systest-link /systest/projects/vrl/vrl_critical.sh /systest/bin/vrl_crit</code>
;systest-rem
:Remove a link in the '''/systest/bin''' directory.

There is also a '''systest-req''' which stores metadata (i.e. documentation) about each of the links in '''/systest/bin''' and a '''systest-info''' which regurgitates it.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

The arguments are separated by spaces so there should be no spaces within the arguments.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-02T18:56:18Z

Tom Sgouros: /* Configuration File */

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

The arguments are separated by spaces so there should be no spaces within the arguments.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-02T17:05:09Z

Tom Sgouros: /* Editing the Test Script */

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight because whatever you check in will be checked out into the appropriate place, but by that point, the build process is already running.

Automatic Build System

2014-05-02T14:37:46Z

Tom Sgouros: /* Configuration File */ added config file element description

Every night an automatic build system runs to compile and test the software in the VRL group. This page is for documenting that process. Unless you are working on the build process itself, you probably don't need to know or care about these details. However, they need to be recorded somewhere, and this is as good a place as any.

=The cron Job=

The machine called franklin has a cron job running that every day at 1am (see '''/etc/cron.d/regression_test'''), runs a perl script created by t-staff. The script ('''/tstaff/bin/regtest''') executes (as root) whatever it finds in '''/systest/bin'''.

Most days, what it finds in that directory is a bunch of scripts tstaff uses to manage the process and a couple of scripts called '''vrl_fast''' and '''vrl_slow''' that actually do the work.

* '''vrl_fast''' executes the script '''/research/graphics/tools/gfxtools-startup.sh''', and then executes '''$G/common/build/valid/test.platform.py'''.
* '''vrl_slow''' does the same thing, but executes '''test.platform.py''' with the option '''-config $G/common/build/site/test.platform_slow.cfg'''.

Any scripts found in the '''/systest/bin''' directory that end in '''.weekly''' will only be run on Sundays.

=The Test Script (test.platform.py)=

The test script is a python program at '''$G/common/build/valid/test.platform.py'''. It runs a series of tests and sends an email to people if they fail.

==Configuration File==

The tests run by the '''test.platform.py''' script are listed and configured in '''$G/common/build/site/test.platform.cfg''' (by default) and '''test.platform_slow.cfg'''.

The configuration file has a line for the Developer and a line for the emails of whoever wants to receive the '''Summary''' email messages. Each line after looks like this:

<pre>
testName testList archList scriptName outputDir
</pre>

Where:

* '''testName''' is an arbitrary string used to label this test.
* '''testList''' is a comma-separated list of email addresses who will hear about it if this test fails. Use '''none''' if nobody cares.
* '''archList''' is a comma-separated list of architectures for which this test is designed. This is just a string to be compared with the $GARCH environment variable set in '''gfxtools-startup.sh''' (see above).
* '''scriptName''', '''outputDir''' The '''scriptName''' is executed in the '''outputDir''' directory. The script should contain the build and all the tests that need to be run. We encourage you to use a simple makefile, and to make the default target do a build and test.

Blank lines are ignored and the '''#''' indicates a comment.

==Editing the Test Script==

The actual copy of the test script that runs is the one in '''/research/graphics/common/build/valid'''. Please don't edit this (or the configuration file) directly. Instead, edit the version that is in your sandbox and use CVS to check it in. Note that the first thing test.platform.py does is check stuff out from the main CVS archive and run that. If you edit this script, expect your changes to take effect the night after whatever runs tonight.

Automatic Build System

2014-05-02T14:19:45Z

Tom Sgouros: added detail

Automatic Build System

2014-05-01T16:48:44Z

Tom Sgouros: added page for build system

Shared Public Directory Structure

2014-05-01T16:02:16Z

Tom Sgouros: typos

The graphics group has developed a system over many years that allows easy development of a large, shared base of software. We give the whole thing the nickname <tt>[[$G]]</tt> ("dollar gee"), named after the environment variable that represents the root of the source tree.

The source code our group has created is modified and backed up through a source control system called CVS (Concurrent Versioning System). You must have CVS set up properly in order to develop with our shared codebase.

Source control works by allowing an individual user to make structured copies of the master versions of files (this process is called "checking out" the files). The user then modifies his or her personal copies of the files, and then "checks in" the changes once they're certain that the code compiles and runs properly. The location where a user modifies a personal copy of shared code is called a "sandbox", because it is in some sense walled off from the master copy: destructive changes to the code in the sandbox do not affect the master copy, provided the user doesn't check them in.

Environment variables are used to configure the development environment. Visit this page for general instructions for [[Setting Environment Variables]] and using them. The instructions in the remainder of this section require that you know how to set up environment variables. For Windows the instructions use the native Windows (cmd.exe) command shell. Unix command examples should work on most shells.

Even if you intend to work on Windows you should set up your sandbox at Brown using Linux. The instructions will include Windows specific instructions when applicable. Explicit procedures for setting up a remote Windows system (like your laptop) are not yet in place. If you are familiar with setting up Windows development environments you should be able to adapt these procedures.

Here's a description of the directories you will find under '''/research/graphics/''':

* '''data''': A directory for large datasets.

* '''users''': Space for students to set up sandboxes.

* '''tools/linux/import''': Pre-installed third party software.

* '''tools/linux/install_linux''': Shared copies of pre-built Linux projects.

* '''tools/linux/install_WIN32''': Shared copies of pre-built Windows projects.

* '''tools/public/yesterday''': Browse recent common and project directories.

* '''tools/public/raw_notes''': Unedited notes on a variety of development topics.

* '''cvsroot''': The CVS repository. The files in here are only for administrators to access. Students should only access the repository through CVS commands.

Within the CVS repository the primary directories are:

* '''import''': Downloaded kits for third party software.

* '''common''': Software used by multiple projects.

* '''project''': Project software.

A copy of the '''common''' and '''project''' directories for you to browse is updated nightly at:
/research/graphics/tools/public/yesterday

See [[Using Public or Private Programs and Libraries]] for
a detailed overview of the environment variables and directories.

At any given time there are several active versions of our software. Students need to be aware of what version is appropriate for their work and set up their workspace to reflect this.

* The latest source checked into CVS

* The version in a students project directory at the time they last checked it out or changed it.

* The version installed in a students sandbox the last time they built and installed it.

* The public installed copy at: /research/graphics/tools/linux/install_$GARCH

* The copy used for cloning at: /research/graphics/tools/public/clone

Software Development

2014-05-01T16:00:00Z

Tom Sgouros: added page for build system

* '''Essential Background Reading'''
** [[Shared Public Directory Structure]]
** [[Understanding File Permissions]]
** [[Setting Environment Variables]]
** [[Introduction to CVS]]
** [[Minimal Coding Conventions|Coding Conventions and Programming Tips]]

* '''Create a Linux Sandbox'''
** [[Get a Linux Account]]
** Set up Your Sandbox
*** [[Automated Quick Start|Automated Quick Start - Linux only]]
*** [[Quick Start for CIT Users|Manual Quick Start - Windows and Linux]]
** [[Merge Installed Programs Into One Directory]]

* '''Software Development Tasks'''
** Before you start, [[Building and Installing Common Components]]
** Work on Existing Projects
*** [[Check out projects|Check out and build existing projects]]
**** [[Building CavePainting|For example: Building CavePainting (includes building VRG3D)]]
*** [[Contribute to projects|Contribute to existing projects]]
** Add a project
*** [[Add a new project]]
**** [[Build a Trivial Program]]
**** [[Build a Trivial Library]]
*** [[Port existing project|Port existing project to the new $G]]
**[[Writing Make Files]]
**[[Automatic Build System]]

* '''Advanced Topics'''
** [[Create a Windows Sandbox|Create a Windows Sandbox (In or out of CIT)]]
** [[Software tests|Create and automate software tests]]
** [[Install 3rd party code|Install 3rd-party programs or libraries]]
** [[Using Public or Private Programs and Libraries]]
** [[Multiple Directories|Set up a project with multiple directories]]
** [[Working With Multiple Sandboxes]]
** [[Working With Legacy Software]]
** [[Software demos|Create and install software demos]]
** [[Distribute software|Distribute software and data]]

[[Category:Software Development]]

Registration of Bones Across Positions

2014-04-15T14:50:54Z

Tom Sgouros: /* What we have here is a failure to register */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#Check whether a "crop_values.txt" file exists -- it helps reduce the number of voxels processed.
#cd to the top-level of your subject's data.
#ssh to a CS-LAB machine, e.g., "ssh cslab9g".
#Run install_linux/bin64/batchGen.py and answer the questions. (The first time you process the data, accept all the defaults.)
#Type "./classify.py" wait a few hours.
#Type "./register.py" wait an hour or so.

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

The result of this step is a set of scripts in $DATA/qsub that will be used for the classification and registration steps. The classify.py script executes the classification step, and unsurprisingly, register.py does the registration. You'll also see a collector.py, which takes the output from the registration step and condenses it to a set of simple transposition matrices. This script is run automatically at the end of the registration step, for the poses where registration succeeded.

===Program inputs===

The input to the classification stage is:

* CT scans, stored in a directory called $DATA/original_scans
* A crop_values.txt file.

The input to the registration step is:

* The output from the classification stage, stored in $DATA/classified_scans.
* The digitized (segmented) bone shapes, stored in $DATA/original_stacks.

Optionally, the input to this stage can include a [[registration configuration file]], which is used to set starting points for a registration match search, or to limit the range of such searches, or to eliminate the need for a search altogether, on a per-bone basis.

Configuration files are generated each time the registration step is run, and put into the $DATA/warmBones directory. You can use these files as raw material for creating a configuration file for your experiment.

===Program outputs===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

* Classified scans in a folder called $DATA/classified_scans.

* Log files found in $DATA/qsub_output/alpha_qsub.sh.oXXXXXX.Y and $DATA/qsub_output/subset_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the run and Y is the number of some process corresponding to that run. The error output is in files called .eXXXXXX.YY. For successful runs, these files will be empty.

The output of the registration step is:

* The positions of the bones within a pose, stored in $DATA/auto_registr_results. There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* The '.txt' files above are the output of the various attempts to find the rotations and translations of the various bones. The registration step ends by executing 'collector.py' that consolidates the rotations and translations in the '.txt' files. These outputs are left in the $DATA/collected_results.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the [[registration configuration file]] you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration of Bones Across Positions

2014-04-15T14:50:26Z

Tom Sgouros: /* What we have here is a failure to register */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#Check whether a "crop_values.txt" file exists -- it helps reduce the number of voxels processed.
#cd to the top-level of your subject's data.
#ssh to a CS-LAB machine, e.g., "ssh cslab9g".
#Run install_linux/bin64/batchGen.py and answer the questions. (The first time you process the data, accept all the defaults.)
#Type "./classify.py" wait a few hours.
#Type "./register.py" wait an hour or so.

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

The result of this step is a set of scripts in $DATA/qsub that will be used for the classification and registration steps. The classify.py script executes the classification step, and unsurprisingly, register.py does the registration. You'll also see a collector.py, which takes the output from the registration step and condenses it to a set of simple transposition matrices. This script is run automatically at the end of the registration step, for the poses where registration succeeded.

===Program inputs===

The input to the classification stage is:

* CT scans, stored in a directory called $DATA/original_scans
* A crop_values.txt file.

The input to the registration step is:

* The output from the classification stage, stored in $DATA/classified_scans.
* The digitized (segmented) bone shapes, stored in $DATA/original_stacks.

Optionally, the input to this stage can include a [[registration configuration file]], which is used to set starting points for a registration match search, or to limit the range of such searches, or to eliminate the need for a search altogether, on a per-bone basis.

Configuration files are generated each time the registration step is run, and put into the $DATA/warmBones directory. You can use these files as raw material for creating a configuration file for your experiment.

===Program outputs===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

* Classified scans in a folder called $DATA/classified_scans.

* Log files found in $DATA/qsub_output/alpha_qsub.sh.oXXXXXX.Y and $DATA/qsub_output/subset_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the run and Y is the number of some process corresponding to that run. The error output is in files called .eXXXXXX.YY. For successful runs, these files will be empty.

The output of the registration step is:

* The positions of the bones within a pose, stored in $DATA/auto_registr_results. There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* The '.txt' files above are the output of the various attempts to find the rotations and translations of the various bones. The registration step ends by executing 'collector.py' that consolidates the rotations and translations in the '.txt' files. These outputs are left in the $DATA/collected_results.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the [registration configuration file] you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration configuration file

2014-04-10T00:28:43Z

Tom Sgouros:

The registration configuration file can be used to control or skip some of the steps in the registration process. It consists of a header section and then a series of per-bone sections.

The header section begins with a line reading <code>[main]</code> and contains a <code>startBone</code> declaration. The declarations following define default values for all the bones in the scan. The pound character <code>#</code> indicates a comment.

[main]
startBone=rad
decentFitValue=10
failFitValue=20
TranslationLimit=5
RotationLimit=0.5
...
[tpd]
dependsOn=tpm
runMode=fixed
StartTranslation=-0.35307 0.28524 -0.301178
StartRotation=0.0150448 -0.0528962 -0.000270465

The fields have the following meaning. All the bone names are the three-letter short versions.

;startBone
:The first bone in the hierarchy. Almost always the radius.
;dependsOn
:Required for each bone except the startBone. Indicates the bone above this one in the bone hierarchy.
;decentFitValue
:A fit value less than this number counts as success. The optimization does not use this value as a test; it only seeks to minimize the fit value. This setting simply issues a warning when it is exceeded.
;failFitValue
:If the final fit value is greater than this number, it will trigger an error and several warning messages. The system will try to repeat the optimization with an increased RotationLimit before it fails.
;TranslationLimit
:In the optimization step, translations are limited to this distance in any direction.
;RotationLimit
:In the optimization step, rotations are limited to the range (-pi * RotationLimit, pi * RotationLimit).
;runMode
:'fixed' or 'twice'. For 'fixed' mode, the optimization step is skipped and the values given by StartTranslation and StartRotation are returned. 'twice' is not implemented and should not be used. If you don't want fixed mode, omit this parameter.
;StartTranslation
:When runMode is 'fixed' this is the final translation value, three coordinates separated by spaces. When not in fixed run mode, this value is sent to the optimization step as an initial guess.
;StartRotation
:When runMode is 'fixed' this is the final rotation value, three coordinates separated by spaces, to be multiplied by pi before being used. When not in fixed run mode, this value is sent to the optimization step as an initial guess.

After a registration run, you will find sample registration configuration files in the $DATA/warmBones directory. These can be used in conjunction with the <code>--warmConfig</code> option to skip the registration calculation for bones whose position has already been found. Use this to recover from an error without having to re-run all the bones before the one that caused the failure.

Registration configuration file

2014-04-10T00:26:36Z

Tom Sgouros: added

The registration configuration file can be used to control or skip some of the steps in the registration process. It consists of a header section and then a series of per-bone sections.

The header section begins with a line reading <code>[main]</code> and contains a <code>startBone</code> declaration. The declarations following define default values for all the bones in the scan. The pound character <code>#</code> indicates a comment.

[main]
startBone=rad
decentFitValue=10
failFitValue=20
TranslationLimit=5
RotationLimit=0.5
...
[tpd]
dependsOn=tpm
runMode=fixed
StartTranslation=-0.35307 0.28524 -0.301178
StartRotation=0.0150448 -0.0528962 -0.000270465

The fields have the following meaning. All the bone names are the three-letter short versions.

startBone: The first bone in the hierarchy. Almost always the radius.
dependsOn: Required for each bone except the startBone. Indicates the bone above this one in the bone hierarchy.
decentFitValue: A fit value less than this number counts as success. The optimization does not use this value as a test; it only seeks to minimize the fit value. This setting simply issues a warning when it is exceeded.
failFitValue: If the final fit value is greater than this number, it will trigger an error and several warning messages. The system will try to repeat the optimization with an increased RotationLimit before it fails.
TranslationLimit: In the optimization step, translations are limited to this distance in any direction.
RotationLimit: In the optimization step, rotations are limited to the range (-pi * RotationLimit, pi * RotationLimit).
runMode: 'fixed' or 'twice'. For 'fixed' mode, the optimization step is skipped and the values given by StartTranslation and StartRotation are returned. 'twice' is not implemented and should not be used. If you don't want fixed mode, omit this parameter.
StartTranslation: When runMode is 'fixed' this is the final translation value, three coordinates separated by spaces. When not in fixed run mode, this value is sent to the optimization step as an initial guess.
StartRotation: When runMode is 'fixed' this is the final rotation value, three coordinates separated by spaces, to be multiplied by pi before being used. When not in fixed run mode, this value is sent to the optimization step as an initial guess.

After a registration run, you will find sample registration configuration files in the $DATA/warmBones directory. These can be used in conjunction with the <code>--warmConfig</code> option to skip the registration calculation for bones whose position has already been found. Use this to recover from an error without having to re-run all the bones before the one that caused the failure.

Registration of Bones Across Positions

2014-04-09T23:03:00Z

Tom Sgouros: /* Program outputs */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#Check whether a "crop_values.txt" file exists -- it helps reduce the number of voxels processed.
#cd to the top-level of your subject's data.
#ssh to a CS-LAB machine, e.g., "ssh cslab9g".
#Run install_linux/bin64/batchGen.py and answer the questions. (The first time you process the data, accept all the defaults.)
#Type "./classify.py" wait a few hours.
#Type "./register.py" wait an hour or so.

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

The result of this step is a set of scripts in $DATA/qsub that will be used for the classification and registration steps. The classify.py script executes the classification step, and unsurprisingly, register.py does the registration. You'll also see a collector.py, which takes the output from the registration step and condenses it to a set of simple transposition matrices. This script is run automatically at the end of the registration step, for the poses where registration succeeded.

===Program inputs===

The input to the classification stage is:

* CT scans, stored in a directory called $DATA/original_scans
* A crop_values.txt file.

The input to the registration step is:

* The output from the classification stage, stored in $DATA/classified_scans.
* The digitized (segmented) bone shapes, stored in $DATA/original_stacks.

Optionally, the input to this stage can include a [[registration configuration file]], which is used to set starting points for a registration match search, or to limit the range of such searches, or to eliminate the need for a search altogether, on a per-bone basis.

Configuration files are generated each time the registration step is run, and put into the $DATA/warmBones directory. You can use these files as raw material for creating a configuration file for your experiment.

===Program outputs===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

* Classified scans in a folder called $DATA/classified_scans.

* Log files found in $DATA/qsub_output/alpha_qsub.sh.oXXXXXX.Y and $DATA/qsub_output/subset_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the run and Y is the number of some process corresponding to that run. The error output is in files called .eXXXXXX.YY. For successful runs, these files will be empty.

The output of the registration step is:

* The positions of the bones within a pose, stored in $DATA/auto_registr_results. There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* The '.txt' files above are the output of the various attempts to find the rotations and translations of the various bones. The registration step ends by executing 'collector.py' that consolidates the rotations and translations in the '.txt' files. These outputs are left in the $DATA/collected_results.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the configuration file you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration of Bones Across Positions

2014-04-09T21:24:18Z

Tom Sgouros: /* Technical Notes */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#Check whether a "crop_values.txt" file exists -- it helps reduce the number of voxels processed.
#cd to the top-level of your subject's data.
#ssh to a CS-LAB machine, e.g., "ssh cslab9g".
#Run install_linux/bin64/batchGen.py and answer the questions. (The first time you process the data, accept all the defaults.)
#Type "./classify.py" wait a few hours.
#Type "./register.py" wait an hour or so.

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

The result of this step is a set of scripts in $DATA/qsub that will be used for the classification and registration steps. The classify.py script executes the classification step, and unsurprisingly, register.py does the registration. You'll also see a collector.py, which takes the output from the registration step and condenses it to a set of simple transposition matrices. This script is run automatically at the end of the registration step, for the poses where registration succeeded.

===Program inputs===

The input to the classification stage is:

* CT scans, stored in a directory called $DATA/original_scans
* A crop_values.txt file.

The input to the registration step is:

* The output from the classification stage, stored in $DATA/classified_scans.
* The digitized (segmented) bone shapes, stored in $DATA/original_stacks.

Optionally, the input to this stage can include a [[registration configuration file]], which is used to set starting points for a registration match search, or to limit the range of such searches, or to eliminate the need for a search altogether, on a per-bone basis.

Configuration files are generated each time the registration step is run, and put into the $DATA/warmBones directory. You can use these files as raw material for creating a configuration file for your experiment.

===Program outputs===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

The output of the registration step is:

* You'll find the positions of the bones within a pose in $DATA/auto_registr_results. There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* The '.txt' files above are the output of the various attempts to find the rotations and translations of the various bones. The registration step ends by executing 'collector.py' that consolidates the rotations and translations in the '.txt' files. These outputs are left in the $DATA/collected_results.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the configuration file you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration

2014-04-09T21:13:52Z

Tom Sgouros: Most of these instructions have changed, and the linked page has the updated version.

[https://wiki.brown.edu/confluence/display/orthobio/Compiling+the+CS+Carpal+Pipeline|Compiling the CS Carpal Pipeline]

[[Registration of Bones Across Positions#Technical Notes|Use instructions here]]

Wrists

2014-04-09T21:11:29Z

Tom Sgouros: /* Specific Tools and Technical Details */

The wrist is a diarthrodial anatomical joint consisting of 8 small bones (scaphoid, capitate, hamate, lunate, trapezium, trapezoid, triquetrum, pisiform) and 7 long bones (radius, ulna, and 5 metacarpals). When subject to injury and disease the wrist undergoes changes in kinematics, inter-bone joint space areas, cartilage thickness, length of ligament paths, etc. Developing computational tools for the analysis of anatomical joint characteristics is important in understanding the cause of injury, tracing the progress of disease, and taking preventative measures.

<gallery widths="250px" heights="250px">
Image:Wrist.jpg.jpeg| X-ray of the wrist with bone names
Image:Ligaments.jpg| Ligaments: posterior view of left wrist
</gallery>

==Description of Overall Pipeline==

#[[Data]]
#[[Bone Surface Extraction]]
#[[Registration of Bones Across Positions]]
#[[Retrieval of Kinematics]]
#[[Inter-bone Joint Space Area Calculations]]
#[[Ligament Path Calculations]]
#[[Cartilage Maps (location & thickness)]]
#[[Cartilage Surface Deformations]]
#[[Joint Simulation]]

==Specific Tools and Technical Details==

#[[Registration of Bones Across Positions#Technical Notes|registration]]
#[[joint space area calculations]]
#[[cartilage building]]
#"wiggling" bones around
#ligament length measures

[[Wrist Pipeline Technical Details | Technical Details on Wrist Pipeline and its relationship to the $G software framework]]

Wrists

2014-04-09T21:10:11Z

Tom Sgouros: /* Specific Tools and Technical Details */

The wrist is a diarthrodial anatomical joint consisting of 8 small bones (scaphoid, capitate, hamate, lunate, trapezium, trapezoid, triquetrum, pisiform) and 7 long bones (radius, ulna, and 5 metacarpals). When subject to injury and disease the wrist undergoes changes in kinematics, inter-bone joint space areas, cartilage thickness, length of ligament paths, etc. Developing computational tools for the analysis of anatomical joint characteristics is important in understanding the cause of injury, tracing the progress of disease, and taking preventative measures.

<gallery widths="250px" heights="250px">
Image:Wrist.jpg.jpeg| X-ray of the wrist with bone names
Image:Ligaments.jpg| Ligaments: posterior view of left wrist
</gallery>

==Description of Overall Pipeline==

#[[Data]]
#[[Bone Surface Extraction]]
#[[Registration of Bones Across Positions]]
#[[Retrieval of Kinematics]]
#[[Inter-bone Joint Space Area Calculations]]
#[[Ligament Path Calculations]]
#[[Cartilage Maps (location & thickness)]]
#[[Cartilage Surface Deformations]]
#[[Joint Simulation]]

==Specific Tools and Technical Details==

#[Registration_of_Bones_Across_Positions#Technical_Notes registration]
#[[joint space area calculations]]
#[[cartilage building]]
#"wiggling" bones around
#ligament length measures

[[Wrist Pipeline Technical Details | Technical Details on Wrist Pipeline and its relationship to the $G software framework]]

Screen program

2014-04-08T15:39:11Z

Tom Sgouros: added external links

The [http://www.gnu.org/software/screen/ screen program] is a useful Linux utility that can leave a session running without a terminal window open. Do 'man screen' to get more information, but here are the basics:

* Log into whatever machine you plan to run your program on.
* Type 'screen' to start the program.
* Get everything ready and start your long-running job.
* Type 'ctrl-A' and then 'd' for 'detach' and the screen you were just looking at will disappear.
* You can now log off and your job will keep on running.

Don't forget to make a note of which machine you were running it on, though. There are a lot of machines in the sunlab and you don't want to have to log onto them all to find the program you left running.

Later, when you want to resume work:

* Log in to the same machine you were running on before.
* Type 'screen -r' to resume where you left off.
* The screen you had before should reappear.

Screen can manage multiple sessions, too, and is useful in dozens of other ways, but there is real documentation out there to consult for that purpose. Type 'ctrl-A' and '?' to get a tiny taste, but don't go much further without at least reading the man page or the [http://www.gnu.org/software/screen/manual/ rest of its ample documentation].

Registration of Bones Across Positions

2014-04-08T15:32:17Z

Tom Sgouros: /* Technical Notes */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#Check whether a "crop_values.txt" file exists -- it helps reduce the number of voxels processed.
#cd to the top-level of your subject's data.
#ssh to a CS-LAB machine, e.g., "ssh cslab9g".
#Run install_linux/bin64/batchGen.py and answer the questions. (The first time you process the data, accept all the defaults.)
#Type "./classify.py" wait a few hours.
#Type "./register.py" wait an hour or so.

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

The result of this step is a set of scripts in $DATA/qsub that will be used for the classification and registration steps.

===Program input===

The input to the classification stage is:

* CT scans, stored in a directory called $DATA/original_scans
* A crop_values.txt file.

The input to the registration step is:

* The output from the classification stage, stored in $DATA/classified_scans.
* The digitized (segmented) bone shapes, stored in $DATA/original_stacks.

Optionally, the input to this stage can include a [[registration configuration file]], which is used to set starting points for a registration match search, or to limit the range of such searches, or to eliminate the need for a search altogether, on a per-bone basis.

Configuration files are generated each time the registration step is run, and put into the $DATA/warmBones directory. You can use these files as raw material for creating a configuration file for your experiment.

===Program output===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

The output of the registration step is:

* You'll find the positions of the bones within a pose in $DATA/auto_registr_results . There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the configuration file you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration of Bones Across Positions

2014-04-08T15:13:22Z

Tom Sgouros: /* Program input */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#check whether a "crop_values.txt" file exists-- it helps reduce the number of voxels processed
#cd to the top-level of your subject's data
#ssh to a CS-LAB machine, e.g., "ssh cslab9g"
#run install_linux/bin64/batchGen.py and answer the questions
##The first time you process the data, accept all the defaults
#type "./classify.py" wait a few hours
#type "./register.py" wait an hour or so

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

===Program input===

The wrist registration program runs in a

The input to the classification stage is:

* CT scans, stored in a directory called $DATA/original_scans
* A crop_values.txt file.

The input to the registration step is:

* The output from the classification stage, stored in $DATA/classified_scans.
* The digitized (segmented) bone shapes, stored in $DATA/original_stacks.

Optionally, the input to this stage can include a [[registration configuration file]], which is used to set starting points for a registration match search, or to limit the range of such searches, or to eliminate the need for a search altogether, on a per-bone basis.

Configuration files are generated each time the registration step is run, and put into the $DATA/warmBones directory. You can use these files as raw material for creating a configuration file for your experiment.

===Program output===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

The output of the registration step is:

* You'll find the positions of the bones within a pose in $DATA/auto_registr_results . There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the configuration file you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration of Bones Across Positions

2014-04-07T21:22:11Z

Tom Sgouros: /* Program output */

The registration process uses bone surfaces extracted from the neutral position and CT volumes to calculate bone kinematics, i.e rotations and translations of the center of mass of each each bone, across each position. This method has 2 steps, classification and registration. The classification step sorts through the voxels calculating a distance from each voxel to the nearest surface. The registration step uses that data to place a surface in such a way as to minimize the total sum of the distances.

==Tissue Classification and Localized Distance Fields==

Bone, soft tissue, and air are represented by different intensities in CT images. Our tissue classification algorithm goes through the non-neutral CT volumes and calculates a distance from the center of each voxel to the closest material boundary. The output of classification is a distance field for each material. We are interested only in the distance field of the bone material.

==Bone Registration==

The input data to this step is the distance field derived in the classification step and the geometrical model obtained from the neutral CT scans. These are used to retrieve bone kinematics across positions. It works by superimposing the geometrical model on the distance field. If a voxel intersects the model surface, the voxel's distance to the nearest material surface is recorded. The sum of these distances provides a measure of how far out of alignment the model surface is. The registration step consists of searching the rotation and translation space of the bone to minimize the sum of these distances.

==Technical Notes==

To run the classification and registration process, follow these steps:

#check whether a "crop_values.txt" file exists-- it helps reduce the number of voxels processed
#cd to the top-level of your subject's data
#ssh to a CS-LAB machine, e.g., "ssh cslab9g"
#run install_linux/bin64/batchGen.py and answer the questions
##The first time you process the data, accept all the defaults
#type "./classify.py" wait a few hours
#type "./register.py" wait an hour or so

(For long-running jobs you want to leave and come back to, the [[screen program]] is your friend.)

===Program input===

===Program output===

The output of the two steps consists of files within the input data directory. For example, if the input data is in a directory called E50072_scan, the output of both steps will be files in subdirectories of that directory. In the following, we'll refer to the input data directory as $DATA.

The output of the classification step is:

The output of the registration step is:

* You'll find the positions of the bones within a pose in $DATA/auto_registr_results . There are two varieties of file in that directory. The '.txt' files contain the output data, while the '.log' files contain potentially helpful output from the program. If the --delete-log flag is used to invoke the registration step, the logs will be deleted upon successful execution.

* During the optimization step, the qsub program is used to run instances of the registration program on many different host machines. The standard output of those runs can be found in files called $DATA/qsub_output/register_qsub.sh.oXXXXXX.Y, where XXXXXX is an identifier for the specific run and Y is the job number. The error output is in files with the suffix eXXXXXX.Y.

* You'll find configuration files that record the bone positions found in the $DATA/warmBones directory. If you need to re-run your job, these files can save some time, since they use the optimized positions found in the registration run. If any pose failed, the configuration file for that pose will include the correct positions of the bones found up to the failure point.

===What we have here is a failure to register===

The registration step often fails on one or more of the poses in a subject's data. You'll know the run has failed from the output to your terminal. It will say something like

ERROR: The WristRegistration runs failed with status = 1
They need to be rerun.

Probably only one or two of the poses failed; you can identify them from the text immediately before this. (An exit code of zero means success.) Note that the job numbers you see on the program output are not the same as the numbers indicating a pose. For example, a normal set of poses might be 2,3,4,5,6,7,8,9,10,11,12 and 15. These will be executed as job numbers 1,2,3,4,5,6,7,8,9,10,11, and 12.

Once you identify the offending pose, you need to use the Wrist Viewer program ([[WristViz]]) to find a good initial position for the bone alignments that failed. Create or copy a configuration file and identify it in the corresponding $DATA/qsub/registerXX_qsub.sh file, where XX is the job number of the run you need to fix. When you open that file, you'll see a messy long line that runs the WristRegistration program. Add this to the end of that line:

--configFile config.txt

Where config.txt is actually the path name of the configuration file you've created. There are sample configuration files in the $DATA/warmBones directory, and if you use the one that corresponds to the failed job, the registration process will use the data from the bones that succeeded and they don't have to be found again in the next run. This can result in substantial time savings.

Repeat the process above and it should succeed this time.

Registration of Bones Across Positions

2014-04-07T21:20:00Z

Tom Sgouros: /* What we have here is a failure to register */

Screen program

2014-04-07T21:02:55Z

Tom Sgouros:

The screen program is a useful Linux utility that can leave a session running without a terminal window open. Do 'man screen' to get more information, but here are the basics:

* Log into whatever machine you plan to run your program on.
* Type 'screen' to start the program.
* Get everything ready and start your long-running job.
* Type 'ctrl-A' and then 'd' for 'detach' and the screen you were just looking at will disappear.
* You can now log off and your job will keep on running.

Don't forget to make a note of which machine you were running it on, though. There are a lot of machines in the sunlab and you don't want to have to log onto them all to find the program you left running.

Later, when you want to resume work:

* Log in to the same machine you were running on before.
* Type 'screen -r' to resume where you left off.
* The screen you had before should reappear.

Screen can manage multiple sessions, too, and is useful in dozens of other ways, but there is real documentation out there to consult for that purpose. Type 'ctrl-A' and '?' to get a tiny taste, but don't go much further without at least reading the man page.

Screen program

2014-04-07T21:00:50Z

Tom Sgouros: brief introduction to the screen program

The screen program is a useful Linux utility that can leave a session running without a terminal window open. Do 'man screen' to get more information, but here are the basics:

* Type 'screen' to start the program.
* Get everything ready and start your long-running job.
* Type 'ctrl-A' and then 'd' for 'detach' and the screen you were just looking at will disappear.
* You can now log off and your job will keep on running. Make a note of which machine you were running it on, though.

Later, when you want to resume work:

* Log in to the same machine you were running on before.
* Type 'screen -r' to resume where you left off.
* The screen you had before should reappear.

Screen can manage multiple sessions, too, and is useful in dozens of other ways, but there is real documentation out there to consult for that purpose.

Registration of Bones Across Positions

2014-04-07T20:55:38Z

Tom Sgouros: /* What we have here is a failure to register */

Registration of Bones Across Positions

2014-04-07T20:55:14Z

Tom Sgouros:

Registration of Bones Across Positions

2014-04-07T20:54:27Z

Tom Sgouros: revamp

Registration of Bones Across Positions

2014-04-07T17:46:30Z

Tom Sgouros:

Registration of Bones Across Positions

2014-04-07T17:45:45Z

Tom Sgouros: /* Tissue Classification and Localized Distance Fields */