|
Size: 11007
Comment: make world-readable
|
Size: 11035
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 123: | Line 123: |
| An example of {{{run}}} script can be found [[RunModelSolve|here]]. | An example of {{{run}}} script can be found [[RunModelSolve|here]] (forthcoming). |
| Line 179: | Line 179: |
| An example of {{{run}}} script can be found [[RunSystem|here]]. | An example of {{{run}}} script can be found [[RunSystem|here]] (forthcoming). |
Participant submission procedure
Contents
Application
Teams willing to participate in the competition can register via Easychair. The registration procedure is as follows:
go to http://www.easychair.org/conferences/?conf=aspcomp2013
click New Submission
add all names, email addresses, and affiliations of the team members in the Author i entries
put the name of their team in the Title entry;
add a small description of your system to the Abstract entry;
choose the category: tick Model & Solve Track Participant Package or System Track Participant Package if you want to participate in the Model & Solve or in the System track, resp.;
- add a few keywords that describe the features of your system; and
tick Abstract Only.
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]
$ exitYour 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.
Input
A problem instance in the prescribed format is fed to run's standard input.
Command Line
run takes three arguments:
The first argument ($1, argv[1], ...) is the maximum integer which is sufficient for solving the input instance (0 if not meaningful for the problem/instance at hand). This information can be used (or not) depending on whether your underlying solver needs to know a priori this bound.
The second argument ($2, argv[2], ...) is the maximum nesting level of Skolem terms which is sufficient for solving the input instance (0 if not meaningful for the problem/instance at hand). This information can be used (or not) depending on whether your underlying solver needs to know a priori this bound, e.g. for guaranteeing termination.
The third argument ($3, argv[3], ...) is a comma-separated list of output predicate names p1,p2,.... This list will differ on a per problem basis (not per instance), and coincides with the list of output predicates which should be included in the output of the run script.
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:
The first argument ($1, argv[1], ...) is the maximum integer which is sufficient for solving the input instance (0 if not meaningful for the problem/instance at hand).
The second argument ($2, argv[2], ...) is the maximum nesting level of function symbols which is sufficient for solving the input instance (0 if not meaningful for the problem/instance at hand).
The third argument ($3, argv[3], ...) is a comma-separated list of output predicate names p1,p2,.... This list specifies which output predicates should be included in the output of the run script. Note that, for avoiding syntactic problem recognition techniques, predicate names might be masked/renamed and might not coincide with output predicate names listed in public problem specifications.
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%)