Participation

This page contains explanations of how to submit the solvers as well as formal requirements to participate in the competition. Please pay close attention to the notes on this page and on the rules page: we require that those comments are strictly followed.

We welcome submissions of genuinely novel ideas as well as new approaches building (techniques of) existing implementations. In any case, the participants are required to (i) list all used solvers or implementations in the system description, and (ii) ensure that they hold the required rights to do so. This applies in particular, but not only, to solvers employing machine-learning based algorithm selection (portfolio solvers). Finally, each solver must only be submitted in one configuration.

Submission Procedure

We ask participants to submit a Declaration of Intent to submit a solver until January 15th 2017 to iccma17@dbai.tuwien.ac.at. We expect this mail to include

• Names and affiliations of each team member.
• Name of the solver.
• List of tasks the solver supports (see Rules)

The solver submission deadline is March 15th 2017. Your submission is in time as long as there is some time zone in which it is still March 15th. In other words, the deadline is 11:59 PM UTC-12. The deadline is strict. The actual solver has to be submitted to iccma17@dbai.tuwien.ac.at. Please consider the following guidelines:

• Your mail should contain the solver either as an attachment, or provide a download link.
• Your email should contain the list of libraries/compilers/external software needed for compiling and running your system. In particular, please specify unusual requirements or, for instance, if a particular version of a given software is needed.
• The solver must be submitted as a zip, tar.gz or tar.bz2 archive.
• The archive must include the full source code of your solver, to be published on this web site after the competition.
• The archive must extract to a directory that has exactly the same name as the submitted solver.
• Solver directories should not contain any unnecessary files (editor backup files, .CVS or .svn directories, .DS_Store files, object files, bytecode, ...), but README files that may help with trouble-shooting the solver are appreciated.

In addition to the executable solvers, we require each participant to submit a system description of the solver. The submission deadline for the system description is April 15th 2017. The following information has to be provided within the system description:

• Abstract: no more than 200 words.
• Description: It should contain the details of the system, including the system architecture, which features or functions the system provides, what design choices were made and what lessons were learned. Moreover, any other (third-party) systems used must be listed.
• Papers must be submitted in PDF format, following the style of the Springer's Lecture Notes in Computer Science (LNCS) series, with 2-4 pages in length, including references.
• Paper must be sent to iccma17@dbai.tuwien.ac.at.

Web Access: The solver should be either accessible via the web or downloadable. A short set of instructions on how to use the application should be provided as well.

Solver Requirements

Submitted solvers must provide a command line interface following the requirements described here. Also the input- and output-format used in the competition is described there.

A generic shell script to be adapted to the concrete solver can be found here. The generic shell script for Dung's Triathlon is available here.

Compiling and running your solver:

• Each solver directory should contain a shell script, named build (note the letter case), which completely builds your solver. Be sure that your build script is executable. You may assume that build is run from the directory in which it resides. In the common case that you want to use the make tool to build your solver, your build script should look like this: make
• Each solver directory must have an executable (either a script or a statically compiled binary file), that provides a command line interface according to the solver requirements.
• You can test your solver with the following sets of example graphs in TGF and APX format:
  First example benchmark set (solutions included)
• You may assume that the solver is run from the directory it resides. UPDATE: The solver will be accessed from outside its directory. Please make sure that it can access all needed resources, for example by adding the following line to the beginning of the shell script:
  cd $(dirname $0)
• We will run the script in an environment that limits memory usage to 4 GB (this value may be changed depending on requirements).
• Solutions returned after 10 minutes of CPU time used by the solver (resp. 30 minutes for Dung's Triathlon) will be ignored and treated as timeout.
• Your solver may write whatever it wants to the stderr stream. Diagnostic output to this stream will be logged, and we encourage you to produce any output that may help in troubleshooting the solver. Stdout stream must exclusively used for providing solutions to the tasks.
• If your solver generates any temporary files, please check or remove them at the start of execution. We will not automatically remove them.
• Your solver will be built and run with limited user rights, but still please make sure that neither the build script nor the solver itself contain any operations that can wreak havoc on the computer. In particular, it must not write to any directories outside the directory it is run in (creating and using subdirectories is fine), and it must not use the network.
• If there are reasons to expect that your solver won't build on a standard Linux machine (e.g. because it uses unusual libraries), please explain any potential issues in your submission email.

Further issues:

• Randomized algorithms: If your solver uses randomized algorithms, please initialise the random seed to a fixed constant. If there are any reasons to expect that your solver won't generate reproducible results, please tell us clearly in the submission email.
• Concurrency: it is not expected that any solver spawns concurrent threads or processes. Nevertheless, if yours do so, e.g., sequentially first to preprocess / encode the AF, and then to start the search process itself, please let us know.
• Various executable files: If your solver consists of a number of executable files (most likely because it uses an ensemble of approaches which are invoked upon some criteria) make sure only one is executed simultaneously. Moreover recall that executable binary files must be compiled statically.
• Disk usage: If your solver uses external search algorithms, we will need to run it in an isolated environment, so please tell us. In that case, we will of course take time spent doing I/O into account for the time limit. Please also tell us how much hard disk space the solver should be expected to require, at maximum, during execution. The solver is only allowed to write to the directory in which it is invoked, or subdirectories thereof. (For example, don't write to /tmp.).