Please note: Sytem Test Procedures are being updated.
John, Serguei and Steve, 19th August 2002.
Note that sometimes this area contains symbolic links to local discs of specific machines to improve performance. E.g.:
/afs/cern.ch/user/s/stesting/stt/prod/SUN-CC/debug_NONISO -> /home3/stesting/prod/SUN-CC/debug_NONISOso you need to be logged into the appropriate machine to see files under these links.
src/: this contains geant4/. This is checked out/updated from the geant4 CVS repository as defined by the *.sdb files (see Defining the Geant4 Source Tree). testtools/: this contains a separately checked out version of geant4/tests/GNUmakefile, History, README, mailing_list, responsibles, results/ and tools/. This is so that the scripts (see below) in testtools/geant4/tools/bin/ are decoupled from the versions under src/geant4/tests/tools/bin. The former are the ones which are effective at run time. This means one can change and develop them without affecting src/. To avoid ambiguities with tag names, each of above files or directories under testtools/geant4/tests/, if changed, must be committed and tagged with distinctive tag names and proposed for testing in the normal way so that they get included in reference tags. The rest contain binaries and output for each system, debug option and ISO option, e.g., SUN-CC/debug_NONISO/, which themselves contain the directories for binaries - bin/, lib/ and tmp/ - for the current tests and stt/, a symbolic link to the current test output, e.g., stt -> stt.geant4-01-01-cand-00. The latter are kept, the directories for binaries are re-used.
| g4status.sh | Prints the status of currently running rsh-submitted jobs. |
| g4allsys.sh | Reads stt-hosts...data files, submits g4sbr.sh via rsh one per line. |
| g4sbr.sh | Submit, build and run. Uses limit.sh and tmpenv.sh |
| build.sh | Builds libraries and/or test and examples excutables. |
| run.sh | Runs tests and examples. |
| limit.sh | Sets limits for some platforms. |
| tmpenv.sh | Sets TMPDIR for some platforms. |
| setup.sh/csh | "Source" script to set environment based on current platform and working directory. Sources... |
| specific.sh/csh | Detailed platform specific environment setting. |
| update.sh | Reads stt...sdb files, updates directory one per line. Uses... |
| updt.sh | Basic CVS update instructions. |
Some other "useful" scripts are also there:
| streamedit.sh | Changes all occurences of given string in given file(s). |
| rename.sh | Changes names of files, replacing occurences of string in name. |
Change to testtools/geant4/tests/tools/bin, set G4DEBUG and/or G4STTNONISO if required, and source setup.csh. Prepare an update driver file, say bonsaiXXX.sdb, from the Bonsai database (by Hasami.plx). Update the code, e.g., update.sh [-n] <bonsaiXXX.sdb >&bonsaiXXX.log &.(csh) or update.sh [-n] <bonsaiXXX.sdb >bonsaiXXX.log 2>&1 & (sh). Check the log file for unexpected CVS flags C, M, or ?. Prepare a file, say hostsXXX.data (by Hasami.plx), for piping into g4allsys.sh and run it, e.g., g4allsys.sh <hostsXXX.data. Check with g4status.sh. Check log files, e.g., sungeant.<area>.deb_NONISO.log for errors.
We are using Tinderbox to check gmake.log and output/diff files: http://pcitapiww/tinderbox/tinderbox/html/
If all's well, update the Bonsai database and mark the tag(s) "Accepted" or "Rejected". Notify the category coordinator.
After a few tags have built up, or for the monthly reference tag, consider placing a global (geant4-wide) reference tag on the geant4 source tree - see below.
This option runs jobs in the following cases: (a) if a test or example has a file ending in large_N.in, in which case this file is taken instead of the normal .in file, or (b) if a job's input is generated by an "hadronic exerciser", in which case the exerciser is run with the large N option.
Announce on the Tags Blackboard and invite category coordinators to add further information.