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.
We developed Ptolemy II 7.0.1 under Solaris 10 and Windows XP and with JDK1.5.0.0_14
Ptolemy II 5.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
Contents:
Codegen has the following new features:
Primary Codegen Developers: Gang Zhou, Man-kit Leung.
Codegen Contributors: Christopher Brooks, Teale Fristoe, Edward A. Lee, Ye Zhou
Actor-oriented design is a common design strategy in embedded system design, where actors are concurrent components which communicate through ports by sending signals to one another. Such systems are frequently modeled with block diagrams, where the blocks represent systems and lines or arrows between blocks represent signals. Examples include Simulink, LabView, and VHDL/Verilog.
A common problem in such environments is managing complexity, particularly when the designs become large. Most actor-oriented design environments allow hierarchy, or systems (blocks) which are composed of other systems (blocks). To take this a step further, we are developing the Ptalon programming language, which allows users to parameterize components with other components.
We have developed a preliminary interpreter for the Ptalon language in the context of Ptolemy II, a general-purpose design environment for actor-oriented systems. We have also developed a mathematical framework for such languages, to help aid our understanding . We are currently investigating the resource management issues inherent in supporting large block-diagram models.
In developing this sub-project, we highlight the following (increasing) list of criteria:
Primary Developer: Thomas Huining Feng
The Continuous Domain is a redesign of the Continuous Time (CT) domain with a rigorous semantics documented in the following papers:
Primary Developers: Haiyang Zheng, Edward A. Lee
The graph transformation facility provides a framework for the analysis and transformation of actor models using graph 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.
Primary Graph Transformation Developer: Thomas Huining Feng
boolean hasKnownLength() int length()The length() method throws a RuntimeException if invoked on an ArrayType with hasKnownLength() == false.
Existing ArrayType instances (creating using the ArrayType(Type) constructor have unknown length. A new constructor ArrayType(Type, int) creates array types with a known length. Generally speaking, array types with known length are incomparable with array types with different lengths, and can be converted to an array type with unknown length and compatible element type. Scalars are convertible to array types with length 1. Getting the code to do this right was significantly more complex than inferring sizes of Fix-point types because:
Unfortunately, this means that there is a signficant backward-compatibility issue Previously, if you wanted to force an arbitrary integer array type, you used {int}, which is really an array with one element. This now has the type arrayType(int, 1), which is more specific than you probably want.
The existing models have been updated using the new description of an array type with an unknown length.
Note that arrayType(int) returns an instance of the special class UnsizedArrayToken, whose only purpose is to have an unknown array size. Regular array tokens always have a known length.
Note also that arrayType(unknown) is no longer the GLB of all of the arrayTypes. The GLB is now represented by BaseType.ARRAY_BOTTOM (which is not an instance of ArrayType). This required moving farther along the path of decoupling type constraints on array element types from the type objects themselves. TypeableElementTypeTerm can now refer to the element type of a typeable which may never esolve to a valid array type (resulting in an unsatisifed inequality term).
Primary Developer of ArrayType changes: Stephen Neuendorffer