Compiler returns no solution

[SamButers]

Hello there.
I have been using PDDL.jl together with the SymbolicPlanners with great results, but, for some reason, I can't get to use the compiler to execute and solve problems with my domain. So I have been wondering if there is any limitation that might be causing the issue.

I do not get an error while running it, but I get no result despite running it on problems that return me a solution under a second or less. This gist has an example of a problem that returns a solution at around 12 seconds, but that doesn't seem to return anything, as far as I have observed, using the compiler.

[ztangent]

Glad the library has been useful!

Are you using the stable version of PDDL.jl, or the the latest development version from GitHub? I recently made a few fixes to the compiler to handle nested forall effects, and it's possible that's what the issue. Maybe you could try updating to the the development version, and see if it works?

(I'll also release a new stable version of PDDL.jl now with the new changes -- it was on my to-do list but slipped my mind.)

[SamButers]

I was using the stable one (v0.2.13), but updated it to the dev one (v0.2.14) to test it since you mentioned the fix you added. Unfortunately the issue still persists.

[SamButers]

I have been testing some stuff and got to notice that when using the compiler, the planner gets stuck at the expand function. More especifically, it seems like it doesn't reach this line.

[ztangent]

Very strange! I unfortunately won't have the chance to try and debug this over the next week, but I'll try and come back to it after that. Let me know if you any updates in the mean time.

[SamButers]

Just passing by to inform that I wasn't able to debug it too much.
What I was able to tell is that the problem seems to be related to the actions flattened array. I wasn't able to iterate over it nor do operations like collect (which I assume iterates over it). Unfortunately, I'm not too well acquainted with Julia, so not sure if that is a simple or complex issue.

[ztangent]

So I've looked at this a bit more closely, and I suspect the problem may have to do with a type mismatch between the PDDL problem file and the PDDL domain. In your problem definition, all objects have the type block, but the domain's actions expect the first argument/object to have the type matching-block. The PDDL.jl interpreter is sometimes a bit lax when checking these type conditions, but what may be happening is that because there are no objects of type matching-block in the problem, the compiled domain always returns an empty list when you run available(domain, state) to list the set of available actions.

An alternative hypothesis as to what's going on might be that there are simply too many action parameters, which the PDDL.jl compiler doesn't handle well (as currently written). Whereas the PDDL.jl interpreter uses Julog.jl to dynamically determine which set of actions are available in the current state, the compiler just naively enumerates over the Cartesian product of all possible arguments in order to check which actions are available. This actually turns out to be quite fast on smaller problems, but it doesn't scale well to problems with a lot of objects, and a lot of action parameters. If that's what's happening, then calling available(domain, state) may take forever to terminate on a large problem when using a compiled domain, but will be fine for smaller problems with less objects.

[SamButers]

Hello again. Thanks for the response.

Well, as far as I'm aware, there are matching-block objects in the problem I shared and the rest of the problems. I even double-checked to see if I had done a mistake regarding that.

As to the latter hypothesis, I think it could be a possible reason, although the problem occurs in small and big problems alike. And the problems don't happen when I try to call the available function, since I actually get a return from it. The problem occurs when trying to iterate over it.

[ztangent]

Yup, for compiled domains you should only see issues when you actually try to iterate over the return value of available, because it's a "lazy" iterator.

Just noticed the matching-block objects in the problem file, so you're right that that's probably not the issue. How small are the small problems that you've tried? I would try a problem with just one or two regular blocks, and one or two matching blocks, to see whether that works.

[SamButers]

Oh, I see, that makes sense then.

The smallest problem has around 25 blocks, 2 of them being matching blocks. I will create a minimum size and complexity problem and see if the results change. I will send an update as soon as it is done.

[helen-of-troy]

One can do a Google search of “pddl nested when”.

One of the search results is KCL-Planning/VAL#22 entitled Domain with nested conditional rejected with error "Problem in domain definition!", status closed.

Let me summarize: PDDL is essentially what people agree it is. Some planners support nested when; others don’t. VAL does not.