Differences between revisions 56 and 57
⇤ ← Revision 56 as of 2016-12-21 14:57:34 →
Size: 7699
Editor: MalteHelmert
Comment: Try simplifying the documentation a bit (work in progress, to be continued soon).
← Revision 57 as of 2016-12-21 15:40:39 → ⇥
Size: 6728
Editor: MalteHelmert
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
Before running Fast Downward, you must [[ObtainingAndRunningFastDownward#Compiling_the_planner|build it]]. Before running Fast Downward, you must [[ObtainingAndRunningFastDownward#Compiling_the_planner|build it]] using the {{{build.py}}} script.
Line 15: Line 15:
=== Different builds === == Different builds ==
Line 17: Line 17:
The driver script assumes that there is a directory {{{builds}}} containing one subdirectory for each build configuration. The script {{{./build.py}}} can create them for some typical builds and you can create your own with a [[ObtainingAndRunningFastDownward#Manual_Builds|manual build]]. To choose a different build, pass the parameter {{{--build=<name>}}} to the driver script. The default name is {{{release32}}} and the parameter {{{--debug}}} is an alias for {{{--build=debug32}}}. Different builds of Fast Downward (e.g. 32-bit vs. 64-bit, release vs. debug) are placed in different directories by the build script. Hence, several builds can coexist and {{{fast-downward.py}}} must be told which build to use. By default, the {{{release32}}} build is used, which is also the default build produced by {{{build.py}}}. To use a different build, pass {{{--build=<name>}}} to the driver script. The parameter {{{--debug}}} is an alias for {{{--build=debug32 --validate}}}.
Line 19: Line 19:
'''Note on IDE projects (Visual Studio, XCode)''': You can use the CMake build system to generate a project for you favourite IDE. These projects are what CMake calls "multi-config generators", i.e., they are created without fixing the build configuration. During build-time, the IDE decides whether to do a debug or release build and creates subdirectories in the output folder. Use the full path to the binaries as the value of {{{--build}}} (e.g., {{{--build=path/to/visual/studio/project/bin/Debug/}}}), or run the components individually without the driver script. '''Note on IDE projects (Visual Studio, XCode)''': You can use the CMake build system to generate a project for you favourite IDE. These projects are what CMake calls "multi-config generators", i.e., they are created without fixing the build configuration. At build time, the IDE decides whether to do a debug or release build and creates subdirectories in the output folder. Use the full path to the binaries as the value of {{{--build}}} (e.g., {{{--build=path/to/visual/studio/project/bin/Debug/}}}).
Line 21: Line 21:
== Exit codes ==
Line 22: Line 23:
=== Exit codes ===

The driver exits with 0 if no errors are encountered. Otherwise, it returns the exit code of the first component that failed. The translator and preprocessor exit with the following codes: 		The driver exits with 0 if no errors are encountered. Otherwise, it returns the exit code of the first component that failed. The translator exits with the following codes:
Line 27: Line 26:
|| 0 || OK: translation/preprocessing successful ||
|| 1 || Critical error: something went wrong (e.g. translator/preprocessor bug, but also malformed PDDL input) ||		 || 0 || OK: translation successful ||
|| 1 || Critical error: something went wrong (e.g. translator bug, but also malformed PDDL input) ||
Line 34: Line 33:
|| 0 || EXIT_PLAN_FOUND || Translation successful/Preprocessing successful/Solution found || || 0 || EXIT_PLAN_FOUND || Solution found ||
Line 44: Line 43:
Below are the instructions for running individual steps without the driver script. == Examples ==
Line 46: Line 45:
== 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 [[TranslatorOutputFormat|output.sas]].
== Preprocessor ==

{{{
preprocess/preprocess < OUTPUT.SAS
}}}

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

Note: Creates a file called [[PreprocessorOutputFormat|output]].

<<Anchor(search)>>
== Search component ==

{{{
search/downward OPTIONS < OUTPUT
}}}

 * `OPTIONS`: Examples below. See OptionSyntax and [[Doc/Overview]] for details.
 * `OUTPUT` (filename): preprocessor output

=== Examples ===

==== A* search ====		 === A* search ===
Line 84: Line 49:
 ./fast-downward.py output --search "astar(lmcut())"  ./fast-downward.py domain.pddl task.pddl --search "astar(lmcut())"
Line 87: Line 52:
 ./fast-downward.py output --search "astar(ipdb())"  ./fast-downward.py domain.pddl task.pddl --search "astar(ipdb())"
Line 90: Line 55:
 ./fast-downward.py output --search "astar(blind())"  ./fast-downward.py domain.pddl task.pddl --search "astar(blind())"
Line 93: Line 58:
==== Lazy greedy best-first search with preferred operators and the queue alternation method ==== === Lazy greedy best-first search with preferred operators and the queue alternation method ===
Line 97: Line 62:
 ./fast-downward.py output \  ./fast-downward.py domain.pddl task.pddl \
Line 103: Line 68:
 ./fast-downward.py output \  ./fast-downward.py domain.pddl task.pddl \
Line 109: Line 74:
 ./fast-downward.py output \  ./fast-downward.py domain.pddl task.pddl \
Line 115: Line 80:
==== LAMA 2011 ==== === LAMA 2011 ===
Line 118: Line 83:
 ./fast-downward.py --alias seq-sat-lama-2011 output  ./fast-downward.py --alias seq-sat-lama-2011 domain.pddl task.pddl

Back to HomePage.

Usage

Before running Fast Downward, you must build it using the build.py script.

To run Fast Downward, use the fast-downward.py driver script. At minimum, you need to specify the PDDL input files and search options. The driver script has many options to do things like running portfolios, running only the translation component of the planner, using a non-standard build, running a plan validator and various other things. To see the complete list of options, run 

./fast-downward.py --help

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

Different builds

Different builds of Fast Downward (e.g. 32-bit vs. 64-bit, release vs. debug) are placed in different directories by the build script. Hence, several builds can coexist and fast-downward.py must be told which build to use. By default, the release32 build is used, which is also the default build produced by build.py. To use a different build, pass --build=<name> to the driver script. The parameter --debug is an alias for --build=debug32 --validate.

Note on IDE projects (Visual Studio, XCode): You can use the CMake build system to generate a project for you favourite IDE. These projects are what CMake calls "multi-config generators", i.e., they are created without fixing the build configuration. At build time, the IDE decides whether to do a debug or release build and creates subdirectories in the output folder. Use the full path to the binaries as the value of --build (e.g., --build=path/to/visual/studio/project/bin/Debug/).

Exit codes

The driver exits with 0 if no errors are encountered. Otherwise, it returns the exit code of the first component that failed. The translator exits with the following codes:

Code

Meaning

0

OK: translation successful

1

Critical error: something went wrong (e.g. translator bug, but also malformed PDDL input)

2

Usage error: wrong command line options

The search component and the portfolios can produce the exit codes listed below. In addition to the numbers we list the names of the exit codes as they are defined in src/search/utilities.h and driver/portfolio_runner.py.

Code

Name

Meaning

0

EXIT_PLAN_FOUND

Solution found

1

EXIT_CRITICAL_ERROR

Something went wrong that should not have gone 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. Only returned by portfolios.

8

EXIT_TIMEOUT_AND_MEMORY

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

Examples

   1 # landmark-cut heuristic
   2  ./fast-downward.py domain.pddl task.pddl --search "astar(lmcut())"
   3 
   4 # iPDB heuristic with default settings
   5  ./fast-downward.py domain.pddl task.pddl --search "astar(ipdb())"
   6 
   7 # blind heuristic
   8  ./fast-downward.py domain.pddl task.pddl --search "astar(blind())"

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  ./fast-downward.py domain.pddl task.pddl \
   3     --heuristic "hff=ff()" --heuristic "hcea=cea()" \
   4     --search "lazy_greedy([hff, hcea], preferred=[hff, hcea])" \
   5            
   6 
   7 ## using FF heuristic (previously: "fF")
   8  ./fast-downward.py domain.pddl task.pddl \
   9     --heuristic "hff=ff()" \
  10     --search "lazy_greedy(hff, preferred=hff)" \
  11            
  12 
  13 ## using context-enhanced additive heuristic (previously: "yY")
  14  ./fast-downward.py domain.pddl task.pddl \
  15     --heuristic "hcea=cea()" \
  16     --search "lazy_greedy(hcea, preferred=hcea)" \
  17

LAMA 2011

 ./fast-downward.py --alias seq-sat-lama-2011 domain.pddl task.pddl

runs the "LAMA 2011 configuration" of the planner. (Note that this is not really the same as "LAMA 2011" as it participated at IPC 2011 because there have been bug fixes and other changes to the planner since 2011. See IpcPlanners for more information.) Please also check the comments below on 32-bit vs. 64-bit mode. To find out which actual search options the LAMA 2011 configuration corresponds to, check the source code of the src/driver/aliases.py module.

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, use the build configurations release64 and debug64. For manual builds, call CMake with the option -DALLOW_64_BIT=TRUE and set up your build environment to compile for 64 bit (this depends on your system). For example, the following would work on Linux with gcc: 

mkdir -p builds/manual_64_bit_build
cd builds/manual_64_bit_build
cmake -DALLOW_64_BIT=TRUE -DCMAKE_CXX_FLAGS="-m64" ../../src
make

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)