Commit Graph

4 Commits (3ab78543a737223be36421ff2cef7757fa4b1bb1)

Author SHA1 Message Date
David Roazen 3ab78543a7 Fix tests that were consistently or intermittently failing when run in parallel on the farm
-Make MaxRuntimeIntegrationTest more lenient by assuming that startup overhead
 might be as long as 120 seconds on a very slow node, rather than the original
 assumption of 20 seconds

-In TraverseActiveRegionsUnitTest, write temp bam file to the temp directory, not
 to the current working directory

-SimpleTimerUnitTest: This test was internally inconsistent. It asserted that
 a particular operation should take no more than 10 milliseconds, and then asserted
 again that this same operation should take no more than 100 microseconds (= 0.1 millisecond).
 On a slow node it could take slightly longer than 100 microseconds, however.
 Changed the test to assert that the operation should require no more than 10000 microseconds
 (= 10 milliseconds)

-change global default test timeout from 20 to 40 minutes (things just take longer
 on the farm!)

-build.xml: allow runtestonly target to work with scala test classes
2013-03-06 13:56:54 -05:00
David Roazen 65d31ba4ad Fix runtime public -> protected dependencies in the test suite
-replace unnecessary uses of the UnifiedGenotyper by public integration tests
 with PrintReads

-move NanoSchedulerIntegrationTest to protected, since it's completely dependent
 on the UnifiedGenotyper
2013-02-26 21:19:12 -05:00
Mauricio Carneiro 2a4ccfe6fd Updated all JAVA file licenses accordingly
GSATDG-5
2013-01-10 17:06:41 -05:00
Mark DePristo 251983b8fb Add GATK-wide command line argument to control the maximum runtime allowed for the GATK
-- Providing this optional argument -maxRuntime (in -maxRuntimeUnits units) causes the GATK to exit gracefully when the max. runtime has been exceeded.  By cleanly I mean that the engine simply stops at the next available cycle in the walker as through the end of processing had been reached.  This means that all output files are closed properly, etc.
-- Emits an info message that looks like "INFO  10:36:52,723 MicroScheduler - Aborting execution (cleanly) because the runtime has exceeded the requested maximum 10.0000 s".  Otherwise there's currently no way to differentiate a truly completed run from a timelimit exceeded run, which may be a useful thing for a future update
-- Resolves GSA-630 / GATK max runtime to deal with bad LSA calling?
-- Added new JIRA entry for Ami to restart chr1 macarthur with this argument set to -maxRuntime 1 -maxRuntimeUnits DAYS to see if we can do all of chr1 in one weekend.
2012-10-26 13:18:34 -04:00