Ignoring a requirement to serialize operations

[fdouglis]

I posted a comment yesterday on #13 regarding concurrency, but in order not to hijack the issue, and because I've now tried to create a minimal use case, posting a new one here.

I'm trying to create a plan that has durations and a limited number of things it can do in parallel. No matter what I try, SMTPlan either says it should all go in parallel, or it hangs and runs forever, or reports the plan is unsolveable. It's quite possible this is an error on my part in the PDDL, or maybe I'm tweaking some issue in the planner. To its credit, SMTPlan is the one thing I find that even comes close --- most in planutils simply dump core or complain!

The idea is to have a count of things that are OK to operate on, aggregated into pools (in this case I have a single "object-group" but there would be more). There's a check per object group that at all times, including after the start of the action with the start effect decrementing this count, the count should be > 0. So if I have 3 things, I expect it to operate on 2, wait 5 seconds, and operate on the 3rd. Instead the plan does all 3 at once.

Here is the simplified domain.

        (domain showbug)
        (:requirements :durative-actions :fluents :action-costs :negative-preconditions)
        (:functions
         (num-objects-unselected ?og)
         )
        (:predicates
                (object-group ?og)
                (object ?o)
                (object-in-group ?o ?og)
                (object-selected ?o)
        )
        (:durative-action select-object
                :parameters (?o ?og)
                :duration (= ?duration 5)
                :condition  (and
                             (at start (object ?o))
                             (at start (object-group ?og))
                             (at start (object-in-group ?o ?og))
                             (at start (not (object-selected ?o)))
                             (at start (> (num-objects-unselected ?og ) 0))
                             (over all (forall (?og2) (> (num-objects-unselected ?og2 ) 0)))
                           )
                :effect (and (at start (decrease  (num-objects-unselected ?og) 1))
                             (at end (object-selected ?o))
                             (at end (increase  (num-objects-unselected ?og) 1))
                             )
        )
)

And the problem instance:

        (problem showbug)
        (:domain showbug)
        (:objects
                o1 o2 o3 og1
        )
        (:init (object o1) (object o2) (object o3) (object-group og1)
               (object-in-group o1 og1) (object-in-group o2 og1) (object-in-group o3 og1)
               (= (num-objects-unselected og1) 3)
        )
        (:goal (and (object-selected o1) (object-selected o2) (object-selected o3)
               ))
)

The plan selects all three in parallel:

0.0:	(select-object o1 og1) [5.0]
0.0:	(select-object o2 og1) [5.0]
0.0:	(select-object o3 og1) [5.0]

In my original domain, it was like this but with a bunch more moving parts, and I tried creating 3 groups of 4, 4, and 2 objects respectively. I also added a counter for the total number of things selected over time. If I simply output that number (i.e. viewed it in debug mode as it was updated) I could see that the number updated was not reflecting that all were run at once. It was as though each one updating it started with the initial value at time T and changed it by 1, even if others were changing it at the same timestamp.

Any thoughts welcome, whether they are about the planner (which seems to have a bug) or my problem (which could certainly have a bug) would be appreciated!