Differences between revisions 1 and 36 (spanning 35 versions)
Revision 1 as of 2010-08-03 09:58:17
Size: 584
Editor: GabiRoeger
Comment:
Revision 36 as of 2013-05-17 15:28:43
Size: 7733
Editor: MalteHelmert
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

Line 7: Line 5:
Running the planner is a three-step process as explained in Section 3 (pp. 202-203) of the [[http://www.jair.org/papers/paper1705.html|JAIR paper on Fast Downward]]. The following instructions show how to run these three steps, in sequence, assuming that the preprocessor and search component have been compiled and that you are currently located in the {{{src}}} directory.

If you want to run any of the planners based on Fast Downward that participated in IPC 2011, please also check IpcPlanners.
Line 9: Line 11:
XXX TODO {{{
translate/translate.py [DOMAIN] PROBLEM
}}}
Line 11: Line 15:
 * `DOMAIN` (filename): PDDL domain file
 * `PROBLEM` (filename): PDDL problem file

If the domain file is not given, the planner will try to infer a likely name from the problem file name, using the conventions used at the various IPCs. (If in doubt if this will work for you, just try it out.)

Note: Creates a file called [[TranslatorOutputFormat#outputsas|output.sas]] (as well as [[TranslatorOutputFormat|test.groups]], all.groups, ...)
Line 13: Line 23:
XXX TODO {{{
preprocess/preprocess < OUTPUT.SAS
}}}

 * `OUTPUT.SAS` (filename): translator output

Note: Creates a file called output
Line 19: Line 35:
 search [OPTIONS] {-s|--search} SEARCH < OUTPUT search/downward [OPTIONS] --search SEARCH < OUTPUT
Line 25: Line 41:
 * `-h, --heuristic` [[ReusingHeuristics#predefinition|HEURISTIC_PREDEFINITION]]  * `--heuristic` [[ReusingHeuristics#predefinition|HEURISTIC_PREDEFINITION]]
Line 28: Line 44:
 * `-r, --random-seed` SEED  * `--random-seed` SEED
Line 30: Line 46:

=== Exit codes ===
The list of '''exit codes''' for the search component is defined in [[http://hg.fast-downward.org/file/tip/src/search/utilities.h|src/search/utilities.h]] and explained below:

|| '''Code''' || '''Symbol''' || '''Meaning''' ||
|| 0 || EXIT_PLAN_FOUND || Solution found. ||
|| 1 || EXIT_CRITICAL_ERROR || Something went wrong that should not have went wrong (e.g. planner bug). ||
|| 2 || EXIT_INPUT_ERROR || Wrong command line options or SAS+ file. ||
|| 3 || EXIT_UNSUPPORTED || Requested unsupported feature. ||
|| 4 || EXIT_UNSOLVABLE || Task is provably unsolvable with current bound. Currently unused (see [[http://issues.fast-downward.org/issue377|issue377]]). ||
|| 5 || EXIT_UNSOLVED_INCOMPLETE || Search ended without finding a solution. ||
|| 6 || EXIT_OUT_OF_MEMORY || Memory exhausted. ||
|| 7 || EXIT_TIMEOUT || Timeout occured. Currently only returned by portfolios. ||
|| 8 || EXIT_TIMEOUT_AND_MEMORY || In portfolio configurations both timeouts and out-of-memory conditions occurred. ||

=== Examples ===

A* search:

{{{#!highlight bash
# landmark-cut heuristic (previously configuration "ou")
 ./downward --search "astar(lmcut())" < output

# merge-and-shrink heuristic with default settings (previously configuration "oa50000")
 ./downward --search "astar(merge_and_shrink())" < output

# blind heuristic (previously configuarion "ob")
 ./downward --search "astar(blind())" < output
}}}

Lazy greedy best first search with preferred operators and the queue alternation method:

{{{#!highlight bash
## using FF heuristic and context-enhanced additive heuristic (previously: "fFyY")
 ./downward --heuristic "hff=ff()" --heuristic "hcea=cea()" \
            --search "lazy_greedy([hff, hcea], preferred=[hff, hcea])" \
            < output

## using FF heuristic (previously: "fF")
 ./downward --heuristic "hff=ff()" \
            --search "lazy_greedy(hff, preferred=hff)" \
            < output

## using context-enhanced additive heuristic (previously: "yY")
 ./downward --heuristic "hcea=cea()" \
            --search "lazy_greedy(hcea, preferred=hcea)" \
            < output
}}}

Q: I would like to see an example that uses the LAMA-FF Synergy feature.

A: See next question.

Q: Is it possible to make the planner behave like "old" LAMA (the IPC 2008 version)?

A: We recommend against doing that and suggest you run the planner in "LAMA 2011 mode" instead (see next question). Still, here is the information for a LAMA-2008-like configuration:

The following configuration has all the ingredients of LAMA: it uses the landmark and FF heuristics with synergy in a lazy alternation search with preferred operators for both heuristics, uses iterated search with the appropriate set of options, and performs LAMA's +1 action cost adjustment on the heuristic for problems with non-unit-cost actions. It also uses the same mechanism for computing landmarks as LAMA. (There are, however, a number of implementation differences that make the behaviour of the planner different from original LAMA, e.g. slightly different tie-breaking in the FF heuristic computation.)

{{{
./downward --heuristic "hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=2,lm_cost_type=2))"
           --search "iterated([lazy_greedy([hff,hlm],preferred=[hff,hlm]),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=5),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=3),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=2),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=1)],
                              repeat_last=true)" < output
}}}

The following is the corresponding call to just find a first solution (i.e., not doing iterated search):

{{{
 ./downward --heuristic "hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=2,lm_cost_type=2))"
            --search "lazy_greedy([hlm, hff], preferred=[hlm, hff])"
            < output
}}}

Q: What do I need to do to run LAMA 2011?

All planners in the Fast Downward family that participated in IPC 2011 use exactly the same code and only differ in the command-line options used for the search component of the planner. LAMA 2011 is a bit special in that it uses two different parameter settings depending on whether the input planning task uses unit-cost actions only or general action costs. To enable this automatic switching, run the planner with:

{{{
 ./downward ipc seq-sat-lama-2011 < output
}}}

To find out which actual search options this corresponds to, check the source code of the {{{downward}}} script. Please also check the comments below on 32-bit vs. 64-bit mode.

== 32-bit mode or 64-bit mode? ==

Our current codebase (as of November 2011) differs from the IPC versions of our planners in one way: by default, planner executables are compiled in 32-bit mode, while 64-bit was used at IPC 2011. The main differences between 32- vs. 64-bit mode are as follows:

 * 64-bit mode is faster than 32-bit mode (in our limited experiments typically by a factor of ~1.1)
 * 64-bit mode needs more memory than 32-bit mode (in our limited experiments typically by a factor of ~1.5)
 * 64-bit mode can use essentially unbounded amounts of memory, while 32-bit mode can only use 3 GB of user space memory (on typical Linux systems -- numbers may differ on other operating systems and depending on kernel options)

In our experiments, the memory advantage of 32-bit mode tends to outweigh the speed disadvantage, which is why we enable 32-bit mode by default. See http://issues.fast-downward.org/issue213 for details. However, for memory limits substantially beyond 4 GB, you should use 64-bit mode due to the address space limitations of 32-bit mode.

To enable 64-bit, change all occurrences of {{{-m32}}} in {{{src/search/Makefile}}} to {{{-m64}}}.


== Other questions? ==

Please get in touch! See the HomePage for various contact options.

Back to HomePage.

Usage

Running the planner is a three-step process as explained in Section 3 (pp. 202-203) of the JAIR paper on Fast Downward. The following instructions show how to run these three steps, in sequence, assuming that the preprocessor and search component have been compiled and that you are currently located in the src directory.

If you want to run any of the planners based on Fast Downward that participated in IPC 2011, please also check IpcPlanners.

Translator

translate/translate.py [DOMAIN] PROBLEM
  • DOMAIN (filename): PDDL domain file

  • PROBLEM (filename): PDDL problem file

If the domain file is not given, the planner will try to infer a likely name from the problem file name, using the conventions used at the various IPCs. (If in doubt if this will work for you, just try it out.)

Note: Creates a file called output.sas (as well as test.groups, all.groups, ...)

Preprocessor

preprocess/preprocess < OUTPUT.SAS
  • OUTPUT.SAS (filename): translator output

Note: Creates a file called output

Search component

search/downward [OPTIONS] --search SEARCH < OUTPUT
  • SEARCH (SearchEngine): configuration of the search algorithm

  • OUTPUT (filename): preprocessor output

Options:

  • --heuristic HEURISTIC_PREDEFINITION

    • Predefines a heuristic that can afterwards be referenced by the name that is specified in the definition.
  • --random-seed SEED

    • Use random seed SEED

Exit codes

The list of exit codes for the search component is defined in src/search/utilities.h and explained below:

Code

Symbol

Meaning

0

EXIT_PLAN_FOUND

Solution found.

1

EXIT_CRITICAL_ERROR

Something went wrong that should not have went wrong (e.g. planner bug).

2

EXIT_INPUT_ERROR

Wrong command line options or SAS+ file.

3

EXIT_UNSUPPORTED

Requested unsupported feature.

4

EXIT_UNSOLVABLE

Task is provably unsolvable with current bound. Currently unused (see issue377).

5

EXIT_UNSOLVED_INCOMPLETE

Search ended without finding a solution.

6

EXIT_OUT_OF_MEMORY

Memory exhausted.

7

EXIT_TIMEOUT

Timeout occured. Currently only returned by portfolios.

8

EXIT_TIMEOUT_AND_MEMORY

In portfolio configurations both timeouts and out-of-memory conditions occurred.

Examples

A* search:

   1 # landmark-cut heuristic (previously configuration "ou")
   2  ./downward --search "astar(lmcut())" < output
   3 
   4 # merge-and-shrink heuristic with default settings (previously configuration "oa50000")
   5  ./downward --search "astar(merge_and_shrink())" < output
   6 
   7 # blind heuristic (previously configuarion "ob")
   8  ./downward --search "astar(blind())" < output

Lazy greedy best first search with preferred operators and the queue alternation method:

   1 ## using FF heuristic and context-enhanced additive heuristic (previously: "fFyY")
   2  ./downward --heuristic "hff=ff()" --heuristic "hcea=cea()" \
   3             --search "lazy_greedy([hff, hcea], preferred=[hff, hcea])" \
   4             < output
   5 
   6 ## using FF heuristic (previously: "fF")
   7  ./downward --heuristic "hff=ff()" \
   8             --search "lazy_greedy(hff, preferred=hff)" \
   9             < output
  10 
  11 ## using context-enhanced additive heuristic (previously: "yY")
  12  ./downward --heuristic "hcea=cea()" \
  13             --search "lazy_greedy(hcea, preferred=hcea)" \
  14             < output

Q: I would like to see an example that uses the LAMA-FF Synergy feature.

A: See next question.

Q: Is it possible to make the planner behave like "old" LAMA (the IPC 2008 version)?

A: We recommend against doing that and suggest you run the planner in "LAMA 2011 mode" instead (see next question). Still, here is the information for a LAMA-2008-like configuration:

The following configuration has all the ingredients of LAMA: it uses the landmark and FF heuristics with synergy in a lazy alternation search with preferred operators for both heuristics, uses iterated search with the appropriate set of options, and performs LAMA's +1 action cost adjustment on the heuristic for problems with non-unit-cost actions. It also uses the same mechanism for computing landmarks as LAMA. (There are, however, a number of implementation differences that make the behaviour of the planner different from original LAMA, e.g. slightly different tie-breaking in the FF heuristic computation.)

./downward --heuristic "hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=2,lm_cost_type=2))"
           --search "iterated([lazy_greedy([hff,hlm],preferred=[hff,hlm]),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=5),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=3),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=2),
                               lazy_wastar([hff,hlm],preferred=[hff,hlm],w=1)],
                              repeat_last=true)" < output

The following is the corresponding call to just find a first solution (i.e., not doing iterated search):

 ./downward --heuristic "hlm,hff=lm_ff_syn(lm_rhw(reasonable_orders=true,cost_type=2,lm_cost_type=2))" 
            --search "lazy_greedy([hlm, hff], preferred=[hlm, hff])" 
            < output

Q: What do I need to do to run LAMA 2011?

All planners in the Fast Downward family that participated in IPC 2011 use exactly the same code and only differ in the command-line options used for the search component of the planner. LAMA 2011 is a bit special in that it uses two different parameter settings depending on whether the input planning task uses unit-cost actions only or general action costs. To enable this automatic switching, run the planner with:

 ./downward ipc seq-sat-lama-2011 < output

To find out which actual search options this corresponds to, check the source code of the downward script. Please also check the comments below on 32-bit vs. 64-bit mode.

32-bit mode or 64-bit mode?

Our current codebase (as of November 2011) differs from the IPC versions of our planners in one way: by default, planner executables are compiled in 32-bit mode, while 64-bit was used at IPC 2011. The main differences between 32- vs. 64-bit mode are as follows:

  • 64-bit mode is faster than 32-bit mode (in our limited experiments typically by a factor of ~1.1)
  • 64-bit mode needs more memory than 32-bit mode (in our limited experiments typically by a factor of ~1.5)
  • 64-bit mode can use essentially unbounded amounts of memory, while 32-bit mode can only use 3 GB of user space memory (on typical Linux systems -- numbers may differ on other operating systems and depending on kernel options)

In our experiments, the memory advantage of 32-bit mode tends to outweigh the speed disadvantage, which is why we enable 32-bit mode by default. See http://issues.fast-downward.org/issue213 for details. However, for memory limits substantially beyond 4 GB, you should use 64-bit mode due to the address space limitations of 32-bit mode.

To enable 64-bit, change all occurrences of -m32 in src/search/Makefile to -m64.

Other questions?

Please get in touch! See the HomePage for various contact options.

FastDownward: PlannerUsage (last edited 2023-10-12 12:14:59 by GabiRoeger)