Edward, We implemented a "MultiContextComposite" some time ago and use it to create multiple instances of the same model (e.g. "logical channels" of "network protocols"). In such a case, one would want to create N instances of the same model and as data arrives, route data to a particular (or all) instance(s) determined by some data element. This is a specialized form of HOF tailored towards the current PTII gui and execution environment.
We have separated the problems of creating multiple instances (MultiContextComposite) from the problem of data routing to a particular instance (MultiContextController) and each may be used independently from the other. Below I will outline the behaviour of MultiContextComposite. If what's outlined below sounds as an acceptable approach, we would be happy to contibute the code to PTII. MultiContextComposite is derived from TypedCompositeActor and as such automatically supports all PTII vergil gui interactions as TypedCompositeActor. One has one predefined parameter, "nContext" that determines the number of instances (clones) to be created from the master. The master model is created using vergil in the same way as a TypedCompositeActor is created. MultiContextComposite input ports must not be multiports (for now) and may be connected to multiports or regular ports. During its preinitialize(), the master MultiContextComposite determines how its input ports are connected and creates additional relations in its container (the model it is embedded in) to connect the input ports of its clones (instances) to the same output port if that port is a multiport. If the output port is a regular port, the clones input port is linked to the already existing relation between the output port and the master's input port. MultiContextComposite output ports must not be multiports (for now) and must be connected to input multiports. The master MultiContextComposite creates additional relations to connect the output ports of its clones to the input port. Finally, after all these connections are made, the master's preinitialize() calls preinitalize() of the clones. >From here on until wrapup() nothing special is needed. Type resolution to occur on all instances in the modified model, so does initialize(), the computation of schedules by directors of the master and clones, etc. We typically connect MultiContextComposite outputs to a Merge actor in the DE domain. Alternatively in SDF, one can use MultiContextComposite with Distributors and Commutators. During model wrapup(), the master MultiContextComposite deletes any relations created, unlinks any ports if needed, and deletes the clones it created. To re-sync vergil's model graph, a changerequest is also queued with the Manager. That's it... The description is almost as long as the code... :-) As far as MultiContextController is concerned, in general, it is similar to a Switch actor without a control input. Instead, the control value is computed based on input data. In our case, we use a (configurable) RecordToken fieldname (int-typed) that is looked up in the input RecordToken to determine which output channel (MultiContextComposite instance) to route data to. Regards, Zoltan Kemenczy Research in Motion Limited (www.rim.net) 305 Phillip St, Waterloo, Ontario Canada N2L 3W8 > -----Original Message----- > From: Edward A. Lee [mailto:[EMAIL PROTECTED]] > Sent: July 30, 2002 3:13 PM > To: Christopher Hylands > Cc: [EMAIL PROTECTED] > Subject: Re: [Ptolemy] Re: higher order functions in Ptolemy II > > > > > > >From: [EMAIL PROTECTED] (Marcus Pang) > >Subject: higher order functions in Ptolemy II > >Date: 26 Jul 2002 14:02:56 -0700 > > > >I'd like to know if anyone has done any work on higher-order > functions > >in Ptolemy II. Does anyone know if this is in Berkeley's to-do list? > > > >Thanks. > >Marcus Pang > > Marcus: > > This has been high on my "to do" list for some time, but I haven't > found the time myself. Several in the group have talked about > work in this direction, but I'm not aware of anything concrete > that has happened yet. I would welcome some help with this. > > We could realize this pretty much exactly as in Ptolemy Classic, > but there is one additional feature of Ptolemy II that suggests some > richer possibilities. In Ptolemy II, models can be modified > during an execution. Thus, one could build more dynamic HOF > mechanisms. > Our plan (if we ever get the bandwidth) is to implement in a > ModelToken, which is a token that carries a model, a createModel() > function in the expression language (that takes a filename or URL > as an argument). Then, for example, an Apply actor would apply > a set of inputs to a specified model. The model could be given > by a parameter or input port (using the new PortParameter mechanism). > > Also, I would like to explore alternative visual representations... > E.g., we could modify Look Inside for the Apply actor so that it > shows the most recently seen model. > > Edward > > > > ------------ > Edward A. Lee, Professor > 518 Cory Hall, UC Berkeley, Berkeley, CA 94720 > phone: 510-642-0455, fax: 510-642-2739 > [EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal > > > -------------------------------------------------------------- > -------------- > Posted to the ptolemy-hackers mailing list. Please send > administrative > mail for this list to: > [EMAIL PROTECTED] > ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
