Issue165

Title performance issue in translator (with negative preconditions code?)
Priority bug Status chatting
Superseder Nosy List gabi, malte, patrik, thofmann
Assigned To Keywords translator
Optional summary

Created on 2010-12-17.23:45:04 by malte, last changed by sprabhu.

Files
File name Uploaded Type Edit Remove
6-cups.pddl thofmann, 2014-10-13.17:01:33 application/octet-stream
bw-no-clear.pddl malte, 2010-12-17.23:45:17 application/octet-stream
bwnc_10_1.pddl malte, 2010-12-17.23:45:27 application/octet-stream
bwnc_5_1.pddl malte, 2010-12-17.23:45:33 application/octet-stream
clean_up_cups_domain.pddl thofmann, 2014-10-13.17:01:07 application/octet-stream
crash-test-dummy.pddl malte, 2010-12-17.23:45:01 application/octet-stream
graph-domain.pddl sprabhu, 2017-01-25.06:15:47 application/octet-stream
graph-prob.pddl sprabhu, 2017-01-25.06:16:12 application/octet-stream
translate.profile thofmann, 2014-10-13.17:01:40 application/octet-stream
Messages
msg3809 (view) Author: thofmann Date: 2014-10-13.17:01:07
We are having similar issues with the translator which seem to be related to
this bug. I've attached a domain (clean_up_cups_domain.pddl) and a problem
(6-cups.pddl) where the issue occurs. The translator uses >16GB of memory when
run with the given problem. I've also attached a profile generated with cProfile.

Note that the example is taken from an application, so it's probably not the
shortest example (although I've tried to clean it up a bit).
msg894 (view) Author: malte Date: 2010-12-17.23:45:01
Not sure if I should classify this as a "bug" since it looks like the code
works, but for Patrik's example it's unusable, and we tend to classify serious
performance issues as bugs too so that they get addressed more quickly that
"feature" or "wish" issues. 

Background:

This is from an old (June 2009) bug report by Patrik (sorry, some context is
missing):

=======================================================================
Attached (domain: crash-test-dummy, problem: bwnc_10_1). It doesn't
crash anymore because I fixed it too (by replaxing "axiom.name" with
"axiom", which produces a totally useless printout like "Removed axiom:
<sas_tasks.SASAxiom instance at 0xb7b3078c>" but at least doesn't crash).

There may be some other problems as well. I tested the the blind search
planner (I think: it's option "ob" to downward/search, right?), and it
claims to have exhausted the space after expanding one node, i.e., the
initial state has no applicable actions). But I don't think that's
right. Also attached is an alternative formulation (bw-no-clear) of the
domain, which I think is equivalent, and can be fed to my parser. Other
planners I've tried (some hsp* variants, ff) explore more than one node
(ff even finds a solution, for both domain formulations).
=======================================================================

This bug does not exist any more; this was fixed when Gabi implemented proper
support for negative conditions. However, Patrik's example now triggers a
performance issue, which I think comes from the "multiply out conditions" code.

Patrik's original 10-block problem fails to translate because it exhausts 3 GB
of memory. It bails out with a memory error in "multiply_out". This is with both
domain versions. I also created a smaller problem (5 blocks) which does
translate after a while, but it generates 25600 axiom rules, which looks a bit
excessive. :-)

So we may need to rethink some of our algorithm choices here.
History
Date User Action Args
2017-01-25 06:16:12sprabhusetfiles: + graph-prob.pddl
2017-01-25 06:15:47sprabhusetfiles: + graph-domain.pddl
2014-10-13 17:01:40thofmannsetfiles: + translate.profile
2014-10-13 17:01:33thofmannsetfiles: + 6-cups.pddl
2014-10-13 17:01:07thofmannsetfiles: + clean_up_cups_domain.pddl
nosy: + thofmann
messages: + msg3809
2014-10-04 19:33:27maltesetkeyword: + translator
2010-12-17 23:45:33maltesetfiles: + bwnc_5_1.pddl
2010-12-17 23:45:27maltesetfiles: + bwnc_10_1.pddl
2010-12-17 23:45:17maltesetfiles: + bw-no-clear.pddl
2010-12-17 23:45:04maltecreate