This page contains the description of the competition domains for the satisfying, optimal and multicore tracks. For each domain the characteristics of the selected problems are shown. For the sake of comparisons, we have used the same problems in the sequential multicore and in the sequential satisficing tracks. The domains used are:
Domain 
Version 
Origin 
STRIPS 
new 

actioncosts* 
ipc2008 

actioncosts 
new 

actioncosts 
new 

actioncosts 
ipc2008 

actioncosts 
ipc2008 

actioncosts 
ipc2008 

actioncosts 
ipc2008 

actioncosts 
ipc2008 

actioncosts 
ipc2008 

STRIPS 
new 

actioncosts* 
ipc2008 

STRIPS 
new 

actioncosts* 
ipc2008 
*other fluents apart from totalcost are defined
Barman
Author: Sergio Jiménez Celorrio.
In this domain there is a robot barman that manipulates drink dispensers, glasses and a shaker. The goal is to find a plan of the robot's actions that serves a desired set of drinks. In this domain deletes of actions encode relevant knowledge given that robot hands can only grasp one object at a time and given that glasses need to be empty and clean to be filled.
For the satisficing track 4 problems for each configuration have been created:
problem 
shots 
ingredients 
cocktails 
p0104 
10 
4 
8 
p0508 
11 
4 
9 
p0912 
13 
4 
10 
p1316 
14 
4 
11 
p1720 
15 
4 
11 
For the optimal track 4 problems for each configuration have been created:
problem 
shots 
ingredients 
cocktails 
p0104 
4 
3 
3 
p0508 
5 
3 
4 
p0912 
6 
3 
5 
p1316 
8 
3 
6 
p1720 
9 
3 
7 
Elevators
From the original description of this domain (click here):
The idea for this domain came up from the Miconic domain of IPC2, however the domain has been designed from scratch. The scenario is the following: There is a building with N+1 floors, numbered from 0 to N. The building can be separated in blocks of size M+1, where M divides N. Adjacent blocks have a common floor. For example, suppose N=12 and M=4, then we have 13 floors in total (ranging from 0 to 12), which form 3 blocks of 5 floors each, being 0 to 4, 4 to 8 and 8 to 12.
The building has K fast (accelerating) elevators that stop only in floors that are multiple of M/2 (so M has to be an even number). Each fast elevator has a capacity of X persons. Furthermore, within each block, there are L slow elevators, that stop at every floor of the block. Each slow elevator has a capacity of Y persons (usually Y<X).
There are costs associated with each elevator starting/stopping and moving. In particular, fast (accelerating) elevators have negligible cost of starting/stopping but have significant cost while moving. On the other hand, slow (constant speed) elevators have significant cost when starting/stopping and negligible cost while moving.
Traveling times between floors are given for any type of elevator, taking into account the constant speed of the slow elevators and the constant acceleration of the fast elevators.
There are several passengers, for which their current location (i.e. the floor they are) and their destination are given. The planning problem is to find a plan that moves the passengers to their destinations while it maximizes some criterion.
In the sequential tracks the objective function is to minimize the total cost of moving the passengers to their destinations. The total cost is increased each time an elevator starts/stops or moves.
For the satisficing track, in the 2008 competition, problems ranged from 9 floors, 4 passengers, and 4 elevators (2 fast, 2 slow) to 25 floors, 39 passengers, and 5 elevators (2 fast, 3 slow). Initial capacity of fast elevators is 3 and of slow ones is 2. The 10 first problems of IPC 2008 increased the number of passengers by one from the previous problem. The number 11, doubled the floors and made passenger = 8, while increasing in one the elevators' capacity. From it, 2 passengers were added till problem 20. From problem 21, a slow elevator was added, the capacity was increased to 6 for fast lifts and to 4 for slow ones, the number of floors was raised to 25 and the number of passengers was 12 an was increased by 3 in each problem. In IPC 2008 planners either only solved the 45 first problems or did not have trouble until the last ten.
We have reused the last 9 problems, plus problem 14 (only solved by one planner like a bunch of other ones). The remaining 10 problems start from characteristics of old problem 30 (current problem 10), adding 2 fast elevators, 1 slow and 1 passenger. The next 4 increase the number of passengers by 3. From problem 16 floors are 40, 4 fast lifts with capacity for 6 passengers, 4 slow ones for 4 passengers, and 40 passengers, increasing the number of passengers in 5 per problem.
The next table shows the problems chosen (numbers in parenthesis are floors, passengers, fast and slow elevators):
problem 
old 
best 
problem 
old 
best 
p01 
p14 
208 
p11 
(254044) 

p02 
p24 
541 
p12 
(254344) 

p03 
p26 
809 
p13 
(254644) 

p04 
p20 
429 
p14 
(254944) 

p05 
p18 
387 
p15 
(255244) 

p06 
p27 
773 
p16 
(404044) 

p07 
p25 
571 
p17 
(404544) 

p08 
p28 
724 
p18 
(405044) 

p09 
p29 
1045 
p19 
(405544) 

p10 
p30 
769 
p20 
(406044) 

For the optimal track, in the last competition, problems started with 9 floors, 3 passengers and 3 elevators (1 fast for 3 passengers, 2 slow for 2 passengers). Next problem increased by one the number of fast elevators. Problem 3 had 3 elevators again and 1 more passenger. Problem 4 increased fast elevators and so on until number 10. Most of the planners were not able to solve more than the problem number 4. Problem 11 increased floors to 13 (with the other parameters left as in problem 1), which allowed planners to solve 34 problems more. So the difficulty is in the number of passengers and not in the number of floors. Problem 21 was like problem 11 but with 4 elevators (1 fast, 3 slow), so a couple of planners were able to solve it. Capacity was not changed in any problem.
We have taken following problems:
problem 
old 
optimal 

problem 
old 
optimal 
p01 
p11 
56 

p11 
p28 
125 
p02 
p21 
48 

p12 
p06 
53 
p03 
p12 
54 

p13 
p07 
62 
p04 
p03 
55 

p14 
p08 
53 
p05 
p13 
59 

p15 
p09 
78 
p06 
p04 
40 

p16 
p15 
66 
p07 
p26 
48 

p17 
p17 
78 
p08 
p05 
55 

p18 
p18 
61 
p09 
p22 
54 

p19 
p23 
69 
p10 
p14 
63 

p20 
p24 
56 
Floortile
Author: Tomás de la Rosa.
A set of robots use different colors to paint patterns in floor tiles. The robots can move around the floor tiles in four directions (up, down, left and right). Robots paint with one color at a time, but can change their spray guns to any available color. However, robots can only paint the tile that is in front (up) and behind (down) them, and once a tile has been painted no robot can stand on it.
For the IPC set, robots need to paint a grid with black and white, where the cell color is alternated always. This particular configuration makes the domain hard because robots should only paint tiles in front of them, since painting tiles behind make the search to reach a deadend.
For the satisficing track 2 problems for each configuration have been created:
problem 
rows 
columns 
robots 
p0102 
4 
3 
2 
p0304 
5 
3 
2 
p0506 
4 
4 
2 
p0708 
5 
4 
2 
p0910 
6 
4 
2 
p1112 
5 
5 
2 
p1314 
6 
5 
3 
p1516 
6 
6 
3 
p1718 
7 
6 
3 
p1920 
7 
7 
3 
For the optimal track also 2 problems for each configuration have been created:
problem 
rows 
columns 
robots 
p0102 
3 
3 
2 
p0304 
4 
3 
2 
p0506 
5 
3 
2 
p0708 
4 
4 
2 
p0910 
5 
4 
2 
p1112 
6 
4 
2 
p1314 
5 
5 
2 
p1516 
6 
5 
3 
p1718 
7 
5 
4 
p1920 
7 
6 
3 
Nomystery
Author: Hootan Nakhost
From the original domain description:
Nomystery is a transportation domain designed to study resource constrained planning [1,2]. In this domain, a truck moves in a weighted graph; a set of packages must be transported between nodes; actions move along edges, and load/unload packages; each move consumes the edge weight in fuel. In brief, Nomystery is a straightforward problem similar to the ones contained in many IPC benchmarks. Its key feature is that it comes with a domainspecific optimal solver allowing to control the constrainedness of the resources. The generator first creates a random connected undirected graph with n nodes, and it adds k packages with random origins and destinations. The edge weights are uniformly drawn between 1 and an integer W. The optimal solver computes the minimum required amount of fuel M, and the initial fuel supply is set to [C ×M], where C ≥1 is a (float) input parameter of the generator. The parameter C denotes the ratio between the available fuel vs. the minimum amount required. The problem becomes more constrained when C approaches 1.
A ubiquitous feature of planning problems is the need to economize limited resources such as fuel or money. While heuristic search, mostly based on relaxation heuristics, is currently the superior method for most varieties of planning, its ability to solve critically resourceconstrained problems is limited: relaxation heuristics basically ignore the resource consumption by actions. Nomystery generator is a nice test domain to study the behavior of planning algorithms in planning problems with resources.
There are two ways to scale problem difficulty in Nomystery: increasing the number of packages and locations, and decreasing C. The generator is very fast up to 18 locations and 18 packages. Two types of encoding can be used for the problems: Hard and Hardcost. The only difference is in the action costs. While all actions have a unit cost in Hard encoding, in Hardcost version action costs are equal to the amount of fuel consumed by the action. Therefore, the total cost of a plan for Hardcost encoding equals the amount of fuel consumed in the plan. In Hard encoding, problems with 12 locations and 12 packages become quite challenging for state of the art planners when C is close 1 [1]. Hardcost encoding makes the problems easier for the current planners. The reason is that the heuristic functions that consider costs are not any more completely ignorant to the resource consumption of actions. However, this type of encoding is not always feasible for resource planning; there might be several resources and the cost of the plan might be different from the amount of the resource consumption. However, our initial experiments show problems in this encoding with 12 locations and 15 packages become challenging for current planners when C is close to 1.
From the two versions of the domain we have chosen the noncost one (cost of the plan and resource consumption are not related). As the domain creator says, this is the most difficult one of the two formulations. In addition, it is the less similar to the Transport domain. According to the domain creator planners find it difficult to solve problems with more than 12 locations and 12 packages when the constraint on the resource tends to 1. For the satisficing track, problems 110 start with 6 locations and 6 packages with c=1.5 and each problem increases 1 package and 1 location to the previous one (so problem 10 has 15 packages and 15 locations). Problems 1120 also start in 66 and increase parameters by 1, but in this case c=1.1.
For the optimal track, we developed a first version where problems 110 start with 2 locations and 1 package with c=1.5 and each problem increases 1 location and 1 package to the previous one (so problem 10 has 10 packages and 11 locations). Problems 1120 also start in 21 and increase parameters by 1, but in this case c=1.1. This version resulted to be quite simple, so we generated a tougher one. We started with 4 locations and 3 packages (last problem had 13 locations and 12 packages) with c=1.5 and c=1.1. That version was also quite simple, so a third one has been generated. From experiments it seems the lower the constraint the easier the problems are for the optimal planners: the search space is pruned quickly as the cost limits the number of applicable actions. Taking that into account we have generated problems with c=1.1, 1.5 and 2.0. Problems 16 have c=1.1 and start in 9 locations and 8 packages till 1413. From 713 c=1.5, starting in 8 locations and 7 packages. Problems 1420 are like 713 but with c=2.0.
References:
[1] Nakhost, H.; Hoffmann, J.; and Müler, M. 2010. Improving local search for resourceconstrained planning. Technical Report TR 1002, Dept. of Computing Science, University of Alberta, Edmonton, Alberta, Canada.
[2] Hoffmann, J.; Kautz, H.; Gomes, C.; and Selman, B. 2007. SAT Encodings of StateSpace Reachability Problems in Numeric Domains. In Proc. 20th International Joint Conference on Artificial Intelligence (IJCAI07), 1918–1923
Openstacks
From the original domain description (click here): This domain was first used at IPC2006. The openstacks domain is based on the "minimum maximum simultaneous open stacks" combinatorial optimization problem, which can be stated as follows: A manufacturer has a number of orders, each for a combination of different products, and can only make one product at a time.
The total required quantity of each product is made at the same time (because changing from making one product to making another requires a production stop). From the time that the first product included in an order is made to the time that all products included in the order have been made, the order is said to be "open" and during this time it requires a "stack" (a temporary storage space). The problem is to order the making of the different products so that the maximum number of stacks that are in use simultaneously, or equivalently the number of orders that are in simultaneous production, is minimized (because each stack takes up space in the production area).
The problem is NPhard and known to be equivalent to several other problems. It was recently posed as a challenge problem for the constraint programming community (see http://www.dcs.stand.ac.uk/~ipg/challenge/).
Note that this is an optimization problem: for any instance of the problem every ordering of the making of products is a solution, which at worst uses as many simultaneously open stacks as there are orders. Thus, finding a plan is quite trivial (in the sense that there exists a domainspecific lineartime algorithm that solves the problem), but finding a plan of high quality is hard (even for a domainspecific algorithm).
There are two versions of this domain, STRIPS and ADL. As there are few ADL compliant planners and in the last IPC there were not too much differences in results between both versions, we have not generated ADL problems for this IPC. In the STRIPS version the goal is to minimize the total number of stacks. The number of stacks is represented using symbols and universally quantified preconditions have been replaced by multiple semiground actions. Note that this requires a different domain file for each problem.
For the satisficing track, in the 2008 competition, objects ranged from 5 to 100. For the first 12 problems, three versions with the same difficulty were created and objects were increased by 5 from one triplet to the next (i.e. problems 1, 2 and 3 were similar, with 5 objects; problems 4, 5 and 6 had 10 objects...). From 13 to 24 objects were increased by 10, while for the last 6, objects were increased by 20. The density parameter has been lost. For IPC 2011, as in the other reused domains, we reused the 10 first problems. From 11 to 20, objects are increased starting from 130 by 30, and 2 problems of the same size have been created, one with density = 20 and the other with density = 80.
The selected problems are (numbers in parenthesis are number of objects of each new problem):
problem 
old 
best 
problem 
old 
best 
p01 
p21 
6 
p11 
(130) 

p02 
p22 
16 
p12 
(130) 

p03 
p24 
19 
p13 
(160) 

p04 
p25 
19 
p14 
(160) 

p05 
p26 
15 
p15 
(190) 

p06 
p27 
18 
p16 
(190) 

p07 
p20 
13 
p17 
(220) 

p08 
p28 
33 
p18 
(220) 

p09 
p29 
31 
p19 
(250) 

p10 
p30 
35 
p20 
(250) 

For the optimal track, in the IPC 2008 a total of 9 problems were not solved by any planner (problem 20 and from 23 to 30). As in the satisficing version, there is no record of the density used to generate the problems. The first problem in IPC 2008 started with 5 objects and each problem had 1 object more than the previous one. So problem 30 had 34 objects.
Five first problems were quite simple so they have been removed from the selection. This results in 16 problems previously solved and 4 non solved for this edition. The selected problems are:
problem 
old 
optimal 

problem 
old 
optimal 
p01 
p6 
2 

p11 
p15 
4 
p02 
p7 
5 

p12 
p16 
4 
p03 
p8 
5 

p13 
p17 
4 
p04 
p9 
3 

p14 
p18 
3 
p05 
p10 
3 

p15 
p19 
4 
p06 
p11 
4 

p16 
p21 
3 
p07 
p12 
3 

p17 
p20 
 
p08 
p13 
4 

p18 
p23 
 
p09 
p14 
4 

p19 
p24 
 
p10 
p22 
4 

p20 
p25 
 
Parcprinter
From the original domain description (click here): This domain models the operation of the multiengine printer, for which one prototype is developed at the Palo Alto Research Center (PARC). This type of printer can handle multiple print jobs simultaneously. Multiple sheets, belonging to the same job or different jobs, can be printed simultaneously using multiple Image Marking Engines (IME). Each IME can either be color, which can print both color and black&white images, or mono, which can only print black&white image. Each sheet needs to go through multiple printer components such as feeder, transporter, IME, inverter, finisher and need to arrive at the finisher in order. Thus, sheet (n+1) needs to be stacked in the same finisher with sheet n of the same job, but needs to arrive at the finisher right after sheet n (no other sheet stacked in between those two consecutive sheets). Given that the IMEs are heterogeneous (mixture of color and mono) and can run at different speeds, optimizing the operation of this printer for a mixture of print jobs, each of them is an arbitrary mixture of color/b&w pages that are either simplex (onesided print) or duplex (twosided print) is a hard problem. For the detail description of this domain and the continual online planner controlling it, please refer to the references listed at the end of this page.
This domain is used in two tracks: sequential and temporal. The temporal track is the most natural fit due to the default objective function for the printer of maximizing its productivity, which equals to finish printing all print job requests as quickly as possible. For the sequential track, we use a more seldom used objective function of minimizing printing cost. For example, using a more expensive color IME to print a black&white page costs more than using a mono IME. However, the cost tradeoff may not be clearcut if the feeder, where the blank sheets originally reside at is closer to the mono IME than to the color IME.
Overall, three different printers have been modeled, two with 2 IMEs (one color and one mono) and one with 4 IMEs (two colors and two monos). Two with rather symmetric design and a third one is asymmetric. Even those the printers are hypothetical, the hardware that can be used to make those printers are real.
For the problem files, to reduce complexity, print request of a single job with multiple sheets have been created. The sheets are randomly set to be either simplex (onesided print) or duplex (twosided print) and each image is also randomly selected to be either mono or color. The number of sheets varies from 1 to 20. Given this print job request and a particular printer configuration, the competing planner needs to find a plan with lowest total printing cost in the sequential track (matching well between image requirement and IME capabilities) and smallest makespan in the temporal track (synchronize well different IMEs).
There is no generator for this domain, so new problems will be byhand generated using IPC 2008 ones. New problems will add some sheets to old problems or will make twosided some of them. As in the IPC 2008, three different printers are used, one for problems 110, another for 1120, and another for 2130.
Remark: Printer 1 is not able to turn a page once printed, so if a problem prints something in the back side, the sheet needs to finish with back side up.
For the satisficing track, in the IPC 2008 the first problem had 1 sheet, second one 2 sheets and so on until problem 10. The same applies for problems 1120 (changing the printer) and 2130. We have reused the 10 following problems:
problem 
old 
best 
problem 
old 
best 
p01 
p07 
1383120 
p11 
p01 + 2sides 
 
p02 
p08 
1852220 
p12 
p03 + 2sheets 
 
p03 
p10 
2490320 
p13 
p03 + 5sheets 
 
p04 
p20 
2754190 
p14 
p04 + 2sheets 
 
p05 
p26 
1216460 
p15 
P04 + 2sides 
 
p06 
p27 
1270870 
p16 
p04 + 2+2 
 
p07 
p09 
2121260 
p17 
p06 + 2sides 
 
p08 
p28 
1681280 
p18 
p08 + 2sides 
 
p09 
p29 
2377260 
p19 
p09 + 3sides 
 
p10 
p30 
2021890 
p20 
p10 + 2sheets 
 
FF solves the previous problems quite quickly (less than 30 seconds), so the battlefield of this domain is going to be quality. From last IPC results it seems printer 1 and 3 are more difficult than printer 2 (out of the 10 most difficult problems, 5 belong to printer 3, 4 to printer 1 and only 1 to printer 2). We have generated 334 new problems increasing sheets or sides from the previously created problems.
For the optimal track, there were 10 unsolved problems in last IPC. Problem number 1 had only 1 sheet and 1 image to be printed in the sheet. Printer had 2 IMEs (one color and one mono). Problem number 2 had 2 sheets and 2 images, and so on until problem 10. In problems 11 to 20 another more complex printer with also 2 IMEs was modeled. In problem 11, using this printer 1 sheet was printed in 1 image, and so on until problem 20. In problem 21 a new printer with 4 IMEs was modelled and we start again with 1 image in 1 sheet (some of them like problem 15 and problems 29 and 30 include extra images so some sheets are twosided).
We have eliminated problems 3, 11, 1 and 21 as they were quite easy, so we have 16 solved and 4 unsolved problems, as follows:
problem 
old 
optimal 
problem 
old 
optimal 
p01 
p22 
375821 
p11 
p26 
1216460 
p02 
p02 
438047 
p12 
p14 
1020510 
p03 
p12 
510256 
p13 
p07 
1383120 
p04 
p04 
876094 
p14 
p08 
1852220 
p05 
p23 
519232 
p15 
p09 
2121260 
p06 
p06 
1514200 
p16 
p10 
2490320 
p07 
p05 
1145130 
p17 
p15 
1695510 
p08 
p24 
751642 
p18 
p16 
1675410 
p09 
p13 
693064 
p19 
p17 
1713580 
p10 
p25 
1215840 
p20 
p27 
1270870 
References:
Online Planning and Scheduling for Highspeed Manufacturing. Wheeler Ruml, Minh B. Do, & Markus Fromherz. In Proc. of the 15th International Conference on Automated Planning and Scheduling (ICAPS) 2005. (PDF)
Lessons Learned in Applying DomainIndependent Planning to HighSpeed Manufacturing. Minh B. Do, & Wheeler Ruml. In Proc. of 16^{th} International Conference on Automated Planning and Scheduling (ICAPS), 2006. (PDF)
Online Planning and Scheduling: An Application to Controlling Modular Printers. Minh B. Do, Wheeler Ruml, and Rong Zhou. In the Proc. of 23^{rd} AAAI Conference on Artificial Intelligence (AAAI), NECTAR Track.(PDF)
Planning for Modular Printers: Beyond Productivity. Minh B. Do, Wheeler Ruml, and Rong Zhou. To appear in the 18^{th} International Conference on Automated Planning and Scheduling (ICAPS), (PDF)
Parking
This domain is original from the learning part of IPC2008. The domain involves parking cars on a street with N curb locations, and where cars can be doubleparked but not tripleparked. The goal is to find a plan to move from one configuration of parked cars to another configuration, by driving cars from one curb location to another. The problems in the competition contain 2*(N1) cars, which allows one free curb space and guarantees solvability. For the satisficing track these problems have been created:
Problem 
Cars 
Curbs 
p01p02 
22 
12 
p03p06 
24 
13 
p07p10 
26 
14 
p11p14 
28 
15 
p15p18 
30 
16 
p19p20 
32 
17 
For the optimal track these problems have been created:
Problem 
Cars 
Curbs 
p01p02 
12 
7 
p03p06 
14 
8 
p07p10 
16 
9 
p11p14 
18 
10 
p15p18 
20 
11 
p19p20 
22 
12 
Pegsol
This domain models the Peg Solitaire game.
In IPC 2008 problems were the same both in sequential satisficing and in sequential optimal. They were taken from a pool of problems. The problem generator (in Ruby) takes problems from the library and converts them to pddl files. A total of 105 problems (some of them unsolvable) were generated. It seems it is the number of pegs and not the number of required movements what makes difficult for planners to find a solution. But most of the problems with more than 17 pegs (problem 20 of the last IPC) had been already selected. So for this year's competition most of the problems (and all of the most difficult ones) come from the last IPC. Then, planners are expected to behave quite well in this domain, solving most or almost all the problems. We include this domain just to check that this year's planners are at least as good as past competition ones.
For the satisficing track, we have reused 15 problems from the last IPC and have added 5 new problems taken from the pool. The selected problems are:
problem 
old 
pegs 
best cost 
problem 
old 
pegs 
best cost 
p01 
p17 
16 
10 
p11 
p23 
18 
8 
p02 
p18 
16 
7 
p12 
p24 
19 
8 
p03 
p19 
16 
8 
p13 
p13 
14 
9 
p04 
073 
16 
 
p14 
p25 
19 
8 
p05 
085 
16 
 
p15 
p14 
15 
7 
p06 
087 
16 
 
p16 
p26 
20 
9 
p07 
065 
17 
 
p17 
p27 
23 
7 
p08 
093 
17 
 
p18 
p28 
25 
16 
p09 
p20 
17 
7 
p19 
p29 
28 
14 
p10 
p21 
17 
8 
p20 
p30 
32 
25 
where problems 48 are the new ones.
For the optimal track, there were only 3 unsolved problems in the 2010 set, and a lot of planners solved about 25 problems. The first unsolved problem of last IPC is the number 28 which corresponds with problem 074 in the library, which has 25 pegs and in theory is solvable with cost 12.
The following table shows the problems selected for this year competition (the most difficult problems, in number of pegs, from the available pool), last column states whether the problem was also selected for last IPC.
Problem 
Library 
Pegs 
Movements 
IPC2008 

Problem 
Library 
Pegs 
Movements 
IPC2008 
p01 
036 
15 
3 
none 

p11 
092 
17 
6 
p22 
p02 
030 
16 
10 
p17 

p12 
093 
17 
11 
none 
p03 
060 
16 
7 
p18 

p13 
047 
18 
8 
p23 
p04 
063 
16 
8 
p19 

p14 
031 
19 
8 
p24 
p05 
073 
16 
12 
none 

p15 
071 
19 
8 
p25 
p06 
085 
16 
9 
none 

p16 
104 
20 
9 
p26 
p07 
087 
16 
7 
none 

p17 
084 
23 
7 
p27 
p08 
044 
17 
7 
p20 

p18 
074 
25 
12 
p28 
p09 
065 
17 
8 
none 

p19 
099 
28 
11 
p29 
p10 
080 
17 
8 
p21 

p20 
105 
32 
18 
p30 
Scanalyzer
This domain models the problem of automatic greenhouse logistic management. More information about it can be found in the ICAPS 2010 paper There is no generator nor information about how problems were generated. In IPC 2008 problems in this domain were the same for both the optimal and the satisficing tracks. In addition, problems 22, 23 and 24 are exactly the same problem.
The following table shows the number of objects in each problem for IPC 2008 and how did they increase:
Problem 
Cars 
Segments 
CYCLE2 
p01 
6 
6 
(cars/2)^2 
p02 
+0 
+0 
/(cars/2) 
p04 
+2 
+2 
(cars/2)^2 
p05 
+0 
+0 
/(cars/2) 
This was continued until problem 21: problems were organized in triplets, where first problem of each triplet (3n+1) had 2 more cars and segments than first problem of previous triplet (3n2), and (cars/2)^2 CYCLE2 segments, which were divided by (cars/2) for the next 2 problems. From problem 22, number of cars was initialized to 4 and CYCLE2 was changed by CYCLE4 (again with car/2 predicates). As said, problem 23 and 24 were exactly the same as problem 22. Problem 25 had 4 more cars, while 26 and 27 divided by 2 the CYCLE4 predicates. The same applies for 2830 (12 cars, starting with 9 CYCLE4 and dividing by 3)
For the satisficing track, taking into account that there is no generator and that there is margin for increasing the quality of the found plans, we have reused the problems of last competition as follows:
problem 
old 
optimal 
best 
problem 
old 
optimal 
best 
p01 
p25 
26 
26 
p11 
p15 
66 
82 
p02 
p10 
36 
36 
p12 
p11 
46 
54 
p03 
p06 
36 
40 
p13 
p08 
38 
44 
p04 
p09 
46 
54 
p14 
p17 
62 
74 
p05 
p13 
42 
42 
p15 
p18 
76 
92 
p06 
p26 
30 
32 
p16 
p20 
70 
84 
p07 
p16 
48 
48 
p17 
p21 
86 
104 
p08 
p27 
34 
36 
p18 
p28 
39 
39 
p09 
p12 
56 
66 
p19 
p29 
47 
81 
p10 
p14 
54 
64 
p20 
p30 
55 
173 
For the optimal track, there were 13 unsolved problems in the last IPC. In addition no planner solved more than 11 problems. From results we can see that usually first problem of a triplet is easiest than the two last problems from the previous triplet. The selected problems are:
problem 
old 
optimal/best 

problem 
old 
optimal/best 
p01 
p23 
13 

p11 
p25 
26 
p02 
p02 
22 

p12 
p06 
36 
p03 
p03 
26 

p13 
p27 
34 
p04 
p04 
24 

p14 
p26 
30 
p05 
p07 
30 

p15 
p08 
38 
p06 
p05 
30 

p16 
p11 
46 
p07 
p19 
54 

p17 
p14 
54 
p08 
p10 
36 

p18 
p17 
62 
p09 
p13 
42 

p19 
p20 
70 
p10 
p16 
48 

p20 
p28 
47 
So we have 14 solved problems. To select the remaining 6 ones we rely on the fact that from 1 to 21 a triplet is always easier than the next one, and the same applies for triplets 22 to 30. So we have taken the second element of each triplet (8,11,14,17,20) and 28 from the last triplet.
Sokoban
This domain models the Sokoban game.
For the satisficing track, in IPC 2008 performance of planners in this domain was somehow poor (best planner had 5 unsolved problems), so instead of generating new problems we have reused the most difficult problems of last IPC.
problem 
old 
best 
problem 
old 
best 
p01 
p25 
52 
p11 
p28 
101 
p02 
p08 
50 
p12 
p18 
43 
p03 
p17 
23 
p13 
p27 
24 
p04 
p16 
33 
p14 
p24 
47 
p05 
p14 
50 
p15 
p30 
80 
p06 
p12 
44 
p16 
p19 
18 
p07 
p13 
31 
p17 
p26 
47 
p08 
p22 
60 
p18 
p29 
42 
p09 
p10 
2 
p19 
p15 
39 
p10 
p23 
46 
p20 
p20 
14 
For the optimal track, at the 2008 edition there were 20 solved problems, and no problem over 21st was solved. We discarded problems 1, 2 and 3, as they were quite easy, which results in 17 solved problems. So 3 unsolved problems have to be added. At IPC 2008 problems were taken from a library, so we have assumed problem 21 is easier than 22 and so on, and have chosen problems 2123. The selected problems are then:
problem 
old 
optimal 

problem 
old 
optimal 
p01 
p06 
9 

p11 
p13 
20 
p02 
p17 
37 

p12 
p20 
2 
p03 
p14 
29 

p13 
p08 
31 
p04 
p04 
29 

p14 
p12 
32 
p05 
p16 
50 

p15 
p18 
49 
p06 
p11 
35 

p16 
p15 
76 
p07 
p10 
30 

p17 
p19 
47 
p08 
p09 
19 

p18 
p21 
 
p09 
p07 
15 

p19 
p22 
 
p10 
p05 
8 

p20 
p23 
 
Tidybot
Author: Bhaskara Marthi
From the original description: The Tidybot domain models a household cleaning task, in which one or more robots must pick up a set of objects and put them into goal locations. The world is structured as a 2d grid, divided into navigable locations and surfaces on which objects may lie. Robots have a gripper, which moves relative to the robot, up to some maximum radius. Existing objects block the gripper, so that it may be necessary to move one object out of the way to put another one down. Robots can carry one object at a time in the gripper, but may also make use of a cart, that can hold multiple objects. The instance generator creates worlds that contain rectangular surfaces ("tables"), as well as Ushaped enclosures ("cupboards"), which are the goal locations of objects.
In many realworld problems, the difficulty is due to the large state space and number of objects, rather than due to complex, "puzzlelike" combinatorial constraints. Humans are able to quickly find feasible solutions in such domains, because they seem to be able to decompose the problem into separate parts and make use of the geometrical structure. This domain is thus intended to exercise the ability of planners to find and exploit structure in large but mostly unconstrained problems.
Optimal reasoning in such problems is challenging for humans as well, and a secondary motivation for the domain is to test the ability to do optimal reasoning in geometrically structured worlds. The presence of the carts adds another combinatorial decision: it might be worthwhile to spend some time fetching the cart to avoid later having to go back and forth with each object.
The instance generator is provided as a .jar file, together with the source code (in the Clojure language). To generate an instance: java cp tidybot.jar tidybot worldsize numtables numcupboards tableminsize tablemaxsize cupboardsize
The number of objects will be numcupboards * objectspercupboard, where objectspercupboard = (cupboardsize  2)^2. Thus, numcupboards should be >= 1, otherwise there will be no objects. It is recommended to set cupboardsize = 4. Scaling worldsize will then increase the number of literals/states, while scaling numcupboards will increase the number of objects and goals. Scaling numtables will tend to make the domain more constrained (since there are more obstacles), and also to increase the branching factor, since there are more places to set objects down.
Problems with the same size can be quite different in difficulty, so we will generate various problems of the same size. The automatic generator returns error quite often (9 out of 10 times at least) when the size of the world is lower than 9. But problems with size 9 are quite challenging even for the satisficing planners. In addition some of the generated problems are unsolvable or are equal to other generated problems. This makes quite hard to generate problems for this domain.
For the satisficing track, problems with world size=8 are solved quite easily, but problems with size=9 are challenging. The following table shows the parameters chosen for the problems at IPC 2011.
problem 
size 
tables 
cupboards 
goal positions 
problem 
size 
tables 
cupboards 
goal positions 
p01 
9x9 
5 
1 
6 
p11 
10x10 
3 
1 
7 
p02 
9x9 
6 
1 
6 
p12 
10x10 
2 
1 
7 
p03 
9x9 
3 
1 
7 
p13 
10x10 
6 
1 
5 
p04 
9x9 
3 
1 
6 
p14 
10x10 
8 
1 
7 
p05 
9x9 
3 
1 
5 
p15 
10x10 
6 
1 
7 
p06 
9x9 
6 
1 
6 
p16 
10x10 
3 
1 
5 
p07 
9x9 
3 
1 
8 
p17 
11x11 
9 
1 
8 
p08 
9x9 
3 
1 
6 
p18 
11x11 
7 
1 
6 
p09 
10x10 
9 
1 
7 
p19 
12x12 
5 
3 
15 
p10 
10x10 
9 
1 
7 
p20 
12x12 
7 
2 
11 
For the optimal track, the following table shows the parameters chosen for the problems at IPC 2011.
problem 
size 
tables 
cupboards 
goal positions 
problem 
size 
tables 
cupboards 
goal positions 
p01 
5 
0 
1 
4 
p11 
8 
0 
1 
4 
p02 
6 
0 
1 
4 
p12 
8 
0 
1 
4 
p03 
6 
0 
1 
4 
p13 
8 
0 
1 
4 
p04 
6 
0 
1 
4 
p14 
9 
3 
1 
6 
p05 
7 
0 
1 
4 
p15 
9 
2 
1 
7 
p06 
7 
0 
1 
4 
p16 
9 
5 
1 
6 
p07 
7 
0 
1 
4 
p17 
9 
4 
1 
6 
p08 
7 
0 
1 
4 
p18 
9 
3 
1 
7 
p09 
8 
0 
1 
4 
p19 
9 
4 
1 
5 
p10 
8 
0 
1 
4 
p20 
9 
5 
1 
5 
Transport
There is no description of this domain in the last IPC, but it seems to be a kind of logistics one. Each vehicle can transport some packages depending on its capacity and moving has a cost depending on the length of the road. Picking up or dropping a package costs 1.
For the satisficing track, the following table depicts the parameters of IPC 2008 problems:
Problem 
Cities 
Total Nodes 
Trucks 
Packages 
Capacity 
p01 
1 
5 
2 
2 
4 
p02 
1 
10 (+5) 
2 (=) 
4 (+2) 
4 
p03 
1 
10 (+5) 
3 (+1) 
6 (+2) 
4 
p06 
1 
30 
4 
12 
4 
p10 
1 
50 
4 
20 
4 
p11 
2 
6 (3x2) 
2 
2 
4 
p12 
2 
12 (2x6) (+6) 
2 
4 (+2) 
4 
p13 
2 
18 (2x9) (+6) 
3 
6 (+2) 
4 
p20 
2 
60 (2x30) 
4 
20 
4 
p21 
3 
6 (3x2) 
2 
2 
4 
p22 
3 
12 (3x4) (+6) 
2 
4 
4 
p30 
3 
60 (3x20) 
4 
20 
4 
So the first 10 problems consider only 1 city, starting in 5 locations and increasing them by 5, with 2 packages that are increased by 2. Trucks are 2 for p01 and p02, 3 for p03p05 and 4 for the remaining problems. Problems 1120 follow the same rules for trucks and packages, but have 2 cities, and number of total nodes is increased by 6 from problem to problem. The same rules apply for problems 2130, but in this case there are 3 cities.
It seems that most difficult problems are those with 2 cities, and easiest those with 3. So for the 10 new problems have generated 334 problems of 123 cities. Starting from parameters of problems 10, 20 and 30 with slow increases so we can characterize the phase transition (first problem increases packages, second one nodes and third one both). So problems for this domain are:
problem 
old 
best 
problem 
old 
best 
p01 
p08 
1216 
p11 
(150422) 
6485 
p02 
p09 
1001 
p12 
(153420) 
8075 
p03 
p29 
3294 
p13 
(153422) 
11768 
p04 
p16 
4928 
p14 
(260422) 

p05 
p17 
4193 
p15 
(262420) 

p06 
p18 
4151 
p16 
(262422) 

p07 
p19 
7648 
p17 
(360422) 
44125 
p08 
p10 
1285 
p18 
(363420) 

p09 
p20 
6773 
p19 
(363422) 

p10 
p30 
5513 
p20 
(366422) 

The number in parenthesis are citiesnodestruckspackages.
For the optimal track, the following table shows the objects of problems at last IPC and how do they increase:
Problem 
Cities 
Total Nodes 
Trucks 
Packages 
Capacity 
p01 
1 
3 
2 
2 
4 
p02 
+0 
+3 
+0 
+1 
+0 
p06 
.. 
.. 
+1 
.. 
.. 
p10 
1 
30 
2 
11 
4 
p11 
2 
4 
2 
2 
4 
p12 
+0 
+4 
+0 
+1 
+0 
p16 
.. 
.. 
+1 
.. 
.. 
p20 
2 
40 
3 
11 
4 
p21 
3 
3 
2 
2 
4 
p22 
+0 
+3 
+0 
+1 
+0 
p26 
.. 
.. 
+1 
.. 
.. 
p30 
3 
30 
3 
11 
4 
We remove problems 1, 2, 11, 21 and 22, which are quite easy. This gives us only 6 solved problems and 14 non solved. As this would make the domain too difficult, we have generated some new problems so the number of previously unsolved problems remains lower than 5. From the tables above we can see that the most important parameters to measure the difficulty of the problems are the number of nodes and of packages. From problem 14 we can elicit that nodes seem to be more important than packages; its equivalents with 7 packages, problems 4 and 24 have both 12 nodes and are solved, while problem 14 (not solved) has 16 nodes. Effect of trucks cannot be measured as no problem with 3 trucks is solved. The phase transition in terms of nodes seems to be between 12 (solved) and 16 (non solved). So we have generated problems with 13, 14 and 15 nodes with 1 city, 14 nodes with 2 cities and 15 nodes with 3 cities (number of nodes needs to be a multiplier of number of cities). We did it for 2 and 3 trucks. This results in 10 new problems.
The selected problems are then:
problem 
old 
optimal 
problem 
old 
optimal 
p01 
p23 
630 
p11 
(21428) 

p02 
p03 
250 
p12 
(21438) 

p03 
p12 
594 
p13 
(11528) 

p04 
p13 
550 
p14 
(11538) 

p05 
p24 
614 
p15 
(31529) 

p06 
p04 
318 
p16 
(31539) 

p07 
(11326) 

p17 
p05 

p08 
(11336) 

p18 
p14 

p09 
(11427) 

p19 
p25 

p10 
(11437) 

p20 
p06 

The number in parenthesis are citiesnodestruckspackages.
Visitall
Author: Nir Lipovetzky
From the attached paper: "The heuristics used in stateoftheart (satisficing) planners are a decade old and are based on the deleterelaxation. Several heuristics that take deletes into account have been formulated but they haven’t been shown to be costeffective. One problem with deleterelaxation heuristics that aproximate h+, appears in instances with multiple conflicting goals. In these cases, that are very common, progress towards one goal means moving away from other goals. Such instances produce large plateaus where the heuristic is almost useless. Indeed, in some cases, stateoftheart heuristics are no better than heuristics that ignore the problem structure completely and just count, for example, the number of unachievable goals. As an illustration of this, consider the VisitAll domain where an agent in the middle of a square grid nxn must visit all the cells in the grid. Solving optimally the delete relaxation h+ gives the exact goal distance as long as there exists a hamiltonian path visiting every cell. Recall that in a 1xn grid, no hamiltonian path exists."
"The use of deleterelaxation heuristics to appraise the cost of achieving all goals together runs into a situation resembling Buridan’s ass: where a hungry and thirsty donkey, placed between a bundle of hay and a pail of water, dies of hunger and thirst for not finding a reason to choose one over the other.
* VisitAll domain description paper
Woodworking
There is no description of this domain in the last IPC. It simulates the works in a woodworking workshop where there is some quantity of wood that has to be polished, coloured, etc. using different tools with different costs. Parameters of each problem are the parts to be done and the quantity (in % of necessary) of available wood (boards). The higher the number of parts and the boards the more difficult the problem is.
In the satisficing track, at IPC 2008 a lot of planners solved almost all the problems in this domain. We have reused the 10 most difficult from last IPC and have generated 10 more difficult than those.
In the last IPC problems were generated as follows:
problem 
parts 
wood 
tools 
p01 
3 
140% 
1 
p02 
6 (+3) 
140% 
1 
p10 
30 
140% 
1 
Problems 1120 followed the same pattern, but with a 120% of wood, so they did problems 2130 but with a 100% of wood. It seems the more the wood the more difficult a problem is. We will generate problems with 120% and 140% of wood, increasing also parts by 3. If we take a 3parts problem with 1 tool of each type, and generate a similar one with 3 tools, solving time passes from some seconds to some minutes. But if we generate an equivalent one with 5 tools time is reduced and is similar to the 1tool problem! Increasing tools to 7 reduces the time even more. So we have generated problems with 1 and 3 tools of each type.
Problems for the competition are depicted in the following table (numbers in brackets are woodpartstools):
problem 
old 
best 
problem 
old 
best 
p01 
p07 
1230 
p11 
(120331) 

p02 
p08 
1465 
p12 
(140331) 

p03 
p19 
1305 
p13 
(120361) 

p04 
p09 
1390 
p14 
(140361) 

p05 
p20 
1615 
p15 
(120391) 

p06 
p10 
1525 
p16 
(140391) 

p07 
p28 
1610 
p17 
(120203) 

p08 
p29 
1400 
p18 
(140203) 

p09 
p18 
1310 
p19 
(120233) 

p10 
p11 
50 
p20 
(140233) 

For the optimal track, at IPC 2008 ten first problems had a 140% of wood and parts were increased by one from one problem to another, starting from 3 parts. Similarly problems 1120 started with 120% and 3 parts. Problems 2130 decreased the available wood to 100%. From last IPC results it seems most planners are not able to handle problems with more than 5 parts. The lower the boards the easier the problem seem to be. Tthe performance of planners in this domain is quite poor. The easiest problems are solved by almost all the planners, but as soon as number of parts is above 5 only one planner is able to solve problems. But this planner finds non optimal or invalid plans for the easiest instances.
Problems selected are:
problem 
old 
optimal 
problem 
old 
optimal 
p01 
p23 
195 
p11 
p26 
345 
p02 
p12 
225 
p12 
p16 
355 
p03 
p13 
215 
p13 
p06 
520 
p04 
p03 
275 
p14 
p27 
470 
p05 
p24 
245 
p15 
p17 
425 
p06 
p04 
280 
p16 
p07 
485 
p07 
p14 
225 
p17 
p28 
675 
p08 
p25 
535 
p18 
p18 
550 
p09 
p05 
330 
p19 
p08 
510 
p10 
p15 
270 
p20 
p29 
675 