QUARTERLY PROGRESS REPORT CONTRACTOR: University of California at Berkeley AGREEMENT NUMBER: F33615-00-C-1703 CONTRACT PERIOD: 5/25/00-9/30/03 TITLE: Process-Based Software Components for Networked Embedded Systems REPORT PERIOD: 4/1/03 - 6/30/03 SPONSOR: Air Force Research Laboratory (AFRL) TECHNICAL POC: Dale Vancleave, dale.vancleave@wpafb.af.mil REPORT PREPARED BY: Edward A. Lee 0. Executive Summary Our focus is on component-based design using principled models of computation and their runtime environments for embedded systems. The emphasis of this project is on the dynamics of the components, including the communication protocols that they use to interface with other components, the modeling of their state, and their flow of control. The objective is to provide mechanisms for introspection, supporting both the ability of the run-time environment to safely dispatch tasks and the ability of components to adapt their interfaces using polymorphism. The focus is on real-time applications, which implies that models of time are a critical part of the abstractions that we are developing. The purpose of the mechanisms we develop is to improve robustness and safety while promoting component-based design. This reporting period was marked by an implementation of the E1 experiment for the software radio OEP ("Ethereal Sting"), first production of executable C code after Java-to-C translation of code generated from a Ptolemy II model, the introduction of mobile models in Ptolemy II, improved semantics for hybrid systems models, a first version of an interface checking framework for Ptolemy II, many software improvements, and a new release of Ptolemy II. 1. Research Status Software Release ================ We released Ptolemy II 3.0-beta, and distributed it on CD at the Ptolemy Miniconference and on the web. The release information is appended in the appendix. Ethereal Sting OEP ================== We implemented the E0 algorithms in Ptolemy II. In the process, we exposed the following limitations with the component library: * The actor library had no actor for array maximum. This was added later by Mark Oliver of Wright Patterson AFB, whose design we have built into our library. A reasonable workaround was to use a signal bus with its width equal to the desired array size. However, this exposed the following limitation: * Type resolution was very slow when using very wide signal busses. This was fixed by Steve Neuendorffer. * The AudioReader actor was unfinished. It used an outdated mechanism for specifying the input file and didn't correctly deliver multichannel signals. * Our FFT actor performs only radix-2 FFTs. A workaround would have been to use the Ptolemy II/MATLAB interface to invoke the MATLAB fft function, but we found that the algorithm performed adequately with this limitation. * Code generation didn't correctly handle the updated mechanism for specifying input files, so when the AudioReader actor was updated, code generation for this actor stopped working. There was also an error in the generated code for the absolute() function. Log of effort: There were three active participants from our group, plus some spectators. We spent 0.5 hours examining EtherealSting website and figuring out what to do, 2 hours constructing and experimenting with the model to detect the baud rate, 1 hour fixing bug in AudioReader actor to use FileAttribute, and 4 hours experimenting with code generation. Our implementation started with a model constructed by Edward Lee at the Mobies PI meeting (which took, perhaps, 1.5 hours to build). The total time spent was 9 hours, of which 6.5 hours fixing bugs or limitations exposed by the experiment. The experiment also stimulated further work on comm/signal processing libraries. Looking forward, Yang Zhao, Steve Neuendorffer and Xiaojun Liu prototyped an approach to model-based design of the supervisory structure, and demonstrated this at the working group meeting in June. This approach allocates signal analysis tasks to compute resources. The components in this model include: * A PushConsumer actor that receives pushed data provided via CORBA, where the data is an XML model of a signal analysis (SA) algorithm. * A Model actor that accepts a StringToken containing an XML description of a model. It then executes that model on a stream of input data. * A PushConsumer actor that receives pushed data provided via CORBA, where the data is a user request for signal analysis. * A PushSupplier actor that sends an XML representation of an SA model via CORBA. * A supervisor state machine that implements the resource allocation logic. * A model of a user, which includes a model that supplies the signal data, a PushSupplier actor that sends a request for signal analysis to the task manager, and a PullSupplier actor that provides signal data on demand from SA algorithm. To make this mechanism workable, there are a number of open issues that have to be dealt with: * We have to handle failures of the mobile model, perhaps using the “model error handler” mechanism in Ptolemy II. * We need secure execution of the mobile model by limiting the authority granted to actors in that model. One approach is to use the Java sandbox in the Java security model. However, in this case, all Java code executed is locally defined, so an alternative is to mark actors and directors that convey no authority and to set the MobileModel security level to restrict actors to a subset. * We need encrypted communication of models & data, which are currently XML plain text. * We need authenticated access to MobileModels. Mobile Models and Mobile Functions ================================== Yang Zhao, Xiaojun Liu, and Steve Neuendorffer created actors in Ptolemy II supporting mobile code. There are two forms. MobileFunction accepts a function defined in the expression language, and MobileModel accepts a Ptolemy II model. Both apply the accepted function/model to streams of inputs. This opens up a rich set of possibilities for model-based design, and a host of security and type system questions. Improved Operational Semantics for Hybrid Systems ================================================= Haiyang Zheng has made a number of improvements to the operational semantics of hybrid systems and the corresponding implementation in Ptolemy II. In particular, * He has greatly improved the handling of instantaneous transitions in continuous-time signals, giving these signals a semantics where the signal at a discontinuity has two or more values. The value before and after the discontinuity is well-defined and unique. * He has improved the library in Ptolemy II for modeling such signals, creating for example a flexible ContinuousClock actor that produces periodic piecewise-constant signals that can be started and stopped. * He has also improved the behavior of the Sampler actor, and given it a consistent semantics when it samples a continuous signal at a discontinuity. * He has improved the LevelCrossingDetector that it is correctly and precisely triggered when a discontinuity crosses the specified threshold. * He has improved the signal type inference mechanism to reduce the number of circumstances in which a user needs to explicitly declare a signal discrete or continuous. * He has improved the evaluation of guards in the state machines of modal models so that a transition is triggered (rather than enabled, as it was before) when the guard becomes true, and he has improved the algorithm that is used to identify the point in time at which the guard becomes true. * He has introduced "chained transitions," which are transitions that are taken after spending zero time in a state. These occur when, upon entering a state, a guard on an outgoing transition is true. This removes a form of nondeterminism that existed in the timing of such transitions. Code Generation =============== Shuvra Bhattacharyya, under subcontract at the University of Maryland, reports progress on the C code generation. - Code Generation was enabled for the C6000 series of DSPs from TI. C code and a makefile targeted at a C6000 can be generated by giving the flag "-target C6000" to the Java-to-C compiler. Generated code compiles correctly for the platform, and we were able to run small test programs on the hardware. - A series of measurements was taken to quantify the code size and performance of the C code generator. We observed performance (in terms of execution time) to be comparable to Sun's JVM (with JIT-compilation enabled) or GNU's gcj Java-to-native-code compiler. However, we observed the size to the generated executable to be an order of magnitude smaller, on average, compared to gcj. - "auto-detect" support for the garbage collection library was added. The compiler can detect whether or not the garbage collector exists. - More progress was made in integrating the code generator with Ptolemy II. Some C code is now generated for simple Ptolemy tests without causing conflicts with the ptII tree. We are working on modifications required on the copernicus kernel to integrate this further. Full compilation with code pruning turned on is being enabled. Single-class compilation works. In related work, Christopher Hylands did some evaluation of gcj, which is the GNU native Java compiler. The numbers are rather rough, but basically using gcj results in about a 4x improvement over a standard Ptolemy run and about 1.4x improvement over the best deep codegen output. The resulting code size is rather large. Steve Neuendorffer reports that he managed to successfully run generated code on the Dallas Semiconductor TINI board. The main difficulty is one of libraries. The TINI board supports libraries that approximate JDK1.1, with some hardware specific enhancements, like CAN bus access. There are several places where we use non-JDK1.1 facilities. Steve was careful to avoid problematic classes, but this is not an ideal solution. Another problem is the use of hardware-specific libraries. Component Interaction ===================== Xiaojun Liu and Yang Zhao have created (and we have previously reported) a "component interaction" (CI) domain, which extends dataflow by supporting both push and pull style interactions and by supporting nondeterminism. We have evaluated a number of alternatives for multithreaded and distributed implementations of CI, and have realized that the Click Modular Router, created by Eddie Kohler from MIT, offers one of several possible approaches to such an implementation. Click is used for designing router software, which is a performance-intensive application. Xiaojun and Yang have created a preliminary document (as yet unpublished) describing this work. The CI domain bears interesting semantic relationships to dataflow models, to the Click Modular Router architecture, and to TinyGals [4]. We are working on a report. Interface Checking in Ptolemy II ================================ Arindam Chakrabarti and Eleftherios Matsikoudis constructed a framework for building into Ptolemy II models interface checkers for arbitrary interface theories. These interface checkers are configurable components that be collected in a library, and interface definitions are attributes that can be attached to actors in an actor-oriented design. A user selects an interface theory from a fixed number of choices in a library and associates interfaces as attributes of ports (similar to data types) and relations. The checker is invoked by pushing a button on the component icon. Operationally, the interfaces and topology are shipped off to Chick, a tool developed by Tom Henzinger's group that checks compatibility, and returns either a confirmation or incompatible behaviors. (It would be interesting to then, in a second step, check if these incompatible behaviors can indeed be realized by executing the model.) This "interface compatibility checking" as a service has appeal to us, because if successful, we could think about doing the same for languages such as UML and Simulink. Behavioral Types ================ Eleftherios Matsikoudis designed a better algorithm for identifying the least upper bound (LUB) of a set of nodes in a partial order. His algorithm has order n complexity rather than order n^2, as our previous implementation did. Lefteris has also proposed an improvement over transient states for interface automata specifying behavioral types. IAs have some difficulty modeling the atomicity of method calls because of input and output are on separate transitions. However, transient states are global... there can only be one transient state active at a time in an entire system. Lefteris has proposed instead associated lock variables by name with transitions. Taking a suitably labeled transition acquires the lock or releases it. He is working on extending the composition operator and formalism of IAs to accommodate this extension. Communications Library ====================== Inspired in part by the work on the Ethereal Sting OEP, we have built a number of actors in an effort to begin building up a serious communications systems library. Rachel Zhou has created (in alphabetical order): ConvolutionalCoder DeScrambler HadamardCode HammingCoder HammingDecoder Scrambler ViterbiDecoder These add to the already extensive signal processing library in Ptolemy II. Image Processing Library ======================== James Yeh has created an image processing library in Ptolemy II based on Sun's JAI (Java Advanced Imaging) API and JMF (Java Media Framework) API. The JAI actors include: DoubleMatrixToJAI JAIDataCaster JAIPNMWriter JAIAffineTransform JAIEdgeDetection JAIPeriodicShift JAIBMPWriter JAIIDCT JAIPhase JAIBandCombine JAIIDFT JAIPolarToComplex JAIBandSelect JAIImageReader JAIRotate JAIBorder JAIImageToken JAIScale JAIBoxFilter JAIInvert JAITIFFWriter JAIConvolve JAIJPEGWriter JAIToDoubleMatrix JAICrop JAILog JAITranslate JAIDCT JAIMagnitude JAITranspose JAIDFT JAIMedianFilter The JMF actors include: AudioPlayer JMFImageToken VideoCamera The AudioPlayer enables Ptolemy II to play MP3's, MIDI files, and CD tracks. Type System and Expressions =========================== With help from Zoltan Kemenczy of Research In Motion, we have improved further the integration of the Ptolemy II expression language with its type system. In particular, we can now define built-in functions (vs. functions defined in the expression language) that have arbitrarily complex (and polymorphic) type signatures. The way this works is that along with function itself, which is registered with the expression language, a type function is registered that, given the types of the arguments, returns the type of the result. This has been used to get precise type inference for several of our more complicated built-in functions. We have also continued to make many improvements in the expression language, and have implemented an expression evaluation shell that supports assignments, and can therefore be used for simple scripting. Yang Zhao added the first set of higher-order functions to the expression language. For example, map takes a function and an array and applies the function to the elements of the array, returning the array of results. The iterate function takes a function and applies it a specified number of times beginning with some initial value. For example, iterate(function(x) x+1, 10, 0)} yields the result array {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} These higher-order functions are fully integrated with the type system. Steve Neuendorffer improved comparisons between function tokens so that two function closures are considered equal (by the isEqualTo() method) if they are congruent. Congruency allows for arbitrary names of internally bound variables. Hence function(x,y) x+y is congruent to function(a,b) a+b If a function has free variables, as in for example, function(x,y) x+y+z then there is a subtlety. If this is evaluated in an environment where the value of z is 5, then the above function evaluation yields the same result as another function function(a,b) a+b+5 However, it will not be the same as evaluating the original function in an environment where the value of z is not 5. Currently, two functions are considered equal if free variables have the same name, and hence the above functions are not equal. This allows us to check for congruence of expressions with registered constants, without evaluating the expression, but has the downside of saying that "5+ 2*pi" is not equal to "5 + twotimespi", even if we had a constant named twotimespi. This seems like a reasonable compromise, since registered constants are in fact variables, so we have no assurance that their values will remain constant. The expression language now fully supports complex data types. Thus, the following operations (and many more) are now supported on complex args, complex matrices, and complex arrays: exp(), cos(), log(), and abs() (which returns the magnitude). Sensor Networks Model ===================== Sanjeev Kohli and Vinay Krishnan created a Ptolemy model of a sensor network with an efficient query broadcasting scheme. This model has an interesting visualization that is very unlike standard Ptolemy II block diagrams. It stimulated a flurry of work on model visualization since it used an unusual architecture in which no explicit connections between actors are created. We created a mechanism for attaching attributes to actors that modify the icon for the actor. This is used in this model to display the communication range of the sensor node. Peer-to-Peer Models and Multicast ================================= Yang Zhao created modified the DatagramReader actor to handle multicast and then used this modification to prototype a peer-to-peer chat application in Ptolemy II. This is illustrative of the network-integrated models that we expect to be creating in the future. Recursive Functions =================== Although it was not our intent to include this capability in the Ptolemy II expression language, Jorn Janneck and Steve Neuendorffer realized that we have the ability to define explicitly recursive functions, since we can pass functions to other functions. For example, if we define factorial = function(x:int,f:(function(x,f) int)) (x<1?1:x*f(x-1,f)) then we can call: factorial(4,factorial) which returns 24. This is somewhat awkward, but interesting. It relies on the fact that the ternary if (represented by the syntax p?x:y, where p is a predicate) only evaluates one of its branches. Note that there are interesting recursive functions that cannot be evaluated because we evaluate arguments strictly. Things get more interesting when we consider less trivial recursive functions. The Ackerman function is a function that grows faster than any exponential function. It is in some sense the simplest function that cannot be specified using only for loops. It can be defined in the Ptolemy II expression language as follows: ackerman = function(x:int,y:int,f:(function(x,f) int)) (x==0?y+1: (y==0?f(x-1,1,f): f(x-1,f(x,y-1,f),f))) But now, ackerman(3,4,ackerman) works fine and returns 125, which is 2^(4+3)-3. However, ackerman(4,1,ackerman) gives a stack overflow exception. It is not clear to us at this point whether this unintended capability is useful. Improvements to Basic Modeling Infrastructure ============================================= -- Xiaojun Liu and Leftherios Matsikoudis diagnosed a flaw in the core support provided by Ptolemy II for thread-safe multitasking execution of models. The problem was that no mechanism had been provided for a request for read or write access to the workspace to be canceled. In particular, if the requesting thread is interrupted (as happens, for instance, when a web page containing an applet is closed), then all applet threads are interrupted. In the previous design, the Workspace class would catch the InterruptedException and throw InternalErrorException. Since this is a runtime exception, it is not caught by any code. The calling thread typically responds by releasing the read or write access (which it has not successfully acquired) before handling the exception. This leaves the workspace in an inconsistent state. If the top-level model then tries to acquire workspace permissions as part of handling the exception, then threaded applications and applets could deadlock. It was extremely difficult to diagnose and fix this problem. -- Elaine Cheong and Steve Neuendorffer changed the semantics of operations on record types so that, for example, rec1 + rec2 yields a record containing only the common elements, whose values are then added. We also changed the convert() method to discard fields when a record is upcast. The reasons for this change are: 1) This makes code generation with records practical. 2) This makes expression operations identical to actor operations. 3) The one key disadvantage (pointed out by Zoltan Kemenczy of Research in Motion) has an easy workaround, and an even better long term solution: The issue is that if distinct record types are multiplexed to travel over the same connections, then the ports on the connection will have to be explicitly declared to be of type "general". This type is the one type we have that functions like a C-style union: Converting anything to "general" returns the same token unchanged. The long term better solution is to support true union types. -- Christopher Hylands created a test suite for the applet generator. He ran this test suite on 302 models in the demonstration suite. It took about two hours to generate applets for these models, but 10 of the models failed to generate applets. We are looking into these failures. -- Haiyang Zheng fixed a failure in the TM domain, determining that the prefire method did not update the current time correctly, and that the first TM event should be processed before the DE events. There are two times in TMDirector: the outsideTime and the currentTime. At the beginning of the prefire method, without executing any statement inside this method, the outsideTime refers the start time of current iteration, while the currentTime refers the start time of the start time of last iteration. The outsideTime is after the currentTime. The getCurrentTime() method of TMDirector returns the currentTime. When the director processes the DE events, e.g. a fireAt request from a clock, the director uses the outsideTime. When the clock fires, it calls getDirector().getCurrentTime(), which does not return the outsideTime. This mismatch of time causes the clock to stop firing. -- Christopher Hylands ported Ptolemy II to Java 1.4.2-beta, resolving a few relatively minor issues that arose. -- Tracking down an intermittent deadlock in an automated test constructed from the ordered merge demo of the process networks domain, Xiaojun Liu identified a bug in ProcessDirector.wrapup(). The stack trace showed that there were two threads trying to acquire lock on two objects in different order, resulting in the deadlock. Analyzing the PN domain code shows that deadlock is not possible in one run of the model. The problem was that ProcessDirector.wrapup() returned without waiting until all process threads (one per actor in the model) stopped. If the model was run again immediately, as was done in the test, there could be "leftover" threads that made inconsistent the internal state of ProcessDirector - specifically, by modifying the active actor count in ProcessDirector - resulting in deadlock on the second run. Adding a wait solved the problem. -- Steve Neuendorffer added an ActorToken to the data package. This token carries an actor (which may be a composite, and hence a model), and will play a major role in building higher-order components in Ptolemy II. Currently the type of an ActorToken is unspecific. The plan is to make the type of an actor contravariant between inputs and outputs, both in the number of ports and in the type of those ports. The least upper bound of all actor types is the type that has every possible input, and creates no outputs. Every actor can be lossless converted to this type by ignoring the extra inputs, and ignoring whatever the actor produces. -- Jorn Janneck added a director to Ptolemy II that realizes a fair execution policy. In each iteration, it executes those actors whose prefire() methods indicate that they are willing to be fired. Note that this director will often yield nondeterministic execution. -- Paul Yang added a Joystick actor that takes input from a joystick. -- Steve Neuendorffer added a debugging tool to the expression language that traces evaluation of a parse tree. -- Added I/O actors: + ArrayPlotter actor for displaying live, changing plots; + InteractiveShell actor for textual input and output; -- Steve Neuendorffer changed RandomSource, the base class for random signal generators, to ensure random behavior even on very fast machines. In Java, a random variable can be created using: new Random() which is equivalent to new Random(System.currentTimeMillis()) On a fast machine, more than one such random variable might be created within a millisecond, which implies then that they will have the same seed, and consequently will be perfectly correlated. -- Paul Yang and Christopher Hylands created a Joystick actor, which allows the use of a Joystick to provide inputs to a Ptolemy II model. -- Steve Neuendorffer made a clean-up pass on the 3-D graphic domain (GR), in preparation for work to add 2D graphics capabilities. Most importantly, he fixed a long standing issue with some GR actors where they were statically referencing the last viewscreen created. This made it difficult to construct models in vergil, and impossible to have multiple view screens in a model. -- We made a number of improvements to the Python interface, including making it easier to design and edit functionality for actors specified in Python and improved error reporting. -- We created a new attribute class, TextEditorFactory, which works as follows: If you put it in an actor, and set its attributeName parameter to the name of a StringAttribute of the parent, then configuring the actor brings up a text editor to edit that StringAttribute. -- Rachel Zhou has made a number of improvements to the library of communications actors. -- Christopher Hylands created a mechanism for running all demos without having to individually open them. This complements our automated test suite, permitting easy sanity checks on packages to be released. -- Christopher Hylands also created a mechanism for automatically determining which optional software packages are installed and providing appropriate copyright notices. -- We have begun using the IBM Eclipse integrated development tool, and in particular, made a number of changes in our repository so that developers get a reasonable starting point when they check out the CVS tree. -- Steve Neuendorffer modified the BasicFigure class in Diva (the graphics package on which the Ptolemy II UI is built) so that it is now possible to usefully modify the shape of the figure dynamically, taking into account the transformations to the figure. His solution is to keep track of the transformation sequence of the BasicFigure internally. He added a new method, setPrototypeShape() which specifies the shape of the figure before transformations. This method can be called to modify the shape of the figure, and the modification will then be subjected to the same transformations that had been applied to the previous figure. Study Group =========== Our quasi-weekly study group examined the following topics: -- Moses, a modeling tool from ETH, Switzerland. -- PI calculus. -- Guy Steel's paper on Growing a Language -- Constraint languages and continuous constraint languages 2. Interactions, Meetings, and Technology Transfer Presentations and Meetings ========================== * Mobies Ethereal Sting OEP: The Ptolemy II Experiment, Ethereal Sting Working Group Meeting June 10, 2003 Arlington, VA. * Simulation to Implementation: Hardware in the Loop Simulation and Code Generation, Chess Review May 8, 2003 Berkeley, CA. * Urban Traffic Light Control Modeling -- A Hybrid System Perspective Yang Zhao and Ye Zhou, Class Project Presentation, Hybrid Systems Class, May, 2003. * Implementation issues in Hybrid Embedded Systems, Stephen Neuendorffer Class Project Presentation, Hybrid Systems Class, May, 2003. Technology Transfer =================== We held the Fifth Biennial Ptolemy Miniconference, where technology developed with SEC funding was showcased together with other work. The Miniconference was held on Friday, May 9, 2003, at the Claremont Hotel, Berkeley and was attended by 90 people from 43 organizations worldwide. The presentations are available at: http://ptolemy.eecs.berkeley.edu/conferences/03/ The program included the following presentations and posters: - Project Status and Overview, Edward A. Lee, UC Berkeley - SimWORKS, A hybrid Java/C++ simulation platform, Ned Stoffel, RSoft Design - Mescal System Design Methodology, Andrew Mihal, UC Berkeley Mescal Group - Embedded S/W Development Using PTII: Modeling Extensions, Data Representation, Compilation, Zoltan Kemenczy and Sean Simmons, Research in Motion - Java Code Generation, Steve Neuendorffer, UC Berkeley Ptolemy Group - C Code Generation, Ankush Varma, Shuvra S. Bhattacharyya, University of Maryland, - JHDL Hardware Generation, Michael J. Wirthlin, Matthew Koecher, Brigham Young University - Ptolemy II and MDA, Vincent Arnould of Thales - The Ptolemy II Graph Package, Shahrooz Shahparnia, Fuat Keceli, Ming-Yung Ko,Yuhong Xiong, Jie Liu, Shuvra S. Bhattacharyya University of Maryland - The OpenModelica Project - Object-Oriented Modeling and Simulation for Continuous and Discrete-Event Systems, Peter Bunus, Peter Fritzson, Peter Aronsson, Vadim Engelson, Levon Saldamli. Linkoping University, Sweden - Embedded S/W Development Using PTII (Poster), Zoltan Kemenczy and Sean Simmons, Research in Motion - Verification of Process Networks derived from Matlab by Compaan using Ptolemy, Bart Kienhuis, Leiden University, The Netherlands - Design Space Exploration in Ptolemy, Bart Kienhuis, Leiden University, The Netherlands - Efficient and orderly co-simulation of heterogeneous computational models, Daniel Lázaro Cuadrado - Simulation to Implementation: Hardware in the Loop Simulation and Code Generation, Steve Neuendorffer, UC Berkeley Ptolemy Group - Methods for Monitoring, Benchmarking and Tuning of Ptolemy II Models' Performance, Mohamed Salem, Ellipsis Design - Using High-level Synthesis from SystemC for Architectural Exploration, John Sanguinetti, Forte Design Systems - Formal composition of web services, Xavier Warzee, Valtech Technologies/General Electric Medical Systems - JHDL Domain, Michael J. Wirthlin, Trent Vandenberghe, Brigham Young University - Image Processing in Ptolemy II, James Yeh, UC Berkeley Ptolemy Group - Distributed Ptolemy Models, Yang Zhao, Xiaojun Liu, UC Berkeley Ptolemy Group - Communications Systems Modeling in Ptolemy II, Rachel Zhou, UC Berkeley Ptolemy Group - Models of Computation in Hollywood, Chamberlain Fong, Digital Domain - Cal: An Actor Definition Language, Joern Janneck, UC Berkeley Ptolemy Group - Multiple Objetive Evolutionary Programming (MOEP), Greg Rohling, Georgia Tech - The Component Interaction Domain: Modeling Event-Driven and Demand-Driven Applications, Xiaojun Liu, Yang Zhao, UC Berkeley Ptolemy Group - TinyGALS: A Programming Model for Event-Driven Embedded Systems, Elaine Cheong, UC Berkeley Ptolemy Group - Conditional Scheduling for Giotto, Ben Horowitz, UC Berkeley Massacio Project - Plans for the Future, Edward A. Lee, UC Berkeley Ptolemy Group Other Interactions ================== * Participated in the Ethereal Sting working group meeting in Arlington, June 10, 2003. * Peter Bunus of the Modelica Project in Linköping University, Sweden, visited us in May. He gave a talk about "open Modelica" and we discussed various options for interfacing Modelica and Ptolemy II. * Dominique Ragot of Thales contributed a distributed process networks (DPN) domain to Ptolemy II. This domain supports parallel execution of Ptolemy II models on SMP machines or distributed networks. * Ernesto Wandeler of ETH Zürich, Switzerland, completed his Diploma Thesis in our group. His thesis is entitled "Static Analysis of Actor Networks" and has the following abstract: "In this thesis we present a new interface theory based approach to static analysis of actor systems. We first introduce a new interface theory, which is based on Interface Automata and which is capable of counting with natural numbers. Using this new interface theory, we can capture both, the temporal aspects of an actor interface as well as an actor’s token exchange rate. We will show, how to automatically extract this information from actors written in the Cal Actor Language (CAL). We further present a method to capture the interface information as well as the connection information of dataflow system environments into an interface automaton. In our approach, this automaton acts as glue between the actor automata of the system, and by successfully composing all actor automata with it, we can prove interface compatibility of all actors with the system environment. After successful composition, the composition automaton will contain the complete token exchange information of the composite actor system. We will extract this information into a Petri Net, which we then analyze to make statements on boundedness, deadlock as well as on the existence of legal firing sequences for the composite actor system." * Zoltan Kemenczy and Sean Simmons of Research in Motion Limited submitted an update to the Ptolemy II/MATLAB interface containing: 1) Logical variable support for Matlab version 6.5 (R13); 2) Remove (the need for) ptmatlab.dll being in the user's path; 3) Removed warnings for gcc version 3.2 (used by latest cygwins); and 4) Add support/configuration for building on Linux. 5) A method to evaluate a Matlab expression within a Ptolemy II scope. * Abhijit Bare of the Computer Networking Research Laboratory at Colorado State University reports that they have used the PtPlot graph package for plotting Reorder Density for a sequence of packets received on a network. See: http://www.engr.colostate.edu/ece/Research/cnrl/Reorder_Applet.html * Elaine Cheong attended the IPSN workshop at PARC in June (http://www.parc.com/events/ipsn03/). * The Lawrence Livermore Lab project Nuclear and Atomic Database Systems (NADS) uses the Ptolemy II plotter to display nuclear cross section and atomic data in a graphical and tabulated format. They currently display ENDL (Evaluated Nuclear Data Library), Radiation Chemistry Library and ENDFB-V (Evaluated Nuclear Data File). They have plans to expand to other cross sections, show processed data and show experimental data. * Steve Neuendorffer and Elaine Cheong attended the federated computer science conferences in San Diego, PLDI (a programming languages conference) and LCTES (an embedded systems conference). 4. Publications [1] Jie Liu and Edward A. Lee,"On the Causality of Mixed-Signal and Hybrid Models," in 6th International Workshop on Hybrid Systems: Computation and Control (HSCC '03), April 3-5, 2003, Prague, Czech Republic. [2] Stephen Neuendorffer,"Implementation Issues in Hybrid Embedded Systems", Technical Memorandum No. UCB/ERL M03/22, University of California, Berkeley, CA, 94720, USA, June 24, 2003 (with SEC). http://ptolemy.eecs.berkeley.edu/publications/papers/03/crazyboard/ [3] Stephen A. Edwards and Edward A. Lee,"The Semantics and Execution of a Synchronous Block-Diagram Language", Science of Computer Programming, Vol. 48, no. 1, July 2003. [4] Elaine Cheong,"Design and Implementation of TinyGALS: A Programming Model for Event-Driven Embedded Systems," Master's Report, Technical Memorandum No. UCB/ERL M03/14, University of California, Berkeley, CA, 94720, USA, May 23, 2003. [5] Ernesto Wandeler, "Static Analysis of Actor Networks," Technical Memorandum UCB/ERL M03/7, Swiss Federal Institute of Technology (Diploma Thesis), Zurich, Switzerland, March 2003. 5. Financial Data Provided separately on a quarterly basis by the university. Appendix ======== Ptolemy II 3.0-beta is available for download from http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII3.0. Below is the release information. Ptolemy II is a software framework developed as part of the Ptolemy project. It is a Java-based component assembly framework with a graphical user interface called Vergil. Vergil enables design of systems by block diagrams and state machine diagrams. The Ptolemy project studies modeling, simulation, and design of concurrent, real-time, embedded systems. The focus is on assembly of concurrent components. The key underlying principle in the project is the use of well-defined models of computation that govern the interactions between components. A major problem area being addressed is the use of heterogeneous mixtures of models of computation. The Ptolemy Project web page (http://ptolemy.eecs.berkeley.edu) contains much more information about the project. The work is conducted in the Department of Electrical Engineering and Computer Sciences of the University of California at Berkeley. The project is directed by Prof. Edward A. Lee. The project is named after Claudius Ptolemaeus, the second century Greek astronomer, mathematician, and geographer. Ptolemy II includes a growing suite of domains, each of which realizes a model of computation. It also includes a component library, in which most components are domain polymorphic, in that they can operate in several of the domains. Most are also data polymorphic, in that they operate on several data types. The domains that have been implemented are listed below. Some of these are preliminary and/or experimental, as indicated below. Ptolemy II 3.0 includes a HSIF to Ptolemy converter, the expression language has been reworked and the code generator updated. It also includes a set of mature and experimental domains, and a more comprehensive actor library than previous releases. Below is a text version of the web page that describes the release. ---start--- Ptolemy II 3.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 Ptolemy II Design Document describes the Ptolemy II design and the implementation of the Java classes. The "Using Vergil" chapter ( PDF - HTML) 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, * SDF: synchronous dataflow, * SR: synchronous/reactive, and * TM: timed multitasking (experimental). Platforms The core of Ptolemy II 3.0 is 100% Java, so it should work on any platform that has JDK1.4 or later We developed Ptolemy II 3.0 under Solaris 8 and Windows XP sp1 and with JDK1.4.1_02. Ptolemy II 3.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 Major Features that are new in Ptolemy 3.0 Continuous Time (CT) domain rework for improved mixed signal and hybrid systems semantics (Jie Liu, Parc, and Haiyang Zheng). Component Interaction Domain (Yang Zhao, Xiaojun Liu) - The CI domain models systems that contain both data-driven and demand-driven styles of computation. Rework of FSM domain to support chained transitions and better hybrid systems semantics (Haiyang Zheng). Expression language rework to create a full-featured, functional and higher-order expression language with extensive support for composite types such as matrices, arrays, and records; the expression language is also now fully integrated with the Ptolemy II type system (Steve Neuendorffer, Edward A. Lee). Configurations have been reworked to make it much easier to create standalone tools that extract portions of the Ptolemy II infrastructure and have customized user interfaces, documentation, and actor and director libraries. Configurations have been refactored into separate directories in $PTII/ptolemy/configs, and one example of such a standalone tool, HyVisual, is provided. Updates to Vergil, the user interface for building models (Steve Neuendorffer, Edward A. Lee, John Reekie): Run buttons on the toolbar and hotkeys. Persistent window sizing and placement. Undo/Redo. Port Parameters. vergil -help lists available configurations. Full-screen mode for use in presentations. Other user interface improvements (Steve Neuendorffer, Edward A. Lee): Interactive shells infrastructure. An interactive expression shell using this infrastructure. Infrastructure for specialized token viewers. Files with the extension .ptd are now opened by a token viewer. The default token viewers is a text editor, but others can be added in the configuration. A matrix token viewer. HSIF Support (Haiyang Zheng). The Hybrid System Interchange Format (HSIF), was developed by the Institute of Software Integrated Systems (ISIS) at Vanderbilt University as part of the ISIS MoBIES effort. The HSIF documentation states: "The goal of HSIF is to define an interchange format for hybrid system models that can be shared between modeling and analysis tools. HSIF models represent dynamic systems, whose dynamics includes both continuous and discrete behaviors." Haiyang Zheng developed a set of XSLT files that convert HSIF into MoML, the XML format used to represent Ptolemy II Models. See the HSIF/MoML documentation. A first version of higher-order components, the MultiInstanceComposite actor (Zoltan Kemenczy and Sean Simmons, Research In Motion, Ltd.). This actor creates a parameterized number of instances of a composite actor. Python integration, with a PythonScript actor that permits definition of actors in Python (Xiaojun Liu). This uses Jython, a Java implementation of Python. Other Features that are new in Ptolemy II 3.0 * Ptolemy II Matlab interface updates (Zoltan Kemenczy and Sean Simmons, Research In Motion, Ltd.): Logical variable support for Matlab version 6.5 (R13). Remove (the need for) ptmatlab.dll being in the user's path. Removed warnings for gcc version 3.2 (used by latest cygwins). Add support/configuration for building on Linux. Resources: Ptolemy II Matlab Interface Overview Java class documentation Matlab Expression Demonstration, Matlab Continuous Time Demonstration These demos require that Matlab be installed locally; they will not work within an applet, but will work with Web Start. * Code generator improvements (Steve Neuendorffer, Christopher Hylands): The Java code generator now handles Expression actors. The code generator now works with Java 1.4. The applet generator has been extended to copy necessary jar files on an as needed basis. * FunctionToken class (Xiaojun Liu, Steve Neuendorffer): An expression that defines a function can be passed among actors in a function token. * Transition Refinements: A transition in an FSM can have a refinement, which is a model that executes when the refinement is taken. * FileAttribute class (Edward A. Lee). This attribute makes it easy to create a parameter in an actor that represents a file or resource. It supports specification of files using paths relative to the model, the classpath, or the user directory. It also provides a convenient user interface for selecting and accessing files on the file system. * ImageToken class (James Yeh): An abstract token that contains images. Derived tokens such as AWTImageToken, ptolemy.actor.lib.jai.JAIImageToken provide concrete classes. * Interface to C actors using the Java Native Interface (Vincent Arnould, Thales, contributor: Christopher Hylands): The jni package contains a prototype of an interface between Ptolemy II actors and C code by using the Java Native Interface (JNI). To use this facility, you must download and install Ptolemy II from source. New Demonstrations CI: Component Interaction Router CT: Continuous Time Compared Clocks Matlab Continuous Time Demonstration HSIF Thermostat and Swimming Pool This example shows a simple thermostat modeled as a hybrid system. The purpose of the example is to demonstrate the ability that HyVisual has to import models defined in HSIF, the Hybrid System Interchange Format. To run HSIF models, you must invoke Ptolemy II with the -hyvisual command line argument or else run the HyVisual Web Edition. These models will not work in a standard Ptolemy II vergil or Web Edition because to support HSIF, we need to check xml each file to see if it is an HSIF file of a MoML file. This check slows Ptolemy II down slightly. See the HSIF/MoML documentation for details. HSIF Swimming Pool. This example shows a simple hybrid system model of a pool. Level Crossing Detector Sampled Clocks DE: Discrete Event HOC DE (New in Ptolemy II 3.0) FSM: Finite State Machine Chained Transitions Modal Binary Symmetric Channel State Tracker SDF: Synchronous Dataflow DFT Subset Fourier Series Sound Spectrum New Actors * ptolemy.actor.lib: BusAssembler (Zoltan Kemenczy, Research in Motion Limited) Assemble input port channels into output bus. BusDisassembler (Zoltan Kemenczy, Research in Motion Limited) split input bus channels onto output port channels. Rician (Rachel Zhou) An actor that outputs a random sequence with a Rician distribution. Stop (Edward A. Lee) An actor that stops a model executing when it receives a true token. ThrowException (Edward A. Lee) An actor that throws an exception when it receives a true token. ThrowModelError (Edward A. Lee) An actor that throws a model error when it receives a true token. * ptolemy.actor.lib.comm: ConvolutionalCoder (Rachel Zhou) Generate a convolutional code. DeScrambler (Rachel Zhou) Descramble the input bit sequence using a feedback shift register. HadamardCode (Rachel Zhou) Produce a Hadamard codeword by selecting a row from a Hadamard matrix. Scrambler (Rachel Zhou) Given an input bit sequence, scramble it in a pseudo random way. ViterbiDecoder (Rachel Zhou) Viterbi Decoder. * ptolemy.actor.lib.conversions: ExpressionToToken (Steve Neuendorffer) An actor that reads expressions and parses them into tokens. TokenToExpression (Steve Neuendorffer) An actor that converts tokens into expressions. * ptolemy.actor.lib.jai: Java Advanced Imaging actors (James Yeh) Actors that use the Java Advanced Imagining framework * ptolemy.actor.lib.jmf: Java Media Framework actors (James Yeh) Actors that use the Java Media Framework Backward compatibility issues Most models developed under Ptolemy II 1.0.1 or 2.0.1 or HyVisual 2.2-beta should run under Ptolemy II 3.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 2.0.1 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. Not all changes can be handled automatically, since some have semantic content. We begin with a description of the changes that are not handled, followed by a description of changes that are handled. Backward compatible issues that are not handled automatically In the CT (continuous-time) domain, instances of Clock and TriggeredClock very likely should be manually changed to ContinuousClock and TriggeredContinuousClock. The reason for this is that we have made progress on the semantics of signals with discontinuities and have improved the software implementation. We created a new set of clocks for the CT domain. ContinuousClock and TriggeredContinuousClock generate piecewise constant signals with discontinuities. The discontinuities are correctly handled regardless of step sizes, and threshold crossing detectors properly identify discrete transitions across the threshold. In principle, Clock and TriggeredClock can still be used in CT models, e.g. to generate a sequence of events, but it is better to use the EventSource actor for this purpose. In hybrid systems models (CT + FSM), the signal types for modal models may not be inferred as expected. If a modal model has both continuous and discrete signal types at its inputs, it may need manual adjustment of the output signal types. To do this, right click an output port and add a "signalType" parameter; then set the value of the parameter to "CONTINUOUS" or "DISCRETE" depending on your needs. AudioReader now uses a FileAttribute instead of a string valued parameter. The name of this parameter has changed from sourceURL to fileOrURL to conform with LineReader and ExpressionReader. Longs are now printed with a trailing capital L character. We have improved the way that the SDF (synchronous dataflow) domain implements rate propagation. Previously, SDF would infer the rates of ports of an SDF model, and create parameters named "tokenConsumptionRate" "tokenInitProduction" and "tokenConsumptionRate". However, this has two bad side effects: 1. If a port has these parameters already, then the SDF scheduler overrides them. This may not be correct. 2. If a port has these parameters already, then running a model will mark it dirty, resulting in a prompt to save the model on exit. We've changed this so that it sets these values only if the parameters do not exist already, and stores them in new attributes called "_tokenConsumptionRate" "_tokenInitProduction" and "_tokenConsumptionRate". These are transient (instances of Variable rather than Parameter), so they will not trigger a prompt to save. Backward compatible issues that are handled automatically ptolemy.moml.filter.AddEditorFactory: If a parameter has a _location, then add a VisibleParameterEditorFactory named _editorFactory. This supports double clicking on visible parameters. ptolemy.moml.filter.AddIcon: Add specialized icons that display in Vergil the value of one of the parameters or certain actors. The affected actors are: ptolemy.actor.lib.Const ptolemy.actor.lib.MathFunction ptolemy.actor.lib.TrigFunction ptolemy.actor.lib.Scale ptolemy.actor.lib.Expression ptolemy.moml.filter.ClassChanges: change class names that have been renamed or moved to a different package. The changes are: ptolemy.kernel.util.VersionAttribute -> ptolemy.kernel.attributes.VersionAttribute ptolemy.moml.Location -> ptolemy.kernel.util.Location ptolemy.actor.lib.comm.SerialComm -> ptolemy.actor.lib.io.comm.SerialComm ptolemy.moml.filter.HideAnnotationNames: If an annotation name ends with 'annotation1', then add _hideName if necessary. This prevents labels from appearing above visible parameters in Vergil. ptolemy.moml.filter.ParameterNameChanges: Update any Parameter names that have been changed. Below are the actors that are affected, along with the Parameter name and the new name: ptolemy.domains.pn.kernel.PNDirector Initial_queue_capacity -> initialQueueCapacity ptolemy.moml.filter.PortNameChanges: Update any actor port names that have been changed. Below are the actors that are affected, along with the old port name and the new port name: ptolemy.actor.lib.conversions.CartesianToComplex imag -> y real -> x ptolemy.actor.lib.Sleep delay -> sleepTime ptolemy.actor.lib.conversions.ComplexToCartesian imag -> y real -> x ptolemy.moml.filter.PropertyClassChanges: Update any actor port class names that have been changed. Below are the actors that are affected, along with the port name and the new classname: ptolemy.domains.sdf.lib.vq.HTVQEncode input -> ptolemy.actor.TypedIOPort output -> ptolemy.actor.TypedIOPort ptolemy.domains.sdf.lib.vq.VQDecode input -> ptolemy.actor.TypedIOPort output -> ptolemy.actor.TypedIOPort ptolemy.domains.sdf.lib.vq.ImagePartition input -> ptolemy.actor.TypedIOPort output -> ptolemy.actor.TypedIOPort ptolemy.domains.sdf.lib.vq.ImageUnpartition input -> ptolemy.actor.TypedIOPort output -> ptolemy.actor.TypedIOPort ptolemy.actor.lib.Expression expression -> ptolemy.kernel.util.StringAttribute Limitations Version 3.0 has the following limitations: Release Limitations * 3.0-beta issues + The following documentation has not yet been updated for 3.0: Using Vergil, the Expressions documentation + The Design Document is not included in 3.0-beta, we will include it in the production release of 3.0 * The gzipped tar file that contains the Ptolemy II distribution requires GNU tar or WinZip. Solaris 2.5.1 tar will fail to untar this file with a checksum error because the pathnames are longer than 100 characters. If you do not have GNU tar, you can obtain source and selected binaries from ftp://ptolemy.eecs.berkeley.edu/pub/gnu. Note further that some of the .class names are longer than 31 characters, which may cause problems when downloading zip files on the Macintosh and using Stuffit. * The documentation for custom actors used in demonstrations is not included in the release. The source code for the custom actors can be found in the source download. * If a URL ends with #in_browser, then Ptolemy II will invoke the User's web browser. Unfortunately, this does not always work, especially under Windows if Netscape is already running. The workaround is to exit Netscape and let Ptolemy II start up Netscape for you. * Web Start does not work very well if the pathname to the vergil.jnlp file has spaces in it. The workaround is to place your Ptolemy II tree in a directory that does not have spaces in the path name if you plan on using Web Start. * Applet issues: + We've experienced problems with the browser freezing when between applets. What happens is that the previous applet gets a InterruptedException and pops up a modal dialog box, which freezed the browser. We are working on a solution. + The Ptolemy II Applets require Java 1.4.1_02 so as to prevent problems with Windows XP and Radeon displays that causes XP to hang when a Java application is exiting. For details, see http://developer.java.sun.com/developer/bugParade/bugs/47 13003.html For non-applet situations, we can invoke the browser with -Dsun.java2d.d3d=false or -Dsun.java2d.noddraw=true, but for applets we must require Java 1.4.1_02 or later. As a result, the applet html code requires version 1.4.1_02, so if you have 1.4.2 installed, you may need to reinstall the 1.4.1_02 JRE for the applets to work. + Applets seem to run out of memory after about 82Mb. + There are no Jython or Cal applets + Opera has problems viewing applets that are on the local file system. In particular, it seems to have problems with urls like file:///d|/ptII/ptolemy/plot/demo/FourierSeries.htm which work fine in Netscape 4.x, IE, Mozilla. However, if I use the following style of URL, then some of the applets work: file://localhost/d:/ptII/ptolemy/plot/demo/FourierSeries.htm. Unfortunately any applet that accesses a data file will not work with the above URL style because the data file will be outside the codebase. The solution is to install a web server on the local machine and view the applets using http://localhost/ + Opera 6.03/Windows 2000/Java 1.4.0, may have problems running applets that include diva.jar if diva.jar is not downloaded in the first applet. To reproduce this problem: 1. Run SDF Butterfly, which does not use diva.jar 2. SDF Expression, which uses diva.jar 3. In Opera, do Window -> Special -> Java Console, and you will see the following stack trace java.lang.NoClassDefFoundError: diva/graph/GraphController at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1576) at java.lang.Class.getConstructor0(Class.java:1748) at java.lang.Class.newInstance0(Class.java:266) at java.lang.Class.newInstance(Class.java:249) at opera.PluginPanel.run(opera/PluginPanel.java:343) at java.lang.Thread.run(Thread.java:536) The problem only occurs under Opera. + Running the Networked demo via an applet on the local file system results in an AccessControlException. com.microstar.xml.XmlException: XML element "entity" triggers exception: java.lang.Exception: Attempted to lookup 'Waveform', but got: java.lang.ClassNotFoundException: Waveform Attempted to find as a moml class, but got: java.security.AccessControlException: access denied (java.net.SocketPermission ptolemy.eecs.berkeley.edu resolve) in file:/C:/Program Files/Ptolemy/Ptolemy II 3.0 beta2/ ptolemy/moml/demo/Networked/ at line 62 and column 118 The Network demo does not work as a local applet because the xml file includes a reference to http://ptolemy.eecs.berkeley.edu, which is not on the local file system, so we get a SecurityException. The workaround is to run the applet by downloading it from the Ptolemy Website: http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII3.0/ptII3. 0/ptolemy/moml/demo/Networked/Networked.htm * Windows Installer Issues: + 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. + Sometimes running a model that uses the Matlab interface will cause Ptolemy II to exit. We are not sure why. + The Windows task bar shows a 'Launch Anywhere' icon instead of a Vergil Icon. + The Cal facility does not work because Cal requires saxon7.jar yet having saxon7.jar in the classpath causes problems for the Hyvisual HSIF to MoML converter. * Web Start issues: + The Python Ptolemizer demo does not work under Web Start, probably because Jython cannot handle loading classes from the Ptolemy II classes. + Viewing a pdf file may bring up a blank window along with the pdf file. Running the code generator may bring up a blank window while the java or javac processes are running. + Some of the links on the GR domain instructions page might not work under Web Start because the files they refer to are not present. * Limitations in demonstrations + CT CarTracking should be run using View->Run so that the user can change the fault parameter. + HTVQ demo: The displays do not go away when the demo is exited. + GR demos: The ViewScreen actor does not go away when the demo is exited. + GR demos: Under Java 3D 1.3.1-beta, the ViewScreen actor may display a black image when a second GR demo is run. The workaround is to install Java 3D 1.2.1_04. + Bouncer demo: If the user drags the bouncing icon, it no longer bounces + TM Merged Events: Clicking on the 'Plot Schedule' icon brings up a plot, but the plot remains empty, the schedule never appears 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 readFile() parameter function does not work with applets. * 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. * 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. 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. Limitations in the User Interface Below are some of the limitations of Vergil, the Ptolemy II Graphical User Interface. * If there are multiple windows open for a model, say, the top level vergil window and the tree view, or the top level window and the inside look of a composite component, when the top level window is closed, all other windows are closed, but the user is not prompted to save any change to the model. * When setting the type of a port, we should provide a combo box that lists the common ports * When creating a Modal Model, use Control-Right-Button to drawn arcs between nodes. One potential workaround would be to have an information message in the status bar about this. * You should not change the names of built in ports - The port mechanism should disallow port name changes on ports that are named in Java. The UI could recognize this. The UI should not allow the user to remove built in Java defined ports. * Manually setting of the types of actors like ArrayToSequence that have constraints on their element types can cause problems. * HTVQ demo is badly laid out when run under vergil. * Weak support for multiports in the graph editor. * It is difficult to control wire routing. * Cannot have more than one vertex in a connection. * No mechanism to set the width of a relation. * The integrated web browser is not a full-featured browser. * Icon editor not yet integrated. * Debugger not yet integrated. * It is difficult to add actors to the libraries. * No dynamic class reloading. 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 3.0 website Last Updated: $Date$ --end--