International Planning Competition 2018
Probabilistic Tracks

Tracks

The competition is run in the tracks discrete MDP, continuous MDP and discrete SSP. These tracks focus on the maximization of the expected reward in a discrete or continuous environment (discrete and continuous MDP tracks) or on the minimization of the expected cost to reach a goal (discrete SSP track).

Additionally, there are the novel discrete data-based MDP and continuous data-based MDP tracks, which are versions of the discrete and continuous MDP tracks where a set of sample traces is provided as input rather than a declarative model of the MDP.

Updates: The data-based tracks as well as the discrete SSP track have been cancelled due to a lack of participants. The continuous MDP track has been postponed to 2019. Please contact Scott Sanner if you wish to stay up-to-date.

Discrete MDP Track

• Organizer: Thomas Keller (University of Basel)
• Model:
  • Markov decision process (MDP)
  • fixed initial state
  • finite horizon
  • no discounting of rewards (the discount factor is 1)
  • binary variables (enum-valued variables are optional, a compilation is provided)
  • discrete transitions
  • conditional (state-dependent) rewards
  • action preconditions
  • no dead-ends (there is an applicable action in every reachable state)
• Resources:
  • memory limit of 4.5Gb
  • time limit depends on the instance
    As a rule of thumb, we provide 75*2.5*H seconds for each instance (exceptions are possible), where H is the finite horizon. As a result of a discussion among the participants and organizers, we decided to increase the average deliberation time significantly (this was 50*H seconds before).
• Evaluation:
  • 75 runs per instance have to be completed in time
  • We provide a minimal reference policy for each instance. As in IPC 2011 and 2014, we use the better of a random policy and a noop policy (if noop is always legal).
  • The instance score of a planner for a given instance is 0 if less than 75 runs were completed in time or if the average accumulated reward of the 75 runs of the planner is less than or equal to the average accumulated reward of the minimal reference policy , and

    

    otherwise, where is the highest average accumulate reward of all participants.
  • The total score of a planner is the sum of its instance scores (this is different from IPC 2011 and 2014) and hence ranges between 0 and the number of instances at IPC 2018. To make sure that all domains are equally important, there is an equal number of instances for each domain.
• Minimal input language requirements:
  • We use the same fragment of RDDL as in IPC 2011 and 2014 with the changes listed below.
    Please have a look at the demo domains for examples of these changes!
    • action-preconditions and state-invariants sections
      The most important addition to the fragment of RDDL that was used in the previous competitions is the action-preconditions section. At IPC 2011 and 2014, there was a state-action-constraints section that could be used to describe invariants, static preconditions and action preconditions, even though the latter was not used in any domain. As it turns out, it is problematic semantically to combine state invariants and action preconditions in one section, since the latter must be checked by the planner at runtime, whereas the former can be assumed to be true (and it is impossible to check all successor states if a state invariant is violated). We therefore decided to remove the state-action-constraints section and replace it with an action-preconditions section and a state-invariants section. The action-preconditions section contains a set of Boolean formulas, each of which must be true for an action to be applicable in some state, and the state-invariants section contains formulas that can be assume to be true in all reachable states.
    • no max-nondef-actions entry in the instance
      Related to the former bullet point, the max-nondef-actions entry of the instance block was an additional way of restricting applicable actions. Since this can be done equivalently in the action-preconditions section, the max-nondef-actions entry is omitted.
    • type hierarchy
      This is not a new concept in RDDL, but it hasn't been used at IPC 2011 and 2014.
    • KronDelta is now optional
      In an attempt to make modeling domains with RDDL easier, KronDelta is now optional. This means that, whenever a value is used in place of a probability distribution, it is assumed that, in place of the value, there is a KronDelta distribution that places all weight on that value.
    • & for logical conjunctions (instead of ^)
      For consistency with the sign for disjunctions (|), we use & rather than ^ for logical conjunctions.
    • no equals sign following the requirements keyword
      Again, this is for consistency reasons (all other RDDL keywords that specify a list do not use the equals sign either).
    • no non-fluents section
      We believe that the separation of a planning task into domain, non-fluents and instance does not have significant advantage over the separation into domain and instance. Since the latter is well-known from all other planning tracks of the IPC, we move the objects and non-fluents block from the non-fluents section to the instance section.
  • The PDDL description was removed since no participant decided to use PDDL as input language.
  • Demo domains and instances:
    • RDDL
    • PDDL domains removed.

Registration

Unlike in IPC 2011 and 2014, competitors do not run their planners themselves. This time, the competitors must submit the source code of their planners, and the organizers will run all planners on the actual competition domains/problems, unknown to the competitors until this time. This way, no fine-tuning of the planners will be possible.

All competitors must submit an abstract (max. 300 words) and a 4-page paper describing their planners. After the competition we encourage the participants to analyze the results of their planner and submit an extended version of their abstract. An important requirement for IPC 2018 competitors is to give the organizers the right to post their paper and the source code of their planners on the official IPC 2018 web site.

Registration Process

There are three important dates for the registration of planners (the deadlines are only important for the discrete tracks; information on deadlines for the continuous MDP track will follow later). This starts with an expression of interest in participation in one or more tracks, which is due February 4, 2018. Please let us know which tracks you are interested in and which input language you are planning to use by sending a mail to ipc2018-probabilistic-organizers@googlegroups.com.

We will use the container technology "Singularity" this year to promote reproducibility and help with compilation issues that have caused problems in the past.

The second step is to register your planner until April 5, 2018. To do so, send an email to ipc2018-probabilistic-organizers@googlegroups.com and let us know if you wish to use a mercurial or a git repository and provide us your bitbucket user names. We will then set up your repository on bitbucket, give you write access and let you know that you can submit your code to the repository. To do so, create one branch per track you want to participate in and name it according to the following list:

• ipc2018-disc-mdp (discrete MDP track)
• ipc2018-disc-ssp (discrete SSP track, canceled)
• ipc2018-cont-mdp (continuous MDP track, postponed to 2019)

We will build all planners once a day and run them on a number of test cases. You can see the results for your planner on the build status page. Test your Singularity file locally (see below) and make sure it passes our automated tests. Please note that the test runs are shorter than the actual competition runs (only 10 iterations instead of 75, and tighter time constraints). The quality of your planner's results is not important at this point, so don't worry if the time limit seems unreasonably small.

A planner is officially registered in a track if it has a green box for that track on the build status page on April 5. You can still make any code changes you want until the final submission deadline on May 3. The build status on the website will update (once a day) when you push new changes the registered branches.

On the final submission deadline on May 3, 2018, we will change your access rights to the repository (or repositories) from write access to read access. If you find any bugs in your code afterwards, you can still fork the repository, fix the bug in the fork and create a pull request for the ipc2018-probabilistic-bot. If we detect any bugs while running your code, we'll let you know and you are also allowed to provide a bug fix. However, only bug fixes will be accepted after the deadline (in particular, we will not accept patches modifying behavior or tuning parameters).

Details on Singularity

In an effort to increase reproducibility and reduce the effort of running future IPCs, we are using software containers that contain the submitted planner and everything required to run it. We are using Singularity which is an alternative to the well-known Docker. Singularity (in contrast to Docker) is specifically designed for scientific experiments on HPC clusters and has low overhead.

Singularity containers can be viewed as light-weight alternatives to virtual machines that carry a program and all parts of the OS that are necessary to run it. They can be based on any docker image. We created an example submission (Singularity file) that uses the latest Ubuntu as a basis and uses apt-get to install required packages for Prost. It then builds the planner from the files that are next to the Singularity file in the repository.

In the following, we collect and answer frequently asked questions about Singularity. We'll update this section as we get more questions. If you run into problems using Singularity and your problem is not answered here, let us know.

sudo apt install automake libtool
git clone https://github.com/singularityware/singularity.git
cd singularity
git checkout vault/release-2.4
./autogen.sh
./configure --prefix=/usr/local
make
sudo make install

git clone https://bitbucket.org/ipc2018-probabilistic/demo-submission --branch ipc2018-disc-mdp
sudo singularity build planner.img demo-submission/Singularity
mkdir rundir
RUNDIR="$(pwd)/rundir"
singularity run -C -H $RUNDIR planner.img recon_demo_inst_mdp__1 2323

/tmp

/tmp