TOC PREV NEXT

2.8 Higher-Order Components

Ptolemy II includes a number of higher-order components, which are actors that operate on the structure of the model rather than on data. This notion of higher-order components appeared in Ptolemy Classic and is described in [88], but the realization in Ptolemy II is more flexible than that in Ptolemy Classic. These higher-order components help significantly in building large designs where the model structure does not depend on the scale of the problem. In this section, we describe a few of these components, all of which are found in the HigherOrderActors library. The ModalModel actor is described below in section 2.10, after explaining some of the domains that can make effective use of it.

2.8.1 MultiInstance Composite

Consider the model in figure 2.37, which has five instances of the Channel class wired in parallel. This model has the unfortunate feature that the number of instances is hardwired into the diagram. It is awkward, therefore, to change this number, and particularly awkward to create a larger number of instances. This problem is solved by the MultiInstanceComposite actor1. A model equivalent to that of figure 2.37 but using the MultiInstanceComposite actor is shown in figure 2.45. The MultiInstanceComposite is a composite actor into which we have inserted a single instance of the Channel (this is inserted by creating an instance of the of Channel, then copying and pasting it into the composite).

The MultiInstanceComposite actor has two parameters, nInstances and instance, shown in figure 2.46. The first of these specifies the number of instances to create. At run time, this actor replicates itself this number of times, connecting the inputs and outputs to the same sources and destinations as the first (prototype) instance. In figure 2.45, notice that the input of the MultiInstanceComposite is connected to a relation (the black diamond), and the output is connected directly to a multiport input of the AddSubtract actor. As a consequence, the multiple instances will be wired in a manner similar to figure 2.37, where the same input value is broadcast to all instances, but distinct output values are supplied to the AddSubtract actor.

The model of figure 2.45 is better than that of figure 2.37 because now we can change the number of instances by changing one parameter value. The instances can also be customized on a per-instance basis by expressing their parameter values in terms of the instance parameter of the MultiInstanceComposite. Try, for example, making the noisePower parameter of the InstanceOfChannel actor in figure 2.45 depend on instance. E.g., set it to "instance * 0.1" and then set nInstances to 1. You will see a clean sine wave when you run the model.

2.8.2 IterateOverArray

The implementation of the Channel class, which is shown in figure 2.42, happens to not have any state, meaning that an invocation of the Channel model does not depend on data calculated in a previous invocation. As a consequence, it is not really necessary to use n distinct instances of the Channel class to realize a diversity communication system. A single instance could be invoked n times on n copies of the data. We can do this using the IterateOverArray higher-order actor.

The IterateOverArray actor can be used in a manner similar to how we used the MultiInstanceComposite in the previous section. That is, we can populate it with an instance of the Channel class, similar to figure 2.45. Just like the MultiInstanceComposite, the IterateOverArray actor requires a director inside. An implementation is shown in figure 2.47 . Notice that in the top-level model, instead of using a relation to broadcast the input to multiple instances of the channel, we create an array with multiple copies of the channel input. This is done using a combination of the Repeat actor (found in the FlowControl library, SequenceControl sublibrary) and the SequenceToArray actor (found in the Array library). The Repeat actor has a single parameter, numberOfTimes, which in figure 2.47 we have set equal to the value of the diversity parameter that we have added to the model. The SequenceToArray actor has a parameter arrayLength that we have also set equal to diversity (this parameter, interestingly, can also be set via the arrayLength port, which is filled in gray to indicate that it is both parameter and a port). The output is sent to an ArrayAverage actor, also found in the Array library.

The execution of the model in figure 2.47 is similar to that of the model in figure 2.45, except that the scale of the output is different, reflecting the fact that the output is an average rather than a sum.

The IterateOverArray actor also supports dropping into it an actor by dropping the actor onto its icon. The actor can be either an atomic library actor or a composite actor (although if it is composite actor, it is required to have a director). This mechanism is illustrated in figure 2.48 . When an actor is dragged from the library, when it is dragged over the IterateOverArray actor, the icon acquires a white halo, suggesting that if the actor is dropped, it will be dropped into the actor under the cursor, rather than onto the model containing that actor. When you look inside the IterateOverArray actor after doing this, you will see the class definition. Add an SDFDirector to it before executing it.

2.8.3 Mobile Code

A pair of (still experimental) actors in Ptolemy II support mobile code in two forms. The MobileFunction actor accepts a function in the expression language (see the Expression Language chapter) at one input port and applies that function to data that arrives at the other input port. The MobileModel actor accepts a MoML description of a Ptolemy II model at an input port and then executes that model, streaming data from the other input port through it.

A use of the MobileFunction actor is shown in figure 2.49 . In that model, two functions are provided to the MobileFunction in an alternating fashion, one that computes and the other that computes . These two functions are provided by two instances of the Const actor, found in Sources, GenericSources. The functions are interleaved by the Commutator actor, from FlowControl, Aggregators.

2.8.4 Lifecycle Management Actors

A few actors in the HigherOrderActors library provide in a single firing the entire execution of another Ptolemy II model. The RunCompositeActor actor executes the contained model. The ModelReference actor executes a model that is defined elsewhere in its own file or URL. The VisualModelReference actor opens a Vergil view of a referenced model when it executes a referenced model. These actors generally associate ports (that the user of the actor creates) with parameters of the referenced or contained model. They can be used, for example, to create models that repeatedly run other models with varying parameter values. See the documentation of the actors and the demonstrations in the quick tour for more details.
1 The MultiInstanceComposite actor was contributed to the Ptolemy II code base by Zoltan Kemenczy and Sean Simmons, of Research In Motion Limited.

TOC PREV NEXT