welcome: please sign in

Revision 16 as of 2013-03-14 18:30:47

Clear message
location: ParticipantSubmission

Participant submission procedure

Application

Teams willing to participate in the competition can register via Easychair. The registration procedure is as follows:

Then click on the Submit button. We will then get in contact with you for the further procedure.

Instructions for testing and submitting systems and benchmarks

Participants are expected to submit their packages as a single ZIP file or 7z-compressed file in ZIP format.

All files in your submission package will be installed as if they were located in /usr/local. This means, the zip file containing your submission will be uncompressed to /usr/local without modification to the directory layout. E.g., if your submission package contains bin/mysolver, bin/xsb, lib/libxsb.so.2, ..., we will uncompress it to /usr/local/bin/mysolver, /usr/local/bin/xsb, /usr/local/lib/libxsb.so.2, etc.

Note that all solvers will be jailed in a dedicated chroot environment without access to the production file system. You can simulate the environment and test linked binaries etc. on a Ubuntu 12.04.1 LTS AMD64 server (Precise Pangolin) installation with the following sequence of commands:

 $ sudo mkdir /path/to/my/sandbox
 $ sudo debootstrap --arch=amd64 precise /path/to/my/sandbox http://at.archive.ubuntu.com/ubuntu/
 $ [install/copy all your tools to /path/to/my/sandbox/usr/local/{bin,lib,...}]  
 $ sudo chroot /path/to/my/sandbox
 $ [perform some tests with your solver on some instances and check that the installation works]
 $ exit

Your solver will be run as an underprivileged user different from root. After each run, the chroot environment will be cleaned up and temporary files created during the run will be wiped. Please note that we have disk/file size limitations: don't forget to pipe the grounding immediately to your solver, and avoid creating temporary files. Interprocess communication should always be done using pipes (or alternatively named pipes---cf. mkfifo---if some tool can only read/write from/to files). Input instances must be read from stdin and solutions written to stdout according to the output specification.

In case additional packages are needed, please include them in your submission packages, and assuming the above unpacking policy. Your run (see below) scripts should take care of setting PATH and other sister environment variables accordingly.

The content of the package depends on whether your team is participating to the system or model competition.

Model & Solve Competition

If your team is participating in the model competition, your ZIP package will contain a subdirectory for each benchmark that you solve: let us call one of such directories benchmark_example.

In the Model & Solve Competition, you're allowed to specify a different software solution per each benchmark problem, provided it is based at its core on a declarative programming system coupled with a declarative problem specification of your choice.

The directory layout of your ZIP file may look like this:

 .
 ├── benchmark_example1
 │   ├── bin
 │   │   ├── run
 │   │   ├── mysolver
 │   │   └── my_helper_tool
 │   ├── lib 
 │   │   ├── libmysolver.so
 │   │   ├── libmysolver.so.4
 │   │   ├── libmysolver.so.4.0.1
 .   .   .
 .   .   .
 .
 ├── benchmark_example2
 │   └── bin 
 │       ├── run
 │       └── the_bm2_solver
 ├── benchmark_example3
 │   ├── bin 
 │   │   ├── run
 .   .   .
 .   .   .
 .

In particular, benchmark_example must contain a directory bin that contains an executable file named run, which will be invoked during the competition run. This file can be a script invoking a binary executable, possibly using other scripts for pre- or post-processing included in your package. Don't forget to make your scripts and binaries executable using chmod 755.

new_2.gif A {zip file containing the folder structure needed to participate to the M&S track is available here

Input

A problem instance in the prescribed format is fed to run's standard input.

Command Line

run takes three arguments:

Of course, the three arguments can be taken into account or not by the submitted scripts at participant's will and necessity (for instance, output predicate names can be hardwired in the run script or elsewhere).

Output

The output of run must be printed to standard output, and a proper exit code must be issued, according to the format specified here.

An example of run script can be found here (forthcoming).

System Competition

If your team is participating to the System competition, your package should at least contain a folder named bin. Your package is expected to be run with the same configuration for all the benchmark domains, i.e., the package must comprise all files required for running your system on any problem encoding and any problem instance.

In the System Competition, you must specify a single fixed software bundle capable of accepting problem encodings written in the ASP-Core-2 format.

The directory bin must contain an executable file called run, which will be invoked during the Competition run.

 .
 ├── bin
 │   ├── run
 │   ├── mysolver
 │   └── my_helper_tool
 ├── lib 
 │   ├── libmysolver.so
 │   ├── libmysolver.so.4
 │   ├── libmysolver.so.4.0.1
 .   .
 .   .
 .

This file can be a script invoking a binary executable, possibly using other scripts for pre- or post-processing provided in your package. Don't forget to make your scripts and binaries executable using chmod 755.

Input

A problem instance, together with an ASP-Core-2 program, is fed to run's standard input. The problem instance concatenated with the ASP-Core-2 encoding complies with the ASP-Core-2 2.01c grammar.

Command Line

run takes three arguments:

Of course, the first two arguments can be taken into account or not by submitted scripts at participant's will and necessity (for instance, a system not having particular constraints on termination when function symbols are into play, can ignore the second argument). The third argument must be explicitly used for filtering and preparing output data such that the checker can verify your solution.

Output

The output of run must be printed to standard output, and a proper exit code must be issued, according to the format specified here.

An example of run script can be found here (forthcoming).

How to compress files using the 7z format

We strongly advise to use the 7z tool for creating a ZIP file with LZMA compression level 9 like this:

 $ cd /path/to/my/sandbox/usr/local
 $ 7z a -tzip -mx=9 -mm=lzma -mfb=64 -md=64m /tmp/mysolver.zip .

 7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,24 CPUs)
 Scanning

 Creating archive /tmp/mysolver.zip

 Compressing  bin/run
 Compressing  bin/mysolver
 Compressing  lib/libmysolver.so
 Compressing  lib/libmysolver.so.2
 Compressing  lib/libmysolver.so.2.0.1

 Everything is Ok

7z is available in Ubuntu 12.04 with the p7zip-full package.

You may also use standard zip if your package does not exceed easychair's filesize limit:

 $ cd /path/to/my/sandbox/usr/local
 $ zip -r /tmp/mysolver.zip .
   adding: lib/ (stored 0%)
   adding: lib/libmysolver.so.2.0.1 (deflated 63%)
   adding: lib/libmysolver.so.2 (deflated 63%)
   adding: lib/libmysolver.so (deflated 63%)
   adding: bin/ (stored 0%)
   adding: bin/mysolver (deflated 20%)
   adding: bin/run (deflated 76%)

Uploading the submission package

Use Easychair for uploading your submission package:

You can submit multiple times by the final deadline.