Action%20Planning%20for%20Graph%20Transition%20Systems - PowerPoint PPT Presentation

About This Presentation
Title:

Action%20Planning%20for%20Graph%20Transition%20Systems

Description:

Department of Informatics, University of Pisa, Pisa, Italy ... Existential quantifier can again be used .. (:goal (exists ?v0 ?v1 ?v2 ?v3 ?v4 ?v5 - node) ... – PowerPoint PPT presentation

Number of Views:38
Avg rating:3.0/5.0
Slides: 23
Provided by: sha8155
Category:

less

Transcript and Presenter's Notes

Title: Action%20Planning%20for%20Graph%20Transition%20Systems


1
Action Planning for Graph Transition Systems
  • Stefan Edelkamp
  • Shahid Jabbar
  • Computer Science Department
  • University of Dortmund, Dortmund, Germany
  • Alberto Lluch-Lafuente
  • Department of Informatics, University of Pisa,
    Pisa, Italy

2
Graph Transition Systems
3
Graph Transition Systems
  • A graph transition system (GTS) is a pair ltM,ggt,
    where
  • M is a weighted transition system and
  • g is a partial graph morphism.
  • The weights of a transition system is modeled by
    a generalize cost-algebra based on monoids
    structure.
  • See Edelkamp, Jabbar, and Lafuente,
    Cost-Algebraic Heuristic Search, in Proc. of 20th
    National Conference on Artificial Intelligence
    (AAAI05), July 2005, Pittsburgh, PA. (to
    appear). for more details.
  • Applications Biology Changing molecular
    structure, Networks Clients appearing and
    disappearing.

4
Objectives
  • How to model and check GTS?
  • How to encode the application of partial graph
    morphism?
  • How to deal with flexible goals?
  • How to guide the search process?
  • Solution Model the problem of checking graph
    transition systems in PDDL and use planning
    heuristics to guide the search process.

5
Outline
  • Arrow Distributed Directory Protocol An example
    of GTS.
  • PDDL Encoding of Arrow Distributed Directory
    Protocol.
  • Experimental Results
  • Performance Planner vs. Model Checker
  • Scaling behavior of the model
  • Conclusions

6
Directory Service Protocol
  • Assume a distributed environment.
  • Clients The nodes in the distributed network
    e.g., different computers.
  • Mobile Objects
  • Could be a file, a process or any other data
    structure.
  • It can be transmitted over a network from one
    node to another.
  • It lives only on one node at a time.
  • Purpose of a Directory Service
  • Navigation To provide the ability to locate a
    mobile object.
  • Synchronization To ensure mutual exclusion in
    the presence of concurrent requests.

7
Usual Approach
  • home-based structure.
  • Each object has its own home.
  • home keeps track of the objects location.
  • All requests are send to the home.
  • home sends a message to the client currently
    holding the object.
  • That client forwards the object to the requesting
    client.
  • Bottleneck Communication costs between home
    and clients.

8
The Arrow Distributed Directory Protocol (Demmer
and Herlihy)
  • Based on the idea of a trail of pointers
  • Distributed Network G (V,E,w)

v
z
u4
u1
u2
u3
u
w
o
9
Properties of the Protocol
  • If link(v) v (self-loop) gt The object either
    resides at v, or will soon reside at v.
  • Else, the object resides some where in the region
    of the directory containing link(v).

link(v) w
o
v
w
10
Messages and Constructs
  • link(u,v) Defines the spanning tree.
  • find(v) Request for the object issued by the
    node v.
  • move(v) The object is free to be moved to v. It
    travels with the object, following the links in
    the original graph.
  • pending(u,v) Every link(u,v) has a buffer that
    keeps the request. Not a FIFO, but reliable.
  • queue(u) v, NULL A predicate attached with
    every node. Tells that u has to transfer the
    object to v when it is finished with the object.

11
Working of the Protocol
  • v issues a request find(v) for the object.

find(v)
o
move(v)
u issues move(v) when it is finished with the
object
The object is moved to v following the shortest
path in G (blue edges)
A queue predicate is declared for v queue(u) v
find(v) inserted in the pending buffer
12
Concurrent Requests
  • find(v) stuck in the communication channel.
  • w also issues a request in the meanwhile.

queue(v) w
queue(z) v
find(z)
ws request would be diverted to v instead
find(v) stuck in the com. channel
find(v)
z also issues a request
All future requests will be forwarded to w
o
find(v) released
queue(u) z
find(w)
Object Path u z v - w
13
Advantages
  • A distributed queue structure.
  • Object request messages travel the shortest path
    in the spanning tree and not in the original
    graph.
  • The queue structure ensures locality all
    requests will go directly to the object or to
    another terminal. Do not have to pass through a
    home.

14
Properties to Verify / Types of Goals
  • Can a particular node u be a terminal? (Subgraph
    matching)
  • Can a particular node u be a terminal and all
    arrow paths end at u? (Graph Matching)
  • Can an arbitrary node ui be a terminal? (Subgraph
    isomorphism)
  • Can an arbitrary node ui be a terminal and all
    arrow paths end at ui? (Graph isomorphism)

15
Part IIPDDL Encoding
16
PDDL Encoding Morphism as PDDL Actions
  • A morphism operation that inverses an edge can
    easily be defined as a very simple action.
  • (action morphism-inverse
  • parameters(?u ?v - node)
  • precondition
  • (link ?u ?v)
  • effect
  • (and
  • (not (link ?u ?v))
  • (link ?v ?u)))

17
PDDL Encoding of Goals Graph and Subgraph
Matching.
  • Subgraph and graph matching are easy to encode.
  • Encode the goal graph with (link u v)
  • and owner with (owner w) predicates.

18
PDDL Encoding of Goals Subgraph Isomorphism
  • Goals are strictly more expressive.
  • Need an existential quantification over all the
    nodes to be described.
  • ADL (Pednault 1989) ?
  • (goal ltexistential-expressiongt
  • ltgoal-conditiongt)
  • Using ADL, subgraph isomorphism can be encoded as
  • (goal (exists (?n - node) (owner ?n)))

19
PDDL Encoding of Goals Graph
Isomorphism
  • Existential quantifier can again be used ..
  • (goal (exists ?v0 ?v1 ?v2 ?v3 ?v4
  • ?v5 - node)
  • (and (link ?v0 ?v0) (link ?v1 ?v0)
  • (link ?v2 ?v0) (link ?v3 ?v1)
  • (link ?v4 ?v0) (link ?v5 ?v4)
  • (owner ?v3)))

20
Performance Model Checker(HSF-Spin) vs. Planner
(FF) Subgraph Matching
Star DFS BFS hf EHC RPH
Stored nodes 6,253 30 6
Sol. length 134 58 5
Chain DFS BFS hf EHC RPH
Stored nodes 78,112 38 6
Sol. length 118 74 5
Tree DFS BFS hf EHC RPH
Stored nodes 24,875 34 6
Sol. length 126 66 5
21
Scaling Behavior of the Model
Topology Nodes Stored Plan Length
Star 10 6 5
Star 25 7 6
Star 50 7 6
Star 70 7 6
Chain 10 6 5
Chain 25 33 28
Chain 50 100 73
Chain 70 138 101
Tree 10 6 5
Tree 25 22 16
Tree 50 47 25
Tree 70 61 31
1.9 GB
22
Conclusions
  • First such efforts to model GTS with PDDL.
  • Advantages Planning heuristics can be employed
    directly.
  • Successfully modeled Arrow Distributed Directory
    Protocol.
  • Still some limitations in modeling the
    full-fledged specification of GTS.
  • Dynamic insertions and deletions of nodes and
    edges.
  • Can be circumvented to some extent by using a
    pool of available objects.
Write a Comment
User Comments (0)
About PowerShow.com