Ptolemy II 5.0 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
- CI:
component interaction (experimental),
- CSP:
communicating sequential processes,
- CT:
continuous-time modeling,
- DE:
discrete-event modeling,
- DDE:
distributed discrete events (experimental),
- DT:
discrete time,
- FSM:
finite state machines,
- Giotto:
periodic time-driven (experimental),
- GR:
3-D graphics (experimental),
- PN:
process networks,
- PSDF:
parameterized synchronous dataflow (experimental),
- SDF:
synchronous dataflow,
- SR:
synchronous/reactive,
- TM:
timed multitasking (experimental), and
- Wireless:
wireless (experimental).
Platforms
The core of Ptolemy II 5.0 is 100% Java, so it should work on any
platform that has JDK 1.4 or later
We developed Ptolemy II 5.0 under Solaris 8 and Windows XP sp1
and with JDK1.4.2_04
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
There are various problems with Java 1.5.0-beta:
Ptolemy II has been compiled and run
under IBM JDK 1.5.0 and IBM JDK 1.4.1
Major Features that are new in Ptolemy II 5.0
Below are new features that were not present in Ptolemy II 3.x
-
Modeling wireless sensor networks (see also
VisualSense).
The wireless domain extends the DE domain with wireless channel modeling and
library of components and methodologies for modeling wireless systems.
This domain is packaged in a Ptolemy II configuration called
VisualSense, which includes
an extensive suite of demos.
-
Hierarchical classes, subclasses, and inner classes. (See also
classes illustrated visually and
Rijndael Encryption).
Version 5.0 introduces actor-oriented classes, subclasses, and
inner classes with inheritance. This is a major improvement in
the modularity mechanisms available in actor-oriented design.
A side effect of the class mechanism is that MoML files are now
much smaller since they do not duplicate information defined
in a base class.
-
Lifecycle management (see also
ModelReference).
Version 5.0 introduces the first of a family of
lifecycle management actors, which are actors
that control the execution of associated models.
This example uses one model to control repeated runs of another.
Other Features that are new in Ptolemy II 5.0
-
Statically Checked Unit System (see also the older
Dynamically Checked Units System).
The new statically checked units system associates
units with ports and checks compatibility in connections.
-
Higher-Order Components.
Version 5.0 adds higher-order components,
which are components (like actors) that operate on other
components rather than directly on data.
-
Interactive decorations in Vergil diagrams.
Actors can have custom icons, diagrams can be decorated with
decorative elements, and parameters of the icons and decorative
elements can be tied to values compute by the model.
-
Reconfiguration analysis
A new capability helps to ensure the safe use of reconfiguration.
Currently it is primarily used by the code generator to
ensure that synchronous dataflow rate parameters are constant
over the lifetime of the model. This analysis also enables
parameterized static scheduling of some models where rate parameters
change only between iterations of a sub-model.
-
Causality analysis (see also
SR FeedbackLoop).
A new (and still evolving) capability unifies causality analysis
that is required by several domains. It provides a systematic
framework for determining whether events at a particular input
affect a particular output.
-
Copernicus
The copernicus code generator has matured significantly:
- Better handling of data types, reconfiguration, and attributes other than
simple parameters.
- Code Generation for the Giotto domain.
- A primitive code generator for generating atomic actors from models.
- Static analysis of reachable code for generating self-contained jar files.
New Demonstrations
New and Enhanced Actor Libraries
New Demonstrations of Older Capabilities
Capabilities requiring additional software and/or hardware
- Other updates to Vergil:
- Single Window Mode (contributed by Thales).
If vergil -single
is invoked, then a single window interface
is used. This interface is experimental.
Limitations:
- The
-single
argument should be the first argument.
- The plot windows come up outside of the single window interface.
- XMLToken.
This is a preliminary mechanism for manipulating XML data in Ptolemy II models.
- Sandbox support
Vergil has better support for operating in a security sandbox.
For details, see the
Ptolemy II Sandbox documentation.
New Actors
Backward Compatibility
Most models developed under Ptolemy II 1.0.1,
2.0.1, 3.0.2 or HyVisual 2.2-beta an Hyvisual 3.0
should run under Ptolemy II 5.0
The MoMLParser includes a list of backward
compatibility filters that make certain changes on models
when read, handling such issues as actors being moved or renamed
and parameter names being changed.
The filters themselves are defined in
ptolemy.moml.filter.
If you have developed your own actors under Ptolemy II 3.0.2 by
writing your own Java files, you should recompile all your java code with
the new release. In theory, copying the .class files should work, but
recompiling is safer.
Backward compatible issues that are handled automatically
Features that were new in previous Ptolemy II releases
Features that were new in previous Ptolemy II releases
Version 5.0 has the following limitations:
Release Limitations
Limitations in the Class Mechanism
The class mechanism is highly preliminary and is likely to change
in future releases. There are several known problems:
- Several higher-order-components will not work inside class definitions.
(ModalModel, several CT actors, etc.).
- Name collisions can occur when adding objects to base classes
whose names collide with objects in derived classes.
Auto naming should look through the derivedList for name conflicts.
- Propagation of changes to a base class is very slow in Vergil.
If there are more than just a very few instances or derived
classes, interactive editing is not practical. As a workaround,
put the class definitions in a separate file and edit them
without opening the model that creates instances. The probable
reason is that MoMLParser handles propagation by issuing large
numbers of change requests.
- Certain actors, such as MathFunction, change the number of ports
when parameters change. This violates the derivation invariance
for classes. To demonstrate the bug, put a MathFunction actor
in a base class that has a subclass. Change the function parameter
in the subclass to anything but "modulo". Then change the function
in the base class to "modulo" (which adds a port). Now attempt
to insert a parameter into the port. You will get an
InternalErrorException when it tries to propagate the change.
Limitations in the Actor Libraries
- The actor library is far from complete.
- The Expression actor does not properly propagate type constraints in
an expression-dependent fashion. It works correctly for double-valued
expressions of double-valued inputs.
- The Ptolemy parameter parser uses comma "," to separate elements
in an array. This causes problems when Ptolemy is run on
European machines that use a comma "1,0" instead of a period "1.1"
in floating point numbers.
- The Display actor uses the Swing JTextArea component which is
known to have memory leaks.
- The readFile() parameter function does not work with applets.
Instead, use readResource().
- The Matlab interface works only under Windows and it requires that
Matlab be installed on the local machine.
The Matlab interface should work with version of Matlab from
R11 (5.3) and up to and including R13 (6.5)
Didier Mauuary reports that under Windows 98, configure failed
to set up the MATLAB_DIR
, PTCC
and PTDLLTOOL
makefile variables, but after
he set them by hand:
MATLAB_DIR = /cygdrive/c/MATLABR11
PTCC = gcc
PTDLLTOOL = dlltool
he was able to get farther with the recompilation of the Matlab interface.
- Matlab interface has problems work with gcc-3.3
Under Windows, the Matlab interface has problems at runtime with gcc-3.3.
Under Windows, we recommend using gcc-3.2.
- The actor.lib.comm.SerialComm actor requires that Javacomm is installed
http://java.sun.com/products/javacomm/index.html
.
The SerialComm actor will only work under Windows.
- IterateOverArray has the following problems
- IterateOverArray: When you drop in an actor, and then
another actor, and then select "undo," the second actor is
deleted without the first one being re-created. Thus, undo is
only a partial undo. The fix to this is extremely
complicated. Probably the only viable
mechanism is to use UndoStackAttribute.getUndoInfo() to get the undo
stack and then to manipulate the contents of that stack directly.
- IterateOverArray: There should be an option to reset
between firings of the inside actor.
- IterateOverArray: If you drop a new actor onto an IterateOverArray
in a subclass, it will simply acquire the new contents, but not
actually do anything with them. It should somehow refuse to accept
the new object in the subclass, since to do so, it would have to
delete the original object defined in the base class, and this would
violate the derived invariant.
- IterateOverArray: If an instance of IterateOverArray in a derived
class has overridden values of parameters, those are lost if
contained entity of the instance in the base class is replaced and
then an undo is requested.
- IterateOverArray: When an actor with a display icon like
Const, Expression, or MathFunction is put into
IterateOverArray, the CopyCatIcon doesn't reflect the text display.
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 the User Interface
Below are some of the limitations of Vergil, the Ptolemy II Graphical
User Interface.
Limitations in JNI
The Interface to C actors using the Java Native Interface
is not available via the Windows Installer (or Web Start).
To use the JNI/Ptolemy II interface, you must download
Ptolemy II as source files and compile.
The JNI user interface does not permit creation of new JNI actors.
If you follow the instructions in
JNIUtilities, then
eventually you will get a NameDuplicationException.
The resulting model will be missing
<property name="output" class="jni.Argument" value="false,false,true,double">
</property>
We are working with the original authors on a solution.
In the short term, one workaround is to edit the xml file directly
and add the appropriate property by hand.
JNI will not work with Hierarchical classes, subclasses, and inner
classes
If Ptolemy exits when running the JNI model, then
try using gcc-3.2.x in the Cygwin installer from
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII5.0/cygwin.htm
which includes gcc-3.2.x
Code Generation Limitations
Code Generation limitations are covered on the
Code Generation page.
Missing Domains
- Boolean and integer dataflow.
- Dynamic dataflow
For limitations discovered after the release, see the
Ptolemy II 5.0 website
Last Updated: $Date: 2004/12/16 16:37:11 $