# Design and Organization

This document contains information about the:

The rules, specifications, and deadlines given here are absolute. Only the competition panel has the right to make exceptions. It is assumed that each entrant has read the web pages related to the competition, and has complied with the competition rules. Non-compliance with the rules could lead to disqualification. A "catch-all" rule is used to deal with any unforseen circumstances: No cheating is allowed. The panel is allowed to disqualify entrants due to unfairness, and to adjust the competition rules in case of misuse.

### Disclaimer

Every effort has been made to organize the competition in a fair and constructive manner. No responsibility is taken if, for one reason or the other, your system does not win.

## Changes

The design and procedures of this CASC evolved from those of previous CASCs. Important changes for this CASC are:

## Divisions

CASC is run in divisions according to problem and system characteristics. There are competition divisions in which systems are explicitly ranked, and a demonstration division in which systems demonstrate their abilities without being formally ranked. Some divisions are further divided into problem categories, which make it possible to analyze, at a more fine grained level, which systems work well for what types of problems. The problem categories have no effect on the competition rankings, which are made at only the division level.

### Competition Divisions

The competition divisions are open to ATP systems that meet the required system properties. Systems that rely essentially on running other ATP systems without adding value are deprecated; the competition panel may disallow or move such systems to the demonstration division.

Each competition division uses problems that have certain logical, language, and syntactic characteristics, so that the ATP systems that compete in the division are, in principle, able to attempt all the problems in the division.

• The FOF division: First-Order Form non-propositional theorems (axioms with a provable conjecture).
The FOF division has two problem categories:
• The FNE category: FOF with no Equality
• The FEQ category: FOF with Equality

• The FNT division: First-order form non-propositional Non-Theorems (axioms with a counter-satisfiable conjecture, and satisfiable axiom sets).
The FNT division has two problem categories:
• The FNN category: FNT with no Equality
• The FNQ category: FNT with Equality

• The CNF division: Clause Normal Form really non-propositional theorems (unsatisfiable clause sets), but not unit equality problems (see the UEQ division below). Really non-propositional means with an infinite Herbrand universe.
The CNF division has five problem categories:
• The HNE category: Horn with No Equality
• The HEQ category: Horn with some (but not pure) Equality
• The NNE category: Non-Horn with No Equality
• The NEQ category: Non-Horn with some (but not pure) Equality
• The PEQ category: Pure Equality

• The SAT division: Clause normal form really non-propositional non-theorems (SATisfiable clause sets).
The SAT division has two problem categories:
• The SNE category: SAT with No Equality
• The SEQ category: SAT with Equality

• The EPR division: Effectively PRopositional clause normal form theorems and non-theorems (clause sets).
Effectively propositional means non-propositional with a finite Herbrand Universe. The EPR division has two problem categories:
• The EPT category: Effectively Propositional Theorems (unsatisfiable clause sets)
• The EPS category: Effectively Propositional non-theorems (Satisfiable clause sets)

• The UEQ division: Unit EQuality clause normal form really non-propositional theorems (unsatisfiable clause sets).

• The LTB division: First-order form non-propositional theorems (axioms with a provable conjecture) from Large Theories, presented in Batches. The LTB division has three problem categories:
• The CYC category: Problems taken from the Cyc contribution to the CSR domain of the TPTP. These are problems CSR025 to CSR074.
• The MZR category: Problems taken from the Mizar Problems for Theorem Proving (MPTP) contribution to the TPTP. These are problems ALG214 to ALG234, CAT021 to CAT037, GRP618 to GRP653, LAT282 to LAT380, SEU406 to SEU451, and TOP023 to TOP048.
• The SMO category: Problems taken from the Suggested Upper Merged Ontology (SUMO) contribution to the CSR domain of the TPTP. These are problems CSR075 to CSR109.
Note: New and bugfixed versions of these problems are eligible for CASC.
The problems section explains what problems are eligible for use in each division and category. The system evaluation section explains how the systems are ranked in each division.

### Demonstration Division

ATP systems that cannot run in the competition divisions for any reason can be entered into the demonstration division. Demonstration division systems can run on the competition computers, or the computers can be supplied by the entrant. Computers supplied by the entrant may be brought to CASC, or may be accessed via the internet.

The entry specifies which competition divisions' problems are to be used. In addition to the competition divisions, for CASC-22 there is an additional demonstration division:

• The THF division: Typed Higher-order Form non-propositional theorems (axioms with a provable conjecture), using only the THF0 syntax.
The THF division has two problem categories:
• The TNE category: THF with no Equality
• The TEQ category: THF with Equality
The demonstration division results are presented along with the competition divisions' results, but may not be comparable with those results. The systems are not ranked and no prizes are awarded.

## Infrastructure

### Computers

The competition computers are Dual-Opteron computers, each having:
• AMD Opteron(tm) Processor 250, 2390MHz CPU
• 4GB RAM
• Linux 2.6.27.10.1.amd64-smp operating system

### Problems

Problem Selection
The problems are from the TPTP Problem Library. The TPTP version used for the competition is not released until after the system delivery deadline, so that new problems have not been seen by the entrants.

The problems have to meet certain criteria to be eligible for selection:

• The TPTP uses system performance data to compute problem difficulty ratings, and from the ratings classifies problems as one of:
• Easy: Solvable by all state-of-the-art ATP systems
• Difficult: Solvable by some state-of-the-art ATP systems
• Unsolved: Not yet solved by any ATP system
• Open: Theorem-hood unknown
Difficult problems with a rating in the range 0.21 to 0.99 are eligible. Problems of lesser and greater difficulty ratings might also be eligible in some divisions (especially the LTB division, because the TPTP problem ratings are computed from sequential mode results). Performance data from systems submitted by the system submission deadline is used for computing the problem ratings for the TPTP version used for the competition.
• The TPTP distinguishes versions of problems as one of standard, incomplete, augmented, especial, or biased. All except biased problems are eligible.
• In the LTB division, the problems are selected so that there is consistent symbol usage between problems in each category, but there may not be consistent axiom naming between problems.
The problems used are randomly selected from the eligible problems at the start of the competition, based on a seed supplied by the competition panel.
• The selection is constrained so that no division or category contains an excessive number of very similar problems.
• The selection mechanism is biased to select problems that are new in the TPTP version used, until 50% of the problems in each category have been selected, after which random selection (from old and new problems) continues. The actual percentage of new problems used depends on how many new problems are eligible and the limitation on very similar problems.

Number of Problems
The minimal numbers of problems that have to be used in each division and category, to ensure sufficient confidence in the competition results, are determined from the numbers of eligible problems in each division and category (the competition organizers have to ensure that there is sufficient CPU time available to run the ATP systems on this minimal number of problems). The minimal numbers of problems are used in determining the CPU time limit imposed on each solution attempt.

A lower bound on the total number of problems to be used is determined from the number of computers available, the time allocated to the competition, the number of ATP systems to be run on the competition computers over all the divisions, and the CPU time limit, according to the following relationship:

```                   NumberOfComputers * TimeAllocated
NumberOfProblems = ---------------------------------
NumberOfATPSystems * CPUTimeLimit
```
It is a lower bound on the total number of problems because it assumes that every system uses all of the CPU time limit for each problem. Since some solution attempts succeed before the CPU time limit is reached, more problems can be used.

The numbers of problems used in each division and problem category is (roughly) proportional to the numbers of eligible problems, after taking into account the limitation on very similar problems.

The numbers of problems used in each division and category are determined according to the judgement of the competition organizers.

In order to prevent systems from recognizing problems from their file names, symbolic links are made to the selected problems, using names of the form CCCNNN.p for the symbolic links, where CCC is the division or category name, and with NNN running from 001 to the number of problems in the respective division or category. The problems are specified to the ATP systems using the symbolic link names.

In the demonstration division the same problems are used as for the competition divisions, with the same preprocessing applied. However, the original file names can be retained for systems running on computers provided by the entrant.

In the LTB division, the problems for each category are listed in a batch specification file, containing:

• A header line % SZS start BatchIncludes
• include directives that are used in every problem. Problems in the batch have all these include directives, and can also have other include directives that are not listed here.
• A terminator line % SZS end BatchIncludes
• A header line % SZS start BatchProblems
• Pairs of absolute problem file names, and absolute output file names where the output for the problem must be written.
• A terminator line % SZS end BatchProblems
LTBSampleInput1 and LTBSampleInput2 are examples.

### Resource Limits

CPU and wall clock time limits are imposed. A minimal CPU time limit of 240 seconds per problem is used. The maximal CPU time limit per problem is determined using the relationship used for determining the number of problems, with the minimal number of problems as the NumberOfProblems. The CPU time limit is chosen as a reasonable value within the range allowed, and is announced at the competition. The wall clock time limit is imposed in addition to the CPU time limit, to limit very high memory usage that causes swapping. The wall clock time limit per problem is double the CPU time limit. In the non-LTB competition divisions the time limits are imposed individually on each solution attempt. In the LTB division the aggregated time limits (the individual problem time limit multiplied by the number of problems) are imposed on each category.

In the demonstration division, each entrant can choose to use either a CPU or a wall clock time limit, whose value is the CPU time limit of the competition divisions.

## System Evaluation

For each ATP system, for each problem, three items of data are recorded: whether or not a solution was found, the CPU time taken, and whether or not a solution (proof or model) was output. The systems are ranked at the division level from this performance data. All the divisions have an assurance ranking class, ranked according to the number of problems solved (a "yes" output, giving an assurance of the existence of a proof/model). The FOF, FNT, and LTB divisions additionally have a proof/model ranking class, ranked according to the number of problems solved with an acceptable proof/model output. Ties are broken according to the average CPU time over problems solved (in the LTB division, time spent before starting the first problem, and time spent between ending a problem and starting the next, is not considered for this measure). All systems are automatically ranked in the assurance classes, and are ranked in the proof/model classes if they output acceptable proofs/models. A system that wins a proof/model ranking class might also win the corresponding assurance ranking class. In the competition divisions, class winners are announced and prizes are awarded.
• Articulate Software has provided \$3000 of prize money for the SMO category of the LTB division. In each ranking class the winner will receive \$750, the second place \$500, and the third place \$250. (Employees of Articulate Sofware, its subcontractors, and funded partners, are not eligible for this prize money.)
• Cycorp has provided €200 of prize money for the CYC category of the LTB division. There are two prizes, one for completeness (most problems solved) and one for efficiency (using the CASC efficiency measure described below, with the added proviso that the winner must solve at least half the number of problems solved by the winner of the completeness prize). Details are available online.

The competition panel decides whether or not the systems' proofs and models are acceptable for the proof/model ranking classes. The criteria include:

• Derivations must be complete, starting at formulae from the problem, and ending at the conjecture (for axiomatic proofs) or a false formula (for proofs by contradiction, including CNF refutations).
• For proofs of FOF problems by CNF refutation, the conversion from FOF to CNF must be adequately documented.
• Derivations must show only relevant inference steps.
• Inference steps must document the parent formulae, the inference rule used, and the inferred formula.
• Inference steps must be reasonably fine-grained.
• In the LTB division the proofs must be in TPTP format.
• An unsatisfiable set of ground instances of clauses is acceptable for establishing the unsatisfiability of a set of clauses.
• Models must be complete, documenting the domain, function maps, and predicate maps. The domain, function maps, and predicate maps may be specified by explicit ground lists (of mappings), or by any clear, terminating algorithm.
In the assurance ranking classes the ATP systems are not required to output solutions (proofs or models). However, systems that do output solutions are highlighted in the presentation of results.

In addition to the ranking criteria, two other measures are made and presented in the results: The state-of-the-art contribution (SOTAC) quantifies the unique abilities of the systems. For each problem solved by a system, its SOTAC for the problem is the inverse of the number of systems that solved the problem, and a system's overall SOTAC is the average SOTAC over the problems it solves. The efficiency measure balances the number of problems solved with the CPU time taken. It is the fraction of problems solved divided by the average CPU time for problems solved. This can be interpreted intuitively as the solution rate (for problems solved) multiplied by the fraction of problems solved.

At some time after the competition, all high ranking systems in the competition divisions are tested over the entire TPTP. This provides a final check for soundness (see the section on system properties regarding soundness checking before the competition). If a system is found to be unsound during or after the competition, but before the competition report is published, and it cannot be shown that the unsoundness did not manifest itself in the competition, then the system is retrospectively disqualified. At some time after the competition, the proofs and models from the winners of the proof/model ranking classes are checked by the panel. If any of the proofs or models are unacceptable, i.e., they are significantly worse than the samples provided, then that system is retrospectively disqualified. All disqualifications are explained in the competition report.

## System Entry

To be entered into CASC, systems have to be registered using the CASC system registration form. No registrations are accepted after the registration deadline. For each system entered, an entrant has to be nominated to handle all issues (including execution difficulties) arising before and during the competition. The nominated entrant must formally register for CASC. However, it is not necessary for entrants to physically attend the competition.

Systems can be entered at only the division level, and can be entered into more than one division (a system that is not entered into a competition division is assumed to perform worse than the entered systems, for that type of problem - wimping out is not an option). Entering many similar versions of the same system is deprecated, and entrants may be required to limit the number of system versions that they enter. The division winners of the previous CASC are automatically entered into their divisions, to provide benchmarks against which progress can be judged.

### System Description

A system description has to be provided for each ATP system entered, using this HTML schema. The schema has the following sections:
• Architecture. This section introduces the ATP system, and describes the calculus and inference rules used.
• Strategies. This section describes the search strategies used, why they are effective, and how they are selected for given problems. Any strategy tuning that is based on specific problems' characteristics must be clearly described (and justified in light of the tuning restrictions).
• Implementation. This section describes the implementation of the ATP system, including the programming language used, important internal data structures, and any special code libraries used. The availability of system is described here.
• Expected competition performance. This section makes some predictions about the performance of the ATP system in each of the divisions and categories in which it is competing.
• References.

The system description has to be emailed to the competition organizers by the system description deadline. The system descriptions, along with information regarding the competition design and procedures, form the proceedings for the competition.

### Sample Solutions

For systems in the proof/model classes, representative sample solutions must be emailed to the competition organizers before the sample solutions deadline. Use of the TPTP format for proofs and finite interpretations is encouraged. Proof samples for the FOF and LTB proof classes must include a proof for SYN075+1. Model samples for the FNT model class must include models for MGT019+2 and SWV010+1. The sample solutions must illustrate the use of all inference rules. An explanation must be provided for any non-obvious features.

## System Requirements

### System Properties

Systems are required to have the following properties:
1. Systems have to run on a single locally provided standard UNIX computer (the competition computers). ATP systems that cannot run on the competition computers can be entered into the demonstration division.
2. Systems must be fully automatic, i.e., any command line switches have to be the same for all problems in each division.
3. Systems must be sound. At some time before the competition all the systems in the competition divisions are tested for soundness. Non-theorems are submitted to the systems in the FOF, CNF, EPR, UEQ, and LTB divisions, and theorems are submitted to the systems in the FNT, SAT and EPR divisions. Finding a proof of a non-theorem or a disproof of a theorem indicates unsoundness. If a system fails the soundness testing it must be repaired by the unsoundness repair deadline or be withdrawn. The soundness testing eliminates the possibility of a system simply delaying for some amount of time and then claiming to have found a solution. For systems running on computers supplied by the entrant in the demonstration division, the entrant must perform the soundness testing and report the results to the competition organizers.
4. Systems do not have to be complete in any sense, including calculus, search control, implementation, or resource requirements.
5. Systems must be executable by a single command line, using an absolute path name for the executable, which might not be in the current directory. In the non-LTB divisions the command line arguments are the absolute path name of a symbolic link as the problem file name, the individual problem time limit (if required by the entrant), and entrant specified system switches. In the LTB division the command line arguments are the absolute path name of the batch specification file, the aggregated batch time limit (if required by the entrant), and entrant specified system switches. No shell features, such as input or output redirection, may be used in the command line. No assumptions may be made about the format of the problem file name.
6. The systems that run on the competition computers have to be interruptable by a SIGXCPU signal, so that the CPU time limit can be imposed, and interruptable by a SIGALRM signal, so that the wall clock time limit can be imposed. For systems that create multiple processes, the signal is sent first to the process at the top of the hierarchy, then one second later to all processes in the hierarchy. The default action on receiving these signals is to exit (thus complying with the time limit, as required), but systems may catch the signals and exit of their own accord. If a system runs past a time limit this is noticed in the timing data, and the system is considered to have not solved that problem.
7. In the non-LTB divisions all solution output must be to stdout. In the LTB division all solution output must be to the named output file for each problem.
8. For each problem, the systems have to output a distinguished string (specified by the entrant), indicating what solution has been found or that no conclusion has been reached. The distinguished strings the problem status should use the SZS ontology and standards. For example
`% SZS status Theorem for SYN075+1`
or
`% SZS status GaveUp for SYN075+1`
Regardless of whether the SZS status values are used, the distinguished strings must be different for:
• Proved theorems of FOF problems (SZS status Theorem)
• Disproved conjectures of FNT problems (SZS status CounterSatisfiable)
• Unsatisfiable sets of formulae (FOF problems without conjectures) and unsatisfiable set of clauses (CNF problems) (SZS status Unsatisfiable)
• Satisfiable sets of formulae (FNT problems without conjectures) and satisfiable set of clauses (SAT problems) (SZS status Satisfiable)
The first distinguished string output is accepted as the system's result.
9. When outputing proofs/models, the start and end of the proof/model must be delimited by distinguished strings (specified by the entrant). The distinguished strings should use the SZS ontology and standards. For example
```% SZS output start CNFRefutation for SYN075+1
...
% SZS output end CNFRefutation for SYN075+1```
Regardless of whether the SZS output forms are used, the distinguished strings must be different for:
• Proofs (SZS output forms Proof, Refutation, CNFRefutation)
• Models (SZS output forms Model, FiniteModel, InfiniteModel, Saturation)
The string specifying the problem status must be output before the start of a proof/model. Use of the TPTP format for proofs and finite interpretations is encouraged.
10. In the LTB division the systems must attempt the problems in the order given in the batch specification file. Systems may not start any attempt on a problem, including reading the problem file, before ending the attempt on the preceding problem. The systems must print SZS notification lines to stdout when starting and ending all work on the problem (including any cleanup work for the problem, such as deleting temporary files). It is recommended that the result for the problem be output as the last thing before the ending notification line (note, the result must also be output to the solution file anyway). For example
```% SZS status Started for /home/graph/tptp/TPTP/Problems/CSR/CSR075+2.p
... (system churns away, solution output to file)
% SZS status Theorem for /home/graph/tptp/TPTP/Problems/CSR/CSR075+2.p
% SZS status Ended for /home/graph/tptp/TPTP/Problems/CSR/CSR075+2.p```
Once the Ended notification is received the output file is time stamped and may not be changed. Systems may spend any amount of time before starting the first problem (e.g., preloading and analysing the batch axioms), and any amount of time between ending a problem and starting the next (e.g., learning from the proof just found). This time is not part of the time used for any problem, but is part of the overall time for the batch.
11. If an ATP system terminates of its own accord, it may not leave any temporary or intermediate output files. If an ATP system is terminated by a SIGXCPU or SIGALRM, it may not leave any temporary or intermediate output files anywhere other than in /tmp. Multiple copies of the ATP systems have to be executable concurrently on different computers but in the same (NFS cross mounted) directory. It is therefore necessary to avoid producing temporary files that do not have unique names, with respect to the computers and other processes. An adequate solution is a file name including the host computer name and the process id.
12. For practical reasons excessive output from an ATP system is not allowed. A limit, dependent on the disk space available, is imposed on the amount of output that can be produced. The limit is at least 10MB per system.
13. All techniques used must be general purpose, and expected to extend usefully to new unseen problems. The precomputation and storage of information about individual TPTP problems and axiom sets is not allowed. Strategies and strategy selection based on individual TPTP problems are not allowed. If automatic strategy learning procedures are used, the learning must ensure that sufficient generalization is obtained so that no there is no specialization to individual problems. In the LTB division, prelearning of generally useful strategies that extend usefully to new unseen problems, based on the problems specified for each category, is acceptable.
14. The system's performance must be reproducible by running the system again.
Entrants must ensure that their systems execute in a competition-like environment, according to the system checks. Entrants are advised to perform these checks well in advance of the system delivery deadline. This gives the competition organizers time to help resolve any difficulties encountered. Entrants do not have access to the competition computers.

### System Delivery

For systems running on the competition computers, entrants must email an installation package to the competition organizers by the system delivery deadline. The installation package must be a .tgz file containing the system source code, any other files required for installation, and a ReadMe file. The ReadMe file must contain:
• Instructions for installation
• Instructions for executing the system, using %s and %d to indicate where the problem file name and CPU time limit must appear in the command line.
• The distinguished strings indicating what solution has been found, and delimiting proofs/models.

The installation procedure may require changing path variables, invoking make or something similar, etc., but nothing unreasonably complicated. All system binaries must be created in the installation process; they cannot be delivered as part of the installation package. If the ATP system requires any special software, libraries, etc, which is not part of a standard installation, the competition organizers must be told in the system registration. The system is installed onto the competition computers by the competition organizers, following the instructions in the ReadMe file. Installation failures before the system delivery deadline are passed back to the entrant (i.e., delivery of the installation package before the system delivery deadline provides an opportunity to fix things if the installation fails!). After the system delivery deadline no further changes or late systems are accepted. If you are in doubt about your installation package or procedure, please email the competition organizers.

For systems running on entrant supplied computers in the demonstration division, entrants must deliver a source code package to the competition organizers by the start of the competition. The source code package must be a .tgz file containing the system source code.

After the competition all competition division systems' source code is made publically available on the CASC web site. In the demonstration division, the entrant specifies whether or not the source code is placed on the CASC web site. An open source license is encouraged.

### System Execution

Execution of the ATP systems on the competition computers is controlled by a perl script, provided by the competition organizers. The jobs are queued onto the computers so that each computer is running one job at a time. In the non-LTB divisions, all attempts at the Nth problems in all the divisions and categories are started before any attempts at the (N+1)th problems. In the LTB division all attempts in each category in the division are started before any attempts at the next category.

During the competition a perl script parses the systems' outputs. If any of an ATP system's distinguished strings are found then the CPU time used to that point is noted. A system has solved a problem iff it outputs its termination string within the CPU time limit, and a system has produced a proof/model iff it outputs its end-of-proof/model string within the CPU time limit. The result and timing data is used to generate an HTML file, and a web browser is used to display the results.

The execution of the demonstration division systems is supervised by their entrants.

### System Checks

• Check: The ATP system can run on a computer that has the same configuration as the competition computers.

• Check: The ATP system can be run by an absolute path name for the executable.
```prompt> pwd
/home/tptp
prompt> which MyATPSystem
/home/tptp/bin/MyATPSystem
prompt> /home/tptp/bin/MyATPSystem /home/tptp/TPTP/Problems/SYN/SYN075-1.p
SZS status Unsatisfiable for SYN075-1
```
• Check: The ATP system accepts an absolute path name of a symbolic link as the problem file name.
```prompt> cd /home/tptp/tmp
prompt> ln -s /home/tptp/TPTP/Problems/SYN/SYN075-1.p CCC001.p
prompt> cd /home/tptp
prompt> /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p
SZS status Unsatisfiable for CCC001
```
• Check: The ATP system makes no assumptions about the format of the problem file name.
```prompt> ln -s /home/tptp/TPTP/Problems/SYN/SYN075-1.p _foo-Blah
prompt> /home/tptp/bin/MyATPSystem _foo-Blah
SZS status Unsatisfiable for _foo-Blah
```
• Check: The ATP system can run under the TreeLimitedRun program.
```prompt> which TreeLimitedRun
/home/tptp/bin/TreeLimitedRun
prompt> /home/tptp/bin/TreeLimitedRun -q0 200 400 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 200s
TreeLimitedRun: WC  time limit is 400s
TreeLimitedRun: PID is 4867
TreeLimitedRun: ----------------------------------------------------------
SZS status Unsatisfiable for CCC001
FINAL WATCH: 147.8 CPU 150.0 WC
```
• Check: The ATP system's CPU time can be limited using the TreeLimitedRun program.
```prompt> /home/tptp/bin/TreeLimitedRun -q0 10 20 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 10s
TreeLimitedRun: WC  time limit is 20s
TreeLimitedRun: PID is 5827
TreeLimitedRun: ----------------------------------------------------------
CPU time limit exceeded
FINAL WATCH: 10.7 CPU 13.1 WC
```
• Check: The ATP system's wall clock time can be limited using the TreeLimitedRun program.
```prompt> /home/tptp/bin/TreeLimitedRun -q0 20 10 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 20s
TreeLimitedRun: WC  time limit is 10s
TreeLimitedRun: PID is 5827
TreeLimitedRun: ----------------------------------------------------------
Alarm clock
FINAL WATCH: 9.7 CPU 10.1 WC
```
• Check: The system outputs a distinguished string when terminating of its own accord.
```prompt> /home/tptp/bin/TreeLimitedRun -q0 200 400 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 200s
TreeLimitedRun: WC  time limit is 400s
TreeLimitedRun: PID is 5827
TreeLimitedRun: ----------------------------------------------------------
SZS status Unsatisfiable for CCC001
FINAL WATCH: 147.8 CPU 150.0 WC
```
Similar checks should be made for the cases where the system gives up.

• Check: The system outputs distinguished strings at the start and end of its solution.
```prompt> /home/tptp/bin/TreeLimitedRun -q0 200 400 /home/tptp/bin/MyATPSystem -output_proof /home/tptp/tmp/CCC001.p
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 200s
TreeLimitedRun: WC  time limit is 400s
TreeLimitedRun: PID is 5827
TreeLimitedRun: ----------------------------------------------------------
SZS status Unsatisfiable for CCC001
SZS output start CNFRefutation for CCC001
... acceptable proof/model here ...
SZS output end CNFRefutation for CCC001
FINAL WATCH: 147.8 CPU 150.0 WC
```
• Check: No temporary or intermediate files are left if the system terminates of its own accord, and no temporary or intermediate files are left anywhere other than in /tmp if the system is terminated by a SIGXCPU or SIGALRM. Check in the current directory, the ATP system's directory, the directory where the problem's symbolic link is located, and the directory where the actual problem file is located.
```prompt> pwd
/home/tptp
prompt> /home/tptp/bin/TreeLimitedRun -q0 200 400 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 200s
TreeLimitedRun: WC  time limit is 400s
TreeLimitedRun: PID is 13526
TreeLimitedRun: ----------------------------------------------------------
SZS status Unsatisfiable for CCC001
FINAL WATCH: 147.8 CPU 150.0 WC
prompt> ls /home/tptp
... no temporary or intermediate files left here ...
prompt> ls /home/tptp/bin
... no temporary or intermediate files left here ...
prompt> ls /home/tptp/tmp
... no temporary or intermediate files left here ...
prompt> ls /home/tptp/TPTP/Problems/GRP
... no temporary or intermediate files left here ...
prompt> ls /tmp
... no temporary or intermediate files left here by decent systems ...
```
• Check: Multiple concurrent executions do not clash.
```prompt> (/home/tptp/bin/TreeLimitedRun -q0 200 400 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p) & (/home/tptp/bin/TreeLimitedRun -q0 200 400 /home/tptp/bin/MyATPSystem /home/tptp/tmp/CCC001.p)
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 200s
TreeLimitedRun: WC  time limit is 400s
TreeLimitedRun: PID is 5827
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: ----------------------------------------------------------
TreeLimitedRun: /home/tptp/bin/MyATPSystem
TreeLimitedRun: CPU time limit is 200s
TreeLimitedRun: WC  time limit is 400s
TreeLimitedRun: PID is 5829
TreeLimitedRun: ----------------------------------------------------------
SZS status Unsatisfiable for CCC001
FINAL WATCH: 147.8 CPU 150.0 WC

SZS status Unsatisfiable for CCC001
FINAL WATCH: 147.8 CPU 150.0 WC
```