The second round of the competition will work with the the instances in XHSTT-ITC2011 (a subset of XHSTT-2012) and hidden instances. The hidden (real world) instances are sent in by colleagues from all over the world. We expect to collect between 10 and 15 of these instances, which are expected to be similar in complexity to the instances in XHSTT-ITC2011.
For this round of the competition constraints of the types AvoidSplitAssignmentsConstraint and LimitWorkloadConstraint are excluded.
In this round of the competition the participants have to implement a single threaded algorithm to tackle the problem; they can use any programming language. Third party software can be used if this is freely available for all, even for commercial use. This excludes the use of, for example, CPLEX, ILOG, Gurobi and SCIP. Participants may use Jeff Kingston's KHE library if they wish. It offers operations for reading and writing XHSTT files, and updating solutions with incremental cost recalculation.
The algorithm can be either deterministic or stochastic. The participants that use a stochastic algorithm should code their program in such a way that the exact run that produced each solution submitted can be repeated by specifying a random seed.
The time limit for all instances is 1000 seconds. Participants have to benchmark their machine with the program provided in order to know how much time they have available to run their program on their machines.
The algorithms should take as input a problem file in the XHSTT format, and produce as output a solution in the XHSTT format as well, all in the allowed CPU time.
The solver submitted by the participants should require as command-line arguments: input file names, output file names, the calculation time in seconds, and for stochastic solvers only, the random seed. For example (stochastic solver):
>> my_solver.exe instance1.xml solution1.xml 1000 1542955064
When submitting solutions to XHSTT-ITC2011 the same version of the algorithm must be used for all instances. That is, the algorithm should not "know" which instance it is solving - while your particular algorithm might analyse the problem instance and set parameters accordingly, it should not "recognise" the particular instance. The programmer should not set different parameters for different instances although if the program is doing this automatically then this is acceptable.
Participants should submit for each instance the best score found by their algorithm in the specified computer time. In case that the algorithm is stochastic the randseed should be specified in the metadata of the solution.
The organisers will select around 5 participants as finalists for the second part of the competition. These finalists will be asked to send in their executables. The finalists' solvers will be run by the organisers on all the hidden instances.
Finalists are expected to write a short paper describing the approach taken in sufficient detail to allow others to repeat their work, plus anything else that seems worthy of mention. See submissions for more details.
Ordering of finalists will be based on the scores on the hidden instances. These scores will be based on the evaluation by HSEval. Participants are urged to use the evaluator to validate their output files. The actual list will be based on the average ranks of solvers in 10 runs on each single hidden instance. The average is taken over the instances that are not contributed by the institute(s) of the participants. The average of these ranks will produce the final place list. More details on how the orderings will be established can be found here.