Ptolemy II 8.0.1 Release Notes

Ptolemy II is a set of Java packages supporting heterogeneous, concurrent modeling and design. Its kernel package supports clustered hierarchical graphs, which are collections of entities and relations between those entities. Its actor package extends the kernel so that entities have functionality and can communicate via the relations. Its domains extend the actor package by imposing models of computation on the interaction between entities. Examples of models of computation include discrete-event systems, dataflow, process networks, synchronous/reactive systems, and communicating sequential processes.

Ptolemy II includes a number of support packages, such as
data, providing a type system, data encapsulation and an expression parser,
plot, providing visual display of data,
math, providing matrix and vector math and signal processing functions, and
graph, providing graph-theoretic manipulations.

The three volumes of the Ptolemy II Design Document describes the Ptolemy II design and the implementation of the Java classes.

The "Using Vergil" describes how to use Vergil.

Complete List of Domains in Ptolemy II

Platforms

The core of Ptolemy II 8.0.1 is 100% Java, so it should work on any platform that has JDK 1.5 or later.

We developed Ptolemy II 8.0.1 under Mac OS 10.5 and Windows Server 2003 and with JDK1.5.0._22.

Ptolemy II 8.0 will not compile under Java 1.3 because we use the java.lang.URI class, which is present only in Java 1.4 and later. JDK 1.5 or later is required so that these packages can use generics: backtrack, ptalon and others.

Ptolemy II has been compiled and run under IBM JDK 1.6.0. There are the following limitations under IBM JDK 1.6.0

  • The Copernicus code generator does not work.
  • Caltrop does not work.
  • The IBM JDK seems to return directory contents in a different order than the Sun JDK. Thus actor.lib.io.DirectoryListing might return elements in a different order.

    • Contents:

    Highlights

     

    Model Transformation

    The model transformation facility provides a framework for the analysis and transformation of actor models using model transformation techniques.

    The design of large-scale models poses a number of challenges. As the size of the models increases to thousands of actors or hundreds of thousands of actors, analysis and consistent modification on the models become extremely hard. Furthermore, to maximize component reuse, a systematic approach is needed for the specification and maintenance of common patterns in the models and the transformation of those patterns.

    The model transformation framework to be developed in this project aims to support the flexible specification of patterns and replacements by means of rules in graph grammar. An intuitive graphical user interface will be built. For novice users, a set of common transformations will be included in a library to facilitate their common tasks.

    The transformations are models in their own right. They can be embedded in larger models hierarchically. Heterogeneous models of computation can be used to control the application of individual "atomic" transformations. This makes it easy to create sophisticated transformations by composing simple ones in a manageable and disciplined way. The sophisticated transformations will also take advantage of the concurrency inherent in those models of computation.

    Model transformation can be applied as an optimization of modal models. These are hierarchical state machines with refinements in their states, which are sub-models to be executed when those states are active. The current implementation includes the complete description of each refinement in the model description, even though refinements of the states in a state machine tend to have large commonality. With the transformation technique, only one refinement needs to be stored completely. The others are obtained by transformations performed on the stored refinement. This eliminates redundancy and eases the job of modifying multiple refinements consistently.

    Other applications of the model transformation technique include recognizing common design patterns in the models in a static analysis, replacing exiting design patterns with more efficient ones, and reusing design patterns by incorporating them into new models.

    References

    Model Transformation Demonstrations

    Primary Model Transformation Developer: Thomas Huining Feng

     

    Ptera (Ptolemy Event Relationship Actor) Domain

    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.

    The Ptera domain supports a different kind of modal models called PteraModalModels, compared to modal models using FSMs (Finite State Machines) as the control. A PteraModalModel uses Ptera at the top level, and each event is refined into a sub-model. The refinements can use Ptera and any other Ptolemy models of computation.

    A Ptera model is timed. Although it should work in many domains, the DE (Discrete-Event) domain or Ptera domain itself are recommended. When embedded in those domains, the scheduling of the Ptera model is delegated to the container by calling the fireAt() function of its director.

    There are many useful additional features for Ptera, such as canceling edges and parameters. A canceling edge, denoted by a dotted line, cancels a previously scheduled event instead of scheduling a new one. If the pointed to event has multiple instances in the event queue, then the first instance is cancelled. Events may also have parameters, and the actual values for those parameters are specified by the expressions on the edges that schedule them. Those expressions are evaluated at run-time. The events may refer to the values of those parameters in their actions by parameter names.

    References

    Ptera Domain Demonstrations

    Primary Ptera Developer: Thomas Huining Feng

     

    Causality Analysis

    Ptolemy II 8.0 includes an update to our Causality Analysis framework. We identified performance problems with our current non-conservative causality analysis for modal models within discrete-event (DE) systems. In this scheme, causality analysis is performed on the entire model at run time each time there is a mode change in the model. This mechanism is far too costly. We are investigating techniques for performing the causality analysis in a compositional way for the various modes at compile time. Unfortunately, brute force solutions result in exponentially growing memory requirements for the results of the causality analysis.

    We designed, implemented and reviewed an interface that defines a causality interfaces for actor networks as described in the paper "Causality Interfaces for Actor Networks."

    Causality interfaces are also described in Ye Zhou Ph.D. Thesis, "Interface Theories for Causality Analysis in Actor Networks."

    Causality interfaces represent dependencies between input and output ports of an actor and can be used to perform scheduling or static analysis on actor models.

    This substantial new work helps address performance problems in large Discrete Event (DE) models. The new work provides more efficient static analysis for directed cycles and scheduling. This work solved a bug concerning execution time with DE models that had many actors at one level of hierarchy. The table below illustrates the improvement.

    # of actors Total execution time before Total execution time after
    100 ~0.2 sec. ~0.2 sec.
    600 149 sec. 0.7 sec.
    Run times for DE models

    One of the challenges in complex, heterogeneous models is that portions of the model have temporal behavior while other portions are purely functional. We have reworked the interfaces that hierarchically heterogeneous models in Ptolemy II present to one another for managing the passage of time. This rework supports much more robust multithreaded and distributed execution without compromising temporal coherence. Concretely, we have defined a formalism whereby a model requests temporal behavior of its container in the hierarchy, and the container responds with an indication of the extent to which it can honor the request. If the extent is sufficient for the application, then the models are compatibly composed. Otherwise, they are not, and the model is marked defective.

    References

     

    Continuous and Modal Domains

    Ptolemy II 8.0 includes a substantial rework of modal models and the underlying finite state machine infrastructure to make them work predictably and consistently across domains.

    Ptolemy II 8.0 includes a new implementation of continuous-time models based on the semantics given in "Synchronous Language Principles for Heterogeneous Modeling and Design of Embedded Systems." In particular, the Continuous domain cleanly supports continuous-time models (using an ODE solver), discrete-event models, and arbitrary mixtures of the two, including signals that combine continuous-time segments with discrete events. It also interoperates cleanly with most other domains (pretty much all except PN and Rendezvous, for which there does not appear to be reasonable semantic model of such an interaction). Modal models are also cleanly supported with the Continuous domain, enabling hybrid system modeling with a rigorous semantics. The Continuous domain is expected to eventually replace CT.

    New Continuous and Modal Demonstrations

    Continuous
    Modal
    The Modal models below are copies of the FSM models with the same name but the Modal models use the continuous domain, whereas the FSM models use the ct domain.

    References

    Other Key New Capabilities

    Additional Features

    New demonstrations

    Discrete Event (DE)

    Process Network (PN)

    Synchronous Dataflow (SDF)

    Synchronous/Reactive (SR)

    PN Code Generation

    SDF Code Generation

    Wireless

    New and Enhanced Actor Libraries

  • New Parameter:
  • New Continuous actors:
  • New Discrete Event (DE) actors:

    Other new classes

    Works in Progress

    Bug fixes

    For the current list of bugs, see Ptolemy II Bugs
    and     Kepler Bugs

    Features that were new in previous Ptolemy II releases

    Features that were new in previous Ptolemy II releases

    Limitations

    Version 8.0.1 has the following limitations:

    Release Limitations

    Limitations in building

    Limitations in the Actor Oriented Class Mechanism

    The actor oriented class mechanism described in has various restrictions and limitations:

    Limitations in the Actor Libraries

    Limitations in the PN Domain

    The PN domain documents that it locally handles mutations. However, this is currently not true in the implementation. For the basic PN model, this doesn't really matter, since mutations happen pretty much the same as they would otherwise. (i.e. they are non-deterministic in when they execute) However, for timed PN models, there is actually some expressiveness lost, since timed PN models can locally execute mutations deterministically.

    Embedding a PN typed composite actor inside a non-process top level such as DE does not work. In fact embedding a process domain inside a non-process domain is likely to have problems. Profess Lee wrote:

    Yes, it looks as if the code is designed so that process domains (PN, CSP) can only be used within process domains. I'm not sure to what extent this is a limitation of the process domains vs. a semantic problem. What would PN mean within DE? Since PN has no well-defined notion of a "firing", how would you assign time stamps to the outputs of a PN actor? By default in DE, the time stamps of the outputs of an actor match those of the inputs that triggered the firing. There is no such notion in PN.

    Limitations in other domains

    Limitations in the User Interface

    Below are some of the limitations of Vergil, the Ptolemy II Graphical User Interface.

    Limitations in $PTII/jni

    $PTII/jni has been replaced by the EmbeddedCActor. We keep $PTII/jni around because we need the launcher for use with JNI under Cygwin and $PTII/jni has some simple JNI tests.

    Code Generation Limitations

    Missing Domains

    For limitations discovered after the release, see the Ptolemy II 8.0.1 website

    Last Updated: $Date: 2010-11-01 13:16:13 -0700 (Mon, 01 Nov 2010) $