The test suite
Reliability in the face of complexity is the real challenge of software development, as discussed in this paper.
Download and explode the test cases
The input files are in the directories below tsuite in the distribution. The output is in this directory. There are three directories below auto which contain different types of tests. Those in the auto directory are run every night in Lexington, is a large number of simulations that test some aspect of the physics. The tests in the slow directory take about three days and are continuously running on machines here. The directories under programs contain programs that call Cloudy as a subroutine. Each directory contains several perl scripts and html files. The readme_*.htm files describe the contents of each directory. The file doc_tsuite.htm documents the purpose of each of the tests. It could be studied to see how to set up the code.
The tests should not be placed in a directory which contained an older version until the old version is first deleted. The names of the test cases change from time to time and placing the current version of the suite on top of an old one will not overwrite all the old ones. This will cause problems when the test suite is run. Either start with a new directory or first delete the contents of the directory.
Running the test cases
The test suite includes Perl scripts to run all the test cases and then check for problems. These are files that have names *.pl.
The runall.pl script will run all the input files. You will need to edit it so that the string "$exe" points to your executable for Cloudy. This test suite takes about half a day on with a fairly modern CPU, so you might want to do this overnight.
The "assert" commands within the test suite
A large code must be completely checked every time anything is changed. The code uses extensive self-checking during a calculation to insure that the results are valid. The assert commands in the input files tell the code what answer to expect, based either on analytical or previous results. This allows the code to confirm that it has found the correct answer. A distinctive string is printed if the right answer is not obtained. The Perl script checkall.pl will examine all output files to search for failed asserts, other problems, or crashes. These would indicate a problem.
The assert commands have nothing to do with the simulation or the astrophysics, but instead provide a way for the code to implement these automatic self-checks. The Perl script tests_remove_asserts.pl will remove all the asserts if you wish to reuse these scripts for other purposes.
Check the results
Problems will be announced at the end of the calculation by a line that includes the string PROBLEM or botched asserts. If the code crashes then the normal end-of-calculation string will not be printed.
The test distribution includes the Perl script checkall.pl that will check for problems once the test cases have been computed. Run this script and notice what it says.
The stellar atmosphere test cases stars_*.in require the compiled stellar atmosphere files. These will not succeed if you did not install the stellar atmospheres. This is OK if you don't need those continua. Starting with the C08 release, the checkall.pl script will quietly skip sims that failed because the stellar atmosphere file was not installed and list them in the file skip.txt instead.
Next step, apply any HotFixes.
Return to the StepByStep instructions.
Return to nublado.org
