Tour of Ptolemy II

If you are viewing this from within Vergil, the graphical editor for Ptolemy II, then many of the following links will open models that highlight the key features of Ptolemy II. If you are using an ordinary web browser, then you will see the XML definition of the models. To run the models in Vergil, click on the red triangle in the toolbar. The diagrams are fully editable, so feel free to explore. You can also access the complete list of demos and the summary of new capabilities . Contents:

Application Domain-Specific Modeling: Application Domain-specific modeling and design.
Heterogeneous Modeling: Mixing models of computation.
Basic Modeling Capabilities: Commonly used models of computation.
Modeling Infrastructure: Capabilities shared by all uses of Ptolemy II.
Actor Libraries: Useful libraries of actors.
Experimental: Demonstrations of less mature capabilities.

Application Domain-Specific Modeling

Ptolemy II can be used to build sophisticated application domain-specific modeling capabilities and frameworks. These frameworks can be packaged as separate executable applications (e.g. HyVisual or VisualSense) or accessed from within Ptolemy II. Here, we illustrate some such frameworks.

Modeling of wireless networks: WirelessSoundDetection (see also VisualSense introduction).
The wireless domain in Ptolemy II provides discrete-event modeling of wireless communication systems. It is useful for modeling and design of communication protocols, networking strategies, and applications such as sensor networks. The VisualSense package is a subset of Ptolemy II that includes the wireless domain and channel models plus domains that support the design of nodes in a wireless network. The WirelessSoundDetection example models a sound localization problem, where single sound source moves through a field of sound sensors. In the example, sound sensors detect the sound and communicate via a radio channel to a sensor fusion component that localizes the sound by triangulation. Two distinct channel models are used, one that models sound propagation and one that models radio communication.
Modeling of hybrid systems: StickyMasses (see also BouncingBall, FurutaPendulum, NewtonsCradleAnimated, and Hybrid Plant). Hybrid systems are a special case of modal models where finite-state machines (FSMs) are combined with the continuous-time models to get mixed continuous-time and discrete-event models. The StickyMasses example models a physical system consisting of two point masses on springs that stick together when they collide.
Stochastic hybrid systems: Noise (see also IncreasingRatePoisson, HysteresisWithRandomDelay, Brownian ).
Stochastic hybrid systems add random behavior to continuous-time models mixed with discrete events. The Noise (and Noise Spectrum , Sinusoid In Noise ) models show bandlimited Gaussian noise processe. IncreasingRatePoisson models spontaneous mode transitions governed by a Poisson process. The HysteresisWithRandomDelay example uses similar spontaneous mode transitions to model random delay in mode transitions. The Brownian example models a stochastic differential equation describing a random walk process.
Signal Processing: MaximumEntropySpectrum (See also LMSAdaptive, SynthesizedVoice, FourierSeries, and SoundSpectrum)
Ptolemy II includes an extensive library and models of computation suitable for digital signal processing, communication systems design, and image and video processing. The MaximumEntropySpectrum example shows spectral estimation of sinusoids in noise. It illustrates models the use of synchronous dataflow (SDF) for signal processing, and also shows many basic capabilities like hierarchical models, the Expression actor, and the signal processing actor library.

Heterogeneous Models

A particular capability of Ptolemy II is the ability to mix models of computation. These examples illustrate some of these capabilities.

Modal Models: ModalModel
A modal model is one whose behavior depends on its "mode" of operation. A modal model in Ptolemy II heterogeneously combines the finite state machine (FSM) domain combined hierarchically with other models. A state in the FSM represents a mode of operation, and can have a refinement that gives the behavior in that mode. The refinement can be another FSM or some other model using some other Ptolemy domain. The ModalModel example combines DE, FSM, and SDF to model a system where regularly sampled signals are perturbed by irregular events in time.
Mixed-Signal Modeling: SigmaDelta
This example shows how to combine continuous-time modeling with discrete-event modeling to get mixed-signal modeling. The example models a MEMS accelerometer where a digital circuit implements feedback control and A/D conversion (a design due to Mark Lemkin). (see also Switching Continuous )

Basic Modeling Capabilities

Many common models of computation have been implemented in Ptolemy II. This section illustrates some of them.

Synchronous Dataflow: Spectrum (See also MaximumEntropySpectrum, FourierSeries, and SoundSpectrum)
This example shows simple spectral estimation of the product of two sinusoids in noise. It illustrates models the use of synchronous dataflow (SDF) for signal processing, and also shows many basic capabilities like hierarchical models, the Expression actor, and the signal processing actor library. In SDF, the firing of actors is statically scheduled, and at the start of execution, boundedness and deadlock conditions are checked.
Continuous-Time Modeling: Lorenz (see also Lorenz with DifferentialSystem, SquareWave, Sinusoid)
This example shows a continuous-time nonlinear feedback system that exhibits chaotic behavior (this system is called a Lorenz attractor). It illustrates the continuous domain, which uses an underlying solver for ordinary differential equations and cleanly supports mixtures of discrete events and continuous-time signals.
Discrete-Event Modeling: Inspection (see also QueueAndServer, Router, and TimingParadox ).
This example shows a famous paradox in probability called the inspection paradox. It illustrates use of the discrete-event (DE) domain, where events occur on a time line and are processed chronologically. In this example, random data stimulates a model and statistics are collected and reported in various ways.
Event-Oriented Modeling with Ptera: CarWash with DE, Ptera and FSM (See also GameOfLife, TrafficLight).
The Ptera (Ptolemy Event Relationship Actor) domain is a discrete-event model of computation. A model in Ptera is represented with a graph of nodes and edges, where nodes represent events and directed edges between events represent scheduling relation. One or more events can be selected as initial events, which are scheduled at model time 0.0. When an event is fired, it possibly performs certain actions, and if there are outgoing edges from that event, the events at the end points of those edges are scheduled after non-negative delays. One or more events can also be selected as final events. The firing of final events causes the event queue to be emptied after their actions are performed, and therefore no more events can be processed.
Process Networks: OrderedMerge (see also NondeterministicMerge, QR).
The process networks (PN) domain follows the semantics given by Kahn and MacQueen in 1977 to get processes with their own threads of control that send messages to one another and achieve deterministic computation. The OrderedMerge example implements an example given by Kahn and MacQueen that calculates numbers whose prime factors are 2, 3, and 5, only, and produces them in an ordered sequence. As of version 5.0, we have extended this model of computation with a nondeterministic merge actor, illustrated in NondeterministicMerge.
Rendezvous: Barrier (see also ResourcePool, ResourcePool, WriteRegulator).
The rendezvous domain implements the classic communicating sequential processes (CSP) semantics introduced by Tony Hoare, with some extensions. In the CSP domain, every actor executes in its own thread, and communication is by rendezvous. The rendezvous domain supports conditional rendezvous (where an actor communicates nondeterministically with one of several other actors) and multi-way rendezvous (where an actor communicates simultaneously with all of several other actors). The Barrier example shows the use of multi-way rendezvous to achieve a classic concurrency design pattern called barrier synchronization.
Dynamic Dataflow: HanoiTower (see also Eratosthenes, IfThenElse, Loop, OrderedMerge, RandomWalk)
In dynamic dataflow (DDF) models, actors are fired in response to available input data. The schedule is dynamic and data dependent, and actors can change their production and consumption rates in each firing. Unlike synchronous dataflow, the DDF model of computation is Turing complete, and questions of deadlock and boundedness are undecidable. The HanoiTower example exploits this to give an algorithmic solution to the well-known towers of Hanoi problem.
Heterochronous Dataflow: Fibonacci (see also Merge).
Heterochronous dataflow (HDF) is an extension of synchronous dataflow (SDF) that permits dynamically changing production and consumption patterns without sacrificing static scheduling. In SDF, the production and consumption patterns of an actor are constant. In HDF they are allowed to change between iterations of the HDF schedule. Modal models can be used to change these patterns. Although HDF can express many data-dependent computations that cannot be represented by SDF, it is not Turing complete. Consequently, deadlock and boundedness remain decidable. The Fibonacci example uses this mechanism in a clever way to extract a Fibonacci sequence from a counting sequence.
Synchronous/Reactive Modeling: TokenRing (see also TrafficLight and GuardedCount).
The synchronous/reactive (SR) domain, which is inspired by the synchronous languages Esterel, Lustre, and Signal, realizes a concurrency model where actors react instantaneously and simultaneously at ticks of a logical clock. The TokenRing example uses the fixed-point semantics of SR to arbitrate access to a shared medium using a token-ring protocol.

Modeling Infrastructure

Ptolemy II models are built on an underlying framework that provides a rich set of generic capabilities that are available in all models. This section illustrates that infrastructure.

The Type System: Router.
This model illustrates the very sophisticated type system of Ptolemy II, where type constraints propagate transparently, actors are polymorphic, and composite types such as records and arrays are supported. This example illustrates composite types, where records are constructed out of tokens with various types. Here, a record models a packet in a packet-switched network, where variable delays may result in out-of-order arrival of packets.
Expression Language: Transmission.
To simplify creating new components, Ptolemy II contains a functional expression language. The expression language is integrated with the type system, allowing static type checking of polymorphic expressions with few type annotations. The expression language also allows new, encapsulated functions, called function closures, to be defined and passed as data. This model illustrates how function closures can be used to make models much more compact.
Model Transformation: SinewaveOptimization (see also AdaptiveCarWash, ConstOptimization, DiningPhilosophers, GameOfLife, MapReduce, RegressionTest ).
Model transformation is a technique to manipulate models as first-class citizens. An atomic transformation rule is defined in a TransformationRule actor. Inputs to a TransformationRule actor are tokens containing models to be transformed, and outputs are tokens containing the results. Multiple transformations can be programmed by a model to transform the input models step by step. Other actors that are commonly used in model transformation include ModelGenerator to generate initial models, and ModelView to show the contents of input models in new windows. In the SinewaveOptimization demo, a transformation is repeatedly applied to the initial model (Sinewave) to statically evaluate arithmetic operations in it, until no more simplification can be done.
Higher-Order Components: HocDE (see also Case, MobileFunction, MultipleRuns, IterateOverArray, DFTSubSet, ApplyFFT ).
Higher-order components are components that operate on components. The HocDE example contains a component that is a composite actor that replicates itself some specified number of times to operate on multiple channels of input. This capability was created by Zoltan Kemenczy and Sean Simmons, Research In Motion, Ltd.
Interactive Signal Plotter: Sketch (see also FourierSeries).
This model illustrates the use of plotter to provide input as well as rendering output from a model. Right click and drag on the plot to trace out a new signal. The model runs each time you do this.
Matlab Integration: MatlabExpression (see also Matlab in Continuous).
This example uses the Matlab interface created by Zoltan Kemenczy and Sean Simmons, of Research in Motion Ltd., to plot a 3-D surface. This works only if Matlab is installed locally.
Classes, subclasses, and inner classes: ClassesIllustrated (see also Noisy sinewaves and Rijndael Encryption ).
Actor-oriented classes, subclasses, and inner classes with inheritance are a special feature of Ptolemy II. They provide modularity mechanisms analogous to those of object-oriented design, but adapted to actor-oriented design. This capability permits, for example, defining a class of models that can have instances and subclasses. The instances and subclasses inherit all the features of the class, and track any changes that are made to the class.
Model Animations: Bouncer (see also AnimateVergil WirelessSoundDetection ).
Ptolemy II models can, while executing, control their visual rendition in Vergil, the visual editor for Ptolemy II. In this example, a model alters the position in the Vergil diagram of one of its own actors.
Three-Dimensional Graphics: Pendulum (see also Helen, Gravitation, SolarSystem, Sticky Masses and Bouncing Ball).
NOTE: These models require that you have installed Java 3D from Sun (see https://java3d.dev.java.net/). The Pendulum example shows a continuous-time physical model of pendulum animated in the graphics (GR) domain, in which graphical components can be assembled and dynamically manipulated. Note that clicking and dragging in the graphics window rotates the model. For further details, see the GR domain.
Statically Checked Units System: StaticUnits (see also Units, the dynamically checked units system).
This model illustrates the use of the statically checked units system. A unit system defines a set of interrelated dimensions and measures. For example, in the time dimension, we might have seconds, minutes, hours, days, weeks, and fortnights. Ptolemy II includes two experimental units systems, one that is statically checked and one that is dynamically checked.
Network Integration: Networked.
This example illustrates that models may be defined in a networked, distributed fashion. This model contains a component that is defined on the Ptolemy project website. When you open the model, you will be alerted to the fact that it requires loading a model definition from a remote source. If you agree to proceed, then you will have a model with a remotely defined component. The component itself is at https://ptolemy.berkeley.edu/xml/models/Waveform.xml. You can open that definition by clicking on the hyperlink, or by using the "Open URL" command in the File menu.
Audio: KarplusStrong (see also SoundSpectrum).
Ptolemy II includes actors that interface to the audio system on the executing machine, assuming it has one. This example shows the Karplus-Strong algorithm, which synthesizes a musical sound that closely resembles a plucked string instrument. It illustrates the audio capabilities of Ptolemy II.
Python Integration: Ptolemnizer (see also PythonScale).
Python is a popular interpreted programming language that has been integrated into Ptolemy II using the jython Java implementation of Python. This example shows that use of Python to alter a string entered by the user to modify any word that begins with "t" so that it begins with "pt". This leverages the excellent string processing capabilities in Python. Python can also be used to prototype actors by defining their functionality in Python.
Image and Video Processing: AdaptiveMedian (see also ImageReconstruction, VQSequenceDisplay, VideoCapture).
If you install the optional packages JAI (Java advanced imaging) and JMF (Java media framework), then you can use a library of actors that operates on images and video signals, including video captured from a video camera.
Fixed-Point Arithmetic: FixFIR (see also FixPoint)
Ptolemy II data types include a fixed-point data type, where a model can explicitly control the binary representation of numbers and the mechanisms used to handle overflow and rounding.

Actor Libraries

Ptolemy II includes several actor libraries that provide sophisticated functions. A few of those are illustrated by the models here.

Array: Actors that operate on matrices and arrays.
ColtRandom: Random number generators (based on Colt).
Signature: Security actors (encryption and digital signatures).
TrellisDecoder: Communication library.

Experimental Capabililties

Ptolemy II has a number of less well-developed experimental capabilities that may continue to evolve over time. These are illustrated in the following examples.

Push/Pull Component Interaction.
The CI (component interaction) domain models communication between components that uses a combination of push and pull. This model illustrates the use of these styles of communication to route packets through queues using some policy that depends on the queue sizes.
Cal: an interpreted actor definition language. Function Closures, Function Definition, Primes, SDFDDI
Discrete-Time Models.
This example shows a simple pulse-amplitude modulation, physical layer communication system. It illustrates the discrete-time (DT) domain, live parameter editing and the scope-style plotter (which shows an eye diagram). Note that discrete-time models can also be represented using the SDF domain, which is not explicit about the passage of time.
Code Generation
This release includes a limited prototype of our code generation facility. This example leads to more information about this capability.
Timed Multitasking.
This example illustrates the timed multitasking (TM) domain, which is inspired by the Giotto language, and has features of priority-driven real-time operating systems. In this example, two control systems share a computational resource. Depending on the scheduling strategy chosen (preemptive or nonpreemptive) and the priorities, the two control systems may be both stable, or one may be stable, or the other may be stable.
Correctness Checking using Formal Methods.
This is an ongoing project which tries to equip Ptolemy II with abilities to test the correctness of a system using formal verification. Currently we develop a code generator to convert Ptolemy II models into files accepted by model checker NuSMV.