Composing Models of Computation in Kepler/Ptolemy II

1. Composing Models of Computation in Kepler/Ptolemy II Antoon Goderis U of Manchester (myGrid/ Taverna) Christopher Brooks UC Berkeley (Ptolemy II) Ilkay Altintas UC San Diego (Kepler) Edward A. Lee UC Berkeley (Ptolemy II) Carole Goble U of Manchester (myGrid/Taverna)

2. The talk • Models of Computation (MoCs) • Use cases from science • PtolemyII/Kepler • Composing Models of Computation • Use cases from science • PtolemyII/Kepler • Conditions for valid (hierarchical-) compositions • Example based on process networks and data flow • Table of valid compositions

3. Use cases for different MoCs To model scientific problems naturally • Biology: Gene annotation pipelines • [Dataflow] for pipeline compositions • Fluid dynamics: Lattice-Boltzmann simulations • [Continuous-time based ordinary differential equation solvers]

4. Models of Computation Thomas Kuhn, originator ofthe paradigm paradigm • What is a component? (ontology) • States? Processes? Threads? Differential equations? Constraints? Objects (data + methods)? • What knowledge do components share? (epistemology) • Time? Name spaces? Signals? State? • How do components communicate? (protocols) • Rendezvous? Message passing? Continuous-time signals? Streams? Method calls? Events in time? • What do components communicate? (lexicon) • Objects? Transfer of control? Data structures? ASCII text?

5. Exploring Models of Computation… … for scientific computing Ptolemy II Kepler

6. Scientific workflow design and re-use • Support design & re-use viaseparation of concerns • Structural data types • Semantic types • Type checking • Structure • Execution semantics

7. What flows through an object is sequential control class name data methods call return PtolemyII/Kepler: Actor-Oriented Design Object orientation: Actor orientation: What flows through an object is streams of data actor name data (state) parameters Input data Output data ports

8. Structure of PtolemyII/Kepler workflows • HierarchicalEntities, Ports, Connections and Attributes Syntax defines the structure of a workflow, but says little about what it means.

9. Execution semantics: Director • Implements the model of computation • Governs the execution of an actor (workflow) • Scheduling, dispatching threads, etc.

10. Survival of the fittest is the onlyreasonable way to choose among these. Implemented Models of Computation • PN – process networks • SDF – synchronous dataflow • DDF – dynamic dataflow • FSM – finite state machines • CT – continuous-time modeling • DE – discrete-event systems • SR - Synchronous/Reactive systems • RendezVous – concurrent threads with rendezvous • GR – graphics • … Each of these defines a component ontology and an interaction semantics between components. There are many more possibilities! In use in Kepler Available in Kepler Realized in Ptolemy II

11. The talk • Models of Computation (MoCs) • Use cases from science • PtolemyII/Kepler • Composing Models of Computation • Use cases from science • PtolemyII/Kepler • Conditions for valid (hierarchical-) compositions • Example based on process networks and data flow • Table of valid compositions

12. Use cases for composing MoCs (1) • Intra-disciplinary collaboration • Biology: gene annotation to systems biology [data flow + cont time] • Inter-disciplinary collaboration • Chem- to bio-informatics [cont time + data flow] • Mix software workflows with physical systems • sensor networks and electron microscopes [cont time] • Performance of computation-intensive workflows • visualization [3D animation]

13. Use cases for composing MoCs (2) • Mix workflow management with running models for analysis or simulation • Biology: selective extraction and analysis of proteins from public databases [finite state machines + dataflow] • Fluid dynamics: dynamically adapting model control parameters of Lattice-Boltzmann simulations [finite state machines + cont time] • Integrated provenance collection • Include dynamic changes in the overall model as well as parameter sweeps within each model

14. MoC composition in chemistry Actor/workflow based on Synchronous Data Flow Actor/workflow based on Kahn Process Network

15. How to compose MoCs (directors)? • No classification exists to determine which director combinations are valid

16. How to compose MoCs (directors)? • No classification exists to determine which director combinations are valid • We need to know two things about a director: • What properties it exports via the composite actor in which it is placed

17. Inner directorexports certain properties

18. How to compose MoCs (directors)? • No classification exists to determine which director combinations are valid • We need to know two things about a director: • What properties it exports via the composite actor in which it is placed • What properties it requires of the actors under its control

19. outer director requires certainproperties

20. If a director’s exported properties match those required by another director, then it can be used within that other director

21. So, what are these properties? It turns out we can determine director compatibility based on three levels of adherence to actor abstract semantics

22. Actor Abstract Semantics • iterate() • prefire() • fire() • postfire() Flow of control • Initialization • Execution • Finalization Specifications: • prefire(): synchronizes to the environment and checks firing conditions • fire(): generates outputs based on current inputs and states • postfire(): updates the states for next iteration

23. Three flavours of actor semantics

24. Compatible director compositions exported abstract semantics should be stricter than or equal to required abstract semantics

25. Example: composing PN and SDF • Kahn Process Networks • Asynchronous communication between processes; thread for each actor. • PN director does not require that any method eventually returns. The methods run in a separate thread belonging entirely to the actor. • PN does not guarantee that any method eventually returns. • Synchronous Data Flow • Director “fires” actors when input tokens are available. • SDF director requires that methods return. The fire() method can change state. • SDF director guarantees that methods return.

26. Determining PN and SDF compatibility exported abstract semantics should be stricter than or equal to required abstract semantics

27. Determining PN and SDF compatibility exported abstract semantics should be stricter than or equal to required abstract semantics

28. SDF inside PN example Actor/workflow based on Kahn Process Network PN requires loosestabstract actor semantics

29. SDF inside PN example Actor/workflow based on Synchronous Data Flow SDF exports looseabstract actor semantics

30. SDF inside PN example Actor/workflow based on Synchronous Data Flow Actor/workflow based on Kahn Process Network SDF exports loosePN requires loosest, so OK to combine

31. FSM very flexible CT (continuous dynamics) works well as inner director PN very inflexible Living document: http://www.mygrid.org.uk/wiki/Papers/IccsPaper2007 The others

32. Summary • A need for multiple models of computation, and their composition, in e-science • Practical table of valid compositions for models of computation in PtolemyII/Kepler • Questions? • E-mail: goderisa@cs.man.ac.uk

33. Xie Xie • Bertram Ludaescher, UC Davis, Kepler • Gang Zhou and Thomas Feng, UC Berkeley, PtolemyII • John Brooke, U Manchester