6610
Comment:
|
8204
fix link
|
Deletions are marked like this. | Additions are marked like this. |
Line 5: | 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. | 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 root directory of the repository. The driver script also assumes that the planner is built in the directory {{{builds/release32}}} were the script {{{./build.py}}} will create it by default. See the [[ObtainingAndRunningFastDownwardcmake#Compiling_the_planner|compilation instructions]] for how to create other builds and [[#Different_builds]] for how to run them. |
Line 11: | Line 11: |
We recommend using the {{{src/fast-downward.py}}} script for running Fast Downward. It supports running all three planner steps or a subset of them and automatically chooses the right steps depending on the given input. To see the list of options run | We recommend using the {{{fast-downward.py}}} driver script for running Fast Downward. It supports running all three planner steps or a subset of them and automatically chooses the right steps depending on the given input. To see the list of options run |
Line 16: | Line 16: |
=== Different builds === 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 [[ObtainingAndRunningFastDownwardcmake#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}}}. '''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. |
|
Line 26: | Line 34: |
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 [[http://hg.fast-downward.org/file/tip/src/search/utilities.h|src/search/utilities.h]] and [[http://hg.fast-downward.org/file/tip/src/driver/portfolio_runner.py|src/driver/portfolio_runner.py]]. | 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 [[http://hg.fast-downward.org/file/tip/src/search/utilities.h|src/search/utilities.h]] and [[http://hg.fast-downward.org/file/tip/driver/portfolio_runner.py|driver/portfolio_runner.py]]. |
Line 129: | Line 137: |
To enable 64-bit, compile the planner with the option {{{DOWNWARD_BITWITH=64}}}, e.g. by running | 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: |
Line 131: | Line 139: |
./build_all distclean ./build_all DOWNWARD_BITWIDTH=64 |
mkdir -p builds/manual_64_bit_build cd builds/manual_64_bit_build cmake -DALLOW_64_BIT=TRUE -DCMAKE_CXX_FLAGS="-m64" ../../src make |
Line 134: | Line 144: |
in the {{{src}}} directory. (If VAL is not currently compiled, the first line may give you an error, which you can ignore.) |
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 root directory of the repository. The driver script also assumes that the planner is built in the directory builds/release32 were the script ./build.py will create it by default. See the compilation instructions for how to create other builds and #Different_builds for how to run them.
If you want to run any of the planners based on Fast Downward that participated in IPC 2011, please also check IpcPlanners.
Driver script
We recommend using the fast-downward.py driver script for running Fast Downward. It supports running all three planner steps or a subset of them and automatically chooses the right steps depending on the given input. To see the list of options run
./fast-downward.py --help
Different builds
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 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.
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.
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:
Code |
Meaning |
0 |
OK: translation/preprocessing successful |
1 |
Critical error: something went wrong (e.g. translator/preprocessor 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 |
Translation successful/Preprocessing successful/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. |
Below are the instructions for running individual steps without the driver script.
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.
Preprocessor
preprocess/preprocess < OUTPUT.SAS
OUTPUT.SAS (filename): translator output
Note: Creates a file called output.
Search component
search/downward OPTIONS < OUTPUT
OPTIONS: Examples below. See OptionSyntax and Doc/Overview for details.
OUTPUT (filename): preprocessor output
Examples
A* search
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 output \
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 output \
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 output \
15 --heuristic "hcea=cea()" \
16 --search "lazy_greedy(hcea, preferred=hcea)" \
17
LAMA 2011
./fast-downward.py --alias seq-sat-lama-2011 output
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.