Concurrent actions and processes

[pschydlo]

Hi,

According to the PDDL+ specifications, it seems to me that processes and actions are intended to run concurrently if the sets of predicates involved are disjoint.

When defining a simple process, which I was hoping would be able to run concurrently while other actions are executing, this does not seem to happen.

(define (domain kitchen)
(:requirements :durative-actions :time )

(:predicates 
    (oven_on) 
    (in_oven ?item) 
    (cooked ?item)
    (in ?container ?liquid)
    (liquid ?liquid)
    (container ?container)                                              
)

(:functions (temp ?item))

(:action place_oven
  :parameters(?item)
  :precondition ()
  :effect (and (in_oven ?item))
)

(:action turn_on_oven
  :parameters()
  :precondition()
  :effect (and (oven_on))
)

(:process cooking
:parameters (?item)
:precondition (and 
                (oven_on) 
                (in_oven ?item))
:effect (and (increase (temp ?item) (* #t 1)))
)   

(:event finished_cooking
:parameters (?item)
:precondition (and (oven_on) (in_oven ?item) (>= (temp ?item) 45))
:effect (cooked ?item)
)

(:action pour
        :parameters 
            (?liquid
             ?container1
             ?container2)
        :precondition 
            (and 
                (liquid ?liquid)
                (container ?container1)
                (container ?container2)
                (in ?container1 ?liquid)
            )

        :effect 
            (and 
                (not (in ?container1 ?liquid))
                (in ?container2 ?liquid)
            )
 )    
)

With the problem of reaching:

(define (problem kitchen_prob)

    (:domain 
        kitchen    
    )
    
    (:objects
        cookie
        cup
        jug
        milk
    )
    
    (:init
        (= (temp cookie) 0)
        (in jug milk)
        (liquid milk)
        (container cup)
        (container jug)
    )
    
    (:goal
        (and 
            (cooked cookie)
            (in cup milk)
        )
    )
    (:metric minimize ( total-time ))
)

I have the following plan execution:

4.0: (place_oven cookie) [0.0]
4.0: (turn_on_oven) [0.0]
49.0: (pour milk jug cup) [0.0]

Here I was expecting the milk to be poured while the cookie is cooking, yet the milk is only poured after the cooking time (45s). Does SMTPlan support concurrent actions?

Thank you for any clarifications which you may be able to help me with!

[Gyoko]

The problem is that SMT does not support optimization, unless it has an OMT extension. SMTPlan doesn't understand (:metric minimize ( total-time )). In other words, the planner will produce you a solution, if it exists, but there's nothing forcing it to give you the best one.
That being said, devs mentioned that they will add metrics in the future.

[fdouglis]

I have a related question. I was unaware before seeing this that SMTPlan doesn't support minimizing a metric (though perhaps that has been added since -- it doesn't complain, anyway, but I also don't really see evidence of minimization).

But regarding the concurrent actions, I have the opposite problem. If I have a durative action that decreases a value at the start, increases it at the end, and expects it to be above some value at all times, then I expect that to limit the number of concurrent activities that will take this action. But with SMTPlan, when I output the debugging state, I can see that it is setting the value as if only a single action is updating it. That is what I would anticipate if there were no concurrency control: when it operates on C1 and C2, say, it starts with 2, decreases it to 1 for C1, and then seems to start with 2 and decrease it to 1 for C2 as well. It says the value at that time is 1 (not 0).

From all the documentation I've seen, PDDL is supposed to detect concurrency and keep multiple objects from accessing the same fluent at the same time. So I'm wondering if SMTPlan is not doing what is expected. I note that I've tried maybe a half dozen other planners on the same domain, and they all die in various ways, whereas SMTPlan generates a plan, just not one I think actually solves the problem!